I also placed some dynamic grass blades on the top surfaces of the rock. Here is a screenshot of a 128x128x128 voxel rock/mountain that uses triplanar texturing with different textures + procedural texture selection to give it a variety of rock/grass features. for each voxel, which is recomputed (using openmp) when the light sources change. This gives multiple bounce indirect lighting from the sun, moon, etc. I also run path tracing on the triangle mesh like in my previous lighting post with the Sponza scene screenshots. They need real ambient, and fortunately it's easy to compute ambient occlusion by ray marching through the 3D volume and tracking the visibility of each voxel (again using openmp). One more important thing is lighting: these voxel scenes just don't look right with simple direct lighting. This is all pretty standard stuff so I won't go into all of those details. Of course I skipped a few steps here, including handling of the mesh boundary, clipping the bottom of the volume with the heightmap floor, removal of disconnected "floaters", etc. Individual blocks can be modified, which is fast enough for realtime voxel editing.View frustum culling can be used to drop invisible blocks when rendering.8 threads (4 core + hyperthreading) gives me about a 5.5x speedup. Each block can be generated independently, so I can use openmp to run separate threads on each core.16x16 tiles seems to work well, and this division gives some nice benefits: I divide the scene up into XY tiles (I use Z=up). This seems to be the most efficient way to render large triangle datasets using OpenGL, and is more compact than storing individual triangles. So I can use MC to get triangles, then connect them together and compute the shared vertices so I can render with indexed triangles. There are some ambiguous cases in MC, but they tend to not show up often in the scenes I create and I prefer simplicity and efficiency over perfect quality, at least for now. I chose to use the Marching Cubes algorithm because it's fairly simple (compared to the alternatives) and the crazy lookup tables needed for MC can be found online. In the end, it only takes 200ms to generate 16M noise values (64 slices) for a 512x512圆4 scene, which comes to 64MB of data.Ī big array of noise values is great, but it needs to be rendered.
If anyone manages to invent a 3D frame buffer then let me know - or I suppose I could give in and use Nvidia-specific compute shaders or CUDA. This inefficiency is partly because I have to generate the volume in 2D slices, to match a 2D frame buffer. Naturally, it's faster to generate noise values on the GPU, though reading back all that floating-point data takes around half the time of the CPU noise generation. They all seem to produce the same sort of lumpy terrain in fact, the only real difference is computation time. The current set of noise functions supported are Perlin noise, Simplex noise, and sum-of-products-of-sines noise (of my own invention). I'm generating a 3D array of noise values using different noise functions, computed either on the CPU or on the GPU using a custom fragment shader.
This time I'll present 3DWorld's voxel terrain system.
0 kommentar(er)
