Steve's Dev-Stream-of-Consciousness

SteveRock

I'm gonna post a bunch of random stuff here that I think people might find interesting, often without much context, but definitely related to what I'm working on for Subnautica. If you're interested in game dev, especially for procedural open world type games, dig in!

Starting with some shadertoy stuff I've been experimenting with...
https://www.shadertoy.com/view/4d23R3#
https://www.shadertoy.com/view/4dB3DV
https://www.shadertoy.com/view/4sXXz7

SteveRock

Currently trying to implement: http://casual-effects.blogspot.com/2014/03/weighted-blended-order-independent.html for really transparent creatures, like jelly fish and stuff. Paper by Max's brother! Here's a preview i guess? http://i.imgur.com/PUDXD3B.png

SteveRock

We haven't fully implemented this yet, but here's like a 10-minute prototype of some procedural creature animation. Pretty basic stuff, really easy to setup in Unity:

SteveRock

we've switched over to Plastic SCM for version control. It is awesome, and I now love branching and merging: http://i.imgur.com/DppPhGP.png

SteveRock

we're using marmoset shaders for a the submarine interiors right now, and hopefully we'll use them for a lot of props and creatures as well. https://www.marmoset.co/skyshop

coolitic

If you keep this up, this will become very long thread lol

Would need more organization. (unless of course you dont plan to keep posting everything here)

Racer1

That's an impressive first go. Hope to see less rigid tail formation in the next iteration. It would be also good to see that in the arms (to a lesser extent), unless they are going to have their own animation.

P.S. How hard is it to slightly vary the the bone position/rigidity/etc at runtime for each entity? It would be great if they not all moved in an identical fashion.

Locklear

That looks really nice!

CarNagE1

Yep the game can use a smooth animations like this, cant wait...

SteveRock

Dev diary mind dump time:
After some random stuff in the morning, I spent most of today working out bugs with the order-independent blending (full acronym: WBOIT). I'll post some shots...anyway, blending in games is always gonna suck to some extent, so we're just trying to find the thing that sucks the least. This WBOIT method definitely has some drawn backs, as I discovered today. Per-pixel light passes can't really be done the same way, so even if you just have 1 layer and 1 point light, you won't get the same results. Effectively, all blended layers have to get drawn "over" lights, since the only thing you can really do is add your lights on top of your opaqe bg and then do the composite pass...ah well. Hopefully the artists will be OK with this, because I think WBOIT lets you do much cooler stuff with heavily transparent creatures and props. Will post some shots hopefully tmrw.

SteveRock

Here's a video showing the benefits of the order-independent blending method:

Racer1

Is it too resource intenstive to "WBOIT" the lifeform then composite pass using more traditional methods to add environmental lighting?

SteveRock

Racer1 wrote: »

Is it too resource intenstive to "WBOIT" the lifeform then composite pass using more traditional methods to add environmental lighting?

That is an interesting thought...but then I think you would have the opposite problem where the lighting over takes everything. Once you do the WBOIT stuff, all depth information is gone. So if a lit part was supposed to be covered up by some other layers above it, there's no real way to figure that out.

SteveRock

The core of the issue is that Unity only does per-pixel point lights in separate passes. This would work fine if all lighting were done in the ForwardBase pass...But there may be a way to blend in the point light passes to preserve the original effect....gonna experiment some more later.

An even more extreme thought is to do the WBOIT passes per-object, so then you'd at least get proper depth cues between objects. But...you're talking about two passes per object..which I suppose isn't the end of the world, but it definitely would be more expensive. I'll have to think about this a bit more..

ellnic

It looks absolutely fantastic. Please post more, PLEASE!

SteveRock

Here's a shot of my test level for the transparency stuff :P

SteveRock

Today was mostly implementing clip maps. Still quite a bit to do, but they are very promising already. The original paper is here: http://research.microsoft.com/en-us/um/people/hoppe/geomclipmap.pdf Although the specific details are very different, since we're doing 3D.

Here's a debuggin' screen shot:



Still a lot left to do, but it's nice to have some sort of huge draw distance, even tho the far away stuff may be horrible

IronHorse

how does marmoset lighting handle LOD? Is it separate from the typical Unity LOD settings so that you can adjust a whole area's lighting and yet have a particular object only show 100% detail at melee range?

SteveRock

IronHorse wrote: »

how does marmoset lighting handle LOD? Is it separate from the typical Unity LOD settings so that you can adjust a whole area's lighting and yet have a particular object only show 100% detail at melee range?

I have no idea It's pretty fast, but for low quality, we might just need to disable the IBL shaders? No idea.

Racer1

So did Steve's consciousness cease?

SteveRock

ok so i took a 3 month long vacation and now i'm back to work on SN.

some pretty tech-heavy stuff here...

current biggest problem i need to solve: terrain performance. our terrain looks pretty great up close IMHO, but our draw distance really blows and the perf is a bit like Crysis 1 all over again :-/ so i need to make the terrain meshes more efficient (ie. less triangles). some simple things i tried worked about as well as you could expect: not too well.

