alembic not picking up baked in material when rendering subdivided

[ronald_a]

Hi,

when baking the materialpath into an alembic, the material will not be picked up when the alembic is rendered as subdivision. I can provide a scene if necessary, but this should be easy to replicate.

[glacierise]

You mean shop_materialpath is an attribute of the unpacked polygons? This hasn't worked well for me, rather we've exploited the alembic user properties path to translate packed primitive attributes to alembic user properties and then back. Of course, with changing shader paths in new scenes you need to repath the shaders to a new location, so we have an extra HDA for that.

[ronald_a]

what I mean is:

geo --> apply material (sop) --> create abc (shop_materialpath is now baked into the alembic (with all its pros and cons like the shader path beeing fix, but thats ok for us). loading abc back in (shader path matches). when rendering (without subdiv) it work (needs forced material). as soon as I render the abc as subdivision (set on obj level) the material is not picked up. I'm not sure if this has worked in vray4 but it does not in vray5.

what do mean with alembic user properties path? can you explain your workflow?

[bdancer]

> as soon as I render the abc as subdivision (set on obj level) the material is not picked up.

Same issue with PatternID... This will be very time consuming implementation, I'll try to implement this asap...

[david.anastacio]

You can get around this by using the shop_materialpath as the path that alembics are written with, then in the alembic read node, instead of using the path as the path attribute use shop_materialpath. This way you hack the material path to be "live" in your primitives automatically. I think this is kind of what Hristo was suggesting, but not sure.
We used several times and no need to force materials or anything else, just don't change the object names.

Best,
David.

[ronald_a]

david.anastacio thanks for the advice, and we have done so already. But every now and then we want the alembic primitives to be split up differently than the material assignment. So this is good for some cases but not for all. I am actually not sure if Hristo meant that because there is actually a user properties drop down menue in the attributes section of the alembic sop. Not sure how to use that, though.

[daeschri]

You can also hack the path the store multiple attributes before write and then conform them right after reading.

This way in houdini the path will ultimately remain as expected but then you have access to other attributes that would normally be stored but not available unless unpacked.

For example In this workflow you can append | after the path with desired attributes following.




As soon as you read in the packed alembic you conform the path back to its original value and split out the other attributes with a simple wrangle.




For the needs at the studio we just use two hdas to do this logic for us.


There is something to consider when doing this workflow, and that's only if you are going into an external DCC

If you were to read in the modified path alembic in Maya for example you will still see the proper scene hierarchy too as it disregards anything after the | character.
However the shape node names are no longer accurate. They default to polySurfaceShape. So we ended up using a tool to rename those shape names if we have to use this alembic in maya too.


For staying all in Houdini this has worked wonderfully so far.


David

[glacierise]

We're also using this path approach - divide using some token, like /RBD/ and then after load split using this, so several useful pieces.

We also wrote a HDA that encodes prim attributes to alembic user properties, and then decodes on load these to prim attributes, using the info from here:https://www.sidefx.com/forum/topic/70783/

You need to add one more thing - retargeting of the shader root, because the shader path in the saved shop_materialpath is absolute, and in the new scene the path might be different. That's quite easy, strip the shader path from all but the last leaf, and prefix with the new path

[ronald_a]

Thanks Hristo and David, that all makes sense. While I still think that my initial issue should be fixed, these approches are certainly something we will pick up.