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.
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.
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!
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.
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.
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.
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.
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 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
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
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.
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.
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.
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
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:)
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.
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.
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.
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?
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?
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 😭
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…
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
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.
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 ?
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().
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.
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.
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)
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.
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
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)
@@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.
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
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. czcams.com/play/PLFt_AvWsXl0dT82XMtKATYPcVIhpu2fh6.html
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.
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.
Can you define "sharp edges" to make sure the seams don't get get distorted when using auto LoD?
@@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.
So the trick is to split the mesh, but keep the number of vertices on both sides of the seam the same, right?
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!
Great reference.
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.
I don't use Godot, but the information provided by the video could be extremely helpful in the future, thank you so much!
As you said yourself, you are sure that we'd like to use fragment shaders to texture the terrain. A tutorial on setting those up would be lovely.
Looks amazing. One thing you should try with the vegetation is to make it fade in instead of just suddenly appearing they way its more smooth looking.
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.
Great idea
Amazing video, very smart technique, thanks a lot for sharing these tips
This is amazing and i have no understanding of the rocket science behind it. Even after the explanation. Incredible.
I was just about to install unity and I saw this. Godot 4 all the way! This engine might be the future.
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.
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!
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.
BEAUTIFUL work!
Fabulous presentation and discourse; excellent video.
Of all the big brain moves , this has to be one of the biggest brainiest moves I have seen. Thanks for sharing this technique
Really liking the progress. The infinite terrain feature is spot on and looks super kool. That is really impressive. Keep it up! :)
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.
I am expecting the collision generation from the same map, cant wait ! thank you
Very nice! Good work devmar!
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.
hey look its that linux music guy
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.
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.
That sound interesting. Is there any article or explanation about your technique? Really like to learn how to approach large world in that way.
Wow very elegant solution to the terrain systems, thanks for sharing
great work! saw one of your videos a while ago and probably forgot to subscribe, fixed now.
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.
Did you build the quadtree system in gdscript?
Actually, with this technique you can also chunk up the clipmap mesh and use frustrum culling.
@@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.
"Boom. Done"
Meanwhile, my brain started leaking out of my ears trying to understand how that shader worked. Good stuff, thanks for doing this!
what a gem! ty for making this Video
this is PERFECT 😎😎😎 exactly what ill need for my road trip game, thx for sharing this with the world
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.
@@actualdevmar Ah! That's the bit you skipped: I'm using the world coordinates as UVs, too. You'll just need different scaling, obviously.
great video..also simple, but clever and effective. Very good.
The first few seconds I thought you remade Death Stranding in Godot XD
I appreciate Your great exposition
Subbed for this video!!! Amazing stuff!
Very impressive! Good work!
Incredible work!!🎬
Love it! Thanks for sharing!
Thanks for watching!
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
I'd be interested in the seeing the QuadTree approach.
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
Thanks, we're going to port to GD4 soon, so I'll try out this technique. Looking forward to collision and vegetation. What graphics card do you have?
2070 mobile
Very cool method.
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.
super - cool technique . . .
This is genius!
This is a brilliant idea.
Amazing stuff you got here
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.
daym bro, tha't brilliant
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.
big fan of your videos, do you have a git repo of your examples?
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
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:)
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.
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.
@@actualdevmar Ah okay it seems i misunderstood thinking its the terrain that is moving. My bad, great video! I learnt something today.
This sticks with me too! Ive been trying to do something VERY VERY similar on a spherical (closed-shape) mesh as well. Still trying :P
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?
you could do this in blender by selecting the edge ring and triangulating the faces but you don't have to - Godot's gltf importer does it for you.
@@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.
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?
Cool solution! What kind of hardware are you working with? Just wanted to be able to put your FPS benchmarks into perspective.
2070 mobile
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?
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 😭
Needs a Tutorial for the Terrain creation : )
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…
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
ok i can make grid in blender but to subdivide it in the middle?
1:11 can someone explain how to section the grid from the time stamp on blender
Do you have a link to a repo ? Easier to understand when I can poke at things :)
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.
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 ?
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().
How to fix rendering clipping at the edges of the camera's viewport?
Great info can you share where did you learned all that ? if i need step by step tutorial to understand
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.
This is clever!
So how is the collision mesh handled for this?
Very cool technique though. very glad I saw this video
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.
Did someone immanent this and have this open source ? looks like the simplest way but very hard to understand without sample project
Is there a tutorial somewhere I can learn about this topic? New to Godot and game dev in general but I have lots of experience programming. Thanks
WHY don't you use the project file so you can read the code in detail?
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)
If I understand correctly, you are limited to only one heightmap texture with this technique?
I'll wait my vacation hahaha
I need to study more
I'll try Godot again
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.
Very interesting! Could you please share that blender script for cutting up a plane into chunks? Would be upser useful.
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 wish there was a tutorial for this
I tried this but i dont get shadows on the terrain after applying the shader... i guess normals arr not updated. How would i do rhat?
I have a video that explains how to fix normals. Its on my channel somewhere..
Wow!
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
Really great video. Is it possible to use this technique with a fixed size heightmap terrain, not infinite?
Sure, thats possible. He was using a fixed size heightmap in the video, only apparently a tiling one.
what if individual want to create a infinite terrain but not so repetitive also? is it possible ?@devmar
Cool i have seen this technique in Unreal but how do you handle level streaming, or are you just using one large height map.
one large height map that tiles to infinity
@@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.
this isn't a complete wandering clipmap implementation, the far LODs will wobble.
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
Thanks
Did someone implement it and have it open source ?
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. czcams.com/play/PLFt_AvWsXl0dT82XMtKATYPcVIhpu2fh6.html
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.
I think there is a screen shader that does it, i recall seeing something like that before in godot.
thanks for making me feel entirely inferior *LOL*, knowing how little I know is better than thinking I know a lot right?