3D World Generation #8: Floating Origins for Bigger Worlds (JavaScript/Three.js)
HTML-код
- Опубликовано: 26 авг 2024
- Follow me on:
Twitter: / iced_coffee_dev
Github: github.com/sim...
In this project we tackle adding floating origins to our procedural worlds, allowing us to build planets far bigger than previously possible. This allows us to scale up from dinky little moon-and-asteroid sized worlds to Earth sized planets (and beyond). We'll be making a few small and painless changes to the existing mesh generation code to support the feature.
This is the 8th in a series of 3D World Generation and procedural terrain tutorials. In previous tutorials, we started with mesh generation using height maps, before moving onto more advanced topics like quad-trees, planetary level-of-detail, atmospheric scattering, and threading. This project examines how floating origins help us expand the size of our generated worlds, allowing us to easily simulate Earth sized planets and beyond in JavaScript.
The three.js library is available in JavaScript for cross-browser 3d graphics, wrapping webgl and making high level functionality available in the web browser. It’s an extremely mature and well maintained library that I use for many of these videos.
In the video, we cover:
* Rendering Issues encountered when scaling up to Earth sized planets.
* How and why floating point precision is important and how it effects rendering.
* What floating origins are and how they work.
* The code changes needed to fix spatial jitter.
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.
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!
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.
you are really pro. I respect you.
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.
Progressing nicely. Good job man.
thx man
Awesome ❤
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.
*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.
This channel is chef's kiss 👌
Nice work Simon!
Fascinating stuff. Thank u
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++)
Great Job
ty
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.
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.
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
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
Far clipping plane would be good for a desert scene.
Are you sure you didn't just create a Brownian motion simulation? is Brownian motion a float?
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.
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.
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.
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!
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
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!
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.
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
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?
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.
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.