Terra support for GI, VCT

[cryham]

System Information

• Ogre Version: 3.0.0 or 4.0
• Operating System / Platform: all
• RenderSystem: all

Detailled description

So I'm very curious if Terra is not suppored for GI methods? The code in Tests/Voxelizer has a list of Items. If I get it right all from scene need to be there. But Terra is not an Item, it is a ManualObject. I see later item->getMesh(); is called. Does it mean I can't use GI for Terra? Is that for all GI methods in OgreNext, or only VCT? If so do I need to like create a mesh myself (possibly with less points and quality) to mock Terra Heightmap just to get GI? And would it even work? Would Terra be lit from GI if that mock was destroyed?

[cryham]

There is also this:

                    LogManager::getSingleton().logMessage(
                        "WARNING: Mesh '" + mesh->getName() +
                            "' contains geometry without index buffers. This is currently not "
                            "implemented and cannot be added to VctVoxelizer. GI may not look as "
                            "expected",
                        LML_CRITICAL );

[darksylinc]

Hi,

Sadly as you found out none of the GI methods we are offering are compatible with Terra.

The clients financing the GI methods were more interested in indoor GI rather than outdoors (also outdoor is easier to fake because the sun and sky are the most abundant sources of illumination so a couple of well placed cubemaps or even a dynamically updating ambient sphere could be enough to fool everyone).

Terra does not have geometry, so the solutions would be to either add special paths for each GI or to generate mock geometry as you say; then use it temporarily so the GI can use it to build its data.

For VCT, a compute pass that fills the voxels with heightmap data may be simpler than it sounds.

Populating the voxel data with terrain data would boil down to this:

float3 pos = float3( gl_GlobalInvocationID.x, 0.0f, gl_GlobalInvocationID.y ) * terraScale + terraOrigin;
pos.y = OGRE_Sample2D( terrainHeightmap, float2( gl_GlobalInvocationID.xy ) * invHeightmapResolution );
float3 voxelPos = pos * terraToVoxelScale - voxelOrigin;
uint3 uVoxelPos = uint3( voxelPos );
/// Umm... colour? fetch it
float4 color = OGRE_Sample2D( terrainDiffuse, float2( gl_GlobalInvocationID.xy ) * invHeightmapResolution );
color.a = 1.0f; // Alpha stores how much light we allow to go through. None.
OGRE_imageWrite3D( voxelAccumVal, uVoxelPos, color );

Where gl_GlobalInvocationID is dispatched to be in range xy = terra_width, terra_height.

I am not handling the the normal data in this example, but it should be done the same as Terrra does it in the pixel shader (sample normal from the heightmap and write it to voxelNormal).

For the case of InstantRadiosity, either mock geometry is used, or a custom version of raycastLightRayVsMesh is used, so that it generates the raycasts on the fly. Bullet Physics has a working raycast implementation for heightmap-based terrains.

[cryham]

Okay, thank you for info. I doubt I could do it, and I'll leave this for last. I got finally SSAO, and it does matter a lot more and looks great in dense jungles. VCT GI looked cool on metal buildings in SR but we don't have that great materials to use it better anyway. I didn't see any detail in reflections from it either, I'm guessing would need some more code. Yeah, I feared there would be need for terrain diffuse etc. Which comes from blendmap, would need a texture. Either for mesh mock or for compute pass. I got some iterative Terra ray cast done too: https://github.com/stuntrally/stuntrally3/blob/main/src/road/Road_Edit.cpp#L723 and normal got from 4 heights: https://github.com/stuntrally/stuntrally3/blob/main/src/road/SplineBase.cpp#L14 likely very slow though.