ROAM terrain rendering, help us make spring much faster!

[tizbac]

maybe it's good idea implementing decent lighting that supports multiple lights so also units can emit light and we can make things like night map with street lights

[smoth]

MC BUMP

[Beherith]

My compy still cant run spring, though I think i have a good idea of where im going wrong in the shadow code. If anyone is interested, you can try removing the setupbigtexsquare call from the landscape.render when your rendering a shadows.

I wont be able to run spring till mid dec.

[smoth]

I don't have any of the libraries etc that are required to compile spring. can you post a compiles windows exe?

[Kloot]

patch to fix the shadows bug (and a few others)

This should apply cleanly against 5ebc793d63660f0fef8efc8f5ffefb8078e81eea of the roam branch.

[Beherith]

I LOVE YOU KLOOT!

Anyhow, Im getting back to a real computer on monday.

[Beherith]

Code: Select all

-	if(framchanged){
+	// if shadows are enabled:
+	//    we need to reset and tesselate in between the
+	//    regular and the shadow-pass even if the camera
+	//    has not moved, so no performance gain in only
+	//    retesselating after large movements
+	if (haveShadows) {
 		landscape.Reset();

Why do we need to retessellate at each frame when shadows are on? This makes us lose almost all of the performance improvement we get from ROAM.

Im currently working under the assumption that only visible terrain patches will cast shadows, while visible is a bit more relaxed then just on screen, its a bit bigger radius.

Also, currently, the shadows flickering on LOD change is caused by a very simple bug on my part. I didnt know the shadows where rendered before the terrain in each frame, and I did the movement checks and retessellation on the terrain render phase, after having drawn the shadows. This is easily fixed on my part.

[Kloot]

Why do we need to retessellate at each frame when shadows are on?

Because the terrain needs to be rendered from the perspective of the lightsource to generate them, which requires (in most cases) a completely different tesselation.

Note that there is one other problem exposed by the ROAM code (though not connected to it; this issue also exists in the old SMF renderer but is normally hidden from view there due to the much denser meshes) wrt. how shadows are projected by Spring. In the old tesselator, when the view radius is decreased to < 10, shadows will start shifting as the viewpoint is moved (because the projection is non-linear). But with ROAM almost all areas are of low vertex density, so the shifting effect is noticeable constantly.

[Beherith]

I really appreciate the amount of work you put into this, and am very grateful. Almost at the end of the patch.

But wouldnt rendering a different mesh on shadowpass than on terrain pass cause shadow artifacts? Because it did for me. Also, I know the shadows are from a different angle, but Im highly partial to the shadows coming from identical sources as the rendered terrain. It just looks right imo.

Since the LOD culling is screen error based, and the shadows obviously have less LOD anyway, since they are only majorly affected by large terrain differences by principle. I would be keen on skipping the retessellation of shadows for performance reasons, or just of keeping a second Landscape for the shadow map, maybe at lower resolution, and optimized tesselation for the static camera angle, since retessellation is by far the most expensive operation in the system.


Kloot, added you as a collaborator on the github repo, and once again, thanks :)

[Argh]

Yay! That solves a lot huge problems in one swoop.

[Beherith]

I applied the patch, yet unit shadows are just as borked as they were.
I extensively looked through the patch, yet didnt find anything that seemed to be the specific fix for shadows. Would you care to elaborate on this?

[Argh]

I just tested with the latest buildbot build of Spring.

Seems to be fixed for me, on SMF / SM3.

Unit shadows are still borked, though. Still can't do floating cities

[smoth]

Godamn spring is going to be amazing!

[Beherith]

Sm3 does not have roam yet...

[Argh]

Oh, and Features aren't casting shadows, at least over here. Units yes, Features no.

[Kloot]

My patch was only intended to fix terrain self-shadows, not the ones cast by units. And as I said, unit shadows are not being broken by ROAM, the existing SMF tesselator shows the same issue for single-digit view radii. The bottom line is that any shadow projected onto a triangle much larger than itself (which is a common situation with roam'ed meshes) will generally be distorted, and shift and warp as the viewpoint is moved. If that's not what you mean by "borked", please clarify.

[Beherith]

Shadows are currently drawn at the same LOD as the terrain mesh. Exact same mesh is sent to renderer on pushstrips.
The cause for the flickering of shadows on cam movement was different. It was caused by the following action in a frame:
1. Push mesh to shadow renderer.
2. Check if visibility of patches changed, if yes, retessellate
3. Send new mesh to terrain renderer.

Flickering on movement was caused by the different meshes being pushed on a single frame.
I have fixed this (not in git yet) by merely checking if shadows are enabled, and if they are, then check for visibiliy change and retesselate in shadow phase.

The error currently looks like this:


Edit: damn, i pressed edit and not comment :0 sorry about that.

Edit 2:
So basically the triangles are too large, so roam is too good for the shadow renderer?

[Argh]

The bottom line is that any shadow projected onto a triangle much larger than itself (which is a common situation with roam'ed meshes) will generally be distorted, and shift and warp as the viewpoint is moved. If that's not what you mean by "borked", please clarify.

That sounds like a succinct description of the problem's cause to me, yeah.

That said, there must be a way to get this done. We see non-warping shadows on giant triangles all the time in FPS games, and they aren't warping all over the place.

[Beherith]

Awesome
Tested on ccr with old renderer at viewradius 2.

So basically I can dumb down roam, but even then shadows will suck. Yay.

[Noruas]

I say leave it and pray someone gets motivated to rewrite or fix shadows. Now just a question? Since You can now do Roam terrain rendering, why not Roam texture rendering on the map, the more you zoom out, the less quality on the map is processed, for real low end users. +

I remember older springs used to cut the map into a square that followed the camera, rest of the map disappeared, and now the whole map is rendered regardless of LOD settings, was this lost or is it still possible to enable hiding the map? It worked very well with overhead camera to hide non-rendered map parts.