[chief1983]

It's amazing how quickly Apple and other development communities are nixing Snow Leopard support, and it looks like without those extensions and SDK support, we're going to have a hard time supporting it much longer as well.

[jg18]

It's amazing how quickly Apple and other development communities are nixing Snow Leopard support, and it looks like without those extensions and SDK support, we're going to have a hard time supporting it much longer as well.

And snow leopards are already endangered as it is...

* jg18 is typing this on a MacBook Pro running SL.

Hard to believe SCP has been making Tiger and Leopard builds for so long.

The deferred lighting and shadows does not require opengl 3 it runs on 2 I coded it that way especially because osx doesnt work. There might be 1 or 2 required extensions tho that might cause problems if they are missing.

It wouldn't surprise me at all if those extensions were missing from at least one version of OS X. Is there any reasonable way to find out what they were (i.e., without doing a ton of work)?

Also, if Snow Leopard support is (slowly) on its way out, and since all later versions of OS X support OpenGL 3.2 Core profile, maybe the main rendering pipeline, along with deferred lighting and shadows, should (eventually) become OpenGL 3 anyway? Not that I really know that much about OpenGL...

[Nemesis6]

It would be lovely if someone could compile a 3.6.18 build with both shadows and deferred lighting. There is the 3.6.17 BP build, but it has quite a few quirks.

[The E]

Might I interest you in some updated builds, sir?

[rscaper1070]

How high does the -shadow_quality setting go? I looked through the thread but only the lower settings are discussed.

Edit: Nevermind, found it. The answer is 2.

[torc]

Just a small suggestion: i found that having shadows in small ships like fighters is almost useless...
Having the possibility to choose what object you wanna affect would be great since it should have less performance impact and allows people to find shadows on ships where are really noticeable like capships and stations (and player ship obviously).

Just my 2 cents

[MatthTheGeek]

Just a small suggestion: i found that having shadows in small ships like fighters is almost useless...

Lies. I actually found those were the most noticeable, especially when you're flying in formation in a wing.

One thing that would be good is to disable shadow on ships/objects that are very far away. For example I noticed a massive slowdown in missions with needlessly large asteroid fields.

[Cobra]

Obviously you need a better sound card.

[The E]

The distances at which shadows are rendered are currently fixed. FSO uses a cascading shadow map render with three shadow maps, with distances of 400, 3000 and 20000 as cutoff points (As in, everything up to 400 units away from the camera gets rendered into the first map, everything up to 3000 in the second and so on).

What we do not want to do is introduce lots of special cases here. I think what would be worthwhile is to introduce commandline switches or mission spec fields to control the shadow cascades.

And yes, shadows on the player ship or cast by the player ship are the most noticeable ones, so they're not gonna go away.

[Kobrar44]

One thing that would be good is to disable shadow on ships/objects that are very far away. For example I noticed a massive slowdown in missions with needlessly large asteroid fields.

I don't know much about performance, but asteroids lod 2/3 have like 80 faces or less. With 256 asteroid cap, that's about 20k or less faces total and each asteroid takes only a handful pixels on the shadowmap 3. Should they impact the performance this much?

[MatthTheGeek]

I don't think it's about how much pixel they take on the map, it's about calculating those pixels in the first place.

[Kolgena]

Faces/vertices don't matter unless the engine uses shadow volumes (which I don't think it does). The number of screen pixels a single shadow takes should have no bearing on performance for either shadow maps or shadow volumes.

I'm actually sort of curious about the method of how shadows in FSO work, because my understanding of how shadow mapping is often implemented is that performance is independent of scene complexity. It should only depend on shadow texture size.

[Luis Dias]

so ... ahh.... what's the current gameplan regarding placing this into the main trunk? 

Is this going into 3.7.2 or are you gonna be wild crazy and call it 3.8? 

It almost deserves it.

[The E]

Regarding the implementation details: FSO uses a technique called cascading shadow maps. This uses several, in our case three, shadow maps to make sure that texel density is highest the closer to the camera an object appears.

While shadow mapping is orders of magnitude faster than regular rendering, it's still a process with a runtime that increases with object count.

It should also be noted that the FSO render pipeline as currently implemented isn't very efficient when it comes to batching render calls, especially in a situation like this one, meaning that there's a few tricks here that we're missing right now.

[Trivial Psychic]

Is this making its way into Trunk with 3.7.0 Final out now?

[Bryan See]

Not sure. I bet it makes its way beyond 3.7.0