Request ; Random Per island Node

Use this forum for general user support and related questions.
User avatar
B.Y.O.B.
Developer
Posts: 3344
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Request ; Random Per island Node

Post by B.Y.O.B. » Tue Mar 17, 2020 11:37 am

Dade wrote:
Tue Mar 17, 2020 10:36 am
I can write shape that can assign vertex colors based on this "island" concept. It is something to do as pre-processing because, indeed, I can not establish what is an "island" at run-time (during the rendering).

I could introduce this "island" concept in general: does Blender has this mesh information ? Can it be exported ?
Here is the Cycles implementation: https://github.com/sobotka/blender/blob ... h.cpp#L662
They also compute it as a pre-processing step.

I'm not sure cramming more and more features into vertex colors is a good idea. From a user point of view, it leads to weird situations: "why are my vertex colors no longer working when I use the random per island node somewhere else in my shader setup?"
However I'm aware that on the other hand, adding more attributes to mesh vertices and/or the HitPoint struct has drawbacks as well.

Benny
Posts: 7
Joined: Mon Mar 16, 2020 1:34 pm

Re: Request ; Random Per island Node

Post by Benny » Tue Mar 17, 2020 11:53 am

With this new node Random Per island you can for example do the same like Fstorm :
1). Random color variation : https://fstormrender.ru/manual/randomcolor/
2), Random bump /offset texture / rotation etc.... https://fstormrender.ru/manual/fstorm-bitmap/
3). Random scale noise texture etc...
4). Shaderswitch to assign random texture etc...

User avatar
Dade
Developer
Posts: 3891
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Request ; Random Per island Node

Post by Dade » Tue Mar 17, 2020 12:15 pm

B.Y.O.B. wrote:
Tue Mar 17, 2020 11:37 am
I'm not sure cramming more and more features into vertex colors is a good idea. From a user point of view, it leads to weird situations: "why are my vertex colors no longer working when I use the random per island node somewhere else in my shader setup?"
However I'm aware that on the other hand, adding more attributes to mesh vertices and/or the HitPoint struct has drawbacks as well.
I could:

1) introduce TRIANGLE_ID, an arbitrary per triangle ID (like OBJECT_ID but with one for each triangle in a mesh instead of one for each object/mesh).

2) add a new HitPointTriangleIDTexture texture; like HitPointColorTexture, HitPointAlphaTexture, etc. but it will pick the TRIANGLE_ID of the hit point as input and the output can be used in any type of texture node tree. It can also have a random option to take the ID as seed of a random number generator and produce a random float or RGB. In order to simplify the process used by Sharlybg in his previous post.

3) add a shape to set TRIANGLE_ID on the per "island" base.

This would a quite generic implementation, solving the problem of this thread, but also opening the door to many other tricks (i.e. we can add many types of shape to set TRIANGLE_ID to whatever we want).
Support LuxCoreRender project with salts and bounties

Oscar9531
Posts: 21
Joined: Sat Oct 05, 2019 3:42 am

Re: Request ; Random Per island Node

Post by Oscar9531 » Tue Mar 17, 2020 12:40 pm

This will be so cool to see!

User avatar
B.Y.O.B.
Developer
Posts: 3344
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Request ; Random Per island Node

Post by B.Y.O.B. » Tue Mar 17, 2020 12:40 pm

This sounds like the TRIANGLE_ID would be present on every triangle, even when not needed. Assuming it is a 4-Byte unsigned int, it would add 4 MB per 1 million triangles. This is not too terrible, but it means for example 120 MB more memory usage in a 30 Mio. triangle scene (which is quite low-poly in professional productions). And I will be assuming that most of these TRIANGLE_IDs will not be actually used in a shader, but the price is paid nonetheless.

Also, once you re-use the TRIANGLE_ID for other stuff, you run into the same problem as with vertex colors: There will be a set of features that has an XOR behaviour, and it will be very hard for users to understand which of these features turn off another feature when used.

Would it be possible instead to add arbitrary data "channels" to a mesh which would only use memory when actually in use?
Sort of like the multiple UV maps/vertex colors. Of course there could be a maximum of these arbitrary channels.
We could then offer shapes to write pointiness, per island ID etc. into these channels, or the client program could actually fill them with any data it wants. We would just need a way to access them in shaders, e.g. with an index.

User avatar
Dade
Developer
Posts: 3891
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Request ; Random Per island Node

Post by Dade » Tue Mar 17, 2020 1:20 pm

