Hi!
In javadoc you can find such thing as Vector3d, but when I try to add Vector3d variable to the project, it gives me a big error like there’s no such thing and would you like to create a class Vector3d.
I will need doubles a lot in my project, so I hope there is some way to add Vector3d :) or there isn’t? :?
Vector3f it is, since it stores 3 floats
The whole engine runs on Vector3f. If you run into problems with float precision or coordinates with too large values you will need to "partition" your 3d space, giving the illusion of a larger space by scaling your scene.
Cheers,
Normen
If you really need/want/must use Vector3d, there is one in the apache.commons.math package.
or use Ardor3D
normen said:
The whole engine runs on Vector3f. If you run into problems with float precision or coordinates with too large values you will need to "partition" your 3d space, giving the illusion of a larger space by scaling your scene.
Cheers,
Normen
This is what I did recently when creating a global coordinate system. I conferred with the man known as renanse about the worth of branching jme to use a Vector3d type of class and he made a good point which was that it will just push out further any precision problems already being experienced. In the end, we ended up doing scene scaling and just using a flat factor of 100 across the board helped a number of problems created by using rather large numbers
MrCoder said:
or use Ardor3D
I'm almost positive that the answer is no, but any noticable difference in memory usage from using doubles as opposed to floats? I think this would only be noticable in scenes with millions of objects but its still a bit interesting to me.
1 Like
sbook said:
I'm almost positive that the answer is no, but any noticable difference in memory usage from using doubles as opposed to floats? I think this would only be noticable in scenes with millions of objects but its still a bit interesting to me.
Only 64bit systems will be able to perform operations as fast with doubles as they do with floats. But the difference is in fact probably neglectible. Memory is probably less of an issue here but of course every double takes twice as much space as a float.
I'm almost positive that the answer is no, but any noticable difference in memory usage from using doubles as opposed to floats? I think this would only be noticable in scenes with millions of objects but its still a bit interesting to me.
You can read in my blog the last post. But as norman told, this may be due to 64bit OS, which I develop under.
This is what I did recently when creating a global coordinate system. I conferred with the man known as renanse about the worth of branching jme to use a Vector3d type of class and he made a good point which was that it will just push out further any precision problems already being experienced. In the end, we ended up doing scene scaling and just using a flat factor of 100 across the board helped a number of problems created by using rather large numbers
I came to this solution also. In my thought I will have all the object pivots stored in doubles anyway, but then transformed to some king of logarithmic scale, and only then placed into the scene.
Can you describe if few words how you did scene scaling? For me the solution is only the following: I always have my cam at (0,0,0) and manually move, rotate and scale all the scene objects. And also, a nice idea just came to my mind - if I have large scene (logarithmically scaled) any movement with cam would move it in position like (12345,0,0) or further. If there would be a a function to tell cam that this new far position is now (0,0,0), and all scene object were recalculated according to this new cam position (or I can say the center of everything), that will definitely spare a lot of time and nerves.
Thanks!
1 Like
KayTrance said:
Can you describe if few words how you did scene scaling? For me the solution is only the following: I always have my cam at (0,0,0) and manually move, rotate and scale all the scene objects. And also, a nice idea just came to my mind - if I have large scene (logarithmically scaled) any movement with cam would move it in position like (12345,0,0) or further. If there would be a a function to tell cam that this new far position is now (0,0,0), and all scene object were recalculated according to this new cam position (or I can say the center of everything), that will definitely spare a lot of time and nerves.
Thanks!
I wrote a set of convenience classes with names like "Rotator", "Translator", etc that all take into account the scale. It's a very simplistic approach, but it seems to have put us in the safe zone for what does and doesn't cause graphical glitches. Since we don't need accuracy down any closer than hundredth of a meter, we can essentially divide the whole scene by 100 without losing any accuracy.
To demonstrate what I mean by this, a float will have precision to the fourth place: 45.1234, when thinking of a single float unit as a meter, this is accuracy to the ten thousandth of a meter! Dividing by 100 gives us .4512, which in a scene scaled down by 100 would equate to 45.12 meters.
Under the hood, it basically looks like:
//SCENE_SCALE is a constant in the class
public void moveX(int metersToMove){
spatial.getLocalTranslation().setX(spatial.getLocalTranslation().getX()+(metersToMove/SCENE_SCALE));
}
1 Like
Have you looked into Celestia? If you want realism concerning space travel, this might be the reference. Its open source space exploration software, unfortunately in C++. I played around with it some time ago, mainly to understand how it works, but didn't get that far ("Time, never enough time…"). It uses an octree for spatial partitioning, which I roughly extracted into some Java classes but didn't use so far.
I'm not sure about what type of numbers they used for global positioning, think it was the equivalent to BigDecimal or something. Will post again later on that.
edit: Celestia uses BigFix for universal coordinates. Don't really know how they convert for the engine though. But I guess its too high precision for a game, even on universal level.