[GSoC 2012] Volume Rendering with LOD aimed at terrain

[sleo]

A lot of games can be made using your terrain
But for games paging is important. In heightfield based Ogre Terrain Component there is no good implementation for pages loading and I really don't understand why not to combine LOD, paging and transitition in single entity. Waiting for completion of GSoC 2013 is not an option!

[youtube]3WwXr3WCi_c[/youtube]

[PhilipLB]

Hi,
nice video. I have some questions:
- How have you implemented the physics? Why is the Ogre walking exactly on the terrain? Because casting rays is not within this GSoCs scope (but in my mind!)
- There are some dark thingies in the terrain. Are that actually cracks or just very dark lit geometry? If later, does the current trunk version of the material solves this? I had a similar bug here and changing this line in the shader

Code: Select all

oBlendWeights = normal;

to this

Code: Select all

oBlendWeights = abs(normal);

fixed it.

Paging and Transition is also not in the scope of this GSoC, but also in my mind. And development won't stop with the end of this GSoC, I'll continue developing.

[sleo]

I think yes I forgot to copy media folder from last trunk, only sources. I will fix that in evening at home. I think organising project from Sample to Component+Sample would be more easier for me to update or maybe there is a way to get slice of GIT repository?

Character is walking on Chunk LOD Level = 5, raycasting (or to be more precisely swept sphere tests) is done by Bullet Physics from Ghost Object to TriangleMesh. Yes, it was not so oblivous to me how to get level = 5 chunk from your mesh builder and chunk manager

There is good explation about difference between raycasting, sweep test and contact test on Panda3D Guide: http://www.panda3d.org/manual/index.php/Bullet_Queries and it is even better than Bullets Wiki.

Very nice to hear about project future after GSoC. There is also beatiful ideas we can orient to is on procworld.blogspot.com. Those all voxel technologies: signed distance fields (SDF), raymarching SDF, radiosity in SDF, SDF procedural generation are near future. Maybe component should be more abstract than just terrain.

[PhilipLB]

Hi,
good feedback, thx.

For getting the Chunks of a specific LOD level: Today, I'll commit a small getter:
vector<Chunk*> Chunk::getChunksOfLevel(size_t level);
That should do it?

Managing and extending the material is the current big task. Afterwards, there will be loading something from a config file and some multitasking in the loading and actually then, moving the stuff to a plugin is on the list.

// Edit: Just pushed a new version with a Helper function like this.

// Edit 2: This one could be very handy! http://procworld.blogspot.de/2011/04/op ... ation.html

[PhilipLB]

Currently, I'm extending the shader to support a lot of stuff you could need (3 lights, fog, normal mapping, triplanar texturing, ...).
I actually already ran into some instruction count limits of ps_2_0 and switched to vs_2_x and ps_2_x. Is it ok to require them nowadays? Or are there situations, where the 2_0 are needed?
And how can I find out, how many instructions where generated by the CG compiler?

[CABAListic]

Depends mostly on what generation of graphics card you want to target. I don't know how stressful your project is on the graphics card in general - if it requires a decently modern card, anyway, then you can probably even assume SM 3 support.

Either way, as long as the material and shader can be replaced by a custom user solution, I wouldn't worry too much. If someone really needs a simpler material implementation for older hardware, he can still do it. Ogre's Terrain component also uses (by default) shader levels that are not supported on older hardware, so ...

[duststorm]

Are you implementing your shaders in hlsl/glsl or are you using CG?

[PhilipLB]

@CABAListic
Ok, sounds good. Thx.
Still interested in how to find out the instruction count for later microoptimizations.

@duststorm
I'm using CG.

[DragonM]

Currently, I'm extending the shader to support a lot of stuff you could need (3 lights, fog, normal mapping, triplanar texturing, ...).
I actually already ran into some instruction count limits of ps_2_0 and switched to vs_2_x and ps_2_x. Is it ok to require them nowadays? Or are there situations, where the 2_0 are needed?
And how can I find out, how many instructions where generated by the CG compiler?

Have you considered writing your material management modules to work with Ogre's RTSS? It sounds like they're very similar.

DM

[PhilipLB]

Hi,

I considered it but it will be "just" one material (with different combinations). So I think, it's not worth it, to dependend on the RTTS system. Even if it would be an Ogre internal dependency. Some projects might not want to include it. And I'd have to extend it here and there I guess.

[duststorm]

Have you considered writing your material management modules to work with Ogre's RTSS? It sounds like they're very similar.

Who knows, maybe you can even contribute reusable tri-planar texturing to RTSS.
I'm not sure how compatible RTSS would be with your terrain component, though. After all, Ogre::Terrain uses a different material generator too, it might not be that easy to do after all.

I considered it but it will be "just" one material (with different combinations). So I think, it's not worth it, to dependend on the RTTS system. Even if it would be an Ogre internal dependency. Some projects might not want to include it.

Maybe not everyone shares this opinion, but I personally prefer having a reuseable component for generating all my shader code than being required to manually mess with different shader implementations everywhere. Especially with openGL3+ and D3D11 on the way. If we are obliged to create our shaders manually everywhere we will completely use the material management that ogre offers.