B.Y.O.B. wrote:
Tue Mar 17, 2020 12:40 pm
This sounds like the TRIANGLE_ID would be present on every triangle, even when not needed. Assuming it is a 4-Byte unsigned int, it would add 4 MB per 1 million triangles. This is not too terrible, but it means for example 120 MB more memory usage in a 30 Mio. triangle scene (which is quite low-poly in professional productions). And I will be assuming that most of these TRIANGLE_IDs will not be actually used in a shader, but the price is paid nonetheless.
No, additional vertex and triangle attributes are already optional: if you don't use vertex normals, vertex colors, etc. the memory is not allocated. It would be the same for TRIANGLE_ID.
B.Y.O.B. wrote:
Tue Mar 17, 2020 12:40 pm
Also, once you re-use the TRIANGLE_ID for other stuff, you run into the same problem as with vertex colors: There will be a set of features that has an XOR behaviour, and it will be very hard for users to understand which of these features turn off another feature when used.
Like with vertex UVs, we can introduce the support for multiple sets.
B.Y.O.B. wrote:
Tue Mar 17, 2020 12:40 pm
Would it be possible instead to add arbitrary data "channels" to a mesh which would only use memory when actually in use?
It is already like that, it is just the type of supported channels to be static: they can, or can not, be defined but their number is fixed and static. So it is more about the API than the internal support: we need to change the API to be extensible and accept any number of vertex and triangle attributes.

For instance, instead of having a DefineMesh() with a fixed number of arguments, we can define the base mesh and than add more vertex and triangle attributes with some additional call to a AddMeshVertexAttribute() or AddMeshTriangleAttribute() :idea:
Support LuxCoreRender project with salts and bounties

User avatar
B.Y.O.B.
Developer
Posts: 3344
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Request ; Random Per island Node

Post by B.Y.O.B. » Tue Mar 17, 2020 1:54 pm

Dade wrote:
Tue Mar 17, 2020 1:20 pm
No, additional vertex and triangle attributes are already optional: if you don't use vertex normals, vertex colors, etc. the memory is not allocated. It would be the same for TRIANGLE_ID.
Ah yes, I forgot about that.
However, the HitPoint struct would grow, and since the OpenCL HitPoint is no longer of variable size, this would mean more memory usage on GPUs?
If we do an array of arbitrary channels, it would mean only one additional pointer in the HitPoint struct.

juangea
Donor
Posts: 107
Joined: Thu Jan 02, 2020 6:23 pm

Re: Request ; Random Per island Node

Post by juangea » Tue Mar 17, 2020 1:59 pm

That could help with deformable mesh motion blur for example?

Having arbitrary properties that can be used by shaders and other things is super powerful I think :)

User avatar
Dade
Developer
Posts: 3891
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Request ; Random Per island Node

Post by Dade » Tue Mar 17, 2020 5:12 pm

B.Y.O.B. wrote:
Tue Mar 17, 2020 1:54 pm
However, the HitPoint struct would grow, and since the OpenCL HitPoint is no longer of variable size, this would mean more memory usage on GPUs?
If we do an array of arbitrary channels, it would mean only one additional pointer in the HitPoint struct.
My idea, at this point, is to remove all pre-computed values from HitPoint structures and compute them on-and-the-fly and on-demand inside the textures code. This would also reduce the HitPoint structure size by a lot.

The disvantage is that, in some case, the same value would be computed multiple times: for instance if two textures use the same UV coordinates, the UV values will be interpolated 2 times. However, interpolating an UV value between 3 vertices costs something like 3 multiplications so I doubt it will be even vaguely noticeable.

Is having multiple normals for vertex useful ? Is it the Blender split-normal thing ? I'm thinking to what can have multiple values and what no.

Single set:

1) vertex position (mandatory);
2) triangle vertex indices (mandatory);
3) vertex normal (optional);

Multiple sets:

1) vertex color (optional);
2) vertex alpha (optional);
3) vertex uv (optional);
4) triangle ID (optional);
Support LuxCoreRender project with salts and bounties

User avatar
B.Y.O.B.
Developer
Posts: 3344
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Request ; Random Per island Node

Post by B.Y.O.B. » Tue Mar 17, 2020 5:35 pm

Dade wrote:
Tue Mar 17, 2020 5:12 pm
Is having multiple normals for vertex useful ? Is it the Blender split-normal thing ?
No, I don't think we need multiple normals per vertex.
Custom normal support does not require this.

Post Reply