I need some advice for getting the best use of Edyn in my space game.

[metric-tensor]

I am working on a client/server space exploration/adventure game using libyojimbo. Space is BIG, I am using high precision numbers to store my positions. To deal with this I am planning on using spatial rebasing of the origin when two or more objects are close enough to interact with each other, for example a ship approaches a planet, so that I can convert the coordinates to double precision with a 'virtual' origin. My dilemma stems from when this occurs in two locations very far away from each other. From the physics side I see two ways to handle this:

• spawn a new instance of Edyn for each group of objects sharing the same virtual origin
• add all objects to the same Edyn instance and assign each group of objects sharing the same virtual origin the the same collision filter bit so that objects from different physical locations can't affect each other.

The second option seems to be a cleaner path but would require the server to send client messages based on collision filter along with, or instead of, the client AABB. It would also limit me to 64 "groups" as I believe that's how many collision filter bits there are. This I can live with.

Thoughts? Is there a better way?

[xissburg]

I imagine this would require modifying the internals of the engine so it can support simulating virtually infinite worlds. One thing I have spent some time thinking about but have not implemented yet is origin shift, but that is not enough in this case. One solution I can think of is splitting space into cubes where each cube has its own broadphase tree and the center is the virtual origin. All calculations are done in its object space. This would allow you to still use a single registry and the whole thing would be transparent. Perhaps the value stored in edyn::position is always the position in local cube space, and there's an additional component that holds the integral coordinates of the cube. But I think there are better solutions for this. I don't know anything about space simulators, so it must be worth doing some research on other methods and then we can figure out how that can be incorporated into Edyn.

[metric-tensor]

Unfortunately there's not a lot of info out there, space sims that take real distances into account are fairly niche. Origin shift on its own is adequate for a single player game but starts to fall apart with multiplayer. I know some people create a new physics "world" for each virtual origin but that seems like a lot of overhead. I agree the edyn::position would be relative to the virtual origin, your object just then needs to keep a reference to its virtual origin when calculating its absolute position.

For my galaxy container I use an octree optimized for range searching. It stores all of the static objects ( stars, space stations, etc ) and allows me to quickly find what is within a specified distance of a given point. I could easily add virtual origins to it and do a nearest neighbor search to find the closest virtual origin to a ship or whatever.

[xissburg]

Space is something of massive scale and great sparsity, so we have to leverage levels of detail and hierarchical space partitioning.

Levels of detail means running separate simulations for each level of the universe, such as one simulation for galaxies, one simulation for each solar system in each galaxy, one simulation for each planet in each solar system, and finally, one simulation that happens at the highest level of detail at the surface of each planet and each space ship/station. Each simulation runs at a scale that is adequate for the size of the objects being simulated. At the correct scale, these objects could be simulated just fine as rigid bodies in Edyn with gravitational forces between them, and even collisions. I am not sure if it is accurate enough though to maintain stable orbits. Probably yes if you use a very low fixed delta time.

Space partition can be used to locate these entities in space, such as a dynamic bounding volume tree, which is what Edyn already uses.

Simulating these individual objects in the universe with gravitational forces seems simple enough. The interesting part is simulating the relatively small stuff such as space ships, stations, asteroids… this is where you’d need to shift origin and maybe employ a multilevel space partitioning, perhaps using an octree with integral coordinates where each point represents a sector of 4km^3. Every small object has a edyn::position plus extra components for the sector coordinates, which could be multiple, I mean there could be three levels for example, so the first coordinate tells into which sector of the universe you are (a sector which could be one light year long on each side for example), then the next level exists inside of that sector and then you have another set of coordinates for that level in a sector that’s smaller, and so on…

It gets interesting when you’re actually descending into the highest level of detail which would be landing on the surface of a planet. I imagine you’d not simulate the surface of a planet like just a spherical object centered at the planet’s position. Instead, you’d simulate individual chunks which could be kinematic objects that have their trajectory derived from the position and orientation of the planet they belong to. The contents of the chunk would likely be generated procedurally so I guess each chunk would simply have the inputs to pass to the procedural terrain and city generator and when the chunk is needed it would generate the triangle mesh and so on.

