Tonight I played around with planets. I just wanted to see if my 'stupid' version of fake scattering would work. Sure enough, it looks good! As you would expect, the atmosphere is a semitransparent sphere slightly larger than the planet. The math is completely fake, but it looks nice enough for me.
Red planet with blue atmosphere and color transitions:
Red planet with uniform blue atmosphere:
Red planet with green atmosphere:
I'm definitely enjoying my first experiences with procedural grass.
A few more details on what's going on:
- 200,000 blades per scene
- Each blade is a curved strip of double-sided quads
- Perlin noise functions control various properties of the grass to give variation
- Blades have simple pre-computed occlusion based on the terrain height function
- Everything is generated on the CPU and shoved into a single vertex/index buffer
First attempt ever at grass! It had to happen sooner or later. I'm excited about the results 🙂
I started playing around with procedural ships again this week. This time, I decided I wanted to have some really quick prototyping fun and focus on the building algorithm rather than on the technical looks of the ship (i.e., ditch the implicit surfaces/contiguous mesh). This desire led to...block ships! What could make easier building blocks than...blocks? At any rate, even though they're just big formations of blocks, some of the ships are still pretty darn interesting. With enough bloom filter, I'd say they even look cool 🙂
99% of the time, algorithms end up being way more frustrating and way less effective in code than they were in your head. Then, there's that 1% of the time wherein divine powder falls from the sky, striking your code at a secret, magical angle that induces ridiculous levels of wow-this-just-works-ness. And then you ask "where's the catch?" and hope that there isn't one.
Such has been the story of SurfaceWrap, my work-in-progress surface-based scalar field polygonization algorithm. It's remarkable how well it's working so far. Granted, it's still not adaptive nor self-stitching, so I'm hesitant to terminate my relationship with marching cubes just yet...but things are looking really, really good. I've run into a surprisingly small number of headaches, especially considering how hard I usually fail at writing topological algorithms.
Here's the current state of the algorithm:
A few things to notice:
- The triangles cover the surface very smoothly and gradually without slivers or jaggies
- The consistency of the triangles is really nice! Looks like this algorithm is going to dominate with symmetric surfaces
- Approximate normals are calculated for free (no gradient evaluations!) during the process! BIG WIN!
- Although stitching isn't yet implemented, no self-intersection has been observed (so long as the boundary isn't allowed to wrap back around on itself). Looks like the small-angle-elimination feature is keeping everything in check
Next step: boundary merging/splitting. Pray for me.
I've set aside the physics engine for a while to undertake another huge project - one that lies at the core of everything I do. My new goal: eliminate marching cubes. It's slow, it's memory intensive, it has no respect for surface topology, and it's not easy to make adaptive.
Instead, I'm building an algorithm that will polygonize a surface using....the surface! Just like my adapted version of marching cubes ('crawling cubes') crawls along the surface, so will my new algorithm. But, unlike MC, my algorithm will orient triangles such that they actually approximate the surface.
This is definitely going to be the most challenging algorithm I've ever designed, and I'm sure edge cases and slight things that I haven't considered yet are going to turn this into an absolute nightmare...but the reward for success is huge: polygonization quality and speed are absolutely essential to my entire engine, since all meshes will be converted at some point. MC is currently responsible for many of the annoyances that I see on a daily basis: poorly-calculated normals (due to sliver triangles), high poly count (due to the lack of adaptiveness), meshes with holes (due to lack of a bulletproof method for determining the isosurface bounds). A good surface-based algorithm will fix all of the above.
At any rate, I'm excited to have some initial results to share! It's not much, but you can see the formation of something that loosely resembles a surface! There's no adaptability yet, and the surface doesn't handle self-intersection (which I anticipate will be the most difficult part of the algorithm). Still, it's an encouraging start, and the surface quality clearly beats out anything MC could produce.