Last night at about 1 a.m. I was trying to put some tests to reveal the difference in calculating floats and doubles. The idea was simple - fix a time when the test stars, put in a loop for 1 million times some equations like multiplying and finding a square root of the number, and then fix the end time so do subtract it from the start time.
In first test floats were used. The number like 123456.78 was multiplied, divided, square rooted and etc. for fixed amount of iterations. And then, using doubles (big numbers from previous post) the same type of test was performed.
I was shocked that rather small float numbers had a higher results than doubles!
This is truly the result that let me think more closely to use doubles instead of floats without any doubts regarding performance.
Wednesday, March 10, 2010
Tuesday, March 9, 2010
Matter of scale
Yesterday I was thinking more closely about numbers to understand the scales of the star system(s), and ways to deal with them.
I started from understanding how far is the distance from our Sun to the last planet. According to Wikipedia, the Neptune is about 30 AU (astronomical units. 1AU = 149’597’871 kilometers, or 92’960’000 miles). Objects of Kuiper belt, or so called trans-Neptunian objects, may be placed at the distance not far from 55 AU in their average radius, and it consists mostly from small objects, like asteroid belt. The biggest body of Kuiper belt is Eris, which has 97 AU in aphelion and 37 AU in perihelion. Beyond Kuiper belt lies The Oort cloud - a hypothesized spherical cloud of comets which may lie roughly 50’000 AU, or nearly a light-year, from the Sun. Oort cloud consists from asteroids, space dust and comets.
So, for the star like our Sun (G2 star), which has a mass of 1.9+E30kg. the distance from its center to the farthest object could be around 1’000 AU, or about 1.49+E11km. A thousand AU came from the idea that if I want to make project close to reality, I may close my eyes on every and very far object in the star system, but, never the less, make enough space to model some really far objects. My guess is that this number can easily be divided even 10 times, and it will be more than enough, and later I will use the number of 100 AU for the stars like our Sun.
But! According to this nice article, O-class stars may have mass from 15 to 90 times more, than the mass of the Sun. Taking in account the dependency of gravity force from objects mass by Newton’s law, such big stars will have the same about of gravitational force at the distance of square root of mass. So, if the mass is 90 times bigger, then the distance will be a bit more less than 10 times.
With all that in mind, I need to be able to operate with the distances of 1’000 AU for a single star.
According to Wikipedia, almost half of the stars in our galaxy are systems of two stars, or binary star systems, where 2 stars floats around their center of mass. It is written there that some binary systems may have more suitable conditions for planet formation, rather than single stars may have.
But let’s fantasize a bit and assume that even star systems with 3 or 4 stars may have a condition to form planets (stable or not), and to be able to make and fly around such star system I will need, let’s say the double space I have calculated.
So, 2’000 AU will be enough for any condition and any star in my virtual galaxy. And it is equal to 299’195’742’000 km, in every direction from the star system center. That is a HUGE space. By the way, if I move with the speed of light (which is equal to 299’792 km/sec.) I will need about 693 days, or almost 2 years to travel from the center of star system to its boundaries. But why should I worry? I have a hyperspace drive, haven’t I? :)
If I want to have a precision of 1 meter in my project, I will need to be able to operate with the numbers from -2.99+E14 to +2.99+E14, which can perfectly be held by double precision floating points. But dealing with doubles every time with every object may significally decrease the performance.
I came up with idea of so called local space and global space to, probably, solve performance issues I might have, if I use doubles everywhere. The idea is to render/calculate everything using global scale units when player’s cam isn’t near any global object of star system (global units have a precision of, let’s say 10000 km), and switch to local (coordinates), when player’s cam enters some certain region near any global space object, for example planet. If we assume that each space body has its global coordinates, then local space would be bounded and centered to the current position of the body.
Switching back and forth from global to local coordinates should probably spare some CPU power and give me necessary precision.
I should post some more thoughts on this idea later.
I started from understanding how far is the distance from our Sun to the last planet. According to Wikipedia, the Neptune is about 30 AU (astronomical units. 1AU = 149’597’871 kilometers, or 92’960’000 miles). Objects of Kuiper belt, or so called trans-Neptunian objects, may be placed at the distance not far from 55 AU in their average radius, and it consists mostly from small objects, like asteroid belt. The biggest body of Kuiper belt is Eris, which has 97 AU in aphelion and 37 AU in perihelion. Beyond Kuiper belt lies The Oort cloud - a hypothesized spherical cloud of comets which may lie roughly 50’000 AU, or nearly a light-year, from the Sun. Oort cloud consists from asteroids, space dust and comets.
So, for the star like our Sun (G2 star), which has a mass of 1.9+E30kg. the distance from its center to the farthest object could be around 1’000 AU, or about 1.49+E11km. A thousand AU came from the idea that if I want to make project close to reality, I may close my eyes on every and very far object in the star system, but, never the less, make enough space to model some really far objects. My guess is that this number can easily be divided even 10 times, and it will be more than enough, and later I will use the number of 100 AU for the stars like our Sun.
But! According to this nice article, O-class stars may have mass from 15 to 90 times more, than the mass of the Sun. Taking in account the dependency of gravity force from objects mass by Newton’s law, such big stars will have the same about of gravitational force at the distance of square root of mass. So, if the mass is 90 times bigger, then the distance will be a bit more less than 10 times.
With all that in mind, I need to be able to operate with the distances of 1’000 AU for a single star.
According to Wikipedia, almost half of the stars in our galaxy are systems of two stars, or binary star systems, where 2 stars floats around their center of mass. It is written there that some binary systems may have more suitable conditions for planet formation, rather than single stars may have.
But let’s fantasize a bit and assume that even star systems with 3 or 4 stars may have a condition to form planets (stable or not), and to be able to make and fly around such star system I will need, let’s say the double space I have calculated.
So, 2’000 AU will be enough for any condition and any star in my virtual galaxy. And it is equal to 299’195’742’000 km, in every direction from the star system center. That is a HUGE space. By the way, if I move with the speed of light (which is equal to 299’792 km/sec.) I will need about 693 days, or almost 2 years to travel from the center of star system to its boundaries. But why should I worry? I have a hyperspace drive, haven’t I? :)
If I want to have a precision of 1 meter in my project, I will need to be able to operate with the numbers from -2.99+E14 to +2.99+E14, which can perfectly be held by double precision floating points. But dealing with doubles every time with every object may significally decrease the performance.
I came up with idea of so called local space and global space to, probably, solve performance issues I might have, if I use doubles everywhere. The idea is to render/calculate everything using global scale units when player’s cam isn’t near any global object of star system (global units have a precision of, let’s say 10000 km), and switch to local (coordinates), when player’s cam enters some certain region near any global space object, for example planet. If we assume that each space body has its global coordinates, then local space would be bounded and centered to the current position of the body.
Switching back and forth from global to local coordinates should probably spare some CPU power and give me necessary precision.
I should post some more thoughts on this idea later.
Monday, March 8, 2010
Core object scheme and hierarchy
Today I was thinking more closely to the overall object hierarchy of the entire project. As well as the bodies in our solar system “attached” to theirs “parent” bodies (like the moon is a “child” of our Earth, it goes around the Earth, and Earth goes around the Sun), and all the space bodies goes around the Sun, my structure tries to stay closer the same hierarchy.
The scheme of object hierarchy can be seen below. Of course, I believe I will modify it in time due to some new ideas, but the core idea should look that way.
Basically almost every entity on this scheme has a name of “factory”, and it’s pretty self-explanatory. Each this entity handles the generation of the named object in the space, stores it’s parameters and handles some object routines.
For example, PlanetFactory is responsible for generating the planet body with all the stuff, that planet consists of, like surface (that’s been generated by PlanetSurfaceFactory), water (PlanetWaterFactory) or whatever liquid the planet may have, sky (PlanetSkyFactory), and maybe some more later (RiverFactory, CityFactory, etc.). Therefore PlanetFactory is a child to PlanetarySystemFactory – class, that is responsible for processing all the bodies, including the planet itself, that orbits around, let’s say, the center of mass of the planet – Planet itself, planet moons, celestial bodies like Saturn rings, asteroids, debris… If we go higher, there is a SolarSystemFactory, and, as you can guess already, stores and processes all space bodies of the star system, including the star itself, planets, asteroids and asteroid belts, comets and all others.
The scheme looks good and logical for me, and I will definitely try to follow it. Next step will be to define common variables and procedures for each node of the scheme.
The scheme of object hierarchy can be seen below. Of course, I believe I will modify it in time due to some new ideas, but the core idea should look that way.
Basically almost every entity on this scheme has a name of “factory”, and it’s pretty self-explanatory. Each this entity handles the generation of the named object in the space, stores it’s parameters and handles some object routines.
For example, PlanetFactory is responsible for generating the planet body with all the stuff, that planet consists of, like surface (that’s been generated by PlanetSurfaceFactory), water (PlanetWaterFactory) or whatever liquid the planet may have, sky (PlanetSkyFactory), and maybe some more later (RiverFactory, CityFactory, etc.). Therefore PlanetFactory is a child to PlanetarySystemFactory – class, that is responsible for processing all the bodies, including the planet itself, that orbits around, let’s say, the center of mass of the planet – Planet itself, planet moons, celestial bodies like Saturn rings, asteroids, debris… If we go higher, there is a SolarSystemFactory, and, as you can guess already, stores and processes all space bodies of the star system, including the star itself, planets, asteroids and asteroid belts, comets and all others.
The scheme looks good and logical for me, and I will definitely try to follow it. Next step will be to define common variables and procedures for each node of the scheme.
Long-awaited update
It’s been a while since I have posted the last message. A lot of thing have changed and a lot of has been redone. It’s a pity that it is now 4th rework on the simple node tree flow, but because I find it essential to the whole project, I think it’s best to find the right solution first, and then continue to make other things.
I have now switched back to Java Monkey Engine due to simplicity of coding from all my platforms that I work on every day. The experience with Ogre3d engine in that area wasn’t very good from the perspective of switching the development platform each day due to the fact that in my work time, I like to put the work away and return to the project, if I have some ideas I want to try. And in that time I work under windows. And at home I have my beautiful iMac with MacOS X in it, of course. Switching back to jME took away the problem of reconfiguring the project settings for each platform each time I put the code written form windows to mac, and vice versa. I know that it’s solvable and my lack of knowledge in that area gives me pain, but for now, it’s better for me to stay with jME to avoid them. Anyway, if you understand the problem completely (and for now, understanding the routines to handle trees for planet surface rendering is the problem), it isn’t very hard to switch to another engine in future.
At the moment I have completely decided what scheme is better for my needs of creating and handling the planet surface, and it’s ROAM. I do not remember whether I posted the link to the ROAM PDF paper or not, but I will do it now anyway. So, here’s the link.
Why ROAM is good? Well, the best way to see it is to define how I want the planet surface to be born and handled. I have found the following scheme the best:
1. Using complex procedural algorithms generate a planetary map (the vision of what the planet will look like with all the coasts, mountains, valleys, etc.) that later can be modified to add crates, rivers, cliffs, and many more.
2. Using the same algorithm make a height map.
3. Make a spherical planet body and apply map to it.
4. Using altitude as the parameter, adjust the height of the planet mesh, and add extra geometry when we approach closer to surface. This means that form space you will see a bump mapped sphere, and as you get closer to surface, the surface will slowly and smoothly change to reveal all the “heights”.
For that scheme I find ROAM is a perfect choice. Later on I will post some updates on the node and tree routines.
I have now switched back to Java Monkey Engine due to simplicity of coding from all my platforms that I work on every day. The experience with Ogre3d engine in that area wasn’t very good from the perspective of switching the development platform each day due to the fact that in my work time, I like to put the work away and return to the project, if I have some ideas I want to try. And in that time I work under windows. And at home I have my beautiful iMac with MacOS X in it, of course. Switching back to jME took away the problem of reconfiguring the project settings for each platform each time I put the code written form windows to mac, and vice versa. I know that it’s solvable and my lack of knowledge in that area gives me pain, but for now, it’s better for me to stay with jME to avoid them. Anyway, if you understand the problem completely (and for now, understanding the routines to handle trees for planet surface rendering is the problem), it isn’t very hard to switch to another engine in future.
At the moment I have completely decided what scheme is better for my needs of creating and handling the planet surface, and it’s ROAM. I do not remember whether I posted the link to the ROAM PDF paper or not, but I will do it now anyway. So, here’s the link.
Why ROAM is good? Well, the best way to see it is to define how I want the planet surface to be born and handled. I have found the following scheme the best:
1. Using complex procedural algorithms generate a planetary map (the vision of what the planet will look like with all the coasts, mountains, valleys, etc.) that later can be modified to add crates, rivers, cliffs, and many more.
2. Using the same algorithm make a height map.
3. Make a spherical planet body and apply map to it.
4. Using altitude as the parameter, adjust the height of the planet mesh, and add extra geometry when we approach closer to surface. This means that form space you will see a bump mapped sphere, and as you get closer to surface, the surface will slowly and smoothly change to reveal all the “heights”.
For that scheme I find ROAM is a perfect choice. Later on I will post some updates on the node and tree routines.
Subscribe to:
Posts (Atom)