I am again trying to get some working shadowmapping and am further than I ever was before.
I have working Parallel Split Shadow Maps which can easily progress to a combination with LispSM, if I get the math behind it. The shadows are soft using Variance Shadow Mapping.
So far I am really happy with my results but my fps is realy very low (35fps in a simple level) with only three splits, which should be enough for a high quality. I guess this has to do with ineffective view frustum culling caused by my own lightviewmatrices.

Is there any "simple" way for me to improve this? If not, could you may mention your ideas on what to do? Because like it currently is, I don´t see a way usable outdoor shadowmapping.

Thank you!

(3 splits, 1024*768 which is not what I want, but I forgot to make the zbuffer fit and thus it currently is like that)

Are you using view_to_light or your own light culling algorithm? It's no problem to implement some lite-C frustum culling function. Just let me know what precisely you need.

We're supporting such projects. We also plan a PSSM shader, but I can also imagine alternatively purchasing such a shader from a user contribution when it works well.

I just place the three light views at sun_pos and scale the position so that the views aren´t that far away from the level. The views are all facing camera.
What I currently do in a dll but which should be easy to do with Lite-C as well, is that I calculate the camera viewmatrix and its projectionmatrix with my own near and far plane. I do this for each light with different near and far planes.
THe next step is that from those resulting view projection matrices I calculate the viewfrustums worldpositions and build the lights orthogonal projection matrix that it fits that frustum. That new view projection matrix for each lightview is then used to render the shadowmap.
I hope my explanation is understandable, I always have the feeling that I get very confusing when trying to describe something, especially in english :P

However, what I think would help a lot is a function which gets the lights viewprojectionmatrix and the view and makes sure that the culling for the given view is right for the view frustum resulting from the matrix.
If you consider it too unflexible or what ever to just set the matrix, everything else I can calculate from it on my own like the frustums clip planes or corners, should do it as well. If you have any other idea for this, it should of course do it too.

Thanks again.

So, what you need is something like

view_setup(view,matrix);

which calculates the view arc and the clip_far plane from the matrix - is that right?

I think basicly yes, but aren´t those the two things I could already calculate and set myself?
And isn´t it going to be a problem that I am using an orthogonal, off center projection matrix? I had the idea to place the lights all at the cameraposition with their different clip_near and clip_far values and then to calculate their view projection matrices as if they where at the sun position. This should basicly work but it should also cause some missing shadows ob objects which aren´t visible but should throw a shadow.
I btw cleaned up my code a bit and had to switch to the latest beta because of a bug in A7.10 which seems to be fixed in the beta. Instead of 35fps I´ve got 100fps now . This is already very nice but I am sure that good clipping could speed things up even more because currently everything is rendered even though only two object are visible with my lightmatrix.

I tried to place the lights at the ccamera position, it basicly works but as I expected a lot of objects which should throw shadows are clipped away and another problem is, that I can´t set view.depth to a value bigger than clip_far which makes everything black if I don´t have a wall directly in front of the camera.
But already due to the missing shadows this isn´t really a good solution.

Nice would also be a flag for views like "NOCAST" to prevent objects from beeing rendered in the shadow view which are not meant to recieve a shadow.

Yes. For an orthogonal matrix you'll need box clipping, not frustum clipping. I'll implement some view flags for making this easier.