Hi all,

I need to reset all my transforms and intrinsics, so also the intrinsic pivot. However, when I change the primintrinsic pivot to be (0,0,0), the different packed geo's get an offset which is not needed.

Basically unpacking and then packing the objects is what works, but it slows down the animation drastically.
Is there any other way of setting the packed geo's pivot to the origin, without offsetting the packed geo's nor using the unpack-pack method?

Thanks in advance,
Chris

Klonkel
… so also the intrinsic pivot

any reason you really need this?

basically geo is always packed relative to the origin, and pivot intrinsic defines the offset form the origin where the pivot of the packed geo is
if you set pivot intrinsic to 0, the pivot will simply be at the origin of original packed geo

so in order to define custom pivot per packed prim without unpacking you'll need to set pivot intrinsic attribute to appropriate values depending on your needs not necessarily to 0

tamte

Klonkel
… so also the intrinsic pivot

any reason you really need this?

basically geo is always packed relative to the origin, and pivot intrinsic defines the offset form the origin where the pivot of the packed geo is
if you set pivot intrinsic to 0, the pivot will simply be at the origin of original packed geo

so in order to define custom pivot per packed prim without unpacking you'll need to set pivot intrinsic attribute to appropriate values depending on your needs not necessarily to 0

You have to update P to be equal to pivot * packedfulltransform, or the piece will move when changing the pivot.

Well the reason has something to do with redshift,

So I have animated objects which I import and pack with an obj merge. Then I split the animation (P and intrinsic for rotation) and the packed geo's. So I have a pointcloud with animation attributes and a static geo, which I reset to 0. This way I can bake the animation via chops for the whole sequence, and I only have to save out the geo once, and then reapply the animation again.
The weird thing is though, when the animation is reapplied and the pivot is off, the viewport is correct, but the render with redshift isn't, but when the pivot was set to 0, the viewport and the render are both correct?

So I feel like redshift needs the pivots to be “reset”, since I am using the packed geo's as instances to increase the render speed.

Chris

I recall having the same issue with Redshift ignoring intrinsic pivot for packed prims therefore RS renders were not aligned with Mantra or Viewport
don't have access to RS right now, but if I remember correctly I resolved if by creating v@pivot attribute and set to something
so maybe try this:

Thanks for the replies!

I tried the v@pivot method, but didn't manage to get it to work yet. Good to know though that having that attribute can fix the pivot offsets, however in my scene it's a little more complicated…

This is the chain we have:
obj import -> set id's -> null OUT for chops -> run packed geo's through foreach and subdiv where necessary -> save out the frozen geo's -> import the saved chops from a side-chain and reapply the transformations again.

So at “null OUT for chops”, the geo's have a intr. pivot offset, but after the foreach their intr. pivot is zero'd out, because they're unpacked and packed again.
When I reapply the transforms from the chopnet back to the frozen geo's it works in the viewport though, but the render is wrong.
That's why I thought zeroing out the geo's intr. pivot before the “null OUT for chops” would be the option. And it does solve the problem, but this chain; (resetting the transformations -> foreach loop with unpack and pack -> reapplying the transformations again) is quite slow to do for all objects before going to chops. Maybe there also is another way to reset the pivot but keep the position?

Chris

it shouldn't matter how complicated your setup is, in my experiance it's only that RS doesn't care about intrinsic pivot, but can use v@pivot attribute instead

can you post a file with for example one of your final packed prims stashed ?

I added the recreated problem in the attachments. I also changed some pivotpoints/orientations of the rubbertoy, since that is also what we have in our scene. When rendering this right now the output does not match the viewport.

so in your case the pivot intrinsic is 0 for every prim, so that's not an issue, however keep it in mind in case you encounter the actual pivot mismatch (you'll also need to uncheck Ignore pivot attrib on RS Object properties to use v@pivot)

however your issue seems to be the mismatch of point numbers and prim numbers which RS seems to have problems with
so just append Sort SOP and set Point Sort to By Vertex Order

The recreated scene file accidentally didn't even need the sort to get it working correctly, I added the sort mainly to check if the channels were applied based on id's instead of ptnums. However what I did find was that redshift actually uses the id's when rendering.
In my actual file setting the sort to vertex order didn't solve the problem, but when I removed the id's after applying the transforms the render looks good.
So, redshift keeps looking at the id's when using “packed geo as instances”.

Thanks for all the help!

Chris