i've been reading a boat load of papers on adaptive voxel meshing, and here's a good list: http://swiftcoder.wordpress.com/planets/isosurface-extraction/ Although it's missing this very important one: http://vis.computer.org/vis2004/dvd/vis/papers/nielson2.pdf

unfortunately, most of the adaptive methods seem to assume you have a pretty hefty data structure (an octree where each node stores a cell with 8 corner values and/or some quantity derived from those). currently, our octree is just one density value per node, and it fits pretty snuggly, usually under 50mb. i'd rather not dedicate 200+MB just for voxel data... it's also not clear how good the results are compared to classic quadric mesh simplification/decimation...

so anyway, my current approach is going to be: mesh it normally, then use mesh simplification to reduce the triangle count. this has the disadvantage of needing to actually get the whole mesh first, but hopefully that won't be a big deal since all that's done on a child-thread anyway. post-meshing simplification will likely get you the best results too. not too worried about borders: just going to not simplify border tris at all so all pieces will definitely fit together, water tight, no T-junctions or anything. a bit wasteful, but just on the borders. Max already helped me by writing the simplification code, so i just gotta plug it in.

if it's too slow to do at run time, we always have the nuclear option: precompute all meshes, simplify them, and ship them. i'd prefer not to do this, since it would mean a long build process, and it complicates terrain deformation (which is low priority, but hopefully eventually).

oh, i did also change our meshing code to actually use density values instead of binary minecraft, so our hills look a lot smoother now. yay!

SteveRock

and since i'm in the mood, i'll say a few words about our voxel meshing approach.

we use dual marching cubes [Nielson2004] to get a nice mesh of all quads. the vertices are positioned using distance-field values (stored as bytes, for 128 fixed points of precision), allowing gradual slopes and smooth spheres and stuff. then we subdivide once and do a Laplacian smoothing to make things look, well, even more smooth! this generates a shit load of quads (and twice as many triangles!), but it gives us a nice rounded look that is pretty different from a lot of voxel engines out there. most engines tend to look sharp and jaggy because they're either based on classic marching cubes, which can generate crappy triangles, or they don't bother with mesh topology so they can't subdivide or smooth normals.

of course, all this comes at a price. our draw distance will probably never be Skyrim-amazing, and as mentioned above, performance is a challenge. but, for a game where you're swimming around and examining things a lot with your face in the sand, we thought it was pretty important for terrain to look good up close and from all angles.

Racer1

So does the performance problem with smoothing show up at medium to far distances (where you already have reduced poly count)? If so, perhaps you could choose to not apply smoothing beyond a certain distance. Alternatively, apply smoothing, but only to every nth vertex (provided you have a way to always choose the same vertexes to smooth, which may be difficult).

SteveRock

it's not really the smoothing that's the bottleneck here. like you said, there are plenty of ways we can compromise with smoothing (which we do). the tricky part is getting the lower poly meshes to begin with for far away LODs. there are some simple things you can do, such as mesh at half-res, but that produces too much noticeable popping. and as i said above, most adaptive meshing methods (which would give you low poly meshes for far away) require hefty data structures. thus, the mesh + simplify approach i was talking about above. it's hard to beat quadric simplification (http://www1.cs.columbia.edu/~cs4162/html05s/garland97.pdf) for quality when it comes to general meshes.

Racer1

How often does distance terrain (that is, terrain being rendered from the low-poly mesh) change? You could keep a low-poly mesh copy in memory and just use it, rotating/transforming as necessary. The only time it would need to be updated is if:
a) the view changes (resulting in a fairly minor slice to be re-meshed), or
b) a distance terrain object is changed, which would result in a localized re-meshing (that would hopefully not be too resource intensive)

Objects that move in the distance could take a different approach, such as being added to a separate low-poly mesh in real-time which would be combined with the terrain low-poly mesh before rendering. They could even be generated at a different LOD depending on their complexity.

SteveRock

yeah that is the basic idea, but the devil's in the details. the basic question is how quickly we can create the low-poly meshes. ideally, i'd like to just do all the simplifying at run time, so we can support terrain modding. as opposed to simplifying the meshes at build-time, which would increase the on-disk size of our game and make terrain modding more of a pain.

SteveRock

ok finally got around to hooking up max's mesh simplify code, multithreading the clip mapping, etc. Results are very very promising:

Warmonger

That looks really nice. Thanks for the eye candy :-)

SteveRock

here's a wireframe break down of our simplification, plus a randomized optimization i just added (following this idea: http://procworld.blogspot.com/2011/10/playing-dice-with-mesh-simplification.html)

SteveRock

And, we are doing this all at run time in a multithreaded manner. This is so we can support terrain modding..so I'm trying real hard to avoid baking meshes (which is probably what most open world games do...?). Although worse case, we can probably bake meshes, but when the player modifies terrain, we just re-bake the ones we need to update. This will increase the size of save games a bit, but we're targetting PC so that may work out OK.

Racer1

Looks very promising. Thanks for the update.

So is going from 57k to 23k triangles per "3D area" enough of a reduction? I was thinking on the order of 10x to 100x reduction being required to fit the visible scene into memory.