dandeentremont

I very much enjoy the convenience of the "Alembic Group" node and would like to bring that to an FBX (File node) pipeline. Alembic Group's hierarchy selection seems to be based on a writeable string primitive intrinsic called "abcobjectpath." When importing an FBX using a File node, it comes with path attributes that can be used with Alembic Group but ONLY if I can somehow copy them as a prim intrinsic called "abcobjectpath." Is there any way of creating an arbitrary prim intrinsic out of nothing?

Well, if you have just the @v and @up, it's not the most ideal to create a spinning around v axis, because the orientation tends to get wonky when the v vector gets near the up vector. Either way, here's a poor man's setup I use: //This method may result in fast flipping if the particles do loop-de-loops //v@up = {0,1,0};//set this if you don't already have an up attribute vector forward = normalize(v@v); //create a quaternion rotating about the forward axis over time vector4 rotQuat = quaternion(@Time*10, forward); //use qrotate to rotate a vector by the quaternion v@up = qrotate(rotQuat, v@up); Using @orient is better because you don't have to worry about zero velocity situations or up vectors, but it requires some extra setup during the sim process (Assuming it's POPs)

Are you using "@v" and "@up" to orient your object, or "@orient"?

If you want to keep the little piece attached to the bigger piece, make the "name" attribute the same before packing/assembling. For example, if the big piece is called "piece34" and the little one is called "piece7" then change the name of the little piece to "piece34" as well. Again, make sure you do this BEFORE packing/assembling it, or the DOP will tell you there's a duplicate name. You want both pieces to be one packed primitive. That being said, if there's a geo overlap problem, I've found it's often due to concave pieces getting convex hulls as proxy geo in the DOP. You can help reduce this by using convex decomposition on the proxy geo.

bumpity

If you look at the attached ColIgnoreA.mp4, you can see the "red" and "green" collisiongroup attributes ignoring one another. Results are as expected. In ColIgnoreB.mp4, with those same collision ignore groups, I glue one red and one green sphere together. The free red sphere now collides with the green sphere, which is not as expected. The best I can tell is that when these pieces are glued together, they somehow combine their collision groups. When I set collisionignore as "red green" it ignores them both. However I still want red to collide with red, so it does not work for me. What's more is that Soft and Hard constraints work as expected, ignoring green sphere collision. Only Glue is strange like this. Is there a way around this? ColIgnoreA.mp4 ColIgnoreB.mp4