Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411511 Posts in 69375 Topics- by 58430 Members - Latest Member: Jesse Webb

April 26, 2024, 12:22:58 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Game engine that supports a large world.
Pages: [1]
Print
Author Topic: Game engine that supports a large world.  (Read 1598 times)
Gnollrunner
TIGBaby
*


View Profile
« on: May 06, 2018, 09:18:07 AM »

Hi, A few years back I wrote some fractal planet software in C++ that used Direct X9. At the time it just did height mapped terrain but I have recently updated (i.e. rewritten) it to use a octrees of prism shaped voxels so that it will support caves and so forth. However I haven't updated the graphics in a long time and I was wondering if there is a game engine that will support a large world model. I currently build terrain chunks in double precision on the CPU and then convert them to single precision for the GPU and transform them to their location. I do collision in a separate model that just exists around a given player as to avoid race conditions. There is currently no data on disk since it generates fractal terrain at run time, so the world can be really big (thousands of kilometers in diameter).  All this works reasonably well, but I would like to use a game engine to make the rest of the development easier, since getting this far has pretty much been hell...... So does someone know if there is a game engine that supports a large world model or will I have to go back to using Direct X?  I've actually never used a game engine before so I have no clue if what I am doing is even feasible using one. Thanks in advance.
Logged
ALourenco
Level 0
***


View Profile WWW
« Reply #1 on: May 08, 2018, 02:58:38 AM »

Regarding the mainstream engines like unity, Unreal, (...) I don't see why you couldn't implement a system like the one you are talking about. It all depends on the way you do it and you could bypass the low level physics and graphics stuff, focusing on the world generation and managing part. It is very likely that something similar was already done before.

Check Spacial OS. This one is not quite an engine, but more of an OS. It's most likely overkill for what you want to achieve and I think it's more directed for massive online stuff.

Good Luck!   Coffee
Logged

GameDev Master Student.
Game Engines and Computer Graphics in free time.

@CodinGree
Tattomoosa
Level 0
**

Making The Decision Engine


View Profile WWW
« Reply #2 on: May 11, 2018, 01:09:33 PM »

If you are concerned about precision, here's a talk from Unite 2013 about how the developers of Kerbal Space Program solved the issue by defining a threshold distance away from the origin where if the player reaches it the entire KSP solar system moves so that the players new location is the origin. This, of course, is instant and invisible to the player.

https://www.youtube.com/watch?time_continue=384&v=mXTxQko-JH0

KSP has an entire solar system with realistic-ish (I think everything is a bit downscaled from real life) distances between bodies.
Logged

Ordnas
Level 10
*****



View Profile WWW
« Reply #3 on: May 12, 2018, 04:06:59 AM »

Regarding the mainstream engines like unity, Unreal, (...) I don't see why you couldn't implement a system like the one you are talking about. It all depends on the way you do it and you could bypass the low level physics and graphics stuff, focusing on the world generation and managing part. It is very likely that something similar was already done before.

Gnollrunner is right having concerns, because with single-precision you can have 8km of terrain until you find issues. Epic roadmap had a DoublePrecision for large world map on their future task, but it seems that they archived that feature: https://trello.com/c/wHS2AZMi/1042-link-to-the-new-public-roadmap
Some says that probably is because of Physx that can handles only single-precision.

I am not sure but it seems that even the CryEngine still did not implement double precision, even if it is one of they future feature. Star Citizen convert their CryEngine-upgraded custom engine to support 64-bit:
https://www.gamersnexus.net/gg/2622-star-citizen-sean-tracy-64bit-engine-tech-edge-blending

So I think you if you need to use a commercial engine you need to do some hack to support very large maps.
Logged

Games:

ALourenco
Level 0
***


View Profile WWW
« Reply #4 on: May 12, 2018, 07:21:10 AM »

Regarding the mainstream engines like unity, Unreal, (...) I don't see why you couldn't implement a system like the one you are talking about. It all depends on the way you do it and you could bypass the low level physics and graphics stuff, focusing on the world generation and managing part. It is very likely that something similar was already done before.

Gnollrunner is right having concerns, because with single-precision you can have 8km of terrain until you find issues. Epic roadmap had a DoublePrecision for large world map on their future task, but it seems that they archived that feature: https://trello.com/c/wHS2AZMi/1042-link-to-the-new-public-roadmap
Some says that probably is because of Physx that can handles only single-precision.

I am not sure but it seems that even the CryEngine still did not implement double precision, even if it is one of they future feature. Star Citizen convert their CryEngine-upgraded custom engine to support 64-bit:
https://www.gamersnexus.net/gg/2622-star-citizen-sean-tracy-64bit-engine-tech-edge-blending

So I think you if you need to use a commercial engine you need to do some hack to support very large maps.

Yeah you're right, the solution Tattomoosa refered looks interesting-
Logged

GameDev Master Student.
Game Engines and Computer Graphics in free time.

@CodinGree
Ordnas
Level 10
*****



View Profile WWW
« Reply #5 on: May 13, 2018, 11:36:53 PM »

Yes, Tattomoosa solution is interesting and the only solution I can think at the moment. To know if you need to shift the origin, I think you need some sort of trigger working like a door / portal, and the entire world needs to be divide in instances, because it will be difficult to manage cases like 2 players fighting against each other at the limit of the map, each one on different map origin.
Logged

Games:

Schrompf
Level 9
****

C++ professional, game dev sparetime


View Profile WWW
« Reply #6 on: May 14, 2018, 05:26:56 AM »

Not exactly a portal. If I remember correctly, Dungeon Siege back in 200x already did this, I'm doing the same, and I suggest a similar approach for you, too: frames of action. For every player (and every other carrier of game mechanics) you define an area of interest (e.g. a rectangle) that defines a local coordinate system for every close object. If the player moves, you re-center that area when it moves off too far. If two players venture off in different directions, you split the area at some point so that both players have their own area each. If two players close in on each other, you unite their areas into one again.

Of course this is only necessary at the server. Each client only knows its own area of interest, anything happening in the other areas is not yet relevant to the client. From my experience with PhysX back in the days, human-like movement speeds broke down at a distance of around 2km at 60fps physics simulation rate. Those are the limits of 32bit floating point calculations, so there's no way to avoid this limit, whatever physics lib you're using and even if you roll your own physics.

Side anecdote: I'm just playing Subnautica, and there you can also see the effect. Its world is limited to ~2km in every direction, and if you're in the farest parts of the map you see all sorts of floating point imprecisions. On the floating island the shadows shiver when you move. In the lava segments deep down the precaching of ground segments comes closer and segments pop up right in front of you. And so on.

Also, back in the days, I found no way to re-center PhysX actors reliably. Setting their positions via the public API did invalidate contact points or other cached values and resulted in a slight jump of every physical body and sometimes in an hefty explosion, launching the crate in question to orbit. I can only guess what caused this as PhysX is still closed source. For my current project I therefore chose Bullet Physics. If all fails, I can still recompile that lib for double by changing a single line.
« Last Edit: May 14, 2018, 05:35:06 AM by Schrompf » Logged

Snake World, multiplayer worm eats stuff and grows DevLog
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic