Jump to content
michaelb-01

Attribute-based object visilibity

Recommended Posts

I wasn't entirely sure what to call this as its quite a complex task..

 

Basically, lets say I have a faceted spehere with some boxes around it. I want to create a primitive attribute on my faceted sphere which corresponds to an id stored on each box and will essentially tell the shader which box it should render. So maybe 'attribute-based object linking' is more appropriate.. Is this possible?

 

In my head I was thinking I could create a shader for the sphere and inside send a test ray to check what this interescts with, if the object id that it hits corresponds with the sheres primitive id that the ray came from then render this object, if not then ignore this object and carry on pathtracing... This would need to be done for reflection and refraction.. Possible?

Share this post


Link to post
Share on other sites

Hi MichaelB,

 

Does it have to happen on the shader level or can it just group geo (by attribute) then use the occlude objects field on the MantraROP?

 

So the boxes carry an id. you want to assign each facet of the sphere a number, but then the facets drive the render visibility of the boxes.

Scene might help.

 

You can move attributes from close objects by doing a ptcloud thing in a vop or easily with attribute transfer. If you transfer an attribute

to a chain, then you can group the geo to remove it from the render.

 

-KF

Edited by kungFu

Share this post


Link to post
Share on other sites

are the boxes supposed to be visible to the camera depending upon this objectid?  or is this JUST for secondary rays?

 

presumably each facet on you sphere has a different objectid to trace for, yeah?

 

for that to work, you'd need to roll your own raytracer in the shader on your sphere.  you'd also need to export the objectid from the shaders on your boxes.  the sphere trace would need to query the objectid from the boxes and continue the trace if it doesn't match the id it's looking for (continue the trace = call trace again from the current hit point and in the same direction).  you'd should make your objectid's start with 100 or something so you can easily detect when the trace hits an object that doesn't know anything about the objectid.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×