[KeldorKatarn]

Right now the engine limits light emitted from primary gun fire to one light per weapon bank.
This makes sense due to efficency limits, but for certain types of ships, which have their guns mounted very far away (an X-Wing e.g.)
this can look very strange and it is usually very obvious, that only one laser bolt emitts light.

To this end I've added a line to weapons.tbl with which you can specify how many lights per gun bank should be rendered.
If this code proposal (patch attached) should be accepted, it has to be used with care of course. Only use as many lights as are needed to
make the lights shine symmetrical. So for the X-Wing only 2 are necessary, not 4. This is especially important if the weapon is mounted on a lot of ships,
so this is clearly a setting that must be used with care and efficiency vs. looks must be decided on. Also the game only handles 256 lights max, so keep that in mind and
don't assign 8 lights per primary.

[attachment deleted by admin]

[chief1983]

For the X-wing example, how do you make sure there's one light on each side of the fighter?

[DaBrain]

For the most part, you can't see it.

It's only clearly visible when the lights on your lasers are per-pixel lights.
The current FSO shaders do not support it.

However, once they do, I agree with Keldor.

[KeldorKatarn]

For the X-wing example, how do you make sure there's one light on each side of the fighter?

To make sure they are on either side, I THINK the game goes through them by their order in the pof. So the modeler would have to arrange them so bank 1 and bank 2 are on opposite sides.
I didn't double check this, but adding this to the patch, i.e. letting the engine go through the banks in the right order, should be easy. I'm pretty sure though that is already the case since I doubt it happens by random since that would be strange coding, and also our exalibur had banks 1 and 2 on the same side and with 2 activated lights I fired several shots and never saw one on the other side, with 3 or 4 lights it worked.

It's only clearly visible when the lights on your lasers are per-pixel lights.
The current FSO shaders do not support it.

However, once they do, I agree with Keldor.

As for the per-pixel lights... well Saga uses those. I rewrote the shaders to support per-pixel lighting for all lights. It makes explosions a lot more spectacular and since we use a very low ambient level it also makes gun fire reflect off the hull very well.
I'm prety sure there are other mods with custom shaders around so I'd say this really has a use. And I mean for all others it doesn't change anything. The lights value defaults to 1 which results in 1:1 retail behavior so nothing is lost really. But it opens up the possibility for mods which use per pixel lighting.

It all depends on the mod anyway. With a high fire rate the thing would probably be even more visible.
And if a mod lets the primary cycle between the guns of one bank (I think that's possible to configure?) it will be VERY visible even with per-vertex lighting, that one gun has no light attached. Unless the engine handles that case as a separate primary salvo of course.

Anyway, for SOME mods it is probably benefiting. For us it is already at the edge, because our guns are usually pretty close together. The excalibur is probably the only fighter where you'll really notice it at all and you'll have to fire a salvo pretty close along a surface, but still. It's a nice deature I think. Easy implemented, easy to use and doesn't break anything.

[chief1983]

With firepoint cycling we would need a light for every point though, or only certain shots would cast lights.  But then they won't be cast at the same time so that hopefully won't hurt performance.  However, when we get selectable firepoint grouping, I'm wondering what the effect will be.  They'll all need to cast lights for the 1x4 mode, but in 4x1 mode that'll be four lights every shot, etc.

[taylor]

It should be possible to make this automatic and tied in to the lighting detail slider.  Light creation would be linked to the distance between fire points and the number of points firing.  If multiple fire-points are close enough then it should modify the light to be more intense, but still a single light.  If they are decently far apart then create multiple lights.  Creating multiple lights should require that the lighting detail slider is maxed.

I just don't see any good reason to force a tbl change to make something like this work.  The code should be rewritten to handle it automatically.

[KeldorKatarn]

That way you cannot specify it per-weapon, you cannot specify how many lights. That's totally unflexible and could cause unnecessary framerate drops for no reason.
Modders know which weapons are mounted where and how many lights are needed to make it look symmetric. Some weapons might need 3 depending on the way they are mounted on ships.
Other modders might want all possible lights no matter how they're mounted. Or just for one weapon that has a very impressive light effect and should be very bright and visible and therefore needs a light for each bolt...

Linking all this to just one slider is making the entire thing useless. it forces stuff on people and cannot be deactivated. Light calculations in the shaders are extremely expensive. Making this on a global scale just linked to the lights-detail slider will have horrible results. Some ships might suddenly have 16 lights instead of 4... you can imagine what happens on a medium machine if that fighter fires a salvo across the bow of a capship...

I'm totally against implementing it in that way. If not flexible then rather not at all.

[taylor]

The game only uses 8 lights per object, so other than some visual issues, there simply isn't going to be some mysterious large performance hit from a bunch of lights.  Those visual issues are going to happen regardless of whether it is an automatic thing or a mod thing anyway.

The game knows where these lights are going to come from as well and where and how many places other lights could come from so this isn't some magic stuff that only the modder knows about.  Unless the code to handle it is just completely stupid it should give entirely acceptable results which both look and work good all without requiring anything extra on the part of the mod maker.  Plus some people might not like the lights behaving that way, regardless of what the modder wants, so attaching it to the detail slider actually puts more control where it should be: the user.

And the problem with shader light performance isn't in the calculations, it's in the brain dead rendering code.  Untold numbers of GPU cycles are wasted working on texels that will never be seen by the player.  If the rendering code were rewritten to fix all of that old crap then real multi-pass rendering with shaders can be done, allowing less complicated single-light shaders which could give you even better results than what is possible now and with significantly improved performance.

[Sushi]

The game only uses 8 lights per object, so other than some visual issues, there simply isn't going to be some mysterious large performance hit from a bunch of lights. 

So what happens if we just turn off the "one light per bank" restriction? How does that affect things?

[KeldorKatarn]

It will generate a light for every gun built resulting in maximum amount of lights all the time for the player and a continuous slowdown if the shaders are using per pixel lighting.

To clearify this.. our shaders only render as many lights as are passed to the shader. So it works faster if less lights are needed. If we always fire with at least 12 lights per ship that not only doesn't leave room for explosion lights and destroys the look it also always slows down, even when right now there would only be 3 lights to render.

I'm totally against that.

Edit: Implementing it without letting the modders control the amount of lights is considered a release breaker by the Saga Team.

In this case we definitely want backwards compatibility. simply changing this without the ability to go back is destorying performance without reason and will most likely result
in other more important lights not being rendered.

After this discussion I'm sorry I brought it up and would rather see this thread closed and deleted.

[Tolwyn]

Edit: Implementing it without letting the modders control the amount of lights is considered a release breaker by the Saga Team.

In this case we definitely want backwards compatibility. simply changing this without the ability to go back is destorying performance without reason and will most likely result
in other more important lights not being rendered.

After this discussion I'm sorry I brought it up and would rather see this thread closed and deleted.

/signed

[DaBrain]

Do we have a light priority system?

Explosions should always get lights, while projectiles should only get lights when there is still room.

I know the per-object limit makes it quite complicated.



Also, there are some rapidly firing weapons. (I.e. the Maxim)
Nobody wants some projectiles to have lights. It should be every (maybe) 10 shots of rapid firing before another light gets attached to a projectile.
In other words, the engine needs to handle lights pretty smart, depending on the situation and the weapon.
We need some hardcoded rules for lights.

[Sushi]

My earlier question was just trying to understand all of the confusing statements about the effect of More Lights on the game. Thanks for the explain!

For what it's worth, I like the patch idea: it's nice and simple, and leaves the modders in control. The only suggestion I have would be to make the number of lights tied to the weapon bank, not the weapon.


Yes, there are more complicated things that can be done to improve lighting, but if we have a simple solution to one problem, why not take it?

[KeldorKatarn]

My earlier question was just trying to understand all of the confusing statements about the effect of More Lights on the game. Thanks for the explain!

For what it's worth, I like the patch idea: it's nice and simple, and leaves the modders in control. The only suggestion I have would be to make the number of lights tied to the weapon bank, not the weapon.

That's a bit complicated. I originally planned that but the light is attached in the object-level code. So the thing doesn't really have any idea what bank it is fired from. it only knows that all objects created from the same bank in the same salvo have the same group-id and checks whether one group already has a light. But that group-id is just generated for a salvo from one bank somewhere else.

Making it bank and/or ship specific would be nice, but that might require a much more complicated code change unless I overlooked something.

[Bobboau]

The game only uses 8 lights per object, so other than some visual issues, there simply isn't going to be some mysterious large performance hit from a bunch of lights.  

it used to handle more than 8 lights via multi-pass rendering, did this get killed when shaders were implemented?

[taylor]

Do we have a light priority system?

Yes.  Lights applied to an object are evaluated for things like intensity and size and those considered as having more of an effect on the object will be given higher priority.  And lighting from suns are always included in the 8 lights, so the more suns are in a mission the fewer lights available for other things.  So the 8 lights with more effect on an object are used.

In other words, the engine needs to handle lights pretty smart, depending on the situation and the weapon.

Exactly.  There is no way for a modder to be able to tell how this stuff should work because it's all dependent on the situation.  Even if the proposed change was made there would be few times where it would actually work.  It would likely just cause more harm than good.  Newer, smart code needs to take care of stuff like this.  That is not to say that idea behind the proposed patch isn't worth adding, just that the patch itself if pretty much useless because it doesn't address a single problem that such a change would introduce.

it used to handle more than 8 lights via multi-pass rendering, did this get killed when shaders were implemented?

It still uses more than 8 when not using shaders (it is based on LOD though, with lower LODs getting fewer lighting passes).  I tried for several months to get it working properly with shaders but failed.  When using multi-pass with shaders I was getting up to an 80% performance drop with some ships, and never less than about a 20% hit.  Through various testing I basically figured out that we needed to fix the design flaws in the code which cause us so many rendering performance issues, and also add early Z, in order to get shaders to perform like they should (with or without multi-pass rendering).  The rendering code was just written for a software renderer, it's simply too dumb to work properly with hi-poly models and complex rendering/lighting techniques.

[Nighteyes]

on the same subject, why are explosions from secondary fire(missiles, flak...) don't emit lights? strange that for primary lasers witch houndreds are flying about we have lights but for a relative small number of secondary fire we don't have lights at all...

[Bobboau]

Through various testing I basically figured out that we needed to fix the design flaws in the code which cause us so many rendering performance issues, and also add early Z, in order to get shaders to perform like they should (with or without multi-pass rendering).  The rendering code was just written for a software renderer, it's simply too dumb to work properly with hi-poly models and complex rendering/lighting techniques.

it's lucky all the geometry is in a BSP tree then, you can get it to render in front to back order, you can save index buffers in a per-ship basis and rebuild them every second or two of on screen time.

[KeldorKatarn]

on the same subject, why are explosions from secondary fire(missiles, flak...) don't emit lights? strange that for primary lasers witch houndreds are flying about we have lights but for a relative small number of secondary fire we don't have lights at all...

Engines don't emmit lights either. In this context taylor is absolutely right. Adding lights to everything and even more graphical improvements is only useful to a point as long as the rendering code isn't optimized. Once that is done, other, a lot more important, features could be implemented. Shadows e.g. without which especially 3D cockpits look terrible IMO. Stuff like that and more complex lighting is simply not possible as long as the code isn't optimized.
That's also why Saga is totally against a global setting to enable full lighting for ALL guns at the moment. The engine is simply not fast enough for that to work well. Even with the intelligent light handling you already see lights disappear or stuff not having lights sometimes, because the limit isn't high enough. Adding more lights will only make that worse if not done in a controlled manner or held back until the code is working better.

[Sushi]

on the same subject, why are explosions from secondary fire(missiles, flak...) don't emit lights? strange that for primary lasers witch houndreds are flying about we have lights but for a relative small number of secondary fire we don't have lights at all...

This is because those explosions are handled as particles, and particles currently cannot be light sources.