[taylor]

Thank you for the details
But what difference between Ambient_factor and ogl_spec ??

-ambient_factor is a value that modifies the ambient light in a mission.  By default the values are 127 for R, G & B (used in the range of 0 to 255).  This translates to 0.47 for OpenGL (which is in the range of 0 to 1).  So -ambient_factor would change that + or -, depending on the value you specify.  I had explained in slightly greater detail the -ambient_factor values in another thread, somewhere, but basically, a value of 127.5 is no change, anything lower than that will decrease the ambient light in a mission, anything higher in increase it.  And -ambient_factor figures up like this: ((ambient_factor * 2) - 255) / 255.  The result of that is then added to the ambient light values used for a mission.

-ogl_spec is, perhaps, what Bobboua says that -spec_exp was supposed to do for D3D.  -spec_exp uses a different set of values though, so I couldn't really use that in the OGL case.  Basically -ogl_spec simply gives a value to the shininess of the specular light used by the game.  I doesn't affect anything else.

Are you sure spec_point and spec_tube do nothing?  Cause I set spec_point to 0.2, fired a few Subach shots along the hull of a Satis, and saw a few streaks of blue.  I then set it to 9.5, and the entire ship turned purple for one shot.  Something tells me thats a bit more than nothing .

Yeah, I didn't look at it close enough.  Technically they don't do anything since the code doesn't make use of the specular values, but the lighting code will copy the diffuse RGB values to the specular RGB values if no specular is specified.  So, it does work, just not terribly well.

Speaking of point lights, is there any way to adjust the radius and/or intensity of said light without modifying each individual weapon (if I can even do that anyway), so that the lighting radius is larger, but also less evident?

Unless Bobboau added that capability a while back and I never noticed, then I'd so no.  The current values that OGL uses were a big time trial and error thing that I went through for the new lighting code.  A lot of tester feedback was also used to hone the values.  I had to make it work well with all mods, even though some of the values looked considerably better in retail, or in a particular mod, then they do in the final code.  Nothing I could do about it at the time, and not really anything that I can do about it now either.

Don't see any reason why that can't be added to the todo list though.  The new OGL lighting code was more of a temprary patch than anything else.  I worked on it mostly just to fix the lighting issues that already existed.  And since we were already in a code freeze for 3.6.9 at that point, I didn't really have the choice of really getting in there to do it like I truely wanted.  Post-3.6.9 should see that properly fixed though.  I'm even going to make sure that things like explosions and the warp effect have modder specified light values, per effect.  Right now the light values for that stuff is hard coded, which sucks, but will later be modified to do some pretty neat things.

What's the difference between '-no_emissive_light' and '-ambient_factor 0' ?

Using an -ambient_factor of 0 will remove all ambient light, but emissive light will still be used.  Generally you would just want to not set an ambient_factor, use -no_emissive_light, and then figure out your best ambient_factor setting when not using emissive light.  So long as emissive light is enabled you will never get anything completely dark.

While I have no issues with Taylor breaking D3D if no one is willing to code for it I don't think you're realising how big a change this is. We're talking about the bypassing and eventually the complete removal of the abstraction layer sitting between FS2 and OGL. That means that OGL will get a lot better but it also means that it will get exponentially harder to stick D3D back in.

^^ Like he said... it's a slightly more complicated situation than simply not supporting D3D, or breaking it.

There already exists the capability in the code to build a binary without D3D support, and it will use only OGL (even if you specify D3D in the launcher).  The current plan is to make that the default (to not have D3D support compiled in) starting with all CVS after Christmas.  If by the end of the summer there is still no plan for D3D, then the code would actually be removed (we would discuss it again at the time before actually removing the code).  If by next Christmas we still have no plan for D3D then we would evaluate the need to keep support for multiple graphics APIs.

None of that is really permanent, unless support for multiple graphics APIs is removed.  At that point it will basically be just an OGL engine and nothing else.  And while I would certainly like to do that for code simplicity and functionality/performance sake, it's a pretty complicated decision to make and actually carry out.  I don't know that we'll actually ever take it that far, since there is more involved that just OGL or D3D, but it is an idea which has been floated for serious consideration at the end of next year.  Deffinitely nothing to worry about now though, since it won't be a real part of the conversation for another year at least.

