Quote:Original post by cgrant
Although precision is an issue, I assume that you may eventually want to visualize your universe sometime. If this is the case, you are going to be constraint on how far you can 'see'. So why would you waste time simulating stuff that is no where near your field of view?

There are two reasons: First, the player should have multiple ships which shall not be constrained by "don't move your ships too far away from each other". The second reasons is that I'm concerned with floating point precision for a "single" scene. I'll have to do further tests, but if I only have 7 decimals of precision and I want to achieve a useful resolution, like 1 cm (1.0f being 1 meter) I can simulate up to 10km and that's it, which ain't that much in space.

Quote:Original post by AndyPandyV2
Bullet does apparently build in double precision mode, you could try that.

I just visited the site again and you're right. I didn't notice the double precision build for c# before. Thanks for the hint: It's just what I needed.

*edit*

Quote:Original post by Noggs
[Warning what follows is total guesswork - maybe someone who knows more about this can explain correctly]

CPU manufacturers are building general purpose processors, and for that purpose floating-point is a good fit. It handles really small numbers and really big numbers. If they went with fixed point then they would need to arbitrarily fix how many bits to assign to each part of the number. Some applications would work really well with the arbitrary number they chose, lots of other apps would be forced to write their own floating point layer to handle their range of numbers that fall outside of the fixed point range!

I almost forgot to answer your post. Your explanation seems reasonable. I was probably thinking too much about this particular problem which would profit from the benefits of fixed point math, but not suffer from it's deficiencies.

[Edited by - SiS-Shadowman on November 18, 2010 2:44:19 AM]

Hi,

Regarding floating point usage - I guess the most prevalent reason for using floats is that its because of the hardware. CPUs were 32-bit for a long time now and floats (4 bytes) work really well with those registers, and the ST registers.

Now imagine the development of libraries such as DirectX and OpenGL at that time and its only natural that float would be the type everyone uses. Then middleware game engines are written using that tech and that dictates some of the requirements of the engine (but not always as some calculation spaces can happen with more than 32-bit, take for example 3D studio MAX's color space which should be 48-bit if I recall).

Now, floating point are very useful and easy to grasp, conceptually. The problems arise with implementations. The fact that round-off errors exist and the problem with accurately representing numbers that are far from the origin.

For most cases, floats work really well. Even in your example it would probably work well.

Think about a spatial cell as the immediate surroundings of a group of entities. You won't want to model a system of entities that interact with one another at a distance of 10,000 Km. If you need to render them and perform collision detection and physics stuff then they are VERY close to one another.

Are you going to display a "spatial cell" as we called it that contains entities at distances of 10,000 KM from one another ? What's the point ?

Suppose you want to have a map view of the neighboring entities but they are that far away from one another. The system can still scale down quite easily, depending on the zoom factor - from how far you're viewing them:

1. If the typical diameter of the volume all entities are in is ~10K Km, you need to scale everything down so 1.0f != 1m, but more likely 1.0f is around 1 Km (BTW, there are a LOT of floating point numbers between 0.0f and 1.0f so that is good in general).

2. If the view zooms in to view the action of several ships fighting, for example, the scale is much smaller of course as the diameter of the volume they occupy is maybe a few kilometers at most.


Now, regarding one of the issues you've mentioned - the problem of spatial cells and how objects interact with them, I think you got me wrong.

You might be tempted to thinking in terms of an octree or quadtree but that's not what I was talking about.

A good example would be a dungeon in an RPG game (or God of War or any other :-)). Rooms, or sets of rooms can be spatial cells. Corridors or other areas that connect sets of rooms can be the "conduit" that connects the spatial cells.
Or, the corridor can be a spatial cell as well but that introduces the problems you're referring to.

In the context of your design - spatial cells are completely separate. One cell can depict a space fight between ships near planet A, while another cell can depict an entirely different space battle.

Ships can't move easily from cell to cell. Maybe with special means such as warp travel. Maybe if the cells are relatively close and ships are allowed to move between them you take an entity from cell 1 and an entity from cell 2 and put them both in a temp cell (or not temp, depends) and they can both interact.

