You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was brought up again recently that having any kind of constant attribute that is derived from a point-cloud onto instances would be great to have, that isn't applied onto the mesh but onto the object itself so that it doesn't break instancing (eg. not having to make the whole geometry unique so that one constant value can be unique). Currently the solutions in Cycles are very much tied to how Blender applies the data:
These are generated in particle_system arrays that get their pointers attached to objects and given an index number, so these also won't break instancing and can be accessed from the particle_info shader.
For OSL, I believe that this is all just using get_attribute() so it's not really any difference where the data is coming from from a shader point of view (double-check me on that though).
I propose that we apply a much more generic way of specifying point cloud array data that is referenced into objects to not be tied to hard-coded Blender-isms (so it's all just seamlessly accessed via the attribute shader also). For backwards-compatibility, we can reserve these names above so that the existing shaders can still work.
It was probably designed this way when the old way of applying point-clouds was to just take advantage of the instancing system to create actual sphere geometry, but now that proper point-cloud support is coming in, we could do better here and make a more generic approach that aligns better with USD and other renderers.
The text was updated successfully, but these errors were encountered:
It was brought up again recently that having any kind of constant attribute that is derived from a point-cloud onto instances would be great to have, that isn't applied onto the mesh but onto the object itself so that it doesn't break instancing (eg. not having to make the whole geometry unique so that one constant value can be unique). Currently the solutions in Cycles are very much tied to how Blender applies the data:
https://github.com/tangent-opensource/cycles/blob/master/src/render/object.h#L49
Some of these can be accessed by the object_info shader and some of the texture mapping inputs, we could use dupli_generated/dupli_uv as our own offsets into textures (which I assume is what they're for) for our own purposes, and with particle_system:
https://github.com/tangent-opensource/cycles/blob/master/src/render/particles.h#L32
These are generated in particle_system arrays that get their pointers attached to objects and given an index number, so these also won't break instancing and can be accessed from the particle_info shader.
For OSL, I believe that this is all just using get_attribute() so it's not really any difference where the data is coming from from a shader point of view (double-check me on that though).
I propose that we apply a much more generic way of specifying point cloud array data that is referenced into objects to not be tied to hard-coded Blender-isms (so it's all just seamlessly accessed via the attribute shader also). For backwards-compatibility, we can reserve these names above so that the existing shaders can still work.
It was probably designed this way when the old way of applying point-clouds was to just take advantage of the instancing system to create actual sphere geometry, but now that proper point-cloud support is coming in, we could do better here and make a more generic approach that aligns better with USD and other renderers.
The text was updated successfully, but these errors were encountered: