Units, coordinates and scales

About the actual programming of the game.

Re: Units, coordinates and scales

Postby Pseudonym » Wed Nov 13, 2013 12:52 am

chaoscode wrote:1. The whole 128 Bit Coordinates are there to get the Position of an Object in Space.

We don't have to have a single number that describes the position of an object in space. Space can be tesselated into regions (presumably cubes), which can be distributed on different servers in a P2P network or cluster. The position of an object in space can then be stored as a position relative to those regions.

The reason why this is a good idea is that this is proven technology. I would wager that pretty much all MMOs work this way.

chaoscode wrote:With 128 Bit there is no need of Overflow Check.

Unless you're planning to store the entire universe on one server, the "overflow check" still needs to be there. Instead of a check as to whether or not a number has overflowed, it's a check that it's on the same server instead.

chaoscode wrote:2. For objects in the Ship there is only a need of a relative Position.

...and already you're advocating multiple coordinate systems.

chaoscode wrote:Use GPU as a CoProzessor is a quite bad Idea,
The Simulation engine is very complex and the shaders of a GPU are usualy quite small.
some parts can be implemented very good for GPU's, but then you have to think of the Overhead for Copy the results back and forth.

Copy overhead can work either for you or against you. Modern game engines tend to do skinning on the GPU because of copy overhead; vertex data can stay on the GPU, and you only need to transfer new bone transforms for each frame. Some do fluid simulation on the GPU for similar reasons.

Once again, I'm not convinced that there's a problem that needs to be solved here.
Pseudonym
 
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

Re: Units, coordinates and scales

Postby VladVP » Wed Nov 13, 2013 4:46 pm

Coordinate structure:
Code: Select all
Shared Universe (64-bit Integer Coordinate System for Servers in a 3D-Grid)
|
|---Server
|
|---Server
|
|---Server (64-bit Integer Coordinate System for Objects)
    |
    |---Object
    |
    |---Object
    |
    |---Object (Relative Arbitrary-Precision Coordinate System (Int/Float shouldn't matter)
        |
        |---Object
        |
        |---Object
        |
        |---Object (Relative Arbitrary-Precision Coordinate System (Int/Float shouldn't matter)


So we will have a global grid of servers. Each server contains an XML-like structure of parent and child objects. The child object's positions are defined relative to the parent's. Children of the very top node of a server use an absolute coordinate system.
VladVP
 
Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

Re: Units, coordinates and scales

Postby thomas9459 » Wed Nov 13, 2013 8:04 pm

Servers should probably not have sharp boundaries. Imagine if two armadas from different factions encountered one another along one of these borders: it would be much better if the encounter was simulated on one server despite being near the boundary.
thomas9459
 
Posts: 101
Joined: Thu Aug 15, 2013 6:18 pm

Re: Units, coordinates and scales

Postby croxis » Thu Nov 14, 2013 3:15 am

One option is use the spheres of influence on celestial objects as the boundary.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Units, coordinates and scales

Postby chaoscode » Tue Nov 26, 2013 3:53 am

VladVP wrote:So you suggest that we should basically just do all the heavy calculations on the CPU, and merely let the GPU render the stuff? You also have to remember that not all CPUs are 3.7 GHz beasts.

Yes, not every CPU is a 3.x GHz beast, but have you ever rent a Server with HighPerformance GPU? You have to print money by your self to pay those.
I think that a CPU (with multiple cores) has enough power if the code is good.


VladP wrote:
Chaoscode wrote:2. For objects in the Ship there is only a need of a relative Position.

...and already you're advocating multiple coordinate systems.

One is Absolute, the other relative. You can just add the relative positions to the absolute ship position to get the absolute part position.
we should use relative positions, else it would be a huge performance penality to recalculate every position of every piece of the ship every Frame!
The Coordinates are relevant for Drawing and Colision Detection.
and when we're drawing we should send relative positions from the Viewers position.
So there will allways be a calculation on every Frame.
chaoscode
 
Posts: 14
Joined: Wed Oct 09, 2013 3:02 pm

Re: Units, coordinates and scales

Postby VladVP » Tue Nov 26, 2013 9:30 am

chaoscode wrote:
VladP wrote:
Chaoscode wrote:2. For objects in the Ship there is only a need of a relative Position.

...and already you're advocating multiple coordinate systems.

Lol wtf? Pseudonym wrote that, not me.
VladVP
 
Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

Re: Units, coordinates and scales

Postby catageek » Thu Dec 05, 2013 2:12 pm

I progressed about the world position categories and their constraints, I also read Bullet documentation. Here is where I am:
- The unit is the meter anywhere in the universe.
- The physical positions will be in the range -1E15/1E15 (in meters) to keep a precision of centimeter anywhere in the physical world. The physical world contain all "small" entities that have a physical representation in the world (players, ships, and so on) and can move and collide. The physical world movement computation is managed by Bullet library. A server has one physical world.
- The astronomical positions will be in the range -1.8E306/1.8E306 (in meters). The astonomical world contain all objects that are not in the range of the physical world. In the astronomical worlds, there is no movement or collision interaction. Players, ships and game entities can not go in the astronomical world. The astronomical world will contain big objects that bullet can not manage: stars, planets, galaxies, black holes and so on. The astronomical world will be "painted" in the sky so that a full reresentation of the universe can be rendered on the screen. It will be static at first, but it can be made dynamic using Newton law. Since the astronomical world include the space occupied by the physical world, some big objects can be present in the physical world, but their movement will not be managed by Bullet (they will be "kinematics"). The astonomical world should be shared across clusters.

I nearly finished the implementation of the Bullet::MotionState class for Sigma that enables the creation of the several position sets, and performs user transformation. This will open the road to the network layer through the event manager, and to multiplayer environment. I plan to release a running code next week.
catageek
 
Posts: 39
Joined: Tue Oct 15, 2013 2:23 pm

Re: Units, coordinates and scales

Postby Zardoz » Thu Dec 05, 2013 2:45 pm

catageek wrote:- The physical positions will be in the range -1E15/1E15 (in meters) to keep a precision of centimeter anywhere in the physical world. The physical world contain all "small" entities that have a physical representation in the world (players, ships, and so on) and can move and collide. The physical world movement computation is managed by Bullet library. A server has one physical world.

Aprox. +/- 6600 AU (Pluto mean distance from Sun is 29 UA), so in theory we can handle entire solar system at scale 1:1 , but perhaps is not practical without some kind of intra-stellar FTL, plus I don't know how bullet will handle something in this size. I hope that Kerbal space kraken not happen.

catageek wrote:- The astronomical positions will be in the range -1.8E306/1.8E306 (in meters). The astonomical world contain all objects that are not in the range of the physical world. In the astronomical worlds, there is no movement or collision interaction. Players, ships and game entities can not go in the astronomical world. The astronomical world will contain big objects that bullet can not manage: stars, planets, galaxies, black holes and so on. The astronomical world will be "painted" in the sky so that a full reresentation of the universe can be rendered on the screen. It will be static at first, but it can be made dynamic using Newton law. Since the astronomical world include the space occupied by the physical world, some big objects can be present in the physical world, but their movement will not be managed by Bullet (they will be "kinematics"). The astonomical world should be shared across clusters.

Physical interaction/simulation of newton physics at the scale of LY is not practical is will be too small that we will need a life to appreciate it.

catageek wrote:I nearly finished the implementation of the Bullet::MotionState class for Sigma that enables the creation of the several position sets, and performs user transformation. This will open the road to the network layer through the event manager, and to multiplayer environment. I plan to release a running code next week.

Kudos!
Yep, I have a blog : http://zardoz.es
Emulator DCPU-16 VM
User avatar
Zardoz
 
Posts: 359
Joined: Mon Aug 12, 2013 8:54 pm
Location: Spain

Re: Units, coordinates and scales

Postby croxis » Thu Dec 05, 2013 4:21 pm

Bullet can be compiled with double support. IIRC there is some performance loss, but I do not know to what degree. There are also other ways to manage a normal float bullet system that are not available to the ksp devs.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Units, coordinates and scales

Postby Zardoz » Thu Dec 05, 2013 7:29 pm

If I remember well KSP is using a old version of physx.
Yep, I have a blog : http://zardoz.es
Emulator DCPU-16 VM
User avatar
Zardoz
 
Posts: 359
Joined: Mon Aug 12, 2013 8:54 pm
Location: Spain

PreviousNext

Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest

cron