Hi,

mucking around with g splats in h22 and noticed something. I've been copying the workflow from the wasp.hip to animate a g splat - one downloaded rather than created in Houdini. I needed to scale the splat to fit the skeleton. But when I scale the gplat or the points before the bakegplat node it doesn't render properly in Karma - it sort of fades out.

This is also the case with the wasp rig itself - when rendered in karma xpu.

I have a feeling this is something to do with how gplats work - but I don't know.

I can rotate translate etc without it affecting the render but scaling messes it up.

Am I missing something or do I have to always work at the scale the gplat comes in.

Attached are images of the wasp rendered in karma xpu with scaling on and off in the transform node.

Thanks.

The "golden rule" is: always bake before the transform, or in fact: before any other manipulation.

Otherwise the attributes get messed up.

protozoan
The "golden rule" is: always bake before the transform, or in fact: before any other manipulation.

Otherwise the attributes get messed up.

Hi,

thanks for reply. The transform in the render above is done after the bake - it's the transform from the wasp.hip itself.

I assume you will need to scale v@scale attribute by the same factor

it'd probably be more robust if the transform of the GSplat was defined by v@P + 3@transform to have scales applied, instead of the current v@P + v@scale + p@orient, which is probably a good RFE

tamte
I assume you will need to scale v@scale attribute by the same factor

it'd probably be more robust if the transform of the GSplat was defined by v@P + 3@transform to have scales applied, instead of the current v@P + v@scale + p@orient, which is probably a good RFE

Hi,

thanks, that has solved it. I just added a attribute wrangle after the main transform, with the v scaled linked to the transforms scale.

Perfect.

Thanks again.

tamte
I assume you will need to scale v@scale attribute by the same factor

it'd probably be more robust if the transform of the GSplat was defined by v@P + 3@transform to have scales applied, instead of the current v@P + v@scale + p@orient, which is probably a good RFE

Yes. Doing it right now.

iirc in the transform node there is an entry which attributes it also applies the transformation on, you can also flag attributes as transformable. Maybe those options can fix this without extra steps.

Jonathan de Blok
iirc in the transform node there is an entry which attributes it also applies the transformation on, you can also flag attributes as transformable. Maybe those options can fix this without extra steps.

Those work only for attributes with transformable qualifiers (type info), hence as mentioned it would nicely work for 3@transform attribute with qualifier set to Matrix

But there is no qualifier that can be set for attribute like v@scale that would only apply scaling portion of the transform but not rotation, which would do if set to Vector, therefore v@scale doesnt have any qualifier set and its not gonna transform even if the attribute pattern on Transform SOP matches it