View Full Version : MaxScript Bug...? (Point3 values)

03 March 2006, 09:45 PM
Original Problem: The noise3, and fractalNoise functions seem to choke when given position values whose x/y/z components are not floats (i.e. integers). No error is thrown, but Point3 values that are not comprised of floats will always return the useless value of 0.0. (The noise4 function seems erratic when using integers, but it doesn't strictly return 0.0 all the time.)


noise3 [222,333,444]
noise3 [222.2,333.3,444.4]
fractalNoise [222,333,444] 0.5 2.0 5.0
fractalNoise [222.2,333.3,444.4] 0.5 2.0 5.0

Bug Report (?): In order to workaround the problem, I tried to simply convert the component values to floats, but MaxScript doesn't seem to allow this if the values are whole numbers. It either won't convert them, or it automatically converts them back to integers if they are whole numbers.


[(222 as float),(333 as float),(444 as float)]

Now, one of these must be a bug....either the limitations of the noise functions or this Point3 behavior. It is currently impossible to get a noise3 or fractalNoise value for any 3d position comprised of whole numbers. In fact, it seems that MaxScript won't even tolerate whole number floats in a point3 value at all.

Anyone know more about this?

I've worked around it for now, but it seems like there is something wrong here....

03 March 2006, 11:57 PM
Your conversion to float is fine, but futile. The problem is that noise3 yields a 0.0 result *even* when you have 1.0 floats. If the only thing after the decimal point is a 0, then it still turns it to an integer.

noise3 [1.0, 2.0, 3.0] -- yields 0.0
noise3 [1.1, 2.0, 3.0] -- yields 0.0654835

03 March 2006, 05:13 AM
It turns out that the function works fine, and that the 0.0 return value is correct. The display of the Point3 component values as integers is just for display....the stored values are actually floats.

The following response by Alex McLeod (from a post I left in the Autodesk MaxScript forum) says it all....hope this helps someone else as much as it helped me.

From: Alex McLeod
Date: Thursday, March 23, 2006 08:02 PM

A point3 is always a collection of floats. What you're seeing is Maxscript omitting the decimal place and the zeroes for display. Try this:

a = 1 --integer
p = [a,a,a] --point3
classof p.x --will return "float"

p / 3 --will return [0.3333,0.3333,0.3333]

--just to be sure it's a display issue, try this:
q = p / 3 --will return [0.3333,0.3333,0.3333]
q * 3 --will return [1,1,1]

Now - the problem you're reporting is actually one of periodicity in the Noise functions, not entirely unlike the periodicity in sine or cosine. Just for fun, open a curve editor, and in the first Global Float track make a Float Script controller with the following body:

fractalnoise [currenttime / 10, 0, 0] 0.5 2 1

What you'll see is a random-looking wiggle that passes through zero every ten frames. You'll see the same thing if you put a Noise controller on an object's position - random wiggles passing through zero on a distressingly regular basis. You've already seen the same thing when passing whole-number point3s to a Noise function; not a problem with the point3 class, just a pattern in the Noise functions.

Computers just aren't very good at producing signals without patterns. The patterns might not be all that apparent at first glance, but anything computer-generated will show a pattern if you look at it from the right angle. Generally it's up to us to spot those patterns and obscure them somehow. One easy way to obscure a pattern is to mix it with another pattern that has a different frequency. For example:

fractalnoise [currenttime / 7, 0, 0] 0.5 2 1 +
fractalnoise [currenttime / 13, 0, 0] 0.5 2 1

That'll still pass through zero, but not quite as regularly. Instead of every 10-frames-like-clockwork, it'll be every 91-frames-like-clockwork (7 * 13), with a more chaotic-looking wiggle in-between. Why 7 and 13? Because they're both primes, so they're only guaranteed to meet at zero on multiples of 91. Mix an 11-frame noise in there as well and they'll only line up every 1001 frames.

Here's another handy method for getting an irregular-looking 1-dimensional noise from a 3D Noise function:

any_old_projection_vector = [-0.304,-0.715,0.629]
fractalnoise (X * any_old_projection_vector) 0.5 2 3

What does that do? The pattern in Fractalnoise is apparent along the X, Y or Z axes, as there's a 3D grid (of sorts) involved in its generation. By reading the function along some arbitrary vector instead of along the X, Y or Z axis, you cross cell boundaries in that grid in a less regular fashion.

One last example in the same vein: make a Noise texture in the material editor and magnify its slot. Set it to Turbulence mode and reduce its size. Looks kinda... regular, doesn't it? Like there's an underlying grid? Now adjust its X Angle (in the coordinates rollout), and note that that grid pattern's gone. Now adjust its Y angle, too, and note that the grid's even goner. The pattern's still in there somewhere, but you're reading the noise function along a different axis, so it's far less apparent. Very handy for making textures look more organic on flat surfaces, but not really important on curvy surfaces, as they're not aligned to the texture's underlying grid in the first place.

Sorry for the long-winded reply, but I think it's important knowledge for anyone with a technical inclination. Obscuring patterns like that goes a long way to reducing that ineffable computeriness of all things computery.

03 March 2006, 10:47 AM
Ah, great info! Thanks for the post. This will be useful in future I'm sure.

CGTalk Moderation
03 March 2006, 10:47 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.