MOPs Forums

Yep, that sounds right. I think those noise functions don't accept a fourth input. Glad to hear it's working!

Just to be certain, did you download the latest experimental build? You need to either switch from the master branch to the experimental branch on GitHub, or use the MOPs Updater shelf tool to grab the Experimental branch. It should be v1.1.18.

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