MOPs Forums

If you enable "Time Varying" on the Noise Falloff or Noise Modifier, there should be a parameter enabled called "Looping Noise". You can then set the Period parameter to determine how many seconds it takes for a full cycle.

Anytime! Let me know if it works for you; I haven't really tested the hell out of it just yet but as long as you don't animate the Offset parameters of the noise, it should loop seamlessly for any noise that supports 4-dimensional inputs (most of them aside from sparse convolution I think?)

Hello,

I probably need to make the error a little more descriptive. The problem is that the sphere that you're trying to transfer an orientation from, does not have an orient attribute. Try wiring a MOPs Orient Mesh onto the sphere before connecting it to MOPs Reorient.

I just added preliminary support for looping noise in the latest Experimental build:
https://github.com/toadstorm/MOPS/releases/tag/v1.1.18e

Feel free to give it a shot if you don't want to do it manually.

Hey Mike, Looping noise is definitely possible... what you want are two identical copies of the same noise operation, offset in time. You then ping-pong back and forth on the "weight" between the two noise patterns so that noise2, which is time offset by say, four seconds, has a weight of 1.0 at fou...

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...