[PhilipLB]

Contribute triplanar texturing to the RTTS is actually an option beside this project. Just for fun.

[duststorm]

Contribute triplanar texturing to the RTTS is actually an option beside this project. Just for fun.

I agree that it's out-of-scope and should probably only be considered after the GSoC. I don't think it's that trivial either, but I haven't looked at the RTSS in detail yet (in fact I should really make a point of doing this).

[PhilipLB]

Bringing the shader to live.

• Supporting up to 3 lights in the shader.
• Supporting light attenuation in the shader.
• Supporting spotlights in the shader.
• Supporting fog in the shader.
• Supporting normal mapping in the shader.
• Added some ideas for later to the wiki.
• Added a possibility to get all chunks of a specific LOD level.
• Added a callback to get the actual meshdata of a specific LOD level while loading.

[duststorm]

Added a callback to get the actual meshdata of a specific LOD level while loading.

That would be great for generating navmeshes from!

Great work, by the way!

[Xavyiy]

Really great work!
If this project continues like until now, it may become the official terrain solution in the Paradise Engine in a future (specially if you continue developing/supporting it after the GSOC).

Btw, care about materials shader model requeriments: try to make it as flexible as possible(fully customizable if possible), take account that nowadays mobile platforms are a very sweet market, so being able to use light materials is a must. But also, on pc & consoles a high quality materials are desired.

In my case, if I finally use it in the Paradise Engine, I'll have to rewrite all materials in order to use materials compatible with our custom parameters/material set, so it'll be very cool if the terrain system is already compatible with custom material generators.

Xavier

[PhilipLB]

Hi,

Nice to hear.

I plan to make most of the shaders configurable. Like materialGenerator.setFog(true/false); or materialGenerator.setAmountOfSupportedLights(2); etc.. This is "just" a bit of string concartanation when I'm done with the full blown version of the shader.
Custom materials are already supported via chunk.setChunkMaterial("name"); Please tell me if this is not enough or you need something different.

[Xavyiy]

Custom materials are already supported via chunk.setChunkMaterial("name"); Please tell me if this is not enough or you need something different

Yeah, that's perect

Dunno if you've already done it, but it would be interesting if you can specify what vertex elements are binded (uv coords, normals, binormals, tangents, ...). That would save some memory on low-end HW or when you're not using materials which require normals, tangents, etc.

[PhilipLB]

Currently, the only binded elements are Position and Normal. The normal could actually be optional, but I can't think of a scenario, where you don't want it?

[duststorm]

Maybe not having uv's on verts might even be the most limiting factor on older hardware. This is just a guess but can it not be that the triplanar mapping is actually the most heavy part in the shader? And since there are no UVs, you practically need it to do texturing.

Unless you perform some other simple texture projection, such as simple cube mapping, maybe...

[PhilipLB]

Hm, I think the triplanar mapping is actually not that heavy?
Vertexshader-Part of it:

Code: Select all

	oBlendWeights = abs(normal);
	oBlendWeights = (oBlendWeights - 0.2) * 7;
	oBlendWeights = max(oBlendWeights, 0);
	oBlendWeights /= (oBlendWeights.x + oBlendWeights.y + oBlendWeights.z ).xxx;

Fragmentshader-Part of it:

Code: Select all

	float2 coord1 = position.yz * texScale;
	float2 coord2 = position.zx * texScale;
	float2 coord3 = position.xy * texScale;
	float4 col1 = tex2D(texFromX, coord1);
	float4 col2 = tex2D(texFromY, coord2);
	float4 col3 = tex2D(texFromZ, coord3);
	float4 textColour = float4(expand(col1.xyz * blendWeights.xxx +
		col2.xyz * blendWeights.yyy +
		col3.xyz * blendWeights.zzz), 1);

+ this if normal mapping is enabled:

Code: Select all

	float3 bumpFetch1 = expand(tex2D(texFromXNormal, coord1).rgb);
	float3 bumpFetch2 = expand(tex2D(texFromYNormal, coord2).rgb);
	float3 bumpFetch3 = expand(tex2D(texFromZNormal, coord3).rgb);
	float3 TSnormal = bumpFetch1.xyz * blendWeights.xxx +  
		bumpFetch2.xyz * blendWeights.yyy +  
		bumpFetch3.xyz * blendWeights.zzz;

Some simpler texture projection could also be considered. Like a single planar projection (might look ok if your scene fits to it). But I actually don't know how to really project the texture on it. Cube mapping might be worth a try. I know about this method, but it sounds very complicated to implement: http://graphics.cs.williams.edu/papers/ ... tionI3D08/

[duststorm]

I guess it's just my limited knowledge of these things.
Anyway, I don't think you should focus on alternative techniques. Focus on the main matter.
But it's good to consider alternatives and possible customization points in the code.

[Assaf Raman]

... Focus on the main matter...

Yes. Do that.

[Mattan Furst]

Hi PhillipLB

Just submitted your student evaluation. I won't keep you in suspense. You passed

[PhilipLB]

That's great, cheers!