Sign in to follow this  
GrosSacASacs

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

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.