I’m trying to procedural generate asteroids recently.
It seems there is no detailed implementation I can copycat.
So far I try to implement it by description in those internet discussions.
I think you veterans definitely have different insight, please take a look and give me some comments or advice if you have time/interested, thank you!
Some sample images:
- Generate a subdivided cube or sphere mesh in 1x1x1 bounding box
- Random scale the mesh
- Cut the mesh by random planes. Cut means project the vertices behind the plane onto the plane.
- Displace vertices along normal by noise.
For texturing, there are 2 ways:
- UV mapping (drawback: there will be seams)
i. Cut the mesh to two half, use auto_uv_map to generate UV.
ii. Use Urho3D built-in function GenerateTangents() to generate tangent.
- Triplanar mapping (drawback: the bumpness is not as clear as method 1)
i. Modify LitSolid shader to LitSolidTriplanar by referencing internet articles.
- Generate height map by placing some random craters and white noise.
- Port NormalMap-Online shader to c++ to generate normal map from height map.
I think the reason you cannot find much material on this topic is because nobody bothers with procedural generated asteroids. If you create at least 5 different asteroid models in Blender (or another 3D modelling software), and bring them in Urho and then position them randomly with random rotations and scale, you can get a pretty convincing looking asteroid field (with the added benefit of being able to use instancing to render them fast).
Sorry this doesn’t answer your question, but it might be helpful in the long run .
There is also much voice of pre-made model in those discussion.
Just want to give it a try since I can’t guarantee I can do better with my crap art skill.
One of my teachers, in his Masters Thesis, developed a procedural cave system (essentially, a network of connected subspaces, and tunnels), which is very similar to your work. The time it takes to generate a bunch of procedural shapes, and connect them, is very low and can be done offline (that is to say, we generate and save our shapes, and load them back in at runtime). His system could add and remove detail based on the camera view using geometry shaders to mess with the tesselation.
Another guy used this for generating entire planets, again using a DLOD approach, at runtime, not in advance (his method is entirely based on the fact that RNG’s are predictable for a given random seed).
Don’t give up on procedural geometry - but do recognize the fact that you are making your life more difficult to get your game up and running. Procedural geometry can wait until the game mechanics work well for a small set of test objects.
Yeah, time to go back to game logic.
So far I have no idea howto improve it…
Or, it doesn’t need to improve much as unnoticeable background object.
ditto on @QBkGames
just take some ready-made rock stuff out there
but if you really want to enjoy some proc gen, you may try with some… how was that… voronoi rock generation?
Ah, there’s this old site about auto-gen:
The video reminds me how powerful blender is.
Seems blender is the right way to go, thanks!
Something funny that maybe in order…
switch the monkey for a big rock shape, cut with random node, and crash it down. Then collect pieces…