Celestial Body or micro world simulation

[0xF6]

Im trying to create a world with planets for rts like game
And here are a few conclusions after the research:

• BigСompound doesn't really support dynamic bodies
• BodyReference.Bodies is not a list of dynamic children of the body, my hopes were destroyed after i checked sources :D

And the only idea that I could come up with is multiple local simulations of planets, for the client the coordinates will be given relative to the virtual global world
And it would probably be a good idea to allocate each simulation along the thread, idk
I would like these planets to be able to collide with each other, but I think the logic here is no more complicated than checking the distance + radius

Tell me is this really a good idea, or is there something else i don't see?

(I already tired you with my questions? :D)

[RossNordby]

From what I understand of what you're trying to do, having a per-planet Simulation does sound like the easiest way to go.

If you want the planets to collide and respond physically, you could put proxies for them into another Simulation too. The stuff on the planets wouldn't need to be in that simulation. But if you don't care about physics enginey stuff at the planet level, then you could indeed just do distance tests or whatever other simple approach works.

There's also the option of having all the planets and everything on them in one simulation, though then you'd have to deal with physically implied things like a planet spinning too fast and launching everything into space :P

[0xF6]

I have conducted tests, now it comes out about the following:

• Each planet has its own simulation of objects located on it, the planet itself in its simulation is a static object
• One more simulation where the shapes of planets move in orbits, this will allow to receive information about collisions and synchronize their position
• Splitting per-planet simulations will allow me to create the hierarchical tree
• Each planet has a death area of radius +30%, if an object accidentally leaves this area, it is destroyed

In general, it really works great
Even in theory, will allow you to scale this system into a small galaxy simulation

Hmm, only thing left to solve is a multithreading
First thing I thought about was AsParallel all planets entity and running their simulation step
But, AsParallel too slow

[RossNordby]

Running a bunch of independent simulations of similar complexity on different threads should give you pretty much linear scaling with hardware. If that doesn't seem to be the case, some of the simulations might be much larger than others and so you end up waiting on one thread to finish while every other thread is idle. If a simulation is expected to be large, you could give it its own IThreadDispatcher to use multiple threads internally, while still running in parallel with other independent simulations.

It may be worth looking into whether the CPU activity matches expectations in general. I'm not familiar with the plumbing beneath AsParallel; there could be some other sequentialization happening that you could avoid. Technically, you could use another ThreadDispatcher (maybe like in the ParallelLooper: https://github.com/bepu/bepuphysics2/blob/8c5215b78fb27e4f1d519e118bdfab1649f46b5d/DemoRenderer/ParallelLooper.cs). Be advised-- the ThreadDispatcher is not reentrant, so you can't use the same instance for the outer loop and within simulations being executed by the loop.

[0xF6]

Yes, because of the architecture, i have to wait for completion of simulation of each planet.
Anyway, i don't yet know what problems there may be, i will not be engaged in such optimization soon
In the future, i will explore all possible options~

[damian-666]

I havent seen the BigCompund, but form the comment you might want to introduce nested spaces intot the core, each with its own spatial index and inner space frame with its own origin . the Ancient ODE (open dynamics engine) had a artitecture to collide spaces. Now even modern engines don't and they should … the basic idea is collide the items in each spaces, then collide on broadphase the spaces by the outer bounds of them, in an outer cosmological frame of refernce ( where the units might be different, as in light years, not km) , and then the pairs in intersection of the spaces, by trasfromfin the geometry and velocity from one into the other refernce frame. for the narrow phase one subspace could have a tree and one could have a hash or even a grid to find quickly. The space collider collided all the spaces via interface, and didnt care about the broadphase implementation used in each , it collected the bodies in the intersection area. If a subspace is a single complex rigid body it would definitely be a tree, if not maybe a dyamic balanced tree, or a hashspace or a grid. This solves some of the precision issues as well, if peple are temped to use doubles or longs. it gives perfomance gaines on order of 100x when i tried it. The the main collider, what it did was for the bodies in teh intersection of the two outer subspaces, collide onlly those together, by converting the cooridnates one of those ones to the other. otherwise just run the inner spaces in parallel of course. With SIMD i dont know the constraints but at least on a cpu leave you could run them eachon a CPU thread. Anoterh use, i wish my physics engine has, is sets of bodies that are jointed together , a like a ragdolls or vehicle.. Each set of thies be a subspace, becasuse teh AABB barely changes , then you could CCD just the subspace before you even fight the characters parts. now have to ccd every damn foot and hand with evey damned other foot and hand of every other monster meters away when i shouldnt have to. Just an idea i hope is useful, as the ODE is long dead but was well-architected. If the needed iinterfaces are there, you can mabye sort of implement it yourself without core changes to the phsycis engine, maybe that would make more sense im not quite sure.

[0xF6]

Yes, i can
Anyway, i have already decided that i will calculate the collision of planets in a separate simulation with placeholders in the form of ordinary spherical colliders, maybe even with the use of scaling, idk