How small can things get in UE4 before breaking?

As we know the largest map size supported for multiplayer is 20Km x 20Km x 20Km

Currently I wish to go past this limit for a multiplayer scenario and since you can’t go past that limit without endangering the stability of physX and rendering precision I chose a different solution

I plan to take everything smaller in scale , by a factor of 0.01 which will make the multiplayer world space 100x in size or 2000Km in each direction

Now the obvious question would be why do I need so much space , am I a mad man? No, the answer is space.

The game is set in space with large empty space around you and you should be able to move around with high speed. Its all just planning and assessments right now

In other words majority of the map will be empty space to travel around with high speed so its not like too many objects putting stress on the engine.

So what I want to learn is what effects should I notice as I operate at scale as low as 0.01 . I can already observe a bit jerkier physics and loss of shadows for objects that tiny.

What other things would change dramatically and are they feasible to fix?

If it’s in space then you might not need physics, in terms of things colliding which would be the issue. I think you could still do motion pretty well, the issue would be once you get small enough the smallest step that it can calculate will become bigger so too small and the object won’t be able to move smoothly.

Yep I’m still contemplating and wondering about things and if they would work out. I understand how big of a undertaking it is and I’m just one man so takes a long time of thinking and testing, The only thing I’ve done in this direction is make the dynamic gravity work https://www.youtube.com/watch?v=jcTLUGVxsWU&index=2&list=PLRflIyLxSMICKC3Xs0blUngcGdH6T_cFh

yeah sorry about that old thread, I went away from forums for some time and it got buried both in the forums and my mind :stuck_out_tongue:

Why wouldn’t I? asteroids colliding with each other and debris free floating in space, not to mention flight physics would be easier if you let physX handle it instead of using UE4 addoffset :stuck_out_tongue:

In realistic space you wouldn’t have things colliding, rarely are asteroids ever close enough to collide. Unless you’re going for something else. But yes, collision would have a lot of difficulty at a small scale.

I see your point but I’m not thinking of a expolration game like no man’s sky with gigantic world. rather a combat simulation where you can move around with tremendous speed. As such combat would be main element of the game and thus collision detection cannot be disregarded.

Turns out there is a better way , you see what is a space game without FTL warp drive jumps, So now I plan to have different sectors of the hypothetical space running in different UWorlds , Since there’s very little stuff in space I don’t see this causing too much stress on a single server unless there is huge overhead of instancing and running multiple worlds.

In a nutshell if we assume the overhead of running multiple UWorlds is negligible then the total workload would not be more than running the game in one UWorld since for this particular game design the units can only exist in one space sector at a time and there would be a limit in number of space sectors.

But I still want the ability to fly around at realistic fighter jet speeds (~1300 KmPH ) so this would need more than the default 20x20x20 = 800KM^3 of space (since 20km is like 55 seconds of flight end to end) , for this I think scaling down by 10x times would work without breaking too much? 200 x 200 x 200 is not bad for a space sector , it’d give you about 9 minutes of space flight end to end at full speed of 1300Kmph which is plenty.

Now only If I can take care of things that would break at that scale like self shadowing and physics prescision

1 Like

The other road is grab the source code for PhysX from their github edit whole of it and UE4 to use double precision calculations and on top of that make a system to offset things back to float in camera space to be able to render it without Z fighting or straightaway breaking game on GPU which does not support 64bit Flops.

Now even though this approach is the true solution , it would be a tremendous undertaking and probably not even be realistic to do without a good experienced team but hey! its guaranteed to work in theory!

hmm, what I gather from that is he might not have needed to rewrite everything , for example the physics, he might have just used add offset and other things to avoid messing with physics engine.

Not to mention once you make PhysX use double precision you’ll likely see a huge drop in GPU acceleration for physX because the ratio of performance of GPU in single precision to double precision is nearly 24:1 , so at that point you might have to switch to CPU physics.

Nevertheless I’ve sent him a PM asking some basic question before I drive down this road

**Final nail in the coffin **

Its a sad day for me, this road is closed unless I gain more brain power than entire Nvidia PhysX staff

seems like origin re-basing or multiple UWorlds are the only realistic ways to go now