[Bobboau]

if we do remove the abstraction layer, I hope we at least keep the OGL stuff partitioned a bit.

another complication with D3D is that the next version of it (10) is extremely different from 8 or 9, it's been designed to take advantage of a high level of programmability in the newer hardware.

[ShivanSpS]

That is because ist really as the Directx that all we know, is a new API, I dindt remember the original name, but MS decided to call it DX10 just to steal popularity from its previus API, thus creating great confucion too. As usual.

[neoterran]

It was previously called Windows Graphics Foundation 1.0

[MetalDestroyer]

Thanks again. Now, I have to play with command line value >_<

[Col. Fishguts]

What's the difference between '-no_emissive_light' and '-ambient_factor 0' ?

Using an -ambient_factor of 0 will remove all ambient light, but emissive light will still be used.  Generally you would just want to not set an ambient_factor, use -no_emissive_light, and then figure out your best ambient_factor setting when not using emissive light.  So long as emissive light is enabled you will never get anything completely dark.

I'm still confused. Ambient light is the base brightness on all objects, right ? The omnidirectional light that would even be there if no sun was in the mission.

Then what counts as emissive light ?

[taylor]

I'm still confused. Ambient light is the base brightness on all objects, right ? The omnidirectional light that would even be there if no sun was in the mission.

Then what counts as emissive light ?

Ambient light is the light provided by the environment, emissive light is provided by the object itself (ie, a glow).  I can't really think of a good comparison for you, but think of it sort of like a room with a TV in it.  If outside is light then the room will have ambient light.  If the room has a lightbulb turned on then you have directional light.  If the room is totally dark and you turn the TV off, the residual energy in the tube will still create a slight glow from the TV screen which you can see, and it will take a few seconds to totally dissipate.  That is emissive light, that general glow given off by some object, but without an otherwise direct source.

