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.
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.
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.
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!
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 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.
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.
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.
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.
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?
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
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…
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.
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.
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?
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
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
@@jakeboots So what I did was went into blender, make a plane then you can resize that plane and apply a Grid to it. The more detailed the grid the more detailed the UV map will be when applied against the clipmap mesh
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.
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.
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.
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().
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.
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 ?
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 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 😭
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
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:)
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.
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. ruclips.net/p/PLFt_AvWsXl0dT82XMtKATYPcVIhpu2fh6
@@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.
@@actualdevmar your solution versus the c++ immediatemesh solution you offered, also, I tried recreating your solution, I have REALLY jagged terrain coming in from the height map, did you run into this issue?
@@trisimix they are completely different techniques. The shader technique allows you to modify the terrain mesh in real time and tile it to infinity. With immediatemesh you'd only create a static terrain mesh. If you want the shading to be smooth there is a setting/code for that in immediatemesh or surface tool (or both, i don't remember). It's covered in the docs.
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.
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
Just place the static objects in the editor where you want them. If you want to place something beyond that starting position of the clipmap, just move the clipmap in the editor to see what the terrain shape is going to be in that remote spot.
It's not a node, it's a variable. In the shading language you use 'uniform' in front of a variable to export it as a parameter into the inspector (in gdscript you'd use 'export'). Float is simply the type of variable.
@@actualdevmar Sorry but could please upload a sample of this whenever you can(just so I can break it down)? I've tried following this a couple of times only to get stumped.
Well, for one, there is almost no performance gained... cause... you basically have to do the same thing just abstracted away... Also, GDExtensions is harder than I expected... So probably there'd be some performance to gain if someone wrote better code than me :))
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
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.
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
I don't use Godot, but the information provided by the video could be extremely helpful in the future, thank you so much!
Amazing video, very smart technique, thanks a lot for sharing these tips
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.
This is amazing and i have no understanding of the rocket science behind it. Even after the explanation. Incredible.
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.
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.
I was just about to install unity and I saw this. Godot 4 all the way! This engine might be the future.
BEAUTIFUL work!
Fabulous presentation and discourse; excellent video.
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!
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
Of all the big brain moves , this has to be one of the biggest brainiest moves I have seen. Thanks for sharing this technique
I am expecting the collision generation from the same map, cant wait ! thank you
Really liking the progress. The infinite terrain feature is spot on and looks super kool. That is really impressive. Keep it up! :)
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
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.
The first few seconds I thought you remade Death Stranding in Godot XD
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.
"Boom. Done"
Meanwhile, my brain started leaking out of my ears trying to understand how that shader worked. Good stuff, thanks for doing this!
Very nice! Good work devmar!
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.
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 appreciate Your great exposition
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.
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.
this is PERFECT 😎😎😎 exactly what ill need for my road trip game, thx for sharing this with the world
I'd be interested in the seeing the QuadTree approach.
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?
Very impressive! Good work!
Subbed for this video!!! Amazing stuff!
Love it! Thanks for sharing!
Thanks for watching!
what a gem! ty for making this Video
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
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…
Very cool method.
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.
super - cool technique . . .
Cool solution! What kind of hardware are you working with? Just wanted to be able to put your FPS benchmarks into perspective.
2070 mobile
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.
Amazing stuff you got here
How to fix rendering clipping at the edges of the camera's viewport?
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?
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 is a brilliant idea.
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
@@aguest5394 how do you make the clipmap pls tell
@@jakeboots So what I did was went into blender, make a plane then you can resize that plane and apply a Grid to it. The more detailed the grid the more detailed the UV map will be when applied against the clipmap mesh
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.
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.
This is genius!
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.
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.
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().
hey devmar 2 years late here but can you please tell me what you did here in 1:22 to make the terrain
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.
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 ?
Did someone immanent this and have this open source ? looks like the simplest way but very hard to understand without sample project
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.
If I understand correctly, you are limited to only one heightmap texture with this technique?
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 😭
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
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:)
Great info can you share where did you learned all that ? if i need step by step tutorial to understand
ok i can make grid in blender but to subdivide it in the middle?
Do you have a link to a repo ? Easier to understand when I can poke at things :)
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)
So how is the collision mesh handled for this?
Very cool technique though. very glad I saw this video
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
what if individual want to create a infinite terrain but not so repetitive also? is it possible ?@devmar
1:11 can someone explain how to section the grid from the time stamp on blender
Very interesting! Could you please share that blender script for cutting up a plane into chunks? Would be upser useful.
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.
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.
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. ruclips.net/p/PLFt_AvWsXl0dT82XMtKATYPcVIhpu2fh6
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..
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
You can also use godot plane meshes and subdivide them instead of using blender.
daym bro, tha't brilliant
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.
in c++ would this technique or immediatemesh be faster do you think
You mean which is faster vertex shader or building a mesh?
@@actualdevmar your solution versus the c++ immediatemesh solution you offered, also, I tried recreating your solution, I have REALLY jagged terrain coming in from the height map, did you run into this issue?
@@trisimix they are completely different techniques. The shader technique allows you to modify the terrain mesh in real time and tile it to infinity. With immediatemesh you'd only create a static terrain mesh. If you want the shading to be smooth there is a setting/code for that in immediatemesh or surface tool (or both, i don't remember). It's covered in the docs.
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.
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
Doing it this way, how do you handle positions of static objects, like trees and buildings?
Just place the static objects in the editor where you want them. If you want to place something beyond that starting position of the clipmap, just move the clipmap in the editor to see what the terrain shape is going to be in that remote spot.
@@actualdevmar You could probably make an editor tool which would move the clipmap in the editor for you at the position of the editor camera. :)
@@novh4ck indeed. should be easy enough to do with the surface tool or immediatemesh
I'll wait my vacation hahaha
I need to study more
I'll try Godot again
This is clever!
WHY don't you use the project file so you can read the code in detail?
Could you set higher bitrate?
Needs a Tutorial for the Terrain creation : )
How do you find the Float Uniform node; or is it only for Godot 4?
It's not a node, it's a variable. In the shading language you use 'uniform' in front of a variable to export it as a parameter into the inspector (in gdscript you'd use 'export'). Float is simply the type of variable.
@@actualdevmar Sorry but could please upload a sample of this whenever you can(just so I can break it down)? I've tried following this a couple of times only to get stumped.
@@neytracg308 I think in the latest godot alpha they are called parameters, though I'm not sure
can you make a download fr the blender file too maybe?
Mind if I steal this and make it into a plugin for godot 4 somewhere in the future?
With GDNative, I mean
I'd love to see/use it!
Well, for one, there is almost no performance gained... cause... you basically have to do the same thing just abstracted away...
Also, GDExtensions is harder than I expected...
So probably there'd be some performance to gain if someone wrote better code than me :))
Wow!
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