[karx11erx]

Hi,

I have been implementing per pixel lighting D2X-XL, and I am looking into deferred lighting + shadow maps right now. Imo FS would lend itself ideally for that lighting method, as it's basically one huge, open "room" with a bunch of objects in it.

If you don't know what deferred lighting is: You first render the scene fully bright and collect all light sources that have an influence on the visible scene. In the lighting pass, you illuminate only those pixels that have actually been rendered. In order to do that, you need to render to textures and write additional information to multiple render targets (e.g. material properties) (-> "fat render buffer"). You can either derive pixel world coordinates from pixel coordinates and depth value, or store them in an extra floating point render target for more speed (requires more memory - no prob for modern gfx cards). This is all no rocket science and I have already implemented RTT and MRT in OpenGL. The advantage of this method is that you can process a tremendous number of lights very fast.

If shadow casting would be restricted to a single light source (sun) we'd only need a single shadow map and could do nice diffuse shadows.

I am also having a lot of experience in depth (Z) buffer usage, e.g. for soft blending of light effects.

In case you haven't heard of D2X-XL or me, take a look at http://www.descent2.de and http://www.descent2.de/worklog.html.

[The E]

Well.....Not to make too fine a point of it, but that's more a suggestion for the SCP board, since it involves a few changes to the render architecture.

[General Battuta]

That would be super cool. Unfortunately FreeSpace (and its mods) often work with missions with multiple suns, but maybe you could just take one as the primary if it's necessary to have only one primary light source?

[The E]

Well, there are several possible optimizations here. In addition, using only one or two lights for shadow calculations is usually enough to give the sense of realism you want.

[General Battuta]

Agreed.

[sigtau]

Perhaps the first sun in the list of suns in the mission file will be taken as the primary light source by the engine (so as to not break any compatibility)?

[The E]

The engine is already sorting all available lights in the scene by relative intensity for each model, so taking the first sun from the mission file is not the right way to do this, I think.

[sigtau]

I dunno, in some of the last Capellan missions in the retail FS2 campaign, some of the more intense lights are suns that happen to be very small (about the size of a star on the skybox texture), so it would look strange to have just one very small sun controlling all of the light while the larger suns don't do anything.  Poor mission design, but eh.

[The E]

Yes, but that's a mission design question, not something that should be debated wrt the code implementation of lighting. And as I said, the code doesn't care where the light comes from, it just cares about how strong it is in relation to the other lights present in the scene.

To be exact, IIRC the engine tracks up to 256 lights at any given time, the 8 strongest of which getting rendered to screen.

[Sushi]

Yes, but that's a mission design question, not something that should be debated wrt the code implementation of lighting. And as I said, the code doesn't care where the light comes from, it just cares about how strong it is in relation to the other lights present in the scene.

To be exact, IIRC the engine tracks up to 256 lights at any given time, the 8 strongest of which getting rendered to screen.

Which often looks awful, especially when the suns get pre-empted by distant explosions and laser shots. You get ships that just flicker in and out of brightness.

Maybe we should also have one sun that we can guarantee is always rendered?

[karx11erx]

Yes, but that's a mission design question, not something that should be debated wrt the code implementation of lighting. And as I said, the code doesn't care where the light comes from, it just cares about how strong it is in relation to the other lights present in the scene.

To be exact, IIRC the engine tracks up to 256 lights at any given time, the 8 strongest of which getting rendered to screen.

Which often looks awful, especially when the suns get pre-empted by distant explosions and laser shots. You get ships that just flicker in and out of brightness.

Maybe we should also have one sun that we can guarantee is always rendered?

D2X-XL tracks an arbitrary amount of lights per level and choses the 32 closest to each face it renders when doing per pixel lighting.

With deferred lighting you wouldn't even have to care about the number of lights, and having to create 4 shadow maps is no big deal either.

I dunno how optimized model rendering is like now, but it would be easily feasible to do something about that, too.

An idea coming to my mind when reading about lighting flaws in the above post is that the engine should prioritize certain lights depending on type. What I can also tell for sure that 8 lights per scene in an environment like Freespace just is not enough.

Thing is, I don't know the code and I don't want to spend weeks and months digging through it, only slowly understanding it and screwing around a lot before really knowing where to get my hands on. So I'd like to collaborate with someone who knows the code well and just help with injecting new tech into it. Rendering to a texture is very easy once you have created a suitable render target: All you need to do is tell OpenGL to render to it instead of the hardware's back buffer. So I would like to just point out such things and let some person who knows where the back buffer is selected change the code (which I could provide). I would also provide code encapsuled in classes that would manage render targets and stuff.

So as I said I would appreciate help when having to interface such modules with the existing code.

Where can I get the source code please (SVN access?)? I cannot seem to find it.

[Dragon]

http://www.hard-light.net/forums/index.php?topic=74840.0
3rd post.

[karx11erx]

Thx. Is there a Visual Studio solution available for building FS2Open?

Edit: Found them.

[Zacam]

Thx. Is there a Visual Studio solution available for building FS2Open?

Several. MSVC 6, 2003, 2005, 2008 and 2010 should all be able to compile, though the Projects files for 2003 were dropped due to no supporting members, and the 2005 will probably soon as well. Lots of us on 2008 and several of us on 2010.

[The E]

Thing is, I don't know the code and I don't want to spend weeks and months digging through it, only slowly understanding it and screwing around a lot before really knowing where to get my hands on. So I'd like to collaborate with someone who knows the code well and just help with injecting new tech into it. Rendering to a texture is very easy once you have created a suitable render target: All you need to do is tell OpenGL to render to it instead of the hardware's back buffer. So I would like to just point out such things and let some person who knows where the back buffer is selected change the code (which I could provide). I would also provide code encapsuled in classes that would manage render targets and stuff.

The problem is that, at the moment, we do not have a dedicated graphics coder. Some of us are in the process of trying to learn how it all works, but we're still beginners. Also note that, for the moment, graphical improvements are not all too high on our list of priorities (which is why the lack of an OpenGL person isn't that big a deal for us).

Now, regarding the graphics code itself, there is an interface layer in place that was previously used to switch between the OpenGL and Direct3D codepaths, refer to gr_init_sub(int mode, int width, int height, int depth) in code\graphics\2d.cpp and gr_opengl_init() in code\graphics\gropengl.cpp for details.

[chief1983]

Yeah, while we don't currently have an active dedicated OpenGL guru, it is one of the areas that has been overhauled the most heavily, and therefore, is supposed to be one of the more readable areas at this point.  Someone who has spent more time looking at it would have to attest to that though.

[karx11erx]

Also note that, for the moment, graphical improvements are not all too high on our list of priorities

Oh.

[chief1983]

Really, that's just a convenient argument.  We don't have a graphics coder, so we fix other bugs and code other features instead.  Prettier graphics are always welcome.

[General Battuta]

Also note that, for the moment, graphical improvements are not all too high on our list of priorities

Oh.

That's mostly because of relatively few people with the knowledge to do them. If you have something to contribute and someone on the team is willing to partner as you suggested there's no harm in at least trying.

[Kolgena]

As for the user-base, many of us go crazy excited when the words "shadow mapping" comes up. There's definitely a point to getting a renderer upgrade, if you're able to do it.