Just a bit of brainstorming…

[metric-tensor]

I agree with everything above.

In my case I wasn't planning on doing any n-body gravitational simulations for planets and other orbiting bodies to keep the computation down and the stability up. I use density wave theory to procedurally generate spiral galaxies. I wrote a solar system generator that creates a procedural solar system from a random seed stored for each star. Orbital elements are precalculated using Kepler's laws to speed the computation for orbital position as a function of time at runtime. My thought was to trigger this whenever a ship gets close enough to it to matter, it can then be kept and cached or discarded when the last ship leaves.

I agree, the small stuff is where it gets interesting, anything player controlled does need to have n-body gravity applied, etc. While I would love to support landing on planets, in reality this is a one man show and I am not getting any younger. I am trying to scale back to reasonable limits. Don't tempt me :)

[metric-tensor]

I am using a double-double data type which gives me 106 bits of precision.

[xissburg]

Simulating an entire galaxy is definitely intense, but it seems reasonable at a much lower scale than real galaxies. Having the ability to do the full trip from the surface of one planet to another would be incredible to achieve, and it seems like a reasonable thing with multiple levels of detail. But you also have to consider the visual/rendering aspects of this, which might be more complex than the physics itself. It all sounds reasonable, it's just a whole lot of work and it's complex to organize everything. Then also considering networking and distributed simulation... it sounds very sexy and tempting but it certainly is a whole lot of work.

[metric-tensor]

Have you used Edyn with Yojimbo? I think I am getting some conflicts with Yojimbo's serialization macros.

[xissburg]

No I haven't. I don't know much about it. Just had a quick look. What errors do you get?

[metric-tensor]

A lot of errors like the following:

1>In file included from main.cpp:6:
1>In file included from ..\basis\edyn\include\edyn/edyn.hpp:31:
1>In file included from ..\basis\edyn\include\edyn/shapes/create_paged_triangle_mesh.hpp:7:
1>In file included from ..\basis\edyn\include\edyn/parallel/parallel_for.hpp:9:
1>..\basis\edyn\include\edyn/serialization/memory_archive.hpp(32,25): error : too few arguments provided to function-like macro invocation
1>..\basis/yojimbo\yojimbo.h(3141,13): message : macro 'serialize_bytes' defined here
1>In file included from main.cpp:6:

[metric-tensor]

Looks like Yojimbo uses a bunch of macros for serialization:

    #define read_float                  serialize_float
    #define read_uint32                 serialize_uint32
    #define read_uint64                 serialize_uint64
    #define read_double                 serialize_double
    #define read_bytes                  serialize_bytes
    #define read_string                 serialize_string
    #define read_align                  serialize_align
    #define read_check                  serialize_check
    #define read_object                 serialize_object
    #define read_address                serialize_address
    #define read_int_relative           serialize_int_relative
    #define read_ack_relative           serialize_ack_relative
    #define read_sequence_relative      serialize_sequence_relative

Some of these conflict with Edyn (read_bytes) for example. I suppose I can undefine them before including Edyn or I might just investigate other networking libraries.

[xissburg]

That's a problem in their library. I do not use macros and everything is in the edyn:: namespace. There are a few #defines but they all have the EDYN_ prefix.

[metric-tensor]

Going to try ENet

[metric-tensor]

Got ENet up and going! What integrator does Edyn use?

[xissburg]

Great!

Semi-implicit Euler.

[metric-tensor]

What are the rules of thumb regarding physics update rate on the client vs the server?

[xissburg]

Generally you want to send out updates as often as possible, but that has bandwidth and performance implications. Usually the snapshot rate in the client is higher than in the server, because you want client inputs to reach the server as often as possible. Also client packets are generally smaller than the server packets, since client packets will only contain info about entities owned by the client while the server is sending the state of most or all entities that are close enough to entities owned by the client (there's an AABB of interest which is set for each client and the entities in that AABB are included in the snapshots).

You can start with 20-30 snapshots per second in the client and 10-15 snapshots per second in the server and see how it goes. Ideally these rates should be dynamic and adapt to network conditions but that becomes a little tricky to do...