MOPs Forums

This is an oversight; I've just rewritten that part of the node to estimate the scale of each instance by finding the largest bounding box axis. There's also now an option to specify which bounding box axis determines the point scale, for very oblong instances. These updates are in the `henry_dev` b...

I think this is standard Houdini behavior... the state of the objects doesn't update reliably inside SOP solvers. I don't think it's something I can patch out, unfortunately.

I think in this case specifically there would have been no way to solve it procedurally. Since every frame is solved independently of the next, there's no good way to get contiguous rotation from one orientation to the next, and so when your randomized rotation suddenly is just a tiny bit closer to ...

Yeah, I think the nature of this being applied as a procedural operation is making it impossible for things not to flip. The changing input orientation means that from frame to frame, the shortest path from the random orientation to the aimed orientation could be different every single frame. I don'...

Hmmm, this is a weird one. This is happening because of quaternions. Something about the changing initial orientation is causing certain instances to take one route to interpolate between two orientations on one frame, and the opposite route on the next frame. I guess it's just close enough to being...

In your example file, the problem is that in the Unpack SOP you're transferring "UV" from the packed geometry to the unpacked geometry, which mangles your original UVs. Just leave the UVs as vertex attributes before the Instancer, then when you're done with the MOPs stuff, unpack using the default o...

Packed geometry in MOPs is no different from packed geometry anywhere else in Houdini. If your objects have vertex UVs prior to being packed (or input into the Instancer), those UVs remain embedded in the geometry. They will not be directly accessible to you without unpacking, but the render engine ...

If you want the deep dive: https://vimeo.com/262883554/description

Ah, perfect! Yeah this is a bit of a flaw in the packed primitive workflow... if it isn't obvious to Mantra where your material definitions are, it'll just skip them unless you embed everything. You can also dodge this problem a little more efficiently by using stylesheets to assign materials, but y...

Try this... on your Mantra ROP there should be an option called "Declare Materials". Set that to declare all materials in your IFD. It's possible Mantra just can't figure out what materials should be included in the IFD because of the way they're applied. Let me know if that changes anything.