Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: karx11erx on April 03, 2011, 09:08:00 am
-
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.
-
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.
-
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?
-
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.
-
Agreed.
-
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 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.
-
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.
-
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.
-
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?
-
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.
-
http://www.hard-light.net/forums/index.php?topic=74840.0
3rd post.
-
Thx. Is there a Visual Studio solution available for building FS2Open?
Edit: Found them.
-
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.
-
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.
-
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.
-
Also note that, for the moment, graphical improvements are not all too high on our list of priorities
Oh.
-
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.
-
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.
-
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.
-
Indeed, it would be great if we got actual shadows into FSO.
-
Cool smoke fx are far more impressive than shadows.
-
Maybe, but I think that those are more appropriate if we were to work on a game in atmosphere. Don't get me wrong, having those would be a good thing, but I believe that the addition of shadowing would have a greater effect on FSO's atmosphere than smoke clouds.
-
I am not talking about smoke clouds, but about rocket smoke trails.
-
I'd still say shadows would look a lot nicer on top of what we already have than new missile trails would. Also, probably not the greatest use of resources to render smoke trails for up to 30 missiles at once.
-
How about we let people work on what they want to work on, instead of trying to drag them about?
If he's got experience with smoke trails and he'd like to help with smoke trails, smoke trails it shall be.
-
I am not talking about smoke clouds, but about rocket smoke trails.
I'm working on it, though the effect is quite excessive, recent improvements in FSO give it acceptable preformance.
(http://img14.imageshack.us/img14/553/screen1811.png) (http://img14.imageshack.us/i/screen1811.png/)
I'm also making a version for Mediavps, but I don't have too much free time, so it's not going quickly.
-
I question your assertion that it has 'acceptable preformance (sic)' on the grounds that you do not have an FPS meter displayed.
-
Cool smoke fx are far more impressive than shadows.
Speaking of which, why did the D2X-XL team think it would be a good idea to remove a majority of the smoke options? Those are by are the most hardware-intensive effects out of anything XL uses and I no longer get the option to turn my ship trails / missile trails off? Even with ship shrapnel at Off I get a massive frame skip from exploding robots because of what smoke effects do appear when they die.
Put it this way: I can have everything else at the highest settings. Everything. Except anything relating to smoke effects, anything above Off and boom, 2FPS.
---Not the right place for this, but I need to know.
-
I don't want to appear rude, but those smoke trails don't look too convincing. What do you think about something like this (confined spaces):
http://www.youtube.com/watch?v=0G58vaNl4Us
or this (wide spaces):
http://www.youtube.com/watch?v=faAdBuVkfKg
You can turn smoke trails down or off. Why most options got removed has been explained in a lengthy article in my worklog on my website. Btw, the real killer is not just smoke, but soft blended smoke. Don't use the highest render quality, and D2X-XL won't do that. I think that if you could be bothered to read the D2X-XL worklog and forum, you might already have found answers for your questions and solutions for your performance issues. I have explained all that stuff often and lengthy enough. That you have maxed out all options but your machine can't handle smoke at those settings tells me that you didn't try to find out what would be the right mix of settings for your machine - and that is exactly why so many options have been removed. There are too many people like you who max everything out and then don't understand the side effects on certain other settings. Lotsa + smoke + highest render quality -> soft particle blending, which requires depth (Z) buffer reads and comparisons in shaders. I also wonder which D2X-XL version you are using. There have been major performance improvements regarding depth buffer handling recently.
Yeah, so once again I wrote stuff I have written over and over before because someone couldn't be arsed to get his ass in the know by reading the easy to find relevant resources about it.
-
I question your assertion that it has 'acceptable preformance (sic)' on the grounds that you do not have an FPS meter displayed.
It's a release build, it runs smoothly on my machine (which is rather average). I'd give it at least 60 FPS, I'll have to check with a meter to be sure.
I don't want to appear rude, but those smoke trails don't look too convincing. What do you think about something like this:
As I said, I'm still working on it. Nuke's particle code allows a lot of options and I have yet to try some of them.
Also, it's an old version, Mediavps one has an updated effect, which looks better.
I've played D2X-XL and I would like to have smoke trails similar to the ones it uses. I just need some time to work on them.
-
You wouldn't need to work on them. I could make a stand alone module out of the code and explain how to use it, and you would get those smoke trails just so. How about it? :)
As I have seen, FS2 still uses the old vm_* vector stuff that's already in Descent 1 (fixed point arithmetic). I can support that as well as floating point vectors.
If I'd get some more suitable textures, I could also enhance them. The golden heat exhaust textures you are using might be a nice addition to what I built. The biggest thing about smoke trails are good textures, and the right mix of them.
-
I don't want to appear rude, but those smoke trails don't look too convincing. What do you think about something like this (confined spaces):
http://www.youtube.com/watch?v=0G58vaNl4Us
or this (wide spaces):
http://www.youtube.com/watch?v=faAdBuVkfKg
You can turn smoke trails down or off. Why most options got removed has been explained in a lengthy article in my worklog on my website. Btw, the real killer is not just smoke, but soft blended smoke. Don't use the highest render quality, and D2X-XL won't do that. I think that if you could be bothered to read the D2X-XL worklog and forum, you might already have found answers for your questions and solutions for your performance issues. I have explained all that stuff often and lengthy enough. That you have maxed out all options but your machine can't handle smoke at those settings tells me that you didn't try to find out what would be the right mix of settings for your machine - and that is exactly why so many options have been removed. There are too many people like you who max everything out and then don't understand the side effects on certain other settings. Lotsa + smoke + highest render quality -> soft particle blending, which requires depth (Z) buffer reads and comparisons in shaders. I also wonder which D2X-XL version you are using. There have been major performance improvements regarding depth buffer handling recently.
Yeah, so once again I wrote stuff I have written over and over before because someone couldn't be arsed to get his ass in the know by reading the easy to find relevant resources about it.
Actually I have experimented with the options on 1.15.125, that's one of the reasons why I know I can go through with most everything except the smoke at higher settings. I haven't checked since then until today, and even with the settings down to mimic the standard Descent II's graphics the smoke effects are still framerate killers. So thanks for assuming that I don't understand anything about mix-and-matching game settings.
And actually, this is the funny thing. When D2X-XL used to have the in-depth settings, I had no problems finding the right combination of high settings and optimal framerates. Now it's simplified and I have more problems getting the desired results.
-
Could the discussion of Descent please be moved to a Descent forum?
Thanks.
-
Could the discussion of Descent please be moved to a Descent forum?
Thanks.
Indeed. Zane, please register on my forum and lets see how we can help you there.
-
I am not talking about smoke clouds, but about rocket smoke trails.
I believe Diaspora has already cracked this problem, though persistence taxes the engine too much.
-
Persistence makes little sense in space, anyway.
-
So does sound, but we're not turning that off. :p
Rule of cool > *
-
You wouldn't need to work on them. I could make a stand alone module out of the code and explain how to use it, and you would get those smoke trails just so. How about it? :)
As I have seen, FS2 still uses the old vm_* vector stuff that's already in Descent 1 (fixed point arithmetic). I can support that as well as floating point vectors.
If I'd get some more suitable textures, I could also enhance them. The golden heat exhaust textures you are using might be a nice addition to what I built. The biggest thing about smoke trails are good textures, and the right mix of them.
Everything I'm doing doesn't involve any code edits, particle system is already pretty good, I just have to explore all the options it gives.
Of course, if you can improve particle code, then it'd be welcome, but remember to allow as many values as possible to be customized in tables. From what you say, it seems that all edits in D2X-XL have to be done in code. This is not the case with FS2_Open, which features such things at tables: http://www.hard-light.net/wiki/index.php/Tables
-
D2X-XL reads its persistent particle system settings from disk. No problem to read it from tables.
You are giving me the impression that you'd rather do this on your own instead of achieving something in a team.
-
Uhm. Yes. Of course there are. Look for the SCP badges. Dragon, despite his badge collection, is not a coder, and what he writes should be read with that in mind.
We are more than willing to work with you. If you can give us hints to improve our particle infrastructure, we're more than willing to listen.
-
Dragon isn't a coder or a member of the SCP, he's just an unaffiliated modder working on it on his own. I wouldn't draw conclusions about the SCP team from his approach.
-
I'm just saying you that you may not need to work on a new particle code, I'd prefer to see shadows implemented first.
Of course, if I'll be unable to get the effect I want with existing code, I'll tell you about it. I'd just like to make sure you wouldn't be implementing a redundant system (and thus wasting time), since there's a possiblity that such effects can be achieved with what we have now.
There's a lot of other things from D2X-XL which FSO could use, for example shadows and collision avoidance for AI (which was rather good in D2, not so in FS2). If you're certain that a your new particle system won't be redundant, then go ahead.
-
Dragon, I think it would be best to let people work on what they want to work on.
-
Shadows are hard to add. Particles are easier.
As I think of it, adding just the particle code is only half the job though. D2X-XL has a halfway efficient transparency renderer that does back to front sorting on the fly, and that is what FSOpen would need, too. That's why it would have been helpful if you had some active OpenGL/graphics coder who knows how to insert such stuff.
Btw, rofl @ your remark about your post count, Battuta!
-
Ok, I think I will look into the entire OpenGL renderer stuff first, and adding particles would be a good approach to that task. Once I have been able to add particle rendering, adding more stuff shouldn't be that hard anymore. I will try to add deferred lighting plus shadow maps after that. Doing something about collision avoidance shouldn't be too hard, too.
-
i am such a smart cookie
If you can do even the smallest thing to improve the efficiency of the renderer you would basically be Jesus. I say this as a layman, but I've heard enough coder complaints to know it's a major bottleneck in the engine (along with collision detection).
-
If particles are to be a start of the whole series of improvements, then I don't mind the modification ending up redundant, especially if it helps you with getting started with the engine.
There's a lot of things that could be ported from D2X-XL. I'd really like to see improved collision avoidance, which, as I said, is really good in D2. Robots can slide throught narrow hallways, make tight turns around corners, camp behind doors and walls, etc. FS2 AI just slams into anything that's in it's way, slams into player when forming up if it's flying a sufficently large bomber, slams into capships it's trying to launch from, etc. . It could use an improvement.
And of course, any efficency improvements to the renderer are really welcome.
-
I see the main problem with renderer performance in how model data is handed to the renderer. There is a very efficient way to handle this with OpenGL.
-
If you can do even the smallest thing to improve the efficiency of the renderer you would basically be Jesus. I say this as a layman, but I've heard enough coder complaints to know it's a major bottleneck in the engine (along with collision detection).
It's not that bad, really. The problem is more that none of us have really grokked it, so adding the features we really want takes longer than it should.
If particles are to be a start of the whole series of improvements, then I don't mind the modification ending up redundant, especially if it helps you with getting started with the engine.
Dragon, learn some bloody patience. We will get what we get when we get it.
I see the main problem with renderer performance in how model data is handed to the renderer. There is a very efficient way to handle this with OpenGL.
Well, now this topic has deviated a lot from the original intent. Would you mind if we continued this discussion here (http://www.hard-light.net/forums/index.php?board=50.0)?
-
I see the main problem with renderer performance in how model data is handed to the renderer. There is a very efficient way to handle this with OpenGL.
If you could implement it without breaking backwards compatiblity, you'd most likely be considered an SCP demigod (do a similar thing with collision detection and you could become a full time one) :)
Also, I indeed think that the discussion reached the point when splitting it and moving into SCP board could be a good idea.
-
Doing something about collision avoidance shouldn't be too hard, too.
No, the tricky part about that is doing so in a backwards-compatible way without rewriting huge swaths of the AI code. :)
-
If particles are to be a start of the whole series of improvements, then I don't mind the modification ending up redundant, especially if it helps you with getting started with the engine.
There's a lot of things that could be ported from D2X-XL. I'd really like to see improved collision avoidance, which, as I said, is really good in D2. Robots can slide throught narrow hallways, make tight turns around corners, camp behind doors and walls, etc. FS2 AI just slams into anything that's in it's way, slams into player when forming up if it's flying a sufficently large bomber, slams into capships it's trying to launch from, etc. . It could use an improvement.
And of course, any efficency improvements to the renderer are really welcome.
its likely he wont even need to touch the spewer code, sounds like he only needs to work with the render code, which should in no way affect the way particle spewers work from the modding side. of course faster particles would mean an increase to the particle limit which means more particles that could be generated, in turn meaning more things can have particle effects. even if the whole system ended up getting deprecated, it would still be worth it just having someone who knows their graphics around.
and (this is not directed specifically at you, but to anyone who could monkewrench this) frankly i dont want to see what happened last time karx11erx came here. i dont want to see hordes of seasoned modders acting like noobs and demanding cookies. show the man some respect this time and leave the code to the coders.
-
I say we let him do his thing, and wait to see what turns up. Since we don't really have anyone working on graphics code at this point, might as well let karx11erx try his hand.
-
I will of course make sure I won't break anything for the modders, or add proper modding support after new features are in place. No worries. I am not planning to take this project over and twist it any way I might like it. I strongly believe in teamwork. ;)
Here's a taste of what would be possible: http://www.youtube.com/watch?v=DQYuhLC-GHY
-
I really like the smoking trail after the explosion of the main ship !
-
Shadows are hard to add. Particles are easier.
As I think of it, adding just the particle code is only half the job though. D2X-XL has a halfway efficient transparency renderer that does back to front sorting on the fly, and that is what FSOpen would need, too. That's why it would have been helpful if you had some active OpenGL/graphics coder who knows how to insert such stuff.
I'm currently working on collision detection optimizations. I'm actually planning on working on the graphics pipeline after the collision code is no longer as big of a bottleneck in the engine. I'd say I'm pretty familiar with the graphics code and probably the closest there is to a "dedicated OpenGL coder" active on this team.
Deferred shading and lighting is something I was also investigating. FSO has framebuffer objects support which fulfills the G-buffer requirements of deferred rendering. I wasn't planning on going through with it until The_E produced his more robust materials system so that there won't be so much trauma in the hypothetical merge. It's something I definitely would like to tackle so any help with that would be obliged.
If you want to work on improving particle rendering, take a look in Particle/particles.cpp. The function you might want to look at in particle_render_all() which uses a geometry batcher to render all particles in batches that share the same texture using glDrawArrays. Our particles are currently just screen oriented unlit quads rendered using the fixed pipeline. It would be nice to have soft particles but our current materials system hasn't been extended to fireballs/particles yet. It would be nice if we had that more robust materials system The_E is working on. :D
-
Does the renderer sort transparent polys back-to-front already?
-
Does the renderer sort transparent polys back-to-front already?
Kinda. We only sort stuff in the Objects array which includes fireballs but not particles.
-
Well, as I said: D2X-XL sorts transparent polys on the fly (no extra sorting), and that is something I would add to FS Open, too.
-
Well, as I said: D2X-XL sorts transparent polys on the fly (no extra sorting), and that is something I would add to FS Open, too.
If what you are describing is what I think it is. Diaspora would likely be interested in that as well (or different application of that technique), so that they don't have to assemble the botanical cruiser out of separate pieces (http://www.hard-light.net/forums/index.php?topic=72663.0).
-
D2X-XL uses kind of a combined hash/or compression algorithm to sort polys. The sort buffer has a fixed size. When doing visibility culling, D2X-XL determines the depth of the scene. The hash value range for the current frame is then [0 .. buffer size / depth - 1]. In the next step, all polys are pushed to the renderer. Each transparent poly is sent to the sort buffer with its distance from the viewer scaled into the hash value range (Z-poly / scene depth), and that hash value used as index into the sort buffer. The sort buffer has a collision handling if a sort buffer element is already in use. D2X-XL can handle up to 250.000 transparent polys, but on a Core i7 920 @ 3.6 GHz and Sapphire HD 5870 Vapor-X more than 50.000 will slow the renderer significantly down. So those few transparent polys on that ship would be nothing. ;)
-
If what you are describing is what I think it is. Diaspora would likely be interested in that as well (or different application of that technique), so that they don't have to assemble the botanical cruiser out of separate pieces.
The described method seems like it'll only apply to effects like lasers, particles, and fireballs, not polygon meshes drawn using vertex/index buffers.
-
How do you render complex polymodels with mixed textures in a single render buffer batch? Afaik that's not possible (unless you put all the model's details in one texture and access them via texture coordinates). Still you shouldn't just render transparent (alpha blended) faces in a single batch that are far away from each other, probably with other transparent stuff between them. At least not with the techniques I know of.
-
Given how FS models are done, with cockpit glass being a separate group of polies with the "glass" texture assigned, this is not an issue, I think.
-
How do you render complex polymodels with mixed textures in a single render buffer batch? Afaik that's not possible (unless you put all the model's details in one texture and access them via texture coordinates). Still you shouldn't just render transparent (alpha blended) faces in a single batch that are far away from each other, probably with other transparent stuff between them. At least not with the techniques I know of.
when the models are loaded a vertex buffer is made, and a different index buffer for each texture is made, when the models are rendered it goes through each texture and draws the related index buffer (obviously using the buffers related to the current LOD and skipping empty buffers). objects are sorted back to front. transparency was never intended in the design of the graphics system, but alpha blending was enabled so some effects could be performed (cockpit glass) if the modder was willing to jump through the hoops to get it working. the assumption when drawing transparent stuff on ships is that there is not a lot of stuff between the transparent poly and the opaque surface behind it (oh, another assumption, there is an opaque surface behind all transparent textures on ships). These assumptions work well enough for 90% of the transparency effects people want in FSO, though some effects don't fair as well as others (any time you can see a transparent surface through another (like big bulky glass domes) you get problems).
freespace's geometry is all stored in BSPs so you can sort it very efficiently if you need to. this is something that has been tossed around from time to time, usually as part of the elusive materials system.