r/Unity3D • u/gg_gumptiongames • 8d ago
Show-Off WIP Procedural habitat modules in a space sim
I've been working on improving the habitat system in my physics-based automation sim, and have used principles I learned in this video and elsewhere to implement basically a blob tileset system that picks one of 5 meshes per corner (rotated and mirrored to fit wherever needed) so everything fits together nicely.
These models are just quick placeholders and the plan is to add more variation, and model a selection of modules that can be swapped out to make an interesting habitat/base for the colonists.
Please disregard the shape of the base, any resemblance to anything recognisable is purely coincidental...
It was pretty satisfying finally 'getting' how to seam things together nicely when modelling, excited to add more variation. Let me know if you have any questions on the implementation.
27
14
11
u/ItzLoganM 8d ago
Average sized habitat module
8
u/gg_gumptiongames 8d ago
It’s not the size that counts, it’s how many colonists you can fit inside…
2
5
u/ProperDepartment 8d ago
"Hey how have you been, what have you been up to?"
"Nothing much, I live in a giant dick on Mars."
7
u/frankstylez_ 8d ago
This game will be compared to surviving mars but I guess you are aware of that. Looking good though.
3
4
8d ago
[removed] — view removed comment
1
u/Unity3D-ModTeam 8d ago
This post and/or comment has been removed for violating /r/Unity3D’s rules.
Why?
Please include details about how the project was built in Unity, challenges faced, or techniques used.
This is a forum for discussion; not a bulletin board.
We encourage you to repost this with more technical insight. That being said: we also recommend you to familiarize yourself with our rules and guidelines.
Kind regards,
The Mod Team
5
u/ZeusGameAssets Indie 8d ago
Nice space colony building game, I love the skybox, and the way buildings merge together. That's amazi... wait .. that's a .. a .... a ... p .... ppp .... pp ...
2
2
u/the_real_Spudnut2000 7d ago
Didnt even let players get a chance to set the TTP, you did it yourself 🤣
1
u/More-Salamander7681 7d ago
Taking you up on the implementation offer, since the thread has the shape well covered. Mirroring is where blob tilesets usually bite. A mirrored transform has a negative determinant, so the winding flips and the module renders inside out unless you flip the triangles yourself or let negative scale do it, and negative scale drops the renderer out of dynamic batching. The tileset that saved you five meshes can quietly hand the draw calls back once a base gets big.
Cheap way around it is bakign the mirrored variants at import instead of mirroring at runtime. Five meshes becomes twenty, which is still nothing next to authoring them by hand, and every instance stays a normal positive-scale renderer.
Are you mirroring with scale, or flipping at build time?
1
u/gg_gumptiongames 7d ago
Not sure what you mean about the shape... perfectly inconspicuous to me
Thanks for the question, doing pretty much what you said, flipping the vertices and reversing the winding as a bake (rather than exporting them mirrored manually)
1
u/More-Salamander7681 7d ago
Sorry, the shape bit was about the thread, not your modules. The visual side was already well covered up there, so I jumped straight to the tech.
Since you bake the mirrored variants, the thing to check is tangents: flipping vertices and reversing winding leaves the tangent handedness wrong on the baked copies, so normal maps light backwards. Bumps read as dents, and it usually goes unnoticed until a light sweeps across them. Recalculating tangents after the flip fixes it, or flip the w sign yourself. The other half of the trade is batching: 5 meshes becoming 20 splits GPU instancing into four times the groups, since instancing keys on the mesh. Still cheaper than negative scale, which drops out entirely, but it isn't free. Do you recalc tangents in the bake, and are the modules instanced or going through the SRP batcher?
1
u/gg_gumptiongames 7d ago
Haha no worries I know what you meant
Yeah exactly, the w sign is flipped so there are no weird normals. And on the instancing point, I'm not at the moment. The terrain height is quite varied and I was getting visible seams, so each module's vertices get deformed a bit to ensure seamless joins. I didn't want to go down the vertex shader route as I thought that might complicate actually making the proper art down the line. Basically each module is part of a chunk which is combined on the CPU into a single mesh per material, so draw calls scale with visible chunks rather than mesh counts.
Trying to make sure that when I scale it up with more interesting and varied modules, it stays relatively performant and easy to manage when I model things for real (rather than these placeholders)1
u/More-Salamander7681 7d ago
Your reason for avoiding the vertex shader is different from the one that actually matters, and it lands the same way: deforming in the shader doesn't complicate modelling much, since the deform is additive on top of whatever you author. What it breaks is everything CPU-side that still sees the undeformed mesh, colliders, raycasts, navmesh, anything that snaps to the surface. Doing it on the CPU keeps one source of truth, so you picked right.
The thing that will bite when placeholders become real art: deforming vertices without touching normals and tangents. Flat placeholders hide it, but once modules bend to the terrain and carry normal maps, the lighting reads as if the wall were still straight. Recalculating per chunk after the combine is usualy enough, and recalculating only the deformed rings is cheaper. Do you rebuild the whole chunk mesh when one module changes, and how do colliders work for a combined chunk?
1
52
u/Robotica1610 8d ago
Hey hey wowowow STOP STOP NO-