Highp doesnt seem to help. The verts themselves are getting heavily deformed - so the values must be getting quantized (in the vert out itself)
I would say it’s definitely the fact that you are doing calculations so far away from the origin.
I have a list of “smallest steps” that can be represented here:
At 32km, the difference between each step is ~2cm!
And that will only compound as, of course, there are calculations made with these numbers.
f: 30000 next: 30000.001953125 diff: 0.00195312
Uggh. Life was so much easier when you could just write pixels yourself.
If we’re talking old school rendering, it is very likely that you would have the same problem with overflowing the fixed point math, so the case would still need to be handled.
The suggestion is to move the sensitive calculations back to origin.
E.g. for each sensitive object, translate them back close to origin, and place the camera accordingly and render.
In this case, it may perhaps suffice with moving the airplane back to origin.
I hope this helps!
Yeah thanks. I guess the camera (world) matrix has those float positions in them, and that kinda multiplies into the problem. Have seen this before on big sims at around the 20km mark.. but was hoping the vert rendering could be localised and the verts would be handled in the gpu as relative to camera. Clearly not 
I mentioned pixel days because rendering this terrain and even really simple things like roads, and shapes.. is an utter pain with the GPU. With a sw renderer.. we often did really simple drawlines over the scene - you could do this with a render texture and sw engine (have done that) but there are things.. that are just easier to do in plain pixel drawing. Making retro looking games, isnt really rendering the same either.. hrm.
Maybe.. I will do it all in sw… then I dont need to worry about the precision. hrm… already have an example renderer for that too. hrm…
Im not keen on the floating origin thing because of the problems with all the other objects in the scene (ships, missiles, aircraft, cities, roads, bridges and so on). I have a renderapi interface that intercepts all go render updates its doable.. but the side effects and all the modelling … hrm.. maybe a few days of tinkering first.
Made a little test project. Will put up here in a bit. And heres the results.
On the same map with same scaling where these objects spnning roughly measure 0.01 of a unit which is 1m and are positioned some 34000 x 16000 away from the origin (thus to them its 3400,000m away or 3400km)
There is substantial vert movement. Oh well.
I have three options Im considering right now:
If anyone has any other ideas (especially reasonably simple ones to implement ) .. happy to hear from you. I probably should consider talking to gpt..
Heres the “big world test” for those interested. This has just the ocean for reference.
big world test.zip (122.8 KB)
This has been a good process, since it took me back to making something I really wanted to build anyway. And thats a world builder for earth scale games (because I want to do a series of these anyway).
After some tinkering today.. I now have a realtime grid based terrain (and data) loader that will solve alot of these problems. Thus the player will probably only ever work within about a 40km - 50km range of the tile/world origin.
A little late to this, and my understanding here is limited at best. When I’ve bumped into this issue my (quite basic) solution has been to keep the main object (in this case the plane) at origo and move the world instead. This may not be a feasible solution in your case, but thought is drop this “very simple” solution in here for flavour.
(a) Strap camera to the aircraft (and damp horizon shake)?
(b) Damp the movement on N*dt ?
(c) Apply delta’s to visuals in local/camera space.
Probably make little sense in your context.
Localizing the origin to the f18 is a problem. This means you need to update all objects (static and dynamic) every frame to ensure world consistency. With a busy battle area with missiles, numerous enemies and more, this is a pretty big burden on performance. Also, I have a number of camera modes (from different places - if youve played the original, youd know what Im referring to ) and they can be from a wide array of vantage points - mobile and static.
This method works ok for infinite runners and similar, but thats usually a quite constrained data set.
Its important too, that the models (physical) Im running for the planes and ships, that they dont become overly complicated as well (esp with collision with other entities etc).
The actual easiest way, is to use doubles in the engine This is what I have done in the past for some of the big sims Ive worked on (train sims, car sim, and defense sims). Especially when making systems > 50km.. you need to have clean and consistent modelling in these types of projects. Note: All my entities are using doubles.. so I dont have to worry too much about their actual position info getting corrupt. Its more about managing and handling larger scenes to get the rendering within good F32 scales.
Ive done grid chunking before and its looking like its going to be the easiest/least risk/least impact atm.
Thanks for the thoughts tho. Keep them coming!
I still have an interest in rendering all the terrain into something a little simpler. Now I have a good and small data set (whole world is tiny 24MB (packed of course).. I may need to use a detail lower which will blow out to 130MB+ but it means it can easily live in the GPU or something interesting like that. Ie.. do some sort of terrain raycasting in a shader. Dunno. Big worlds are always an interesting problem to solve
World builder is coming along now. The tile/chunk loader is pretty good. I can preload the whole data set, and generate blocks of tiles. Im doing 25 ( 5x5 ) atm.. but prob only really need 9 (3x3).
Will add some editing tools:
Will be a couple of weeks before I can regenerate my missions. Its a bit of a delay, but will mean I have a bespoke mission/world editor tool which will probably end up on steam workshop or something like that.
Ok. Another update. And hopefully one of the last major render systems I need for the env.
.. there’s over 4000 in that picture alone. .. its a 1 pixel sprite. That I stretch in X the length of the segment, and width can be adjusted to suit the line width I want (can be different for different road types). Its a super simple solution, and if people want a little sample project to play with, I’ll put it up.
Onto:
Hopefully in a few weeks, this will all be back in the main game, and the large world system will happily work! (over the whole planet ).
Interesting side note. Total world data for roads, land and urban is: 96MB. Kinda nice
Heres the sample line drawing project within the basic 3D sample from Defold.
I wanted to be able to render lines in 3D too.. not just in 2D. There’s only really one script of importance, and a couple of other necessary files - atlas, png, and factory.
Feel free to use it however you like
Wow very cool, thanks for sharing. This would be a great “3d line drawing” sample project on its own.
Thanks. There are a few limitations in this implementation though:
(Im working on this). .. again.. something Im going to add to my batch one.Its kinda cool how nice it works though, you can set every color and individual line thickness too. So there are some really nice benefits.
