Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a way to scale up VoxelLodTerrain with an SdfSphere to extreme sizes and still be smooth with accurate collisions? #639

Closed
TheBeastOfTrenzalore opened this issue May 19, 2024 · 4 comments

Comments

@TheBeastOfTrenzalore
Copy link

is there a way to have a VoxelLodTerrain with an SdfSphere have a 24,000,000 unit radius? I've tried setting the radius of the SdfSphere to 24,000,000 units, but it comes out not smooth looking:

Forsaken Horizons (DEBUG) 5_18_2024 7_54_28 PM
Forsaken Horizons (DEBUG) 5_18_2024 7_54_44 PM

If I make it generate at 240,000 units and then scale it up by 100 to be 24,000,000 units it will look smooth, but then if I move over 100 units per second (and occasionally slower) I clip through the colliders (changing collision margin up or down didn't seem to help either):

Forsaken Horizons (DEBUG) 5_18_2024 8_05_38 PM

@Zylann
Copy link
Owner

Zylann commented May 19, 2024

This is too big for what's currently supported. 24,000,000 is 4 times the radius of the earth btw. Maybe the cause is that the graph generator is using floats for calculation (not just in basic nodes, but also FastNoiseLite, FastNoise2 and GPU support), there is no easy way to change that, other than going into every node in the source code and replacing every float with double, not using FastNoise2, not using GPU and maybe also track down subtle issues with memory copies. Another solution is to write your own generator so you can decide how to use doubles.

if I move over 100 units per second (and occasionally slower) I clip through the colliders

It's hard to tell exactly what the cause is from your description. Keep in mind Godot doesn't support large worlds by default, it needs to be compiled with double-precision support otherwise you will have all sorts of problems beyond 8 Km away from the origin.
Note that scaling by 100 means each voxel will be 100 meters long, and mesh collider triangles will be about that large too, and Godot might simply fail to detect collision due to tunnelling.
Another possible cause is that somehow generation can't keep up with your movement speed, which would be odd, but it's hard to tell with your limited description. If you can confirm colliders definitely generate where you should have hit, then the issue is the former.

@TheBeastOfTrenzalore
Copy link
Author

I'm aware 24,000,000 is far larger than the radius of the earth, however it is about the size of the largest rocky planet in the universe, so I'm using it a maximum size for testing purposes.
I'm looking into changing the nodes to use double precision, as that might be helpful for many things, I think I might have seen an article about emulating double precision on the GPU, so I may be able to leverage that to help.
I am using a version of Godot compiled with double-precision support already, as I figured that would be helpful for rendering such large objects.

Do you think if I change all float into double in the source code that the game/editor would still run okay if I can emulate doubles on the GPU using multiple floats?
Would FastNoise2 not work if I changed float to double?

@Zylann
Copy link
Owner

Zylann commented May 19, 2024

If you go that route then you'll have a lot to figure out I think... because I don't want to hardcode this if possible, even if it's just when Godot uses doubles. I also don't want doubles to be flat-out used everywhere (that's what Godot did, and it has some issues regarding performance/resource usage in some areas), so I'll probably decide how to do this when I get to investigate this in the future.

But if you want to use doubles everywhere for your project, you need to replace all floats to doubles in pretty much every source file that touches the graph generator. You might also have to account for this in places that are less obvious (can't think of which ones off top of my head, I'm just suspecting some places might implicitely use floats and the compiler might not tell you automatically).
FastNoise2 does not support doubles AFAIK. FastNoiseLite might though.
GPU support is tricky because emulating doubles with floats will actually not give you the same level of precision, and it will also not return exactly the same results as the CPU version (the engine assumes results will match). It depends on your generator and what you want to use the GPU for. Also if you want to emulate doubles, that very likely means you will have to rewrite every piece of GLSL in each node to use your emulation. That includes the entire port of FastNoiseLite to GLSL that the module is using to match the CPU calculations.
If you use detail normalmaps, you also have to change these compute shaders to use your double emulation, as well as account for it in shader code generation the module does with them etc...

@TheBeastOfTrenzalore
Copy link
Author

TheBeastOfTrenzalore commented Jun 7, 2024

I seem to have found a stupidly simple answer, by simply turning up the noise resolution in my generator graph and turning down the scale a bit mostly seems to have fixed the terrace looking cliffs and collisions seem to work fine, now it looks like this (this is a 6000km planet btw):

Forsaken Horizons (DEBUG) 6_6_2024 7_19_36 PM

Forsaken Horizons (DEBUG) 6_6_2024 7_19_50 PM

it does still have some weird texturing on the places where the textures are mixing, so there's still a few little things, but I can probably fix them pretty easily.

(as a side note though, you still can't scale up to 24000km, the terraces reappear if you get that large and don't seem to go away)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants