OK I just realized (after uploading the vid) that you can easily optimize this even further by splitting the clipmap mesh into pieces before exporting to Godot. That way you can get frustrum culling to work for you. Just make sure to switch off Godot 4's auto LoD for the individual pieces to avoid cracking at the seams.
@@FinaISpartan that would prevent the horizontal cracks but not vertical. If 2 neighbouring chunks have different LODs (which will happen in this case) and are deformed by the same heightmap, there will be vertical cracks between them no matter what. Vertical cracks are even more visible from the player's POV.
Tried this way, when i create meshes for frustrum, they are affected by shader in the same way, godot do not have any node class that can group up meshes in to 1 vertex array and cut unused. Also if you are using heightmap 4k x 4k, you are using clipmap with same resolution, cause when i tried to make clipmap less with 4k map, all map is rendered on my small area. Or maybe im doing something wrong?
This is a damn clever solution to a problem I feel needs more resources in GODOT. It also makes me think of the Futurama episode where they said their ship moves the universe around it instead of them flying around the universe. really cool!
The problem is the popping as you can observe in 4:49. The sudden increase or decrease in geometry detail bring popping, the geometry popps out and in suddenly, which looks discontinuous and ugly. The counter this, you need to create transition regions near in the finer mesh, which starts 3/4 form its center, to the end. The idea is that the transition region slowly removes geomtery from finer region as it moves away to coarser one. So the height in the region will be (1-alpha)*finerHeight + alpha*coarserHeight, where alpha is between 0 to 1 and becomes 1 at end of the ring. This creates a smooth transition rather than sudden one, removing popping artifacts.
Mmm interesting, I used the first method but marked the outter edges of every terrain chunk as "Sharp edges" in blender so that the auto LOD in godot woldn't mess the seams.
Honestly, this is genius. Well done man, and thanks for making this available. It's going to help me with a similar issue and it's such a simple solution!
Nice, I'm using this technique as well for my terrain, though it is subdivided into several meshes to make it easier. I aslo added skirt vertices to blend the seams nicely.
Using a premade clipmap like that is pretty brilliant, never thought of it that way. Lots you can do further with this, I think I'll definitely be using this technique for one of my projects.
Your project has the best graphics I've seen made with Godot so far. I think only developer with huge experience and programming skills can achive this by now. I'll keep with 2D hahaha
My thoughts exactly... devmar seems to have a god tier understanding of Godot, 3D and mathematics... for my first 3D project I'm making a simple first person 'backrooms' exploration game and am thinking I've bitten off more than I can chew.
This is a interesting approach and is good in the way it is easy to setup. However a quad tree approach is far more performant with a chunking system due to only having to recalculate the terrain heights on a subdivision which do not occur very often, whereas this method requires you to recalculate the whole thing which includes many more vertices than a single chunk and it occurs every movement frame.
Hey, if you're recording screencasts for your videos I recommend that you disable subpixel AA for system font rendering - it will make the screencast text cleaner. Video compression butchers the colored pixels and makes them look messy.
While this technique is pretty good, it has some drawbacks when you want great render distances. To avoid terrain shape floating in the distance (especially visible mountain edges) you always have to move your mesh by the size of it's biggest (outer) grid quads. This means that if you have 4 levels of density, your innew grid will always have to jump by 8 quads. This should be fine, but what if you want big render distance? You would end up with a lot of polygons unless you use more levels of detail. If you have 8 levels of detail, your inner grid will have to jump 128 quads every time you move your grid. That means if your inner grid is 512x512 quads (0,5M triangles) it would still jump 1/4 of it's own size. My preferred technique is simple binary space partitioning. You can still have one mesh reused all over with different offsets and scales. That means rendering using single draw call and instancing if you want. The only problem is that mesh with 2x density will not match at it's edges with next mesh. You will need extra triangles along the edges to bridge the mesh resolution difference. Additional advantage of this technique is that you can use simpler terrain material at greater distances, further optimizing performance.
This is an amazing explanation. The quadtree approach is best when you also vary in height (e.g. in KSP or a flight sim) so you want a steady zoom in, although you could probably also stack clipmaps at different distances.
I'm blown away by this technique. Honestly, this is one of the best things I've ever seen. It's so simple! Quick Question: Why did you use nested square shapes for the clipmap? Wouldn't circles be preferable so that you get a more convincing horizon? (I'm assuming that the outermost square that makes up the level is also part of the clipmap. Sorry if I've misunderstood) Oh, and what if you used many layers in the clipmap technique so that you could get a smoother gradient of LOD?
The stepwise movement of the mesh, making it appear vertices move with the terrain, constrains the mesh to a regular tiling. A triangle/hexagon pattern should work.
Possible optimization: Set the render mode `world_vertex_coords` and you'll get actual world coordinates as vertex coordinates, so you can skip your shader parameters and instead use vertex coordinates for UV mapping directly, avoiding all the math originating from the player position (especially considering you're calculating the height and don't have to derivate it from vertex coordinates). Also cool fun fact: The technique you've used is basically how The Legend of Zelda: The Wind Waker mapped its massive ocean "full" of waves (that always stick to your ship), so it could be rendered on the GameCube's limited hardware.
Tried it before but it doesn't work like this. world_vertex_coords still modifies the verts/normals etc. except it does it in global coordinates as opposed to local, so it's like position vs. global transform - it doesn't 'detach' the projection from the moving object.
@@actualdevmar Think you misunderstood me. It should just make the math involved more simple and save you from using the extra uniforms, you'll still have to move the mesh, obviously. Will have to try this later, wanted to recreate a Wind Waker esque scene anyway.🙂
@@Smaxx My point is, since the terrain mesh is moving, you still have to update the shader uvs in-game to keep them stationary. Setting the render mode to world coord doesn't lock the uvs in place, they're still moving with the terrain and thus the need to counter that movement remains. The only difference is a different coord system is used so the math is different but not necessarily simpler. At least that's my conclusion from experimenting with world coords, but chances are I'm doing sth wrong.
I've tried something similar in Godot 3, but ended up with a quadtree approach, where I blended the seams in the vertex shader. The one-mesh-approach that I tried before that had the issue that I couldn't display as many vertices, because no frustum culling could happen, so also the vertices behind the camera where rendered. I haven't ported either of those approaches to Godot 4 yet, so there could be something in the new renderer that changes the situation. I used a single mesh for the water close to the camera, but that mesh had fewer vertices anyway. But I more or less restarted my project for Godot 4 and I'm focusing on other aspects first and plan to port my rendering stuff later.
@@actualdevmar Yes, the quadtree-related stuff is all gdscript. It doesn't seem to be the bottleneck. However, rendering performance in my Godot 3 prototype is generally quite bad for other reasons (mainly trees/grass rendering), so I hope that will improve with Godot 4.
this looks pretty cool, might use this technique for the game i’m working on. it’s a fixed premade map but is gonna be large enough that i want to do some lod stuff with it
I realize a major point of this video is not having to use C# for this, but i just want to note that C# is relatively easy to learn if you are already pretty decent at GDScript. The static typing can be a bit confusing at first but that was my biggest hurdle
You might still be able to use an LOD with terrain if you use two cameras (with the same transformations) and overlay the high detail terrain over the low. No gaps, no math, no vertex manipulation. We already have the subviewport in place for it. Dunno, I haven't tried it, so I'm spitballing. Might be a good "poor man's" alternative if you're not allowing a camera to get close to the low detail areas.
Trying to figure out the uv height part (not sure how to get it working in godot) I see the setup but im struggling i may not even have the right type of height map img etc...; iv made the clipmap mesh in blender @actualdevmar
I wish you had a tutorial or something for this, Im new to game development but not coding and Im having a hard time trying to find the right steps to get to this? 1. How do I make infinitely generating terrain that isn't repetitive (because a basic noise image can only go so far before the terrain repeats) 2. How do I make the terrain? is it that tree thing in the video? is it written code? C++ or GDScript? 3. I wish I wasn't dumb 😭
I know it's late, but Zylann's heightmap terrain now works on Godot 4, but they don't update it nearly as much as their godot voxel project which seems like a far better solution at this point.
This is absolutely amazing. I wonder how it work when you get to far because of precision. I remember Outer Wilds Devs had problems with distances when the player was too far from origin.
Should not be an issue. I tested it by running the map for a real-world equivalent of 100km without a hiccup. You're just cycling though the UVs so not much can happen. The terrain is basically one big tiled vertex texture:)
Very nice and simple technque! Thanx for sharing The clipmap you're showing at 2:49 in the Godot editor have morphing effects between large and smaller quads. Are those morph done also in blender?
@@actualdevmar I don't think that is what he is talking about, he means how there is a interpolation between the finer area and coarser area as you move, in between full "snap" positions. Basically you see edges between those areas that gradually slide around. That's the typical Clipmap, but listening to your video it sounded to me like you just have a static mesh with no changes in vertex positions on the plane, only in height (per vertex) and global translation for the entire thing. And looking at you move through the scene I can see the popping that I would expect when you don't have this interpolation.
Pretty neat solution. I got stumped by the same problem but I was using procedural marching cubes terrain, and implementing the transvoxel algorithm to connect different LOD chunks was beyond my math skills. While it works well for a heightmap I don't think this method could be adapted for voxel terrain. At least not by me lol.
This is interesting. I wonder if this by attaching the ground mesh to the player and moving it in the opposite direction of the player's movement affects the physics of rigid bodies that is on the terrain? For example, a stationary sphere sitting on a surface may roll around as the player moves. Forgive me if this is a stupid question.
The terrain isn't moving in the opposite direction. It's the uv projection of the terrain that is moving in the opposite direction. There is no impact on physics as physics is only interested in collision. The collider is stationary.
Hey, I just stumbled upon this. How did you make the shadows cast properly (as in make the shadows match the vertex displacement)? I just can't seem to find anything about it in your video, did I miss anything?
Amazing work! I’m a bit confused though on how should the clipmap mesh be generated, I mean is it a grid with mode subdivs inside another grid with less subdivisions? I’m willing to try something similar to this technique but in Godot 3.5…
what would be cool is if you added a "stamp" system. Where you can place heightmaps in level and they get baked into a final heightmap texture for your shader to use. Shader World for Unreal does this.
I've been playing with vertex shaders for terrain after seeing your video (Great videos btw!), have you solved how to use omni/spot lights against the terrain? Playing around it looks like the light has to be near the origin of the mesh as opposed to the adjusted height of the vertices.
I have seen this technique before but the one thing that nobody talks about is how a whole game works with this technique. Presumably you will want enemies and towns and the like. All these objects are moving instead of the player moving. How does this affect enemy movement AI and physics?
hi i just made a terrain like what you did in video and here are two problems 1 - terrain doesn't cast shadows as it do in video 2 - my entire map loads at once and scaling model isn't working and btw how to add Collision to this type of terrain ?
I wonder if this is cheaper than unreal's terrain system. Might be worth recreating in unreal for something like a Meta Quest VR based project. (mobile)
Wouldn't it also be possible to keep a sector of the clipmap (for first person) that is also able to keep 2 "snaps" (maybe 45°) of the terrain, thus discarding most of the geometry that would be outside the frustum? And then, wouldn't it just be possible to take any shape, e.g. a radial sector, that allows for smaller "snaps" of angles? I assume it's a bit harder mathematically, but might reject a lot of geometry. Either way, I think you should attenuate the snapping from high res (no snapping) and low res (better snapping), possibly interpolating between both values, minimizing by error.
There is a simple way in blender to chunk up the clipmap mesh into a grid. That's what i did. I only render the chunks inside the frustum. This terrain has minimal weight on performance. That's how i can afford grass and trees to go with it at 120fps.
On the note of LOD and chunks, I think SimonDev encountered the same problem of his series on rendering a planet in ThreeJS, can't really remember how he handled it
makes me wonder if you can create moving collision such that only a certain radius around the player checks for collision and ensures things outside it freeze. probably not worth it but my mind is everywhere
I have a couple of questions regarding the player movement and enemies. If the terrain mesh is attached to the player, how do you get the player to look like they are running in a specific direction? Also, how do you have enemies operate in this frame of reference?
When I followed this, UV_X & Y values of 1 or -1 move the heightmap all the way? Not sure why this happens, I am using an image heightmap instead of noise. It's not really a problem as I have divided this value by the resolution of the heightmap but am curious as to why this is.
First, thank you for the tutorial, I found it quite nice and informative, although I'm just getting back into this amazing world (haven't been able to code in quite some time due to work forcing overtime daily and working us 6 days a week) so I'm basically back to square one, and having to learn from scratch again. I'd like to know, could this be used with real world heightmaps? Would it be possible to cover a large area using several real world heightmaps together, and if so, how would one continue to bring in the additional heightmaps in a seamless manner? And lastly, any chance of getting a detailed tutorial on the blender portion of the video also, start to finish? I'm attempting to port my multiplayer framework network code from 3.x over to 4.0 right now. Once I've done that, I'd like to introduce a world into that code in order to actually be able to do something, such as exploring the world. If the above is possible, I'd like to put together the entire game world and then begin populating it, placing assets, etc...
If i understood correctly you're asking if you can use a tilemap as a heightmap for the vertex shader and load tiles into it? If so, my honest answer is that I have no idea. I haven't found anything on it. But, if you wanted your terrain to be massive and seemingly non-repetitive, you could use a huge heightmap image (like 8k) and make it much larger than the clipmap.
@@actualdevmar I came across these videos, basically, this guy Sebastian stitches together every tilemap available for the entire planet, and then proceeds to fly around it. He then turned around and added more and more geographical data, to the point where he ends up flying around the city of Paris France, and it's highly detailed. Problem is, he does this in unity and with C#. I do have a piece of software I found some videos on that shows how to stitch tilemaps together, and I've already downloaded ALL 30m tilemaps from the SRTM project. I will have to find all the ocean data tilemaps as well if I want to do the entire Earth, however, going from one continent to another doesn't have to be seamless, but, each continent being as massive as they are, will take some extreme coding to get it right. It would be very nice to be able to reproduce what Sebastian did in unity and C# within Godot and GDScript. ru-vid.com/group/PLFt_AvWsXl0dT82XMtKATYPcVIhpu2fh6
Its a nice idea. But as i played around wirh this, i acknowledged polygon folding which gave me steps in the terrain... is my clipmesh resolution too low? Or you know any trick to circumvent this?
Make sure your clipmap mesh is scaled such that it snaps to Godot's grid. Best way is to set its scale to a nice round number in meters, in Blender. Say, 4000m. Apply scale and export to Godot. In Godot, make sure that when your terrain mesh moves around in 3d space, it's global position is set to .snapped().
Here is script for creating this mesh in blender if somone needs it. ``` import bpy import bmesh def create_clip_map_mesh(name, initial_size, lod_levels): # Delete all existing objects bpy.ops.object.select_all(action='SELECT') bpy.ops.object.delete(use_global=False) # Create initial grid mesh bpy.ops.mesh.primitive_grid_add(size=initial_size, x_subdivisions=initial_size, y_subdivisions=initial_size) obj = bpy.context.object obj.name = name # Enter edit mode bpy.ops.object.mode_set(mode='EDIT') mesh = bmesh.from_edit_mesh(obj.data) # Iterate through LOD levels for lod in range(1, lod_levels + 1): # Calculate the size of the inner square inner_size = initial_size / (2 ** lod) outer_size = initial_size / (2 ** (lod - 1)) # Deselect all vertices bpy.ops.mesh.select_all(action='DESELECT') # Select faces inside the inner square for face in mesh.faces: face_center = face.calc_center_median() if -inner_size / 2
im new to godot, justa question, usually i see videos of people writing code/scripts inside godot, but i see you connecting nodes ( likes those in blender), can we just use the node system in godot instead of typing code ?
You're referring to the visual shader graph - you can build shaders in this way in Godot. As for gdscript, I believe visual scripting was abandoned a long time ago in Godot. I know UE has a visual scripting system, called Blueprints. Visual scripting is great for beginners but if you want to do anything remotely serious you'll need to learn to code.
@@actualdevmar cool I was thinking you might be able to modify the grip so it only occupies the viewable area eg a triangle instead of square. I know Godot already occludes the outside the frustum but it is one less thing it needs to calculate. You could then also use the triangular region to spawn assets more efficiently without Godot having to calculate this as well. The only thing would be pop in as the player rotated but maybe the triangular region could be a little oversized so edge assets were already loaded.
Is there a way to implement fake motion blur in Godot as of now? I know it has been slated for future, but looking at the speed of Godot's stable releases, I think that it will be atleast 5 years from today when we get a motion blur feature in 3D.
very cool but way more complex for me to play around with it without any code samples, and I promised myself I wont copy paste things out of video-s anymore, as I ended up waisting a lot of time with it in the past. I really wish you would upload it to github
