Calculations precision space limits
12 October 2016 15:04
Hi there:
I've been working in a project which implies really big scenes, I'm trying to make kind of a space voyage game and I'm using the Gliese Stars Database to create the stars programatically in blender with Python which is great and in a couple of minutes you have the 1500+ stars in the scene. If you do it treating the coordinates units as meters it works fine and all the stars appear correctly in the exported scene and you can fly by and everything, but…
If you increase the distance by multiplying the distance you find one pretty bad problem I didn't have notice of. Indeed I'm not quite sure if the problem is what I think it is. I think it is about the precision of the calculations when you deal with big numbers. The thing is: as the 'space ship' is a cabin wich I attach the camera to by a semi stiff constraint of the camera to an empty that is at the same time a child of the rigid body which is the hull of the ship, when you progresively go further in space the constraint starts to behave in strange ways, in fact it ends up losing completely the position and no longer works properly, even going out of the cabin and viewing the ship from outside.
Then I found this page in the Blender documentation which explains that as we are using float 32 numbers the calculation with big numbers loses precision as we get further away from the origin, a thing a have heard of but never suffered as I hadn't work with so big distances.
Googling a little I found that this is not only a Blender problem but a problem with all the game engines and 3d software and hardware that are using these mumbers in it's core (which is pretty astonishing, I hope my bank to use double precision, hehe…)
Aside from that I'm still checking if this is in fact the case cause I'm using blender parenting and blend4web parenting at the same time and it could be that using only one type it works ok.
I tried to scale the scene too. In the blender documentation says that if you don't want so much precision in sculpting et al and scale the blender units to be 10 meters instead of 1 meter you get better calculations at big distances. I tried it, and it seems to work better, you go further away and the constraints keep stable.
But I found another problem the character don't seem to get the rescaling well and although the object itself gets scaled the physic body is still the same size and the body floats one meter above the ground
Is there any workaround to this problem? I'm still working on it and maybe I can adapt the object ok in the javascript using b4w api. It appears to be a hard problem. I mention it here because it is an issue that is pretty interesting all that float 32 thing…
Well, if you have any idea that could work it will be welcome, I'll keep on it and update this post as I go through it.
Cheers.
I've been working in a project which implies really big scenes, I'm trying to make kind of a space voyage game and I'm using the Gliese Stars Database to create the stars programatically in blender with Python which is great and in a couple of minutes you have the 1500+ stars in the scene. If you do it treating the coordinates units as meters it works fine and all the stars appear correctly in the exported scene and you can fly by and everything, but…
If you increase the distance by multiplying the distance you find one pretty bad problem I didn't have notice of. Indeed I'm not quite sure if the problem is what I think it is. I think it is about the precision of the calculations when you deal with big numbers. The thing is: as the 'space ship' is a cabin wich I attach the camera to by a semi stiff constraint of the camera to an empty that is at the same time a child of the rigid body which is the hull of the ship, when you progresively go further in space the constraint starts to behave in strange ways, in fact it ends up losing completely the position and no longer works properly, even going out of the cabin and viewing the ship from outside.
Then I found this page in the Blender documentation which explains that as we are using float 32 numbers the calculation with big numbers loses precision as we get further away from the origin, a thing a have heard of but never suffered as I hadn't work with so big distances.
Googling a little I found that this is not only a Blender problem but a problem with all the game engines and 3d software and hardware that are using these mumbers in it's core (which is pretty astonishing, I hope my bank to use double precision, hehe…)
Aside from that I'm still checking if this is in fact the case cause I'm using blender parenting and blend4web parenting at the same time and it could be that using only one type it works ok.
I tried to scale the scene too. In the blender documentation says that if you don't want so much precision in sculpting et al and scale the blender units to be 10 meters instead of 1 meter you get better calculations at big distances. I tried it, and it seems to work better, you go further away and the constraints keep stable.
But I found another problem the character don't seem to get the rescaling well and although the object itself gets scaled the physic body is still the same size and the body floats one meter above the ground
Is there any workaround to this problem? I'm still working on it and maybe I can adapt the object ok in the javascript using b4w api. It appears to be a hard problem. I mention it here because it is an issue that is pretty interesting all that float 32 thing…
Well, if you have any idea that could work it will be welcome, I'll keep on it and update this post as I go through it.
Cheers.
13 October 2016 02:06
Hello again:
I've been working in this a little more and the behaviour is intriguing. The thing is when you are reaching more or less 5000 meters the parenting of the objects starts to mess up. It is interesting that if you return to the origin the things get ok and no strange behaviour happens.
Now I think the solution is pretty obvious although I have not tried it: working with smaller objects . I'm going to try to work with objects 10x smaller so the impression of the space would be 50 kilometers, which is pretty big if you adjust the speed of the ship and fake the units.
Tomorrow I'm going to upload the file, as I want to include the keys assignment in a little help div so you can look at the problem for yourself.
I've been working in this a little more and the behaviour is intriguing. The thing is when you are reaching more or less 5000 meters the parenting of the objects starts to mess up. It is interesting that if you return to the origin the things get ok and no strange behaviour happens.
Now I think the solution is pretty obvious although I have not tried it: working with smaller objects . I'm going to try to work with objects 10x smaller so the impression of the space would be 50 kilometers, which is pretty big if you adjust the speed of the ship and fake the units.
Tomorrow I'm going to upload the file, as I want to include the keys assignment in a little help div so you can look at the problem for yourself.
14 October 2016 00:17
Hi again:
This is the link to the file. I hope you can download it without any problem.
If you press 9 or H you can see the keys. The ship is a rigid body so if you hit anything you can start spinning without control. The roll over the z-axis is not followed by the camera (one of my problems). Ah, and it is still working in 16.08 so the axis is the old way. In a couple of days I will go updated and will make a new version.
This is the link to the file. I hope you can download it without any problem.
If you press 9 or H you can see the keys. The ship is a rigid body so if you hit anything you can start spinning without control. The roll over the z-axis is not followed by the camera (one of my problems). Ah, and it is still working in 16.08 so the axis is the old way. In a couple of days I will go updated and will make a new version.
14 October 2016 10:20
Hi Marcos,
Yes, the problem of big sizes is really a common one for any 3D software.
Generally, such issues are being solved by dividing world into tiles and moving everything closer to the origin when a new tile is reached.
As of scaling a character. Check the Step Height parameter in character settings. It doesn't take scale into account, so you need to set a new value after scaling.
Yes, the problem of big sizes is really a common one for any 3D software.
Generally, such issues are being solved by dividing world into tiles and moving everything closer to the origin when a new tile is reached.
As of scaling a character. Check the Step Height parameter in character settings. It doesn't take scale into account, so you need to set a new value after scaling.
15 October 2016 17:03
Hi again:
Yes, the character thing worked, thank you I was seeing me changing all the character movement to rigid body…Thanks Evgeny.
Well, the thing seems to be in his way for now, I have down-scaled ten times and port it to 16.09, now I am going to correct the movement speed so it must be ten times slower now, then I'll upload a file so if someone wants to take a look can.
Yes, the character thing worked, thank you I was seeing me changing all the character movement to rigid body…Thanks Evgeny.
Well, the thing seems to be in his way for now, I have down-scaled ten times and port it to 16.09, now I am going to correct the movement speed so it must be ten times slower now, then I'll upload a file so if someone wants to take a look can.