RBD sim / copy to points discrepancy

[paulchambers3d]

Hi folks, long time lurker, first time poster so apologies if this is a newbie question.

I'm running a simple RBD sim and from there swapping in geometry using a DOP import and then copy to points. For the purpose of testing I'm copying on identical geometry to the sim. You can see that the blue guide geometry from the sim is (presumably) a sub-step or two ahead or behind of the copy to points (gray).

How do I remove this discrepancy so that the copy-to geometry exactly matches rotation of the sim?

And please note, yes I am aware of other methods for swapping in high-resolution geometry to sims etc. There's a specific reason why I want to swap in objects.

Your help is appreciated!

 

 

[toadstorm]

The reason this could be happening is likely dependent on how you're setting up your geometry pre-simulation. If the geometry is copied and transformed before being assembled and packed, for example, what constitutes "up" and "forward" for a given box might not be what would visually be "up" and "forward" for that box. 

What I've found to be the most consistent solution is to get the packed primitive intrinsic attributes that define the transform, and use those to create / overwrite any template point attributes on the RBD points. You can do this in a Point Wrangle:

matrix3 xf = primintrinsic(0, "transform", @ptnum);
3@xform = xf;

vector pivot = primintrinsic(0, "pivot", @ptnum);
v@pivot = pivot;

Then try copying the final geometry to those points.

[paulchambers3d]

Thanks Henry, appreciate your help. I am using a particle system upstream to generate the initial points, so the scenario you describe sounds right.

Unfortunately though the wrangle didn't help. I've also tried using a Transform Pieces SOP to apply to the points and I'm getting the same results.

I wonder if this is a bug.

[toadstorm]

It's unlikely to be a bug. Can you post a hip file that demonstrates the problem?

[paulchambers3d]

Many thanks. I've attached the file. I was originally calling in external geometry but I've changed the objects to simple spheres and cubes. The API subnetwork is where the discrepancy is occurring where objects are copied to simmed points and are expected to have matching orientation.

Really appreciate any insight you have.

TEST.hip

[paulchambers3d]

Another screen shot the demonstrates the problem. The wireframes show the DOP import, the solid geometry is copied to those points. The discrepancy is particularly visible on the boxes, but also present on the spheres.

 

 

[paulchambers3d]

I actually think I found the issue in my POP network. On my initial copy to points within the POP - I had "Transform using Point Orientations" checked. This attached the initial boxes and spheres to the particle emitter. Un-checking this solved the discrepancy. 

Doh! Really appreciate your offer to help on this one.