Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constant attributes on instanced objects for shader access #37

Open
boberfly opened this issue Apr 23, 2021 · 0 comments · May be fixed by #91
Open

Constant attributes on instanced objects for shader access #37

boberfly opened this issue Apr 23, 2021 · 0 comments · May be fixed by #91
Labels
enhancement New feature or request

Comments

@boberfly
Copy link
Contributor

boberfly commented Apr 23, 2021

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

uint random_id;
int pass_id;
float3 color;

float3 dupli_generated;
float2 dupli_uv;

ParticleSystem *particle_system;
int particle_index;

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

int index;
float age;
float lifetime;
float3 location;
float4 rotation;
float size;
float3 velocity;
float3 angular_velocity;

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.

@boberfly boberfly added the enhancement New feature or request label Apr 23, 2021
@dedoardo dedoardo linked a pull request Jul 20, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant