Great stuff! For a game I am making, I hope you'll also talk about how to generate different "archetypes" of planets. I.e. those more Earthlike or more Martian, and so on.
I just used double CPU side. I convert to float on the way to the GPU and each chunk has an offset. The main trick I use is to never go to word coordinates GPU side. You go straight to view coordinates so it's a bit like what you are doing since that camera is always at the origin.
@@simondev758 I figured clouds might be a way into obscuring that weird scattering transition where the planet is essentially naked, then gets a cataract around, then the scattering looks right. But maybe there's other ways to address that :)
Yeah looking at some shots of the international space station and capsules entering orbit, the clouds do a good job of adding some detail on top of the scattering, otherwise it does kinda look naked lol.
But when you leave the planet, do you not have the same problem of precision error when moving towards the planet again? Let's take your example at 5:40 and use it "backwards": I leave the planet, so it is at (100.000, y, z) relative to the player camera. Now I move towards it again, just 1 millimeter, which should result in the loss of this movement and the planet would stay where it is. Same with the opposite faces of the planet, when the planet is big enough which should result in the planet breaking apart... can someone tell me where my misunderstanding lies?
The precision issues are always there, that's just a fact of life working with floats. The choice you have is to either have them up close and visible, or so far away that they're inconsequential. So yeah, at distances the planet will be subject to floating point inaccuracies. But you still had those at ground level, they're just so far away that it doesn't matter.
@@simondev758 I was looking for a way to simulate and render arbitrary large objects and stumbled across your video. So, it seems I will have to divide the game world into sectors and combine it with the floating-origin approach... Thanks for your reply and great channel btw!
If we set the origin to the camera (or virtual character), what is the best way to know the exact position of the camera/character in the world ? The position of a character in the world is crucial for networking.
@@simondev758 It's an honor to talk to you. I haven't got that far in my project yet, so I got some concepts theoretically in my head still. But yeah I want to do what you do here in the video.
@@simondev758 can't wait for final product, i need to make planets/moons in Unreal 4. Your solution is the only one i found that can load height maps, do you think i could make height maps on world machine or world creator, then load them on a project like this ? then i would need to apply masks, do you think it's possible ? (Unreal works with C++)
I totally get the IEEE754 issue, but why is it whobbling? I would expect an uneven surface, but not a nondeterministic mesh/transformation result. Even with float, the same calculation should yield same in-precise float, not a different float. I you don’t move the camera where’s the source of the nondeterministic behavior?
Yep, new one came out monday (the log depth one), and I have the code for fixing the gaps between lods done, that was a little tricky because it's not just about fixing the mesh itself, which isn't' that hard, but fixing lighting discontinuities. Video will be up... when I make it. Probably in the next few weeks.
About a decade in game development (major studios, console + pc), then nearly as long at Google. Have a Bsc. in computer science, but anything you see here is self-taught.
*pause at 7m* thank god, it's indeed about true floaty and not shifty, almost anything I find on it is shifty origin. Which wouldn't be the best for what I want to try.
Hey! Someone linked to your channel from the three.js slack channel. Do you think your approach could be used as a good basis to create something a google-earthl-like ui?
Google Earth's major requirement seems to be to stream in the appropriate textures/meshes seamlessly given what's visible. I'd think the floating origin thing should work fine in that setting, the rest of the approach/design is mostly centered around making this all procedurally.
Hah, seems like it! Calling me out on issues is a good way to get me to actually do something about them. I'm wrapping up the house renovations, so possibly in Nov we'll start seeing me post more than once a month :P
Nice. Looks like such clean and efficient code. Makes my huge quadtree planet generator code look ugly as hell! I use Unity with threading and compute shaders and everything is double precision to get around the problem. And thousands of lines of ugly code haha.
@@simondev758 It's still faster than CPU of course but getting the data back means you need to spread the generation of your terrain over a few frames.
@@tonywells6990 That makes much more sense, and this was all written in an async, "we'll swap things when they're ready" style, so switching to compute shouldn't be too bad then.
is there any chance you could redo this series for unity? I know you may not be a unity dev(not sure if you are or are not) but if you could do this series for unity you would have 10x the views, as so many people want to know how.
Yeah I've been considering redoing the series in Unity. In reality, the concepts are 100% the same, there's just a slightly different api surface to generate the mesh and all that. Should be relatively straightforward. Anyway, yeah been thinking about it, you'll probably start to see some stuff in Unity once I have time to properly sit down with it.
@@simondev758 Dude, please do it up. You have brain skills that many of us are dying for! Unity has its own unique challenges which make it difficult, or perhaps thats just my evaluation of it. All I can say is, Unity has a massive community of prospective developers and everyone wants to know how to do procGen planets. Its the holy grail.
seems overcomplicated. what i usually do is wrap the whole scene graph into a container, and put it in the root. and then each frame i just set containers position to the relative position of the camera. this way the global position of the camera always stays in the global origin. the cost is a few more matrix updates every frame though
The terrain doesn't look real because you have low hills everywhere. It looks like vomit. A real landscape has hills and mountains in ranges, with plains that can extend for hundreds or thousands of miles.
Vomit is a bit harsh, but yeah it needs work. Up until now, we've only covered gradient noise and fbm's, without going into advanced noise, layers, etc. So it is what it is for now.
Yo, just stumbled upon this channel, I love your approach to these vids a lot! Thank you
Awesome, let me know if you've got ideas for future vids too!
All my brain could process when you explained your solution was Professor Farnsworth explaining how the dark matter engines work in Futurma.
Aw man, missed opportunity to put that reference in the video!
A video on a solution to the far clipping plane would be very helpful. This video was awesome!!
Definitely coming, know how to fix it, just gotta actually do it. Will revisit this series soon.
Great stuff! For a game I am making, I hope you'll also talk about how to generate different "archetypes" of planets. I.e. those more Earthlike or more Martian, and so on.
Great idea, I think it'd be really cool to have a whole lot of different planets.
Progressing nicely. Good job man.
thx man
ah perfect. Wanted to get started on js game making. This channel is just perfect.
Glad to have you around! If you have any suggestions for future content, let me know.
I just used double CPU side. I convert to float on the way to the GPU and each chunk has an offset. The main trick I use is to never go to word coordinates GPU side. You go straight to view coordinates so it's a bit like what you are doing since that camera is always at the origin.
Once again, outstanding. Looking forward to learning how you tackle the remaining issues! Then maybe volumetric clouds?
Good suggestion, trying to decide if I should " go closer" and put things onto these worlds, or focus on moving "further out".
@@simondev758 I figured clouds might be a way into obscuring that weird scattering transition where the planet is essentially naked, then gets a cataract around, then the scattering looks right. But maybe there's other ways to address that :)
Yeah looking at some shots of the international space station and capsules entering orbit, the clouds do a good job of adding some detail on top of the scattering, otherwise it does kinda look naked lol.
Nice work Simon!
This channel is chef's kiss 👌
But when you leave the planet, do you not have the same problem of precision error when moving towards the planet again? Let's take your example at 5:40 and use it "backwards": I leave the planet, so it is at (100.000, y, z) relative to the player camera. Now I move towards it again, just 1 millimeter, which should result in the loss of this movement and the planet would stay where it is. Same with the opposite faces of the planet, when the planet is big enough which should result in the planet breaking apart... can someone tell me where my misunderstanding lies?
The precision issues are always there, that's just a fact of life working with floats. The choice you have is to either have them up close and visible, or so far away that they're inconsequential.
So yeah, at distances the planet will be subject to floating point inaccuracies. But you still had those at ground level, they're just so far away that it doesn't matter.
@@simondev758 I was looking for a way to simulate and render arbitrary large objects and stumbled across your video. So, it seems I will have to divide the game world into sectors and combine it with the floating-origin approach... Thanks for your reply and great channel btw!
@@PizzaFreak89525 np thx!
you are really pro. I respect you.
4:57 The green part is wrong if it is supposed to be a binary representation of 10. I have no idea what the red part is saying.
Are you sure?
green = exponent = 10000010 = 130 - 127 = 3
so, the whole float is:
sign * mantissa * 2^exponent
= 1.250125... * 2^3
= 1.25... * 8
= 10.001... roughly
Unless I missed something?
If we set the origin to the camera (or virtual character), what is the best way to know the exact position of the camera/character in the world ? The position of a character in the world is crucial for networking.
The origin thing is just for rendering.
@@simondev758 It's an honor to talk to you. I haven't got that far in my project yet, so I got some concepts theoretically in my head still. But yeah I want to do what you do here in the video.
Awesome ❤
Fascinating stuff. Thank u
Hello world,
will this project be continued?
100%, in fact I'm just finishing up the next one, should be good to go for monday, and the code for the one after is done.
@@simondev758 glad to hear! I almost felt in love with this tutorial series :)
Thinking about making a real time strategy game out of it
Are you sure you didn't just create a Brownian motion simulation? is Brownian motion a float?
Great Job
ty
next video when ? mind blowing series !!
ty! The series isn't dead, mostly just hinges on what I decide to work on and how much time I have in any given week.
@@simondev758 can't wait for final product, i need to make planets/moons in Unreal 4.
Your solution is the only one i found that can load height maps, do you think i could make height maps on world machine or world creator, then load them on a project like this ?
then i would need to apply masks, do you think it's possible ? (Unreal works with C++)
I totally get the IEEE754 issue, but why is it whobbling?
I would expect an uneven surface, but not a nondeterministic mesh/transformation result.
Even with float, the same calculation should yield same in-precise float, not a different float.
I you don’t move the camera where’s the source of the nondeterministic behavior?
Yep you're right, if you stay perfectly still it'll stop jiggling. I'm translating/rotating the camera looking around.
Is there more to come in this series?
Yep, new one came out monday (the log depth one), and I have the code for fixing the gaps between lods done, that was a little tricky because it's not just about fixing the mesh itself, which isn't' that hard, but fixing lighting discontinuities. Video will be up... when I make it. Probably in the next few weeks.
Can you combine your minecraft demo with these planets to make planets where you can build and break the terrain? That would be super dope!
Ya that could be pretty sweet
Simon how long have you been coding for? And how did you learn? Thanks I love your videos
About a decade in game development (major studios, console + pc), then nearly as long at Google. Have a Bsc. in computer science, but anything you see here is self-taught.
*pause at 7m* thank god, it's indeed about true floaty and not shifty, almost anything I find on it is shifty origin. Which wouldn't be the best for what I want to try.
Hey! Someone linked to your channel from the three.js slack channel. Do you think your approach could be used as a good basis to create something a google-earthl-like ui?
Google Earth's major requirement seems to be to stream in the appropriate textures/meshes seamlessly given what's visible. I'd think the floating origin thing should work fine in that setting, the rest of the approach/design is mostly centered around making this all procedurally.
Basically you need to be presented with issues and challenges to keep the videos rolling :D (Y)
Hah, seems like it! Calling me out on issues is a good way to get me to actually do something about them.
I'm wrapping up the house renovations, so possibly in Nov we'll start seeing me post more than once a month :P
Nice. Looks like such clean and efficient code. Makes my huge quadtree planet generator code look ugly as hell! I use Unity with threading and compute shaders and everything is double precision to get around the problem. And thousands of lines of ugly code haha.
Compute shaders though! Must run crazy fast.
@@simondev758 You'd think so but getting the data back is slow.
Ah darn, had wanted to try out some webgpu stuff on this.
@@simondev758 It's still faster than CPU of course but getting the data back means you need to spread the generation of your terrain over a few frames.
@@tonywells6990 That makes much more sense, and this was all written in an async, "we'll swap things when they're ready" style, so switching to compute shouldn't be too bad then.
Far clipping plane would be good for a desert scene.
is there any chance you could redo this series for unity? I know you may not be a unity dev(not sure if you are or are not) but if you could do this series for unity you would have 10x the views, as so many people want to know how.
Yeah I've been considering redoing the series in Unity. In reality, the concepts are 100% the same, there's just a slightly different api surface to generate the mesh and all that. Should be relatively straightforward.
Anyway, yeah been thinking about it, you'll probably start to see some stuff in Unity once I have time to properly sit down with it.
@@simondev758 Dude, please do it up. You have brain skills that many of us are dying for! Unity has its own unique challenges which make it difficult, or perhaps thats just my evaluation of it.
All I can say is, Unity has a massive community of prospective developers and everyone wants to know how to do procGen planets.
Its the holy grail.
@@triangle4studios Look up Sebastian Lague, he has a very similar tutorial series, but in Unity.
seems overcomplicated. what i usually do is wrap the whole scene graph into a container, and put it in the root. and then each frame i just set containers position to the relative position of the camera. this way the global position of the camera always stays in the global origin. the cost is a few more matrix updates every frame though
awesome thx
np
@@simondev758 the new code will be there? github.com/simondevyoutube/ProceduralTerrain_Part8
Oops sorry looks like I didn't upload, I'll do that as soon as I'm at my desktop.
Ok here you go, let me know if you see it.
@@simondev758 perfect!
Can you add a real ocean 🌊
No man sky planets looks so fake, I mean there are visible transitions or something. Space engineers planets looks real though
Nice, hadn't seen their stuff, checking it out.
The terrain doesn't look real because you have low hills everywhere. It looks like vomit. A real landscape has hills and mountains in ranges, with plains that can extend for hundreds or thousands of miles.
Vomit is a bit harsh, but yeah it needs work. Up until now, we've only covered gradient noise and fbm's, without going into advanced noise, layers, etc. So it is what it is for now.