And yes, having emissive light serves little point for a game from a realistic point of view.  But, it's there for usability purposes, and not for the purposes of realistic lighting.  The FS2 engine is for space games, and there is little contrast between objects without direct light and the background.  With the original lighting code changes I had made, you could easily lose a ship in space since you wouldn't be able to see it and be forced to target it instead (if that was even possible, which is wasn't in some test missions I had chosen).  With a good background, or enough ambient light, this isn't so much of an issue, but some missions/mods have really crap backgrounds and really low ambient light settings and you'll run into this problem.  That's the usability purpose of emissive light for us, and why it's enabled by default.

The emissive light thing may be removed in 3.7 though, or at least be turned off by default.  I have made numerous lighting changes since I originally added it for usability purposes and it isn't totally necessary at this point.  Further lighting and texturing improvements, plus the addition of shaders and normal maps, should pretty much invalidate any need/desire for emissive light in a few months.

[Col. Fishguts]

Ah, I see. Thanks for the clarification.

[ARSPR]

Till yesterday, reading the post, I didn't know about -no_emissive_light flag. I was always surprised about not having true dark sides on the ships even with -ambient_factor 0.

No, I've been playing a little and I can swear that with -no_emissive_light and low -ambient_factor values (about 40 - 60) the game looks great  . (Although as Taylor has said, sometimes it can be quite hard to locate objects in space).

Nevertheless, despite the technical explanation, and after playing for a while, I would say that "emissive_light" behaves more or less the same than -ambient_factor about 110. So IMO. it can disabled by default. (Check "-ambient_factor 110 -no_emissive_light" vs. "-ambient_factor 0").

OTOH, I don't really understand which differences you'll see between an object that has a global illumination (ambient light) versus another one inside a fully dark place but with an inner source of light (emissive light). I feel the final appearance of both would be pretty much the same.

[taylor]

Nevertheless, despite the technical explanation, and after playing for a while, I would say that "emissive_light" behaves more or less the same than -ambient_factor about 110. So IMO. it can disabled by default. (Check "-ambient_factor 110 -no_emissive_light" vs. "-ambient_factor 0").

Like I mentioned though, the real need for emissive light isn't as great as it was 7-8 months ago when I original wrote the new code.  Several tweaks and changes have been made since then and you should be able to get by without it in most cases.  But, it isn't going to get any sort of change until I redo the code again in a couple of months.  At that point I'll probably disable it by default, since slightly better/faster lighting code will be in place, and probably remove the feature totally by the time that 3.7 is getting ready for code freeze.

OTOH, I don't really understand which differences you'll see between an object that has a global illumination (ambient light) versus another one inside a fully dark place but with an inner source of light (emissive light). I feel the final appearance of both would be pretty much the same.

The benefit of emissive light is simply that it's always there, and it lights all objects the same way.  For the original purposes of the code there was more of a difference than there is now, since I have tweaked the ambient lighting a bit.  The emissive light is set really low, less than 10% (the minimum I could get to look ok in testing), but how much you actually realize it depends on the user/monitor/display settings/model/textures/mod.  At this point it's not really needed any longer, but it's too late to go in changing it for 3.6.9.  And technically, ambient light can't actually be disable btw.  It is clamped in the range 0.2/1.0, which means that it will always have at minimum of 2% ambient light.  But again, new lighting code is coming, and that is a self-imposed limit which is likely to get removed as well.

As far as not knowing about -no_emissive_light, that doesn't really surprise me, since I never really advertised that it existed or what it did.  The option to disable emissive light only showed up a month or two after the new lighting code, at DaBrain's request. 

[Mongoose]

Getting back to the whole D3D issue for a moment, from an outsider's perspective, what would be the purpose of bothering to have support for multiple graphical APIs at all?  If OpenGL is a fully open API that is portable across OSes, why is there any need to maintain support for a Windows-only interface in the first place?  Maybe I'm missing something really fundamental here, but even if Bobboau/someone else were to iron out all of the current/future D3D bugs, would there be any benefit at all to having that as a second option?  From this ignoramus's viewpoint, if completely "integrating" the code with OpenGL allows you to pull off more amazing feats in the future, then full steam ahead, and to hell with maintaining compatibility with anything else.

[Huggybaby]

If OpenGL is a fully open API that is portable across OSes

I think that's the answer: it's not as portable as it should/could be. Many machines support D3D better than OGL for whatever reason, and the situation is constantly in flux.

[neoterran]

Nvidia cards are generally far better at openGL than their counterpart ATi cards.

[taylor]

Getting back to the whole D3D issue for a moment, from an outsider's perspective, what would be the purpose of bothering to have support for multiple graphical APIs at all?  If OpenGL is a fully open API that is portable across OSes, why is there any need to maintain support for a Windows-only interface in the first place?  Maybe I'm missing something really fundamental here, but even if Bobboau/someone else were to iron out all of the current/future D3D bugs, would there be any benefit at all to having that as a second option?

For the same reason that supporting multiple OSes is a good thing, you can indentify and work out problems far more effectively.  For instance, there have been several bugs which were a real problem with Windows builds, but didn't affect Linux or OS X builds in the least.  Because of that it was obvious that the problem was in Windows specific code and was readily found and fixed.  And some bugs are simply easier to track down in one OS over another.

Having support for both D3D and OGL allows us to verify whether a problem is more general to the game code, or is in the API specific parts.  That can save a tremendous amount of work in finding and fixing the problem.  The problem at hand, and why dropping D3D is being considered, is because the D3D code has basically fallen apart without someone keeping it up.  So as a debugging tool it's practically useless at this point.  It's also practically useless as an end user thing as well, given it's serious speed, quality and feature deficiencies.

Getting rid of multiple API support does allow us to greatly simplify and also performance enhance the code a bit, as well as have an easier time adding new features, but it wouldn't actually give us any new capabilities.  If anything it will only remove capabilities, the capabilities afforded to us by being allowed to easily make use of a different API.  We are going to change to having D3D disabled in all builds by default, but that will hopefully just be until the code can be fixed.  Removing multiple API support is a huge deal and is not an idea which will be seriously entertained for quite some time.

OpenGL is far more supported at the moment simply because I'm supporting it.  It is used on all three supported platforms so there is considerable incentive to get it working as well as possible, and keep it working that way too.  But, I'm not really a graphics person.  Having someone to actually come in and add really cool new graphics features is needed, because I can't do that.  If that someone knows D3D and not OpenGL, that makes it easier for them to add the features, and then I could go in and add the specific support for it in OpenGL.  It works out better for everyone that way.

And plus, at some point I'm not going to be involved with this project any longer.  Whether I simply no longer have the time, get sick and tired of you people, or get hit by a bus ... at some point, someone will have to take my place.  It's beneficial to the project to just have the options available for the future, so that we don't paint ourselves into a corner and then regret it later.

I think that's the answer: it's not as portable as it should/could be. Many machines support D3D better than OGL for whatever reason, and the situation is constantly in flux.

It is as portable as it should/could be.  The problem with compatibility isn't with OpenGL, it's with the graphics card makers.  ATI OpenGL support pretty much sucks overall, but the quality can vary wildly between different driver versions.  NVIDIA OpenGL support is practically unmatched.  Intel cards (the integrated stuff) will be getting far better OpenGL support in the near future, and not just through Vista either, though partially because of it.

But in any case, this has to do with the drivers, rather than the hardware.  It is likely that your card can do great with OpenGL, if it only had quality drivers.  With ATI getting folded into AMD (a rather Linux friendly company), it's possible that we'll see improved support for non Windows-only tech in their future drivers.

[neoterran]

And plus, at some point I'm not going to be involved with this project any longer.  Whether I simply no longer have the time, get sick and tired of you people, or get hit by a bus ... at some point, someone will have to take my place.  It's beneficial to the project to just have the options available for the future, so that we don't paint ourselves into a corner and then regret it later.

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 

[neoterran]

While I have no issues with Taylor breaking D3D if no one is willing to code for it I don't think you're realising how big a change this is. We're talking about the bypassing and eventually the complete removal of the abstraction layer sitting between FS2 and OGL. That means that OGL will get a lot better but it also means that it will get exponentially harder to stick D3D back in.

well, i am not aware of the technical implementation of it, but removing an abstraction layer can lead to simplicity in the codebase and some speed improvements, no ? The way it is now, d3d is useless anyway. I don't see a super huge problem with forcing users to use OpenGL if it'll make it better for everyone; after all, if they want sound, they're forced to use OpenAL already, what's the difference ? All modern 3D cards, including Intel onboard variants suppport OpenGL....

Direct X 10 is messing everything up for D3D anyway.... OpenGL seems the way to go, for this project. Plus it's OSS. Doesn't it feel better 

[karajorma]

Well one major reason to have a second API is as a fallback position if OpenGL doesn't work. We've had quite a few people have problems with OpenGL and yet have D3D work for them.

I'd rather have that then see them go away cause FS2_Open won't work for them.


And as Taylor hinted at we have much more chance of attracting a graphics programmer if we support D3D and OpenGL than if we only support OpenGL.

[Turambar]

What does -spec_exp, -spec_tube, -spec_point and -spec_static ?

-spec_tube applies to tube lights, basically just beams (but I'm going to try and make warp effects use it too, for the coolness factor).  The RGB values for the specular of that light are multiplied by this value.  The default value is 1.0.

-spec_point is just like -spec_tube, except that it applies to point lights (weapons fire, explosions, warp effect, etc.).  The default value is also 1.0.
 

when you add in warp effects as tube, do you think you might be able to set engines as point glows?

one thing that always bugged me was that the engines were so bright, yet they cast no light on anything else, not even the ship theyre attatched to.

[taylor]

when you add in warp effects as tube, do you think you might be able to set engines as point glows?

Nope.  The reason is that we only have so many lights to work with (eight) per rendering pass.  If you had 8 engines then it would take two passes just to render them (since light from the sun always gets rendered first), and then you have light from explosions, weapons, warp effects, etc.  We don't really get the ability to use baked on lights like other games do, since all of our lighting is dynamic.

The only way that we would do this is if it's via a light map, where the lights are rendered to a texture and then we just use that texture.  I suppose it would be possible to have a pre-rendered map, and some extra POF data, which would let you use an included light map and still have it turn on or off based on the engine state.  That is all more of Bobboau's department though, he's the graphics expert.

[Bobboau]

that's the sort of efec I wanted that material system for.