sphere.position.y = does not transform into a number both sides

[GrosSacASacs]

I am not sure if this is a bug or not. When I use something like sphere.position.y = string1; if string1 can be converted into a number it will , and this value is used to update what you see on the screen. So far so good.

Now when I did sphere.position.y += 1; I expected it to use the internal number it used to position ittself correctly on the y axis and to add 1 to it, but instead used string1 as a basis, and the result is far off.

Why does sphere.position.y = ... not transform into a number both sides the internal number but also the public number; what you get back when you look for sphere.position.y  again.

See in the console, in this playground

 

http://www.babylonjs-playground.com/#1QFFPV#1

[Samuel Girardin]

Hi, 

Maybe you need to retrieve positions as string in a json file, in this case juste use  parseFloat("3.5").

 http://www.babylonjs-playground.com/#1QFFPV#2

 

[GrosSacASacs]

I know about parseFloat and how to bypass this problem, what I want to know is, why is the external sphere.position.y not updated with the same number that was internally used to calculate the sphere position in space ?

[GameMonetize]

Hello there is no internal/external number. The position.y is a member and not a property.

SO when you set position.y = string, you change the internal value

[fenomas]

17 hours ago, GrosSacASacs said:

I know about parseFloat and how to bypass this problem, what I want to know is, why is the external sphere.position.y not updated with the same number that was internally used to calculate the sphere position in space ?

When you set the y property to a string, and then add 2 a few lines later, those commands execute synchronously, before Babylon has a chance to do anything. In other words, doing:

sphere.position.y = "3.5";

sphere.position.y += 2;

is exactly the same as doing:

var y = "3.5";

y += 2;

sphere.position.y = y;

or even:

sphere.position.y = "3.5" + 2;

The code executes the same way, Babylon doesn't have anything to do with it.

[GrosSacASacs]

I am not sure about that, I looked at the babylon source a little bit and saw heavy Object.defineProperty usage. When y is changed maybe a setter function is called to handle that, parseFloat it, calculate the new position.

[fenomas]

26 minutes ago, GrosSacASacs said:

I am not sure about that, I looked at the babylon source a little bit and saw heavy Object.defineProperty usage. When y is changed maybe a setter function is called to handle that, parseFloat it, calculate the new position.

It could do that in principle but it doesn't.  Mesh.position is a Vector3, and if babylon's core vector class defined setters to call parseFloat every time one of their coordinates changed I think that would affect performance..

[GrosSacASacs]

The reason I say parseFloat or similar is called is that you need a number to determine the position of the sphere. So maybe it is indeed called elsewhere, maybe in the renderloop, that would also make sense with what Delkatosh said

[fenomas]

6 hours ago, GrosSacASacs said:

The reason I say parseFloat or similar is called is that you need a number to determine the position of the sphere. So maybe it is indeed called elsewhere, maybe in the renderloop, that would also make sense with what Delkatosh said

Babylon isn't calling parseFloat explicitly, the string just gets converted back to a number once the engine starts doing math. Javascript is loose that way, many of the math operators will implicitly cast to number types if they can.

var s = "3.5"

s + 1       // "3.51"
s * 2       // 7
typeof(s*2) // number

I haven't checked, but probably the first thing BJS does with the position vector is transform it, meaning it gets multiplied, so the results don't wind up breaking anything.

Note however, that you should try to avoid misusing types this way for performance reasons. Modern Javascript VMs are fast because they do a good job of speeding up code that uses types consistently, and if they can't figure out what type each variable should be they tend to get slow.

[GrosSacASacs]

All makes sense now, thanks alot fenomas