Its a very fluid system but don't think about them as adjacent cells in a grid because that is a simplification that doesn't necessarily work in every context.

Thanks for the lengthy and detailed post :)

Quote:Original post by voguemaster
Hi,

Regarding floating point usage - I guess the most prevalent reason for using floats is that its because of the hardware. CPUs were 32-bit for a long time now and floats (4 bytes) work really well with those registers, and the ST registers.

Now imagine the development of libraries such as DirectX and OpenGL at that time and its only natural that float would be the type everyone uses. Then middleware game engines are written using that tech and that dictates some of the requirements of the engine (but not always as some calculation spaces can happen with more than 32-bit, take for example 3D studio MAX's color space which should be 48-bit if I recall).

Now, floating point are very useful and easy to grasp, conceptually. The problems arise with implementations. The fact that round-off errors exist and the problem with accurately representing numbers that are far from the origin.

For most cases, floats work really well. Even in your example it would probably work well.

I was about to experiment with a fixed point implementation and that's when I grasped some of the problems that come with fixed point which are no problem at all when using a floating point format. There are pros and cons to both formats, but floating point seems to do a better job when nothing specific is known about the range of values that is needed.

Quote:
Think about a spatial cell as the immediate surroundings of a group of entities. You won't want to model a system of entities that interact with one another at a distance of 10,000 Km. If you need to render them and perform collision detection and physics stuff then they are VERY close to one another.

Are you going to display a "spatial cell" as we called it that contains entities at distances of 10,000 KM from one another ? What's the point ?

It's not displaying those units I'm worried about, but rather the transition between units. There's no point in rendering a space ship that is 10km away, maybe I'll visualize it as an icon. However your cell approach doesn't quite fit into my design of a totally seamless world.

Quote:
1. If the typical diameter of the volume all entities are in is ~10K Km, you need to scale everything down so 1.0f != 1m, but more likely 1.0f is around 1 Km (BTW, there are a LOT of floating point numbers between 0.0f and 1.0f so that is good in general).

2. If the view zooms in to view the action of several ships fighting, for example, the scale is much smaller of course as the diameter of the volume they occupy is maybe a few kilometers at most.

That's really useful information. I was never really sure which unit 1.0f should represent. I picked the SI unit since I feared a precision loss if it's more than that. However since about 7 decimals of precision are guaranteed, 1km doesn't seem that bad.

Quote:
Now, regarding one of the issues you've mentioned - the problem of spatial cells and how objects interact with them, I think you got me wrong.

You might be tempted to thinking in terms of an octree or quadtree but that's not what I was talking about.

A good example would be a dungeon in an RPG game (or God of War or any other :-)). Rooms, or sets of rooms can be spatial cells. Corridors or other areas that connect sets of rooms can be the "conduit" that connects the spatial cells.
Or, the corridor can be a spatial cell as well but that introduces the problems you're referring to.

In the context of your design - spatial cells are completely separate. One cell can depict a space fight between ships near planet A, while another cell can depict an entirely different space battle.

Ships can't move easily from cell to cell. Maybe with special means such as warp travel. Maybe if the cells are relatively close and ships are allowed to move between them you take an entity from cell 1 and an entity from cell 2 and put them both in a temp cell (or not temp, depends) and they can both interact.

Its a very fluid system but don't think about them as adjacent cells in a grid because that is a simplification that doesn't necessarily work in every context.

I totally got you wrong. I was thinking about an octree when I wrote that post before. The system you're proposing should work very well, since those cells are completely separate. They've been used in several games like the X series or Eve: Online. I've played the latter for some hours and they did a really nice job on the transition between those cells: It creates the illusion of not being constrained at all.
The X-Series didn't disguise their approach at all and those games are totally awesome. However a sector having a diameter of ~50km still makes me laugh.
Maybe I'm aiming for something different, but I want a completely seamless world where I'm not constrained by "sectors/cells/whatever".
From what I understood so far, I could achieve at with floating point precision. However the player must keep it's ships together so they "fit" inside one scene. Things that move outside this scene get unloaded and new stuff gets loaded, once it's near enough.

And, lets not forget its possible to represent cell locations or even object locations using 64-bit fixed point with a small number of fractional bits (which gives great range).