NewtonSetWorldSize and unfreezing

[rvangaal]

Hi,

I'm doing the following with Newton 2.07 (race game):
- read a list of objects, create physics bodies as you go along. Many objects are >100m away from the origin.
- at the end, calculate a bounding box of all bodies and call NewtonSetWorldSize()

The world starts with a cube of 100m, so most objects are frozen. For example, I have cones around a race track. My car is able to move, but as I hit a cone, I can see the car react (drives over the cone) but the cone doesn't move.
If I set a big worldsize before loading it all works (cone is hit and flies off). I'm trying to unfreeze the bodies:

NewtonBody *body;
for(body=NewtonWorldGetFirstBody(world);body;body=NewtonWorldGetNextBody(world,body))
{
// Wake up
float v[3]={ 0,1,0 };
NewtonBodySetVelocity(body,v);
NewtonBodySetFreezeState(body,0);
}

But this doesn't work. An older thread suggested to call NewtonBodySetAutoFreeze() but that function doesn't exist anymore in 2.07.

Any ideas?
Thanks.

[Julio Jerez]

few bug had been fixed on tha regard, we are at version 2.10 soon to be 2.11

[rvangaal]

Thanks, I'm going to try that (a bit late).
Note that all the newton.h files have this:

---
//********************************************************************
// Newton Game dynamics
// copyright 2000-2004
// By Julio Jerez
// VC: 6.0
// One and only header file.
//********************************************************************

#ifndef NEWTON_H__736495_6495_076__INCLUDED_
#define NEWTON_H__736495_6495_076__INCLUDED_

#define NEWTON_MAJOR_VERSION 2
#define NEWTON_MINOR_VERSION 00
---

Might be time to update those comments. And perhaps keep updating the NEWTON_MINOR_VERSION.
I'll let you know here how it goes with the dynamic world resizing.

[rvangaal]

Good news! The problem of world resizing is fixed now.

[Julio Jerez]

If you are reading this, I have a question
How do you handle large worlds?
do you limit there tracks to small sizes.
I have worked on archaded race games before and we always run in the problem of float losing accuracy,
on PC for I76, I-82 we solved the problem by making the matrix have the rotation part in 32 bit floats and the position in 64 bit floats.
In consoles you cannot really do that without losing lots of performance, plus the matrix class becomes very awkworks to work with.
If you are having large tracks maybe you will be interested in a new feature that will be available in 3.00
that is un limited world size, but still using single person floats.

3.00 is a drop in replacement for 2.00, with newt funtions.
one function is NetwonSetCameraPosition.
this will set a center that will tell the engine the world oaring, and will calculate the location of all bodies relative that that center.
so let us say you have a track tsh is 40 kilomiter long, or say one teh is 100 kilomiter long.
when the camera is at the origin, the car loo good no jitter, but the played car is say 20 kilometer away from the origin, they are a lot.

this new function you can call
NewtonSetCameraOrigin (position)

the location of each body will be relative to that origin, therefore the body position will not jitter

essentially this is done by the body encoding the location as the sum of two or more float,
one floats hold the high position while the other hold the single lower precision,

all callback will get a offset matrix relative to a high precision value, for example a joint will make sure the low offset have the same high precision so all calculation are on the same offset, simulate the scientific notation math.

function NewtonSetCameraOrigin (position) will just set the high offset to a value that will allow to render bodies close to the camera and in field of view to keep rendering accuracy.
This will also allow for streaming worlds of unlimited sizes, even space size sim with detail bases on different planets.

Pople using 2.00 or not using that new function should not see any difference since all high ofsset will be zero.

[JernejL]

This 3.0 feature sounds actually VERY interesting, especially for simulating space scenes.. So newton will simply internally "translate" the best part of floating point range to the active part of world, not worrying about precision loss? wouldn't this be a costy step?

Also a suggestion - Perhaps a better name for the function: NewtonWorldSetOrigin, since it has nothing to do with camera really, but the simulation.

[Julio Jerez]

