Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411281 Posts in 69324 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 09:26:36 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Implementation of large space (different scales)
Pages: [1]
Print
Author Topic: Implementation of large space (different scales)  (Read 1050 times)
diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« on: August 17, 2018, 02:44:27 PM »

My day work is killing me and even though I cannot stop that now I really need some neat project to cool down. (my excuse for not working on apple and worm is that project is too complex to work casually)

There are many space sim games out there and certainly each came up with their own solution to handle all different scales changes. I could not find anyone actually explaining what they did though, so I'm trying to come up with my own hypothetical solution and writing my thoughts. Feel free to discuss, suggest, criticize etc. I have no idea what I'm doing here.

The main problem, of course, is floating number precision. You can't use a normal float number and expect it to be precise on a planetary scale and inside a tiny room. So naturally you need two or more 'spaces' to coexist in synchrony. The fundamental solution I can understand: In the case of 2 scales you have positions and velocities defined on both spaces, both coordinates will be using normal sized numbers the engine can handle and they will be related by a multiplication factor and a displacement, one representing the position in local space in, say, meters, the other the position in the solar system in kilometers or whatever.

I haven't given enough thought to other scenarios but if the only dynamic object is the camera it seems somewhat simple; the smallest scale coordinate, being the most precise, dictates the coordinates on higher scales. That is, you always calculate the position in a higher scale as a function of position in lowest scale. Reversing that would require some sort of interpolation. But at any single time some objects won't have a small scale coordinate. So the issue is when to start updating objects defined in higher scales in low scales. When the camera's coordinates in a higher scale reaches a distance of some object defined in that scale, then the representation of said object in lower scale pops up. Again, I haven't thought about other scenarios. If more than one object is dynamic then I guess it would need to have its own smaller scale coordinate, separated from that of the camera, and I don't know if that would create synchronization issues. Maybe it won't. Haven't given thought to that yet.

I am tempted to put something together in Unity. Seems possible to use the layers system and more than one camera for each scale to achieve the effect.

Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #1 on: August 18, 2018, 10:23:06 AM »

Another thought. Resolution is not the only problem but size of numbers. So clearly you need to either move the frames with respect to the higher frame or occasionally reset the origin. Moving it constantly seems conceptually more complicated. You need to add velocities to every object in the frame and if you want physics you need to add phantom forces too. Resetting the origin might be simpler.

Edit: Apparently this is a common problem with common solution called floating origin. There's even a nifty script that handles all the problems that comes from resetting the origin https://wiki.unity3d.com/index.php?title=Floating_Origin
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #2 on: August 19, 2018, 01:41:06 PM »

The logic of changing coordinates of different scales seems solid enough. I made a quick test in unity to test it out



A simple test is far from a full working system but at least I know the logic makes sense.
Logged

J-Snake
Level 10
*****


A fool with a tool is still a fool.


View Profile WWW
« Reply #3 on: August 31, 2018, 04:23:12 PM »

Have you thought about the idea of merging multiple data types to create one bigger data type? That way, you eliminate the cause of the problem instead of fighting the symptoms.
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.<br /><br />Trap Them: http://store.steampowered.com/app/375930
Crimsontide
Level 5
*****


View Profile
« Reply #4 on: August 31, 2018, 08:29:11 PM »

Perhaps just use doubles for all the in game physics/simulation, then convert to floats for the final render?  At least that's what if I'd do if I was writing the game in C++, I'm not that familiar with the internals of unity.
Logged
diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #5 on: September 01, 2018, 06:20:21 AM »

Have you thought about the idea of merging multiple data types to create one bigger data type? That way, you eliminate the cause of the problem instead of fighting the symptoms.

I considered doing that. In a way, that is what I'm doing. If you take the position of each object in the hierarchy and multiply by a specific factor and displace it a specific amount you get the absolute position. That's kind of a bigger data type, right? But by doing it this way I get to also reset the origin of some specific scales to avoid large number problems and always work on convenient frames.

Perhaps just use doubles for all the in game physics/simulation, then convert to floats for the final render?  At least that's what if I'd do if I was writing the game in C++, I'm not that familiar with the internals of unity.

I read some people tried to do this with partial success. I think it might work depending on the scale of the things you want to be able to describe in your project. However, even if you can make the whole game world fit inside a double range space, you would still have to deal with loss of precision. Say you have things happening with a 0.001 precision (maybe some physics collisions or whatever), and for sake of example let us say 5 digits is all we get abcde and a floating point. Anything happening at a distance far from the origin will shift the "." and thus lose all ability to handle 0.001 changes.

What I'm saying is: physics will go all wiggly wiggly far from the origin.

But that can be fixed by resetting the origin and only making relevant changes that require precision that are close to the origin. Well... yeah, I guess that could be done. I still prefer this method because it is virtually infinite. I can have this solar system inside a galaxy, this galaxy inside a cluster of galaxies, this cluster inside an universe, this universe inside another. Or even go the other way around, go inside a bird's nest, inside a cell etc...
Logged

ProgramGamer
Administrator
Level 10
******


aka Mireille


View Profile
« Reply #6 on: September 01, 2018, 02:56:31 PM »

Another possible way of dealing with this problem might be fixed precision numbers Grin

If you decide to use 64 bits for positions, you can allocate, say, 8 bits to the fractional part of the number and 56 to the integral part, which gets you a precision of about four millimeters, and gives you a bit less than 4000 light years of magnitude, in both positive and negative range. You probably don't need that much magnitude unless you want >lightspeed travel, so you can probably allocate some more bits to the fractional part to get smoother movement.

I don't know how flexible Unity is with using your own data structures for positions, though maybe for the purposes of rendering it's at least possible to change the position of objects in the scene just before rendering so that the player's actual position is the origin, that way you don't lose precision. You would probably have to implement your own collision functions in that case though.
Logged

