I'm having an issue with the mops_aim / MOPs_Shape_Falloff nodes that are causing some simulated points to sometimes have their @orient s flipped/jump/"pop". My points are simulated earlier to rotate and move around in a certain way for art direction. My goal is to have a falloff move over the group of points which I will use to force their rotations to look at a camera as the camera moves towards them. This is basically to get the points which are eyes/spheres to look at the camera in a creepy way. For whatever reason, I'm getting popping on the rotations when my MOPs_Shape_Falloff uniform scale is set to a value greater than the default of 1. I want to make the falloff uniform scale greater so that I can get slower rotations of the eyes, so they don't rotate so quickly, it's creepier that way. But I keep getting rotation flipping/popping on a few @orient values.
Attached is link to my HIP and point sim. Everything you need to look at is in the "eyes" node from the obj context. For whatever reason whenever you open the file it defaults to placing you in my CHOP network. So just jump over to the eyes node.
Why would increasing MOPs_Shape_Falloff uniform scale past 1 cause some point @orient values to flip/pop/not animate smoothly during animation? How do I prevent this without having to leave uniform scale at default of 1?
Unfortunately you have to leave the viewport in wireframe mode if you want to see the popping because I don't have any textures. You can't see spheres rotating when they're smooth obviously. It's a little difficult to see popping rotations among so many spheres in the scene so have fun.
Do I need to look into quaternions to fix this?
Thanks!
https://drive.google.com/file/d/1UJyXig ... sp=sharing
Point @orient flipping with mops_aim & mops_shape_falloff
Re: Point @orient flipping with mops_aim & mops_shape_falloff
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 the exact opposite orientation that the shortest path becomes hard to define. This is a pretty tricky problem to solve without getting some kind of solver involved.
I'm gonna spend some more time on this one and see if there's a way to handle this procedurally... if not I can help you handle this in a solver. Sorry to make you wait! I'll keep posting findings here.
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 the exact opposite orientation that the shortest path becomes hard to define. This is a pretty tricky problem to solve without getting some kind of solver involved.
I'm gonna spend some more time on this one and see if there's a way to handle this procedurally... if not I can help you handle this in a solver. Sorry to make you wait! I'll keep posting findings here.
Re: Point @orient flipping with mops_aim & mops_shape_falloff
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't think it's a problem that can really be solved without building on top of the orientation from prior frames.
I think what might work better is to handle this aiming inside your simulation. You could use a SOP Solver DOP to slowly aim your points via MOPs Aim, along with a tapered Falloff. I'm attaching a modified version of your file demonstrating this. I'm sure you'd need to make more adjustments to it (I disabled your timeshift to simplify things) but hopefully this approach will solve your problem.
I think what might work better is to handle this aiming inside your simulation. You could use a SOP Solver DOP to slowly aim your points via MOPs Aim, along with a tapered Falloff. I'm attaching a modified version of your file demonstrating this. I'm sure you'd need to make more adjustments to it (I disabled your timeshift to simplify things) but hopefully this approach will solve your problem.
You do not have the required permissions to view the files attached to this post.
Re: Point @orient flipping with mops_aim & mops_shape_falloff
Thank you for the fantastic explanation and taking time to look into it! It seems to be working, no popping. It never occurred to me to use a SOP solver. I didn't realize you could actually do regular SOP stuff in there.
In terms of my understanding of the issue, I think I understand most of it. It's a shame it can't be done proper procedurally. Thank you for diagnosing the issue and working a fix for me! No worries about having to make me wait. I barely have enough time as it is to work on this project and so you had already posted your second reply before I got back to work on it.
Biggest down side of doing the mops in the dopnet is there's no quick playback over a large baked sim. Of course I could just use my low res sim to test falloffs and whatnot but I enjoyed seeing it all respond so quickly in my original file.![Smile :)](./images/smilies/icon_e_smile.gif)
Ultimately, do you think this problem was caused by a general limitation with proceduralism for this specific case or was it mops functionality that could be improved?
Again, thank you so much. It's very nice of you to work out the sop solver for me. I hope it wasn't too much trouble. I never would have figured it out.
I'll be sure to share the finished product with you when it's rendered!
In terms of my understanding of the issue, I think I understand most of it. It's a shame it can't be done proper procedurally. Thank you for diagnosing the issue and working a fix for me! No worries about having to make me wait. I barely have enough time as it is to work on this project and so you had already posted your second reply before I got back to work on it.
Biggest down side of doing the mops in the dopnet is there's no quick playback over a large baked sim. Of course I could just use my low res sim to test falloffs and whatnot but I enjoyed seeing it all respond so quickly in my original file.
![Smile :)](./images/smilies/icon_e_smile.gif)
Ultimately, do you think this problem was caused by a general limitation with proceduralism for this specific case or was it mops functionality that could be improved?
Again, thank you so much. It's very nice of you to work out the sop solver for me. I hope it wasn't too much trouble. I never would have figured it out.
I'll be sure to share the finished product with you when it's rendered!
Re: Point @orient flipping with mops_aim & mops_shape_falloff
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 one side of the unit sphere than the other, it snaps. I think a solver is the only real solution here.
Thanks for this nasty edge case! I'll keep thinking about the problem and see if there's any way to smooth out jumps like this as a post process. There will be a MOPs Aim DOP with the paid add-on, whenever that releases...
Thanks for this nasty edge case! I'll keep thinking about the problem and see if there's any way to smooth out jumps like this as a post process. There will be a MOPs Aim DOP with the paid add-on, whenever that releases...
Re: Point @orient flipping with mops_aim & mops_shape_falloff
I tend to have a problem in finding obscure issues like these which hold back my creative projects ha. I’m glad I could help you notice this edge case.
I will be more than happy to buy your paid add on in the future. Mops has been pretty promising to me so far and it’s nice to be able to get away from C4D’s destructive workflows and other mograph limitations.
I will be more than happy to buy your paid add on in the future. Mops has been pretty promising to me so far and it’s nice to be able to get away from C4D’s destructive workflows and other mograph limitations.
Re: Point @orient flipping with mops_aim & mops_shape_falloff
Oh and I also noticed another bug but this one is minor. With the mops shape falloff in the sops solver in dops, sometimes turning on the sprite representation of the falloff gets stuck as enabled even when you disable it. I’m not at my file right now so I’m trying to remember: I believe I enabled sprite mode, then went up a node level to the dopnet, went back down into the sop solver, disabled sprite view, but nothing changes. Only until you go up 2 levels to SOP context something remembers to update and it’s back to normal. I might be misremembering a step though.
Re: Point @orient flipping with mops_aim & mops_shape_falloff
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.
Re: Point @orient flipping with mops_aim & mops_shape_falloff
Oh well, thanks anyways. Off to find another bug.