The operation is not costly at all. It is not exactly translation the world origin, basically this is a technique that CPU use to implement virtual memory, and multitasking operation system.
It works like this:
Everybody in body matrix is compost of two parts, the real address and the virtual address just like is a computer.
The real address is and address that is compose by the sum of few float values, say 4 float, (the number is irrelevant and does not affect the performance.
The virtual address will and offset part of the real address.

Say for example you have computer and you launch the same program twice. Say the program is not complete in a way that is can be memory independent, therefore it can only works in one fix location in memory.
What the operation system does is that is use a feature of the CPU called virtual address space.

What that is, is that it finds a free place in the lineal memory space, where the program fixes.
Then it calls the operation system to create a Virtual address space for the address and the size of eth program.
The OS places that address range into a look table all starting with the initial origin.

Then the virtual address mechanism is set make that every address between the origin and the range is substrate for the initial address using the hardware.

For example say a program start at address 0 and it is 1000 byte long
Say you lance the program the first time.
The OS find that location 5000 is free, and it call the OS to make a virtual address space at location 5000, 1000 bytes long.
The CPU returns the segment index.
The OS now run eth program at address 0, by the hardware know that at that segment anything less than 1000 sue be added to 5000,
So the program runs normally at for address 0, to 1000, but in reality it is locate at 5000 to 6000.

If you launch the same program again The OS fin the next available address space. An repeat the same process, so you can have more than one copy of the same program all running on same address virtual address, but internally they are running on different lineal addresses.
When the OS run out of linear memory, this functionality also extends easily to Storage space.

How does this translate to our game?

The matrix of a body remain the same they location is the address of the body.
In addition each body will also have a virtual address which is made from the sum of several float values.

Now say you are making a multiplayer space game and you has tow player large world,
In your side you are looking at the world form you player which is say near the origin, but another player is looking the world from his location which is say 100,000 miles away.

Both players can only see as far as the camera cal reach which is say 4 miles.

What you do is that you for you call you say Set Virtual address by passing the location of you player
And all call back will make the bodies location relative to that position. But internally the real address remains the same. The other players made the same call but they pass their player location and from his view point everything is relative to his location.
As you can see the functionality is not a Camera function but it can be use for that.

Any Game that does not use that feature still work the same way since all real address will have the sam segment and as long as bodies do not pass the limit of Victual address precision the they offset will no change.


For that there will be a function that set precision of the virtual address, for example
Say the precision is set to 6 significant decimal digit

Is a body location is say: 10.0031 is the X direction
Say another body is at the same location but 100000 units away.
Than would be 100010.0031
As you can see that number require more than six digit of float precision to keep all it significant digits.

The engine will keep those tow address as

Body1 0.0e0 + 1.00031e1
Body2 1.0e5 + 1.00031e1

The magic of floating point arithmetic allows for this to work automatically with very lithe performance impact.

If you are on body1 you set segment at zero,
For your body1 zero will be at 0.0 and body tow at 100010.00 but you could not see the second body, so it does not matter, you will see without jitter anything in the view frustum.

If the other player is on body2 he set segment at 100000,
he sees his body2 at 0.0 and the body1 at -100010.00

[rvangaal]

I spent a day or so on this once, trying to translate all objects to the origin. However, I hadn't read things correctly and did everything in floats, so no change there.
My method is indeed just to limit the playfield to around 5km x 5km. However, at those extremes you do notice things to jitter indeed.
I tried to plot the XY coordinates, which did seem quite ok. I couldn't really tell whether it was the gfxcard that made things worse when I passed it floats for vertex positions.

The hard point for me would be how to do graphics; I store the whole race track in VBO's (on the gfxcard). For those absolute positions, I'd need to offset 3D objects to come back near the origin, then while painting, offset them relative to the camera origin and the objects original origin. Hm. So all blocks of 3D would be located near (0,0,0), only to be offset relative to the camera origin.

[Julio Jerez]

Ha but that is where Newton 3.00 will come to kelp.

The idea is that working with floats you will still keep all the presition even if a tracks are 30, 40 or even 100 miles.
for the graphics part of large mesh there is also a solution, basically the mesh is save with an offset.
The Archemedia tool can be use to hep with that eiteh by a plug in or by linking the library you editor.
the Mesh archive (alchemedia) will clip the mesh into segment that will be gurateed to not drift when rendered from seperate camera segment.

so basically all you will need to do is to call the world to see what segment the Camera is and the mesh will be resnder corrently in the correct position.
I will make a demonstration.