Community
3ds Max Programming
Welcome to Autodesk’s 3ds Max Forums. Share your knowledge, ask questions, and explore popular 3ds Max SDK, Maxscript and Python topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

decimal precision

4 REPLIES 4
SOLVED
Reply
Message 1 of 5
Anonymous
4883 Views, 4 Replies

decimal precision

Okay, this question might sound like I am being too knit-picky, but in my situation, this is very import to have. 

 

The project:

I am looking at creating a few MCG tools, in which will cut down on doing repetitive work. These tools will require finding the local translation from the parent pivot. I have come up with using the quaternion rotation between to vectors node to find the direction that the parent object is pointing towards.

 

 

The problem:

Once the tool calculates the local translation, its answer has this extremely long decimal, instead of either saying it is a zero or 1. For example, if the local translation is pointing towards the 'Y' axis, its answer is [0.0, 0.99999999, -3.090862E-08]. At first, some people might think this is overkill to worry about, but in reality, this can make a huge difference, depending on the project. How is this so, you might ask? Think of it this way, to move an object along its local translation, the formula is Local Vector * Scalar. A first example, could be maybe you wanted a child object to move 2 units in its local direction. So, taking our above local direction and multiplying it by 2, we get [0.0, 0.99999999, -3.090862E-08] * 2 = [0.0, 1.99999998, -6.181724E-08]. This example is not that bad. I can still get away with moving the child object 2 units in the 'Y' axis and make it visually appear that it is laying on the grid without any gaps between each child object. However, my system units are in centimeters, so I am usually duplicating my child objects by 100cm or more. So with this example, taking [0.0, 0.99999999, -3.090862E-08] * 100 = [0.0, 99.999999, -3.090862E-6]. Normally, when modeling things to be rendered in 3ds Max or other 3d applications, this isn't too bad. However, my objects are made for Unreal Engine 4, which requires the engine to bake-out all static lights that are placed in the scene. So, what might seem to be considered minute gaps in between each object, it is huge in Unreal Engine 4, due to the fact, it can create lightmap leaking. This is when there is enough space for light to seep through, causing seams and artifact shadows to show up in your objects .

 

So my question, Does 3ds Max have a decimal precision allowance that I can set it to?

4 REPLIES 4
Message 2 of 5
Swordslayer
in reply to: Anonymous


@Anonymous wrote:

 

 So my question, Does 3ds Max have a decimal precision allowance that I can set it to?


No, like most today's dccs, it uses single-precision floats. Note that the example you gave is quite stretched since you're multiplying by 100 (scaling 100 times) where you'd be adding 100 instead (thus most likely losing the extra digits anyway since floats have 6 to 9 significant digits precision).

Message 3 of 5
Anonymous
in reply to: Swordslayer

@Anonymous:

I am not fully understanding what you are saying. I get the "no" part of your answer. Basically saying that for what I want to do, it is not possible to adjust. However, the stuff thereafter becomes a little foggy.

You have mention that I should be adding 100 to my vector instead multiplying. Why? Adding a scalar to a vector prior to knowing which way the parent object is facing, only produces world coordinate motion. For example, if my parent object is facing towards vector[0.25, 0.75, 0] and I move my child, say 100 units in the 'Y' axis, the child object will move to vector[0.25, 100.75, 0]. As you can see, the child object is not moving in the same direction that the parent object is facing. However, if I first calculate the direction that the parent is facing, hence in this example vector[0.25, 0.75, 0], and then multiply this direction by a scalar, vector[0.25, 0.75, 0] * 100cm, it will give me the correct axis the child object should move towards, while keeping the child's translation moving in the same direction as the parent object's direction, hence giving you vector[25, 75, 0].

 

In spite of the above decision, you  are basically saying don't worry about it. However, I have tried my best to make my original post as clear as possible for which this one particular incident that the amount of acceptable spacing does matter. Not as a general rule of thumb, but more specifically because my assets will be imported a to game engine that handle things a tiny bit different then the average 3d application. Therefore, the above example of 99.999999, in UE4, is enough space for light to leak through. You might not be able to visually see a gap between 2 objects, but the baked lighting will dominantly show the final results having visual lightmap baking errors.

Overall, I guess the best thing to do is build a compound that rounds off the value to its nearest grid snap setting.

 

P.S., I am still keeping this thread as not answered, so that others can chime in with there opinions as well.

Message 4 of 5
Swordslayer
in reply to: Anonymous

Oh right, that was direction and you calculate it yourself. Either way, there's not much you can do - use different units, stay as near to the origin as possible (due to the mantissa+exponent way of storing numbers, you only have limited number of significant digits so the further you get from origin and the more digits in front of the decimal point, the less precision after that - if it doesn't happen to be a power of two). Calculation errors pile up, even more so when both big and small numbers come into play at once.

 


@Anonymous wrote:

Therefore, the above example of 99.999999, in UE4, is enough space for light to leak through.


The precision for values around 100 is already lower than your threshold, it's ±0.000002 (both in max and UE4, neither supports double precision coordinates - currently, that's pretty much the domain of CAD packages) which means that if you subtract 99.999999 from 100, you'll get a difference of zero. The further you get from the origin, the bigger the threshold will be. Still, if your units are centimeters, the average diamater of a human hair is 0.002 (this imprecision within cms starts around one kilometer from the origin). You won't be able to change that but you can either tweak the render engine settings prior to baking or change the render engine.

Message 5 of 5
Anonymous
in reply to: Swordslayer

@Swordslayer:

I love your last answer. It is straight to the point and much clearer. Once again, thank you Smiley Very Happy

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report