Why not the equivalent of an animation hierarchy at the high level. The end nodes are where there is some spatial data structure. The resolution can be very low as exactly where the spatial data structure is attached can be specified by a registration point which can move as needed to give fine grain resolution. Then all actual objects are simply stored as coordinates inside the local spatial data structure. If these are still too big, they could be store cell local as the higher levels coordinates are all implicit. The effect of the spatial data structures on one other could then be a simplified model (or models depending on distance)…for example a point mass for all it’s contents if very far away or as a projected line of varying mass, etc. etc.
I hate to admit that I have no idea what you´re saying… (^_^;) Give me some time to process that, but first I need to get some food so my head starts working again…
Roquen has the right idea. When you are looking at different starts you use a different scale, say 1km per count. Then when you “zoom in” you use the 1mm scale for local simulations with coordinates centered on the star, or alternatively everything is 2 numbers a baseline+local delta. Most of the math only needs to use the local delta and can ignore the baseline, while other parts of the simulation can ignore the delta and only work with the baseline. [edit fixed typo]
The old java3d did something like this with its concepts of baselines.
You still have not really said what this is for? I am intrigued. And you are aware of http://www.shatters.net/celestia/ right?
So you´re basically approving of what I wrote earlier? Baseline = a long where 1 unit is 1 km or so, and local delta = an int or something. But how do I handle overflows/underflows in the local delta? Overflow = increase baseline, underflow = decrease baseline…
Don´t get too excited about this… Just me pondering over the technical plausability of a 2D space MMORTS… 
I liked Ogame except for the fact that it sucked. Since no one wants to make a decent space browser game that…
- does not depend on how fast you are at pressing F5 to update the browser
- does not have laughable physics and planets 5 meters away from each other
- is not ****ing textbased -_-
… I figured I might as well try to make one myself. There you go, add determinism to the list! ^^ But like I said, don´t get too excited. I have 2 other games to complete first and 2 shadow mapping techniques to test before I can work on this. xD And since I´m completely stalled for around one more week my head is soon going to explode with programming ideas… ><
Here’s how a realistic Space MMO would be:
“Set course for Proxima Centauri. Arrival time in 2387 standard years.”
quit
Well, only 6.5397 years in his simulation. Don’t be such a nay-sayer.
I just did some benchmarking of verlet integration (2 particles and 1 spring).
double vs BigDecimal(DECIMAL128): over 20000x slower.
A heck of a lot more stable than 64 bit doubles though :persecutioncomplex:
Local coordinates = good. Single precision = usually good.
If you really need more than doubles for some things you can always use unevaluated chains (like double-doubles for ~108 bits, etc)…but why bother.
It´s only newtonian physics so we´re not limited by the speed of light at least, and 1 light year takes only 1 day at the spee of light. xD In Ogame it takes weeks or even months to build certain buildings since the cost and time taken to build something increases exponentially.
Thanks for testing that, but that sadly rules out BigDecimal then…
For some kind of MMO game i would stick with 100% parametric for everything. More or less. Run totally different “modes” for between stars vers within systems. Since its parametric it is easy to move any one part of the system to where it should be at any given time. Even approximate orbits for ships etc can work this way, and its probably going to just as accurate as any simulation that would be practical.
Since the transport mode between stars will need to be some kind of FTL to make the game interesting you already have a natural way to separate the scales.
So sad… in C++ you could have used long double on 64-bit machines… sad…
Or rather a long long, if there is such a thing… xD
You can’t just throw precession at chaotic systems. Well not really. Errors eventually grow exponentially regardless. The only way to really do it properly is with interval arithmetic. Next best is always be smart with the precision you have. Doubles are seriously pretty good if used properly. rounding errors are about 1mm at 8 light hours. Longs are also good for 1mm error at 2 light years. Add a base line and a galaxy is no problem at all.
And no matter how “good” c++ is or whatever using the longer versions are much slower that the base versions. Its not like its hardware native format.
There is, but due to hilarious compatibilities reasons it’s usually 64 bits (ie. identical to long).
It is MUCH faster (than BigDecimal), if you let the cpu do all that things… btw, I’ve got an Idea:
theagentd: maybe, you could make something like a Chunk-System (lol… sorry its minecraft again.), where you have chunks in size, where your double has a good precision (that could be HUGE). Having a chunk system below would make everything acctually really … yeahh. reeeaaallllly huge: MAX_VAL_LONG * MAX_VAL_LONG Chunks? I think, thats okey :D. And since you can have really big chunks, you don’t have to switch the chunk too often and its not an expensive calculation anyways.
moveInWorld(double dx, double dy) {
// dx = Moving on x axis
// dy = Moving on y axis
// cx = Current Chunk x
// cy = Current Chunk y
// halfChunkSize = your desired/wanted Chunk size /2
// WARING! UNTESTED CODE:
if (dx != 0) {
if (dx > 0) {
while (x+dx > halfChunkSize) {
cx++;
}
} else {
while (x+dy < halfChunkSize) {
cx--;
}
}
}
if (dy != 0) {
if (dy > 0) {
while (y+dy > halfChunkSize) {
cy++;
}
} else {
while (y+dy < halfChunkSize) {
cy--;
}
}
}
}
Yepp, but on 64-bit machines it works.
delt0r semi beat me. Over-engineering kids. Use local coordinate frames. Example:
Distance sun to earth: 1.509x108 km
A power of two local coordinate frame large enough to cover the sun, the earth’s orbit and everything inside, where ‘1’ represents a meter
: 2.748779x108 km
Size of the ULP at the edge of this local coordinate frame: 6.103516x10-5 m
This is kind silly big.
Also lets consider the time resolution. If you want 1mm accuracy that mean the integration steps need to be pretty small. Earth orbital velocity is about 30km/s. So to travel 1mm it takes 33ns. Of course you don’t want to use that sort of time step. But you see that you simply don’t need all this precision.
Unless you are studying the long term stability of the solar system (really really hard), you just don’t need more than properly used longs/doubles. And it will be fast. But not as fast as parametric equations of motion.
Seems to me that you’d want to maintain rectangle coordinates as well for pretty much everything else.
Thanks everyone for your thoughts! I´m glad this sparked so much discussion! So how to store positions is pretty much solved then, but feel free to discuss this further.
huh? YAY 