parallax not working when using sidemapping on terrain textures

#1 Hey Scott.

It is a known limitation.

So how side projection works is it looks at the normal of the surface and blends between a texture projected in the X axis and a texture projected in the Y axis.

So to do parallax on that i need to do parallax twice... once for the X and once for the Y projection. Then blend that result.

Worse it has to happen once during the generation of screenspace depth and normals and again during the forward rendering pass.

And it needs to be able to do this for multiple terrain materials.

So... considering all that... i made the choice to disable parallax on side projection for 1.0.

I'm totally open to revisiting this decision, but i do worry about people expecting miracles out of the terrain system.

Looking at your screenshot (great parallax map there by the way) in that particlular case i really don't think side projection would win you very much... in fact i think it would be a waste of fillrate. If found in my tests that side projection works best on *very* steep terrain... 60 degrees or more.

Also for 1.1 we've softened the terrain normals for rendering which really improved the lighting and side projection on terrain.

#2 don't get me wrong i just wanted to know one way or another, that's actually your deathball or whatever example map. i haven't had much playtime on my project so most of that was just spread on the closest semi cliff to my little town.

i'm yet to fetch my maps from beta 5.

knowing the limitations is the most important step to getting the most from what you have. i'll use meshes on the cliffs. more potential detail and accurately cast shadows where relavant. i'm just feeling my way through the changes.

#3 If you deconstruct Crysis a bit... most of the terrain detail comes from smart usage of static meshes to decorate up the cliffs and overhangs.

I highly recommend that technique.

#4 if and when i need cliffs i would have been. i would have liked the ability to vertex blend textures/materials for cliffs/rocks but that doesn't seem likely. someone implemented a shader for that in leadwerks and it made for some incredible results.

like these meshes

it was pretty advanced modelling required to make use of it and i think i ended up being the only artist on those forums to even use it. but each of those meshes has a maximum texture resolution of 512x512. so very cheap to draw on screen and very highly detailled. excellent for rocks and trees.

#5

Quote:i would have liked the ability to vertex blend textures/materials for cliffs/rocks but that doesn't seem likely.

Hum... its interesting.

How would you see this working... some stock material feature or more of a custom shader for special cases?

#6 well i can describe the inner workings on it. i modified the example made for LE

essentially you paint the vertex colours on a mesh. le materials called the shaders individually so i'm not sure how your dx driven engine would handle all that

really you had to assign every vertex as red, then it was varied from that, the percenetage of red at a vertex was the percentage of texture 1 + normal 1, likewise fro green and blue. so each mesh was the result of adding the three textures based on the opacity set by the colour.

if you need more then 3 textures, you would ahve to assign multiple materials then use one of your layers as a merging texture. eg the mud texture in that example was used to blend the rocks and the trunks with the woodchips. by having variations of the same textures you could blend out any patterns in the tiling.

i can post the glsl if it's of any help, at least the glsl for the frag shader. it's probably easier to understand than my gibberish.

and yeah you would only apply it on objects that needed it. the technique allows for smaller textures but you use far more of them. the mesh with the three rocks and the treestump, would have had 16 textures. all of them very small, in total adding upto an equivalent 1x 2048 in dds dxt5.

// Use combine shader.
		#ifdef LW_COMBINE

			// --- First layer ---
			diffuse = texture2D(LW_COMBINE_0, texcoord)*fragcolor.x;
			
			// --- Second layer ---
			diffuse += texture2D(LW_COMBINE_1, texcoord)*fragcolor.y;

			// --- Third layer ---
			#ifdef LW_COMBINE_2
			diffuse += texture2D(LW_COMBINE_2, texcoord)*fragcolor.z;
			#endif
			
			diffuse *= fOcclusionShadow;
		#else
		// Use common diffuse.
			diffuse *= texture2D(LW_DIFFUSE,texcoord)*fOcclusionShadow;
		#endif

we had another one to blend all the normalmaps as well, it was all very complex which is why of the few artists in the le community it seemed i was the only one interested in using it.

#7 That really helps the hard edge caused by objects on terrain, without having to hide it with ground cover. What's the cost of performing something like that? Seems like that would be a lot of texture lookups in the shader.

#8 no idea le wasn't particularly art focussed so costs of rendering were just lumped into one big ball of framecount most of which was eaten by shadows and lighting. the cascaded shadow map quadrupled poly count on the spot and every pointlight added another 6 of each triangle it touched. so making large ellaborate scenes always got difficult.

i guess it's usefullnes boils down to 16 textures@512x512 vs 1X2048x2048. the first gives you 8 textures + normalmaps which can be blended and tiled to produce the same effect as 1 uvmapped 2048x2048.

from the point of view of saving memory on the shipped product the combined 8 could make hundreds of unique objects. whereas the mapped 1 makes exactly one object unless you get creative. it also has higher in use memory requirements for the additional normalmap.

i know nothing about how shaders would find these textures to apply them for lookups and memory handling in that regard so i couldn't answer that.


edit: whenever i described the feature to other forum members i would refer to it as terrain texturing your meshes.

if i had to describe how i would implement it into torque i would follow that description

ie. the material is assigned to the mesh using the standard setup we use now.

an additional option for texture combine could be added, and when checked allowed selection of 4 combine textures. when first enabled the vertex colours would be displayed for debugging purposes. no point proceeding if the whole mesh is black, red, blue, green or white.

then assign a material very similar to the terrain materials. to make these combine with terrain as flawlessly as possible the diffuse value should probably be taken from the closest terrain vertice.

this technique should NOT allow parallax. the code to get that working would be insane and performance would nose dive. if users want bigger bumps in meshes they should model them anyway. vertices are far cheaper than calculating eye vectors.