Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nighteyes on September 02, 2010, 06:20:12 pm
-
I think a neat addition that can be implemented is more lights on stuff, like muzzleflashs, missile explosions, and capship engines, how cool would it be to have a blueish hue on fighters when flying close to capships engines? :P
-
There's some engine limitations with the number of available light sources. We're slowly working towards being able to add a lot more though.
-
hmm ok... so how about shadows? :D
-
Shadows are not possible at the moment without causing a massive performance hit. Get us someone who knows OpenGL very well, and we can talk about it again.
-
Shadows are not possible at the moment without causing a massive performance hit. Get us someone who knows OpenGL very well, and we can talk about it again.
Shadows also need lightsources, so currently only shadows would become from suns at the moment.
What would be possible is using glowmap for GI like effects within ships.
First paint Basic Glowmap, then render GI to texture with rendering probram and add on top of the previous glowmap.
This would mean that lights from portholes and such actually would light the ship.
-
Lasers are light sources as well, in case you didn't notice.
And again, unless you are or happen to know an OpenGL programmer with lots of spare time who can make this happen, it's not going to.
-
Lasers are light sources as well, in case you didn't notice.
And again, unless you are or happen to know an OpenGL programmer with lots of spare time who can make this happen, it's not going to.
What happens if we just bump the max number of "laser-like" light sources? How many can we add before the engine starts to choke?
-
I thought a light source is a light source, period.
-
What happens if we just bump the max number of "laser-like" light sources? How many can we add before the engine starts to choke?
It's not so much the engine as the Shaders. OpenGL 2, IIRC, allows for a max of 8 lights per scene, which the current mvp shaders are using fully. More lights are possible (the data just has to be passed to the shaders properly) in OGL 3/GLSL 1.3+. Now, I have no idea what the performance implications are, but what I do know is that it's already hard enough to make the shaders work. (And since I am personally comitted to trying to make shaders work on OpenGL 2 and GLSL 1.2, I have not much incentive to work on higher-end shaders).
-
OpenGL can render 8 lights in hardware per pass. More render passes mean more lights on an object, but at a performance cost. Without shaders the code can handle up to 5 render passes pretty well. With shaders it can do just one relatively well.
FSO itself still processes something like 256 lights per pass though. That is done per the older software rendering, and the HTL graphics code doesn't use all of that lighting info. It is possible to change the code to use it however, rendering 8 (or less) lights in hardware and using vertex coloring for the remaining lights all in a single pass. The lights over the first 8 wouldn't look as good of course, but they would work and would allow for all 256 in a scene that the game processes to be used. The performance hit should be minimal using this method but I haven't tested it myself so I can't say that for sure.
Of course the biggest performance hit with the current shaders is the lighting. By having 8 lights in there all of the time the instruction count on the vertex shaders is very high and that makes them very slow. For instance, in the ships lab, if you trim the shaders to only do one light (since the lab only has one light anyway) you can get a 5-10x FPS boost. The shader code as originally coded was intended to have three sets of each shader, each supporting a different number of lights: 1, 2 & 4. Using that combination it would then be possible to render using a maximum of 2 passes and still get all of the lights. The shader complexity would be a lot less which also would provide a noticeable performance boost, particularly if you only needed a single pass. Unfortunately the renderer is too old and slow to handle multiple passes with shaders without a very large performance hit. The code was subsequently trimmed down to what eventually got put in SVN.
I did work on that performance hit a little earlier this year, to take one last crack at it. Although the reworked code did help a bit (7-180+% performance boost depending on the model) it still had some issues with multi pass. Also, the reworked shaders were still a little too instruction heavy for good SM2.0 level hardware support, with them being about a dozen instructions too big with the 4 light shader. Cutting it to 3 lights max, with up to 3 passes for all of the lights, does work with SM2.0 level hardware but has a performance hit that makes it a bit slower than the current code/shaders. The reworked code could do 2 passes at relatively the same performance of the current code, but no more.
So the point I guess is that: the game processes 256 lights at a time, it will only render 8 of them per object each pass, it would be possible to use all 256 lights with shaders but with a slight hit to visual quality, the reason for the 8 light limit is a hardware performance thing, the engine was designed for software rendering of low-poly models and is set up in a way that is rather inefficient for shader use, the way that our shaders handle lighting is stupid.
It is possible to address these issues, to remove some of the brute force from the renderer so that it is better set up for using shaders, but no one has done it.
-
Shadows are not possible at the moment without causing a massive performance hit. Get us someone who knows OpenGL very well, and we can talk about it again.
Shadows also need lightsources, so currently only shadows would become from suns at the moment.
What would be possible is using glowmap for GI like effects within ships.
First paint Basic Glowmap, then render GI to texture with rendering probram and add on top of the previous glowmap.
This would mean that lights from portholes and such actually would light the ship.
I think we already simulate this with a couple assets. Look to the engine section of the Iceni, and the original glow maps of the Hatchepsut (the current glow maps of the official models botched the porthole lighting)
-
Very informative post
Very interesting, thanks.
I think it might be interesting to try raising that 256 limit and/or allowing missiles/missile explosions/flak explosions to emit light as well. We'd still be limited to 8 lights per object, but IMO that's probably plenty anyway. I believe that Nighteyes' goal is not to have more lights per object, but to just have more potential light sources... and I agree that it could potentially be very cool. From what you've said, it looks like the performance impact of doing so might even be pretty small.
-
I think it might be interesting to try raising that 256 limit and/or allowing missiles/missile explosions/flak explosions to emit light as well. We'd still be limited to 8 lights per object, but IMO that's probably plenty anyway. I believe that Nighteyes' goal is not to have more lights per object, but to just have more potential light sources... and I agree that it could potentially be very cool. From what you've said, it looks like the performance impact of doing so might even be pretty small.
Of those 256 lights we only ever use 8, so that really isn't a limit worth bumping since it wouldn't do anything. And I believe that explosions from flak and missiles do give off light already. Might have to check the code to be sure, but I am pretty sure that they are fireballs and fireballs give off light.
Lights are sorted based on type, intensity and size, so we have to keep that in mind when adding additional light sources. In general you only have 7 lights to work with (since the sun, at least one almost always present, takes a light). The big stuff has lights already and giving small stuff lighting as well would just be a complete waste of CPU time since they would get processed but never used. Also, since lights are sorted in priority order you don't want to add little light sources to models since they would flicker on and off in battle and what not.
Somebody just needs to give colored vertex lighting a try, to render the lights past the first 8, and see if it is worth it from a visual/quality standpoint. I think that DaBrain has previously made a post requesting that as well. I believe that it should only require code changes, with the vertex color already being passed to the current shaders.
-
One thing that may or may not be related to this, though I've had it in my mind for some time;
You mentioned Shader 2.0 and I think we're up to 5.0 right now though everyone uses 4 because that's what the consoles allow.
I was thinking as time progresses, shouldn't you make bigger demands on the hardware? While I do like that my five year old computer can run the game with all options on at 60 frames per second in 1080 (and I can even force AA on with great results), I do find it somewhat odd that the performance hit on it isn't bigger, and that it still passes muster as far as "demands" are concerned.
Not that it's lost on me that you would have to do all kinds of hard work and coding from scratch for some/all of the stuff, but I was wondering if there's any bar that you guys keep raising as time goes by with regards to how much you push existing hardware?
Using my rusty piece of **** to achieve optimum results is kind of criminal.
-
Ideally, I think we'd have a system that detected the optimum shader set for your hardware, but that would requiring having a great many shaders available and a detection mechanism. Maybe we will have that at some point, but right now we're trying to optimize the current experience for the most hardware we can.
-
What about just general settings the user could define, like FS2's Option/Detail config? Just instead of cranking it up to 11 and it working on old hardware, when you crank it up to 11, a hexacore Nehalem rig with a SLI Geforce 480 causes Fermi Fire to burn down the
dancefloor house?
Not that I'm complaining or anything, since I don't really understand what it's like to build on old code intended for something completely different and having the first rule be that you're supposed to make it work on a majority of hardware.
However as time obviously goes on, and as far as visual fidelity goes, it's obvious that FSOpen is getting left behind if it's not attempting to max out the newest hardware. I was just wondering if there are steps planned to address that, or is that just unimportant in the grand scheme of things?
I mean taylor mentioned performance hits, but what are we talking about here? Performance hits to what? Five year old hardware? Is that not okay? And if not, why? Shouldn't it be logical to raise the bar?
-
what Sushi says is what I mean, I want flak explosions, missilehits, muzzleflashs and other effects in the same nature to cast light when going off, I tested it and this is not currently working, while on the other hand ship explosions do cast light... they are not all defined as "fireballs" as you say...
and from what I read here, adding this feture will not hurt preformance one bit, as its always the same amount of lights being generated
-
When taylor is talking about performance hits, it's relative to everything. If you have an inefficient algorithm, it's going to be inefficient and slow no matter what machine you're running it on.
Keep in mind that graphics isn't a wholly a GPU thing. The CPU has to tell the GPU what it needs to do which takes up a huge amount of processing on the CPU side. FSO has to go through each object and set up the render states, vertex buffers, materials, and shaders before finally doing a draw call. It's entirely on the CPU side up to that point.
With multipass rendering, you're rendering an object X number of times repeatedly but with different shader programs each time. Switching shader programs is an expensive operation. If you're doing multiple shader switches for each and every single object, that's going to be very expensive and even top of the line machines will likely slow to a crawl. Most modern game engines are smart with their material states and optimally sort all their draw calls based on material, texture, and vertex buffer to minimize the amount of state changes between render calls and subsequently minimize drawing time.
I'm not sure if not having a state sorting system is the core problem of FSO's but I'd like to think that it wouldn't hurt if we someday implemented it. Please correct me if I'm wrong, taylor.
-
Of those 256 lights we only ever use 8, so that really isn't a limit worth bumping since it wouldn't do anything. And I believe that explosions from flak and missiles do give off light already. Might have to check the code to be sure, but I am pretty sure that they are fireballs and fireballs give off light.
Actually, missile and flak explosions are implemented as particles, which can't/don't give off light.
-
Of those 256 lights we only ever use 8, so that really isn't a limit worth bumping since it wouldn't do anything. And I believe that explosions from flak and missiles do give off light already. Might have to check the code to be sure, but I am pretty sure that they are fireballs and fireballs give off light.
Actually, missile and flak explosions are implemented as particles, which can't/don't give off light.
thats probably also the reason they dissapear just before the whole effect leaves the screen, when the center of the effects is out of the screen(the particle), the whole effect just pops out of view...
-
And again, unless you are or happen to know an OpenGL programmer with lots of spare time who can make this happen, it's not going to.
I'm an OpenGL programmer!
Although I've never (successfully) done shadows. And as far as "spare time"... not so much.
-
So you reminded us of something most of us already know, to be of no help. :P
-
Well, fine then. See if I care that FS2 hasn't got shadows or multilights 5 years from now... :P
:nervous:
Yeah ok, I would care. :(
-
Ideally, I think we'd have a system that detected the optimum shader set for your hardware, but that would requiring having a great many shaders available and a detection mechanism. Maybe we will have that at some point, but right now we're trying to optimize the current experience for the most hardware we can.
The git test branch ("go_faster") that I was playing with earlier this year did actually have basic support for that. It would detect if the hardware was SM2, SM3 or SM4 capable and set a define in the shaders. You could then add #ifdef'd features requiring better hardware support to the shaders. It makes the shaders kind of crap, due to so much code in them, but it is something that would work.
One of the main goals of the new shader code (what I had planned for 3.7) was to use a tbl type of thing which could reference different shaders for different detail levels and different hardware. You could then write clean shaders for each level of hardware support and even different detail settings (such as conditionally enabling per-pixel lighting). Obviously that isn't going to ever come from me at this point, but it's probably worth mentioning in case somebody else feels like taking a crack at it later on.
I'm not sure if not having a state sorting system is the core problem of FSO's but I'd like to think that it wouldn't hurt if we someday implemented it. Please correct me if I'm wrong, taylor.
I did some state stuff for the current shader code to try and squeak out a little bit of extra performance from it all. It was pretty basic, and didn't help a ton, but it was better than leaving it the way that it was. In my previously mentioned test branch I tried to clean things up a little bit more as well.
But the main purpose of that test branch was a proof of concept for improving rendering performance with as little code and time investment as possible. That was primarily fixing the VBO stuff to work in a remotely efficient manner. The way it was coded originally was so that each subobject of a model had it's own index buffer and VBO. That may very well be the worst possible way to implement something like that because changing those buffers is one of the most costly operations you can do. I rewrote the code a bit to use a single IBO and VBO per model, eliminating the buffer switch when rendering except for the one buffer setup when you call model_render(). On small ships like fighters the performance improvement was easily measurable, but it wasn't that big (avg. 20-40 FPS boost). On large ships with a lot of subobjects the performance improvement was massive, in some cases giving a 3x boost. And this was just in the lab, so you can imagine how better it would perform in-game when you have numerous big ships each having the performance enhancement.
And I worked on that code for about 3-4 days, so it wasn't a big time investment either. There are lots of little changes like that, and maybe a few slightly larger ones, which can be made to the current code that can really help out performance wise. Mostly just cleanup, but things like better object sorting and an early-Z pass should provide a sizable performance improvement with shaders (the old render setup is too brute force, far too many things are textured, lit and rendered without ever been seen). No massive rewrite needed. ;)
Actually, missile and flak explosions are implemented as particles, which can't/don't give off light.
I might have been thinking about my old Xt tree then. I reworked lighting on quite a few things (like changes for subspace stuff, and various other items) but never got it working 100%. It was too many code/quality changes for the intended purpose of the code base though (ending up as 3.6.10, when it has it's original release date of June/July 2007) and I ditched the code.
Still, adding such a feature shouldn't be a big deal for someone to do.
-
But the main purpose of that test branch was a proof of concept for improving rendering performance with as little code and time investment as possible. That was primarily fixing the VBO stuff to work in a remotely efficient manner. The way it was coded originally was so that each subobject of a model had it's own index buffer and VBO. That may very well be the worst possible way to implement something like that because changing those buffers is one of the most costly operations you can do. I rewrote the code a bit to use a single IBO and VBO per model, eliminating the buffer switch when rendering except for the one buffer setup when you call model_render(). On small ships like fighters the performance improvement was easily measurable, but it wasn't that big (avg. 20-40 FPS boost). On large ships with a lot of subobjects the performance improvement was massive, in some cases giving a 3x boost. And this was just in the lab, so you can imagine how better it would perform in-game when you have numerous big ships each having the performance enhancement.
That's really encouraging to hear because I've coincidentally thought about about changing the VBO arrangement from one per subobject to one per model. Diaspora has some very subobject heavy models which is likely murdering our framerate.
But here's a question that's been nagging at me for a while. Is there a size in which the vertex buffer becomes suboptimal? I've heard some wildly diverging figures on this question. How well do you think would a vertex buffer with 100,000 polys run? Probably better than switching buffers between a 100 or so subobjects? :P
And I worked on that code for about 3-4 days, so it wasn't a big time investment either. There are lots of little changes like that, and maybe a few slightly larger ones, which can be made to the current code that can really help out performance wise. Mostly just cleanup, but things like better object sorting and an early-Z pass should provide a sizable performance improvement with shaders (the old render setup is too brute force, far too many things are textured, lit and rendered without ever been seen). No massive rewrite needed.
For the early-Z test, would you suggest using ARB_occlusion_query?
Where can I find this go_faster branch? :D I'd like to bring over some of these optimizations and improvements.
-
But here's a question that's been nagging at me for a while. Is there a size in which the vertex buffer becomes suboptimal? I've heard some wildly diverging figures on this question. How well do you think would a vertex buffer with 100,000 polys run? Probably better than switching buffers between a 100 or so subobjects? :P
Optimal size is about 2meg, according to OpenGL docs. And it needs to be properly aligned as well. The general rule is to have as few VBOs as possible and just use offsets to change the render data.
I didn't set it up in my tests for size, just to lower the count and reduce the number of low poly counts in each buffer. So even with what I did there is still some room for improvement.
]For the early-Z test, would you suggest using ARB_occlusion_query?
You really just need to render the scene once with depth writing enabled and pretty much everything else disabled. Then render normally with depth reading and it should just use the depth buffer to avoid rendering all of the polys that wouldn't otherwise be seen. A google search should turn up something a bit more detailed, but there really isn't much more to it. Transparency will be an issue, and that's where better sorting would be needed, but otherwise it's pretty simple.
It's really pretty horrible how the code is now, rendering all of the subobjects with full texturing and lighting, then rendering the hull over them. You almost never get to see any of that stuff and it completely wastes the GPU cycles. With the depth culling it should allow the shaders to skip processing all of that useless junk and just discard it.
Where can I find this go_faster branch? :D I'd like to bring over some of these optimizations and improvements.
It's just a branch in my local git repo. I'm going to post a diff of it at some point, and detail the changes as well as how others can continue those types of changes, I just haven't gotten around to finishing a few things. I don't think that it will be good enough for committing to trunk, or even Antipodes, but it should be something that the rest of you can build off of and maybe work towards getting it somewhere in SVN. Just keep a watch in the internal forum the next few weeks, it should be posted before the month is out (I hope). :)
-
It's just a branch in my local git repo. I'm going to post a diff of it at some point, and detail the changes as well as how others can continue those types of changes, I just haven't gotten around to finishing a few things. I don't think that it will be good enough for committing to trunk, or even Antipodes, but it should be something that the rest of you can build off of and maybe work towards getting it somewhere in SVN. Just keep a watch in the internal forum the next few weeks, it should be posted before the month is out (I hope).
Sure! In the meantime, I'll try to replicate your VBO enhancements since it doesn't seem like it's too complicated of a change and also Diaspora desparately needs that right now. Unless it's not much trouble to ask for a quick diff for that specifically. ;7
-
It's not really all that quick of a change actually, it's more of a rewrite of the feature. Also it breaks IBX files and starfield rendering, the two things that I haven't finished getting working again. I don't want to post it publicly but I don't mind e-mailing you the current diff if you want to have a look at it.
-
I would be interested in said diff as well.
-
I should have it posted in the internal forum sometime next week.
-
so back on topic, how hard will it be to add lights to explosions from missiles and such? as in setting these explosions to be "fireballs"(like fighter explosions, those do give off light) instead of particles...
-
Given that, under the current renderer, only 8 lights per scene are rendered, chances are these wouldn't be all that notable.
-
so back on topic, how hard will it be to add lights to explosions from missiles and such? as in setting these explosions to be "fireballs"(like fighter explosions, those do give off light) instead of particles...
It wouldn't be hard at all, but as has already been mentioned, the engine currently only renders 8 lights per-pass per-object. So even if light sources were added to missiles and such the chances of actually seeing it would be next to zero, and pretty much absolute zero in the case of an actual battle where those lights sources would most likely to be generated. It would essentially be adding code to the game for the sole purpose of slowing things down and without any real graphical benefit what so ever.
-
so back on topic, how hard will it be to add lights to explosions from missiles and such? as in setting these explosions to be "fireballs"(like fighter explosions, those do give off light) instead of particles...
It wouldn't be hard at all, but as has already been mentioned, the engine currently only renders 8 lights per-pass per-object. So even if light sources were added to missiles and such the chances of actually seeing it would be next to zero, and pretty much absolute zero in the case of an actual battle where those lights sources would most likely to be generated. It would essentially be adding code to the game for the sole purpose of slowing things down and without any real graphical benefit what so ever.
Still seems to me that given the "priority" system for choosing lights, a missile passing close over the surface of a ship could make a difference. The bigger problem is probably that there is no way to have "small" lights that only light up part of a big ship, and also the fact that lights getting swapped in and out could result in some weird color flashing.
Hard to say for sure until someone tries it though.
-
another big difference that this will make is eliminate the "bug" where these "particle" effects(flak, missile explosions...) dissapear from the screen without being completly out of view...
right now when the center of the particle is out of the screen, the whole particle stops rendering, now, if we have a big explosion you have about half an explosion suddenly stops rendering abruptly, looks very bad...
if it would render as a "fireball", not only will it render lights, but it will also render properly and will only stop rendering once the whole effect is off the screen...
*I've placed this "bug" in mantis a few months ago
-
It's really pretty horrible how the code is now, rendering all of the subobjects with full texturing and lighting, then rendering the hull over them. You almost never get to see any of that stuff and it completely wastes the GPU cycles. With the depth culling it should allow the shaders to skip processing all of that useless junk and just discard it.
something i asked for at some point and was shot down by almost everybody was to have subobjects lod levels determined based on its distance from the camera rather than their parent ship's current lod. on a ship thats about 2-3 km long, and looking it from the front or back, some turrets would be incredibly close to the camera, while others would be up to 3 km away at minimum. its no substitute for completely omitting things that shouldnt be rendered, but it would help reduce the rendering overhead associated with subobjects.
-
another big difference that this will make is eliminate the "bug" where these "particle" effects(flak, missile explosions...) dissapear from the screen without being completly out of view...
I'm not sure how adding light sources to particle effects would do anything to fix the only real flaw of point sprites. :confused:
something i asked for at some point and was shot down by almost everybody was to have subobjects lod levels determined based on its distance from the camera rather than their parent ship's current lod. on a ship thats about 2-3 km long, and looking it from the front or back, some turrets would be incredibly close to the camera, while others would be up to 3 km away at minimum. its no substitute for completely omitting things that shouldnt be rendered, but it would help reduce the rendering overhead associated with subobjects.
I don't believe many models are actually designed to allow that to work. It can't tell that something is a turret for instance, so it would have to apply the lod change logic to every subobject on the model and I don't think that would work out so well visually for most models. Using render boxes would be the best way to address that particular issue, since then it would be up the modeler how it would work rather than leaving it to the game (which would more often than not get it wrong).
-
I'm not sure how adding light sources to particle effects would do anything to fix the only real flaw of point sprites. :confused:
well, the idea was not to simple add lights to the particles, the idea was to tell the engine to render these effects as it renders "fireballs"... not as particles, as adding lights to particles will not help us much, as you have tons of them on missile trails, thrusters, damage trails and such...
-
Fireballs are rendered in a fixed point in space though. Particles move, so the lighting setup will have to be through the particle system in order for the light to move with the particle. It wouldn't be for everything either of course, we would just set a flag when the particle is created that it should emit light and that would be easy enough to do just for flak explosions and missiles or whatever.