Hi Nout, federico, all.
Thank you for their attention Nout.
If to you it doesn't bother them I would like to ask in the forum and not for private, there will surely be a lot of people that interests him this topic.
I will try to be it more clear possible, my english is not very good.
You wrote:
Tokamak is not using a real unit system and the integration into RF was just 1 texel to 1 Tokamak unit.
Ok. That is to say Tokamak unit is generic, they don't represent meters or feet.
Is equal that Genesis3D. Right ?
I could make the same thing with Newton, that is to say one GenesisUnit = one NewtonUnit (Newton unit are meters).
But I have a problem with this.
To simplify the problem I outline it in a dimencion.
Let us suppose that I have a room of 1000 GenesisUnit of lengthy, that now they are 1000 NewtonUnit, that is to say 1000 meters.
Now, Let us suppose that I have a car of 3.5 GenesisUnit of lengthy or meters.
If I draw my automobile with this measure, the automobile will see very small in the room. Right?
One room of this measure is not very big and even so my car is very small.
Extracted of Newton help:
the physics system in theory should be dimensionless, however in practice the engine have to be implemented with limited precision floating numbers and is also built for real-time simulation, it is inevitable that tolerances have to be used in order to increase performance, and reduce instabilities. These tolerances make the engine dimension dependent, for example let say a rigid body is considered at rest when its velocity is less than 0.01 units per second for some frames. For a program using meters as unit this translate to 0.01 meters per second, however for a program using centimeter this translate to 0.0001 meter per second, since the precession of speed is independent of the unit system, this means that in the second system the engine has to work much harder to bring the body to rest. A solution for this is to scale all tolerances to match the unit system. The argument globalScale must be a constant to convert the unit system in the game to meters, for example if in your game you are using 39 units is a meter, the globaScale must be 39. The exact conversion factor does not have to be exact, but the closer it is to reality the better performance the application will get. Applications that are already using meters as the unit system must pass 1.0 as globalScale.
In Newton version it is not possible to modify the variable globalScale.
That is to say I am forced to use 1 unit = 1 meter, I could use a scale of 20 GenesisUnit = 20 NewtonUnit = one meter and my automobile would have this way 3.5 * 20 of lengthy.
Is the problem that I am not sure if this affected the simulation or not?
Already ask in Newton forum, but I don't have answers
Perhaps for that they don't understand the problem or because it is very easy of solving and I don't realize
How this resolved one this in Tokamak?
In tokamak there are not problems if I define an automobile of 150 units of lengthy?
I am not sure of explaining the problem well .
You wrote:
ODE offers more features and more flexibility, but is also more expensive in CPU time.
I was investigating on ODE and I can use the scale that I want there are not defined units.
I can define 20 unit = one meter (theoretically )
You wrote:
Not sure what your goal is, but Newton integration with more modern open source 3D engines are.
Yes, NewtonOgre implementation for example.
But it seems that this Engine doesn't have this problem
Advance thank you
KIKO
Tokamak/Genesis3D Code
Units: Real physics works of course with units. Eg acceleration of a car can not be unit-less, it's some meters/second. As physical engines are based on integration methods, errors in the precission of calculations are accumulated and increase to bigger errors. Therefore mathematical tricks are used and using a "reasonable" unit system helps to keep these errors small and make the simulations more stable.
On the other hand, 3D engines also use calculations, but not so much integration. Consequently 3D engines in general suffer less from calculation errors. There are of course exceptions, sure, but realistic speaking, when you turn an object 1000 times, it's less critical in a game to be within 0.0001 radian accurate positioned... while for physics this integeration happens all the time and any error will affect the next simulation result. So the idea is to use the best unit system a physics engine works with and to apply the same unit system to your 3D objects. If this is 1 texel or 10 or 100 in general will not make so much difference for the 3D engine, while it does for physics. Eg Tokamak is more stable when you apply a gravity of only 0.96 rather then the real gravity of about 9.6 we all live in.
The example you give is rather exceptional. Most physics engines like small dimensions, so not meters, but some centimeters. The reason can be understood in the following way. Assume a physical object was bouncing and finalizes his movement to come to rest. This "rest" is the part where the integration will work with numbers close to zero to finally converge to zero. In reallity you never get to zero, but always a little bit positive and the next iteration cycle it will be a little bit negative, so on average, you will be close to zero. Now if you work with large units, you will swing with "large" values around zero and thus not come to rest but oscillate (is unstable). If you work with smaller units, you will come to nearly rest (very small forces and movements no longer seen). And if you would work with too small units, the errors in your calculations will determine if you go slightly positive or negative instead of the real physical forces, so you pure integrate the precision of you CPU, rather then any physics still involved, making the object to show stange movement. This I hope illustrates why you need "reasonable" dimensions. Not too small, not too big.
In your example you think in real meters. In a game, a unit is in fact not important. What is important is that all object are proportionally correct sized relative to eachother. The real size you will see it depend on zooming in and the size of your screen, the pixels you have etc.... So when you build a game, you best draw objects in the unit best fitting to the physics, and not worry too much about absolute units but only about relative proportions. For Tokamak, he like units in the order of 0.1 to 10 texels only, so far below meters.
You talk about a room of 1000 meters and a car of 3.5 meters. A room of 1000 meters is already quite huge for an engine like RF / Genesis. More realistic is to think in a builing of 15m*15m (in real live thats already a nice size) with a car of 3.5m. In RF, I would use the standard units scaled down by at least 10 time. It's all a matter of building up your code flexible to easy adopt units and to experiment a bit what works more stable. For the reasons described earlier, it's clear that large units and very small units will fail to give a decent result.
Hope this can help
On the other hand, 3D engines also use calculations, but not so much integration. Consequently 3D engines in general suffer less from calculation errors. There are of course exceptions, sure, but realistic speaking, when you turn an object 1000 times, it's less critical in a game to be within 0.0001 radian accurate positioned... while for physics this integeration happens all the time and any error will affect the next simulation result. So the idea is to use the best unit system a physics engine works with and to apply the same unit system to your 3D objects. If this is 1 texel or 10 or 100 in general will not make so much difference for the 3D engine, while it does for physics. Eg Tokamak is more stable when you apply a gravity of only 0.96 rather then the real gravity of about 9.6 we all live in.
The example you give is rather exceptional. Most physics engines like small dimensions, so not meters, but some centimeters. The reason can be understood in the following way. Assume a physical object was bouncing and finalizes his movement to come to rest. This "rest" is the part where the integration will work with numbers close to zero to finally converge to zero. In reallity you never get to zero, but always a little bit positive and the next iteration cycle it will be a little bit negative, so on average, you will be close to zero. Now if you work with large units, you will swing with "large" values around zero and thus not come to rest but oscillate (is unstable). If you work with smaller units, you will come to nearly rest (very small forces and movements no longer seen). And if you would work with too small units, the errors in your calculations will determine if you go slightly positive or negative instead of the real physical forces, so you pure integrate the precision of you CPU, rather then any physics still involved, making the object to show stange movement. This I hope illustrates why you need "reasonable" dimensions. Not too small, not too big.
In your example you think in real meters. In a game, a unit is in fact not important. What is important is that all object are proportionally correct sized relative to eachother. The real size you will see it depend on zooming in and the size of your screen, the pixels you have etc.... So when you build a game, you best draw objects in the unit best fitting to the physics, and not worry too much about absolute units but only about relative proportions. For Tokamak, he like units in the order of 0.1 to 10 texels only, so far below meters.
You talk about a room of 1000 meters and a car of 3.5 meters. A room of 1000 meters is already quite huge for an engine like RF / Genesis. More realistic is to think in a builing of 15m*15m (in real live thats already a nice size) with a car of 3.5m. In RF, I would use the standard units scaled down by at least 10 time. It's all a matter of building up your code flexible to easy adopt units and to experiment a bit what works more stable. For the reasons described earlier, it's clear that large units and very small units will fail to give a decent result.
Hope this can help
-
kikosmalltalk
- Posts: 37
- Joined: Mon Sep 25, 2006 1:12 pm
Hi Nout, all
Thank you again, very nice explanation.
I have left very clear because I should not use very big or very small units.
You wrote:
You talk about a room of 1000 meters and a car of 3.5 meters. A room of 1000 meters is already quite huge for an engine like RF / Genesis. More realistic is to think in a builing of 15m*15m (in real live thats already a nice size) with a car of 3.5m.
Yes. I use it as example to show which is the problem.
You Wrote:
In RF, I would use the standard units scaled down by at least 10 time.
OK. Surely this it is the key so that I can solve the problem.
In code you do this whit the actors: " actor scale: 1/10 ". Or their equivalent one is C++. Right?.
You wrote:
In your example you think in real meters. In a game, a unit is in fact not important. What is important is that all object are proportionally correct sized relative to eachother. The real size you will see it depend on zooming in and the size of your screen, the pixels you have etc.... So when you build a game, you best draw objects in the unit best fitting to the physics, and not worry too much about absolute units but only about relative proportions.For Tokamak, he like units in the order of 0.1 to 10 texels only, so far below meters.
OK. I should adopt 1 unit = 1 meter, since Newton uses meters.
Then it is alone a zoom problem, to see more big or more little my objects. Right ?
This way I can work perfectly with meters
I believe that I was drowning in a glass of water
Thank you again
KIKO
Thank you again, very nice explanation.
I have left very clear because I should not use very big or very small units.
You wrote:
You talk about a room of 1000 meters and a car of 3.5 meters. A room of 1000 meters is already quite huge for an engine like RF / Genesis. More realistic is to think in a builing of 15m*15m (in real live thats already a nice size) with a car of 3.5m.
Yes. I use it as example to show which is the problem.
You Wrote:
In RF, I would use the standard units scaled down by at least 10 time.
OK. Surely this it is the key so that I can solve the problem.
In code you do this whit the actors: " actor scale: 1/10 ". Or their equivalent one is C++. Right?.
You wrote:
In your example you think in real meters. In a game, a unit is in fact not important. What is important is that all object are proportionally correct sized relative to eachother. The real size you will see it depend on zooming in and the size of your screen, the pixels you have etc.... So when you build a game, you best draw objects in the unit best fitting to the physics, and not worry too much about absolute units but only about relative proportions.For Tokamak, he like units in the order of 0.1 to 10 texels only, so far below meters.
OK. I should adopt 1 unit = 1 meter, since Newton uses meters.
Then it is alone a zoom problem, to see more big or more little my objects. Right ?
This way I can work perfectly with meters
I believe that I was drowning in a glass of water
Thank you again
KIKO
The exported models are not good because they export every brush and every side of every brush - if you have a terrain inside the level you end up having like 3 or 4 times more faces than you had when you were compiling the stuff.
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
(semiofftopic) If only the visibility calculations were applied to levels as they were exported to 3ds... (/offtopic)
RF2 site: http://realityfactory2.sourceforge.net/
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
RF2 tasks: http://sourceforge.net/pm/?group_id=179085
-
kikosmalltalk
- Posts: 37
- Joined: Mon Sep 25, 2006 1:12 pm