Crimsontide
Level 5
*****


View Profile
« Reply #7 on: September 02, 2018, 07:44:38 PM »

Eh... I implemented a full fixed point library in C++.  All the bells and whistles, trig/hyperbolic/power/log/etc.. functions, the whole 9 yards.  For simple stuff (addition/subtraction) it works fine, but as soon as you get into anything more complex things get all messed up.

Imagine for example something as simple as sin(x)*y.  If you have 8 bits decimal precision in a 64 bit number it'll mostly be wasted precision.  Then you multiply those mostly zeros with y, and now you've lost 56 bits of y's precision.  Of course, then you go through and implement mixed precision fixed point math... and now something as simple as writing a camera transformation matrix becomes a massive nightmare of precision calculations.  And stuff like integrals or derivatives...  just... no.

In the end, after finishing it, I just abandoned it.  Now I just use float/double and not worry.

I'm not saying don't try (using fixed point or hierarchical precision).  I'm just warning you that the rabbit hole goes far deeper than you would think...  
Logged
Deckhead
Level 1
*



View Profile WWW
« Reply #8 on: September 02, 2018, 08:32:34 PM »

I struggled a lot with this topic when I was creating my game engine for a 4x space game. I wanted to implement things like relativity into it and that required that I had huge distances and massive velocities.

I never did complete it; ended up become sort of hard to work out. I mean, how do you play a game that has relativity effects?

Anyway; I never did get to a final solution. What I was last attempting from memory was to basically put everything into multiples of the smallest possible unit. So, if I was to say, have nothing less than 1AU speed, and nothing less that 1AU in diameter, and no distance measured in less than 1AU, I could use a 64 bit unsigned int.

I went for unsigned int rather than floats because at these min values, precision becomes even more important. So now, I have 0 to 18,446,744,073,709,551,615 AU. For reference, the sun is 1AU away. Alpha Centauri is 268,770 AU away.

Of course, this means that EVERYTHING has to be at these distances.

Once, you're looking at a solar system specifically though, you can easily now use a smaller scale. So for example, the stars are in AU units apart, but the planets in a solar system use a more precise local scale.

I found that if I tried using floats or doubles, even at the solar system scale, using KMs, I still had precision issues. Depending on how the player navigates the game, and how the objects interact, having a smaller scale at the planetary level could probably work.

Of course, you can see that everything has to be bucketed at these local scales though.
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #9 on: September 02, 2018, 09:09:12 PM »

I'm just warning you that the rabbit hole goes far deeper than you would think... 

I totally believe you. I read others talking about using double precision as well and they also had partial success. At the end the system I'm using is more than good enough for the job. It's simple and infinite in principle. I suspect most large scale games use some variation of this.

I never did complete it; ended up become sort of hard to work out. I mean, how do you play a game that has relativity effects?

That's a cool idea! I remember playing some games with relativistic effects. It's really not very intuitive.
Logged

Deckhead
Level 1
*



View Profile WWW
« Reply #10 on: September 02, 2018, 09:47:31 PM »

I never did complete it; ended up become sort of hard to work out. I mean, how do you play a game that has relativity effects?

That's a cool idea! I remember playing some games with relativistic effects. It's really not very intuitive.

Probably heading a little off-topic here.... The relativity came into it by having the time information takes to travel be shown in game and be utilized. So for example, for me to send an order to a fleet to return to earth (as a crude example), that order has to travel at close to the speed of light to the fleet receiving it, and me seeing that results of that order would take the time for that data to travel back to me.

So it meant that you are always behind the 8-ball so to speak. There would be various in-game techs that would decrease the effect maybe, or increase your ability to "predict" what was actually happening (in my mind, the player was taking on the role of a humanity-deciding computer, like that show Travelers).

But it got to the point where I was struggling with the math so much that it wasn't much fun any more. I also questioned if the game would even be playable. Like... would it feel fair that the fleet you thought was coming back to earth turns out to have been destroyed instead. Or that the fleet you sent to attack a moon arrives after 1000 years to find the moon's defensive tech far outweighs your fleets capabilities.
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #11 on: September 03, 2018, 08:00:32 AM »

Quote
Probably heading a little off-topic here...

meh, the original topic ran out of steam. It was (very) surprisingly simpler than I anticipated. I even made this topic expecting to encounter major difficulties that would to discussions.

About your strategy game ideas though, I think there's a lot of interesting things that can happen when you make information travel at finite speed. You don't even need relativity though, just finite speed of light, which is equivalent to messengers on horseback if you're doing it in a medieval setting. When you say relativity you mean the speed of light is constant in all frames? that would be complicated, I agree. But I'm curious to see what would come out of that, with space dilation and all that crazy stuff.

Better yet! Relativity on a medieval strategy game! In a world where the top speed possible is 50 Km/h and the only thing that moves that fast is the magic messenger horse. If you try catching up to a messenger horse by going at 49 Km/h the magic horse will continue to be at 50 Km/h with respect to you, and the entire universe will be stretched to compensate. That would be fun. Lots of pancake looking people running around.
Logged

Deckhead
Level 1
*



View Profile WWW
« Reply #12 on: September 03, 2018, 03:29:53 PM »

TBH I hadn't fully fleshed out the relativity idea.

But consider that there are things like how in one frame of reference events happen before others but in a second frame of reference it's the other way around. Like the effect happens before the cause sort of crazy things. Like I said, it's sort of hard to come up with gameplay mechanics that make sense and/or would be fun.

Remembering of course that nothing can reach the speed of light, only approach it.

I cannot think of any gameplay mechanic for a 4X style game other than not knowing exactly where your units are and what they're doing right now.
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic