Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Scuddie on December 18, 2006, 04:47:17 pm
-
OK, so I've always been trying to get those awesome looking graphics shown in screen shots, and I've always been trying to do it in OpenGL... However, as I have found out, it's much easier to get the kind of image quality from D3D, and unfortunately it mat very well be abandoned? That somewhat upsets me, but I can live with it. See attached below why I enjoy D3D (left) over OpenGL (right). Yeah, it's a ****ty example, but I dont take the best screen shots.
Secondly, does ambient_factor not work inside 500-600km of player view? With it set to 30, the transition isnt so bad, but when it's set to 0, distant models are nearly invisible as I approach them, but once they come within ~500km, it's as if they appear out of nowhere. It's much more apparent in D3D than it is in OpenGL though. I dont know if this is an LOD thing or what, but I'm quite curious about it.
Also, as for the D3D font distortion, is there any reason that problem is still there, since it's been known of for a damn long time?
C:\Games\FreeSpace2\fs2_open_3_6_9-7dot9x.exe -mod mediavps -spec -glow -env -jpgtga -mipmap -nomotiondebris -2d_poof -missile_lighting -dualscanlines -targetinfo -rearm_timer -ship_choice_3d -3dwarp -warp_flash -snd_preload -alpha_env -fps -ambient_factor 30
[attachment deleted by admin]
-
The D3D version uses the shinemap as the actual texture, though. And it's showing very strongly in that image. The OGl one is how it's supposed to look.
-
I am with Scuddie here. i also prefer DirectX over OGL - somehow the shadows are "harder" (contrast is higher or how you want to put it) in one word "more spacy" I messed around with the command parameters and ended up with this:
-ambient_factor 7 -spec_exp 7.0 -spec_tube 5.0 -spec_point 5.6 -spec_static 9.8
might well be that some of those parameters are out of the range, dunno, but I stopped altering when i felt the looks were ok.
BTW, is there a reason that Bobs DirectX code has not been included into the latest releases (at least the CVS builds) yet? I didn't experience any problems when testing some missions, and I feel it's better to have something that may have some glitches than nothing, but thats just my humble feeling.
(same goes for the long abandoned shadow code but, Alas, this is what seems to happen....)
-
No DirectX programmers equals no DirectX report. We need someone who is willing and motivated to sit down and study the code for bugs.
Bobboau is great for producing prototypes, but he doesn't have the best bugfixing (or clean code design) record. :)
-
Well.
DirectX is *screwed* on my install/computer/build/config. I don't even want to try in-game when the Tech Room looks like this:
(http://img86.imageshack.us/img86/7742/fs2d3dwtfsj7.th.jpg) (http://img86.imageshack.us/my.php?image=fs2d3dwtfsj7.jpg)
:nervous:
That's eith D3D8, 32-bit, 1280x1024, multisampling set to 4 samples.
All textures don't show like this, however. When I first get into the Tech Room, the first craft in the list (usually Ulysses, this time it's the Apollo since I've got INF:A mod enabled) is shown as white model, but when I pick another craft it throws the texure - or a part of it - onto the background, covers the interface except the text, and shows that model as white. Some textures only show what is apparently a tile of texture. The Orion looks like that, for example.
...On the other hand, I'll see how it looks like in the game itself. :drevil: Might be amusing.
EDIT: It seems that this is specific to Inferno: Alliance. Without it loaded, it seems to work way better. Although it's still frakked to kingdom come, some textures show as white boxes etc etc. The lighting doesn't work as it's supposed to. PErhaps we should have a competition. Who can find the goofiest D3D error in current builds... :lol:
-
As I seem to keep having to explain to people, you can't compare D3D to OGL in the current (or past) code and have it be a true visual comparison. The OGL code has leap-frogged the D3D code in both features and capabilities. D3D simply won't show the same detail levels that OGL will, because the D3D code hasn't yet been fixed to handle all of it. Until the code is actually feature compatible between OGL and D3D, a visual test doesn't mean ****.
Driver settings can also have a rather large impact on visual (lighting/texturing) quality since, by default, some video drivers are optimized more for performance than for look. I'm not really sure at what level said driver setting for OGL will match D3D, but checking your driver settings and playing around with the quality/performance slider for the OGL settings can have a substantial affect on visual quality in OGL games.
Secondly, does ambient_factor not work inside 500-600km of player view? With it set to 30, the transition isnt so bad, but when it's set to 0, distant models are nearly invisible as I approach them, but once they come within ~500km, it's as if they appear out of nowhere. It's much more apparent in D3D than it is in OpenGL though. I dont know if this is an LOD thing or what, but I'm quite curious about it.
-ambient_factor is an overall setting, and doesn't really depend on the distance of anything. What you are probably seeing the the effect of spec maps, which are only used on the first 1-2 LODs. When specmaps are rendered on a model then the lighting changes and you can sometimes see it pop into view. The OGL code was modified to help prevent this, partly because of the use of emissive light (mentioned later) and partly just because the lighting code was simply modifed to work and look better. The D3D code has never gotten any such work.
Also, as for the D3D font distortion, is there any reason that problem is still there, since it's been known of for a damn long time?
I managed to greatly reduce font issues in the OGL code, but that doesn't help D3D at all. Perhaps a D3D coder will come along and fix up that part of the D3D code to work better as well. Regardless, there is new font code coming the first half of next year which will give full TrueType font support, and that will have font quality immensely. That TTF support will initially be for OGL only obviously, with no one to code in support for the new code for D3D, it simply won't show anything.
Unless a D3D coder shows up by the end of next year you can pretty much assume that all D3D support will officially vanish. It is already going to be disabled by default in builds starting next month. Only builds which have D3D support compiled in specifically will be able to make use of it. D3D doesn't support properly support alpha textures yet (for effects or alpha specmaps), doesn't support mipmaps properly yet, doesn't support using pre-generated envmaps yet, won't support shaders when that hits in the near future, won't support normal maps when they hit in the near future, won't support the new font rendering code, and won't work with newer particle and bmpman code either. And it's unlikely that the D3D code will even be able to compile in a few months simply because all of the coder support is behind OGL (plus, I can't even use D3D since I use Linux & Mac).
... somehow the shadows are "harder" (contrast is higher or how you want to put it) in one word "more spacy"...
OpenGL uses emissive light to make it easier to see things overall (as was dictated by the various testers of the, at the time, new OpenGL lighting code). You will never really get a full transition from light to dark so long as it's enabled. Turn it off with -no_emissive_light and see if that appeals to you better.
-
-ambient_factor 7 -spec_exp 7.0 -spec_tube 5.0 -spec_point 5.6 -spec_static 9.8
:yes:
-no_emissive_light
:yes:
And oddly enough, after applying these settings, my framerate went up.
-
Maybe because they cause less drawing than the defaults?
-
I messed around with the command parameters and ended up with this:
-ambient_factor 7 -spec_exp 7.0 -spec_tube 5.0 -spec_point 5.6 -spec_static 9.8
...
Wow, how can you play with this -ambient_factor value >_< I generally put -ambient_factor 105 (or something near to 75 - 100) but never under 60 unless if I put the in-game gamma to the maximum value.
What does -spec_exp, -spec_tube, -spec_point and -spec_static ?
-
What does -spec_exp, -spec_tube, -spec_point and -spec_static ?
-spec_exp does nothing for the most part. It only applies to non-HTL mode, which pretty much no one uses. The default value is 16.0.
-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.
-spec_static is just like tube and point, but applies to static lights (suns, techroom, etc.). Like the other two, the default value is 1.0.
So, for -spec_tube, -spec_point and -spec_static, values less than 1.0 will reduce the amount of specular from that light and values greater than 1.0 will increase the amount of specular from that light. And note that all of this only applies to the specular portion of the lights, not the overall light brightness. Also take note of the fact that nowhere is the current code does the RGB values for specular on point or tube lights get set. And the default value is 0, which means that currently, neither -spec_point nor -spec_tube actually do anything. :) However, -spec_static does have a default value of 1.0, so of all of the options it's the only one which actually makes a difference in the game.
Personally, I use a -spec_static value of 1.5, -no_emissive_light, and an -ogl_spec value of 60. I tend not to change the default ambient light setting though, that all depends on the particular mod. The -ogl_spec value changes the basic shininess of the specular light in OpenGL. A lower value reduces the overall intensity of the light making it broader and less powerful. A higher value makes it more focued and brighter. The default value is 80, and the usable range is 0 to 128 (clamped). The original default value was 60, which is why I still use that, but many people seemed to think that 80 or so was more "D3D" of it.
-
-spec_exp is supposed to be the specular exponent, it defines how hard the specular highlights are, I thought it was used, it was at one point in D3D.
I find it hard to motivate myself to fix D3D when it will quite posably be removed soon.
-
I find it hard to motivate myself to fix D3D when it will quite posably be removed soon.
The only reason that we're thinking about removing it is because no one will fix it! Go ahead and fix it and then the discussion is moot. Don't fix it and we have no choice but to remove support for it. It's as simple as that. :)
I've held off on a whole lot of code this past year simply because it would have broken D3D and no one was there to fix it. I'm not holding back post-3.6.9 though, so it is going to completely break in a couple of months, unless it gets some serious coder lovin' really soon.
-
Don't hold off.
Break d3d, because you have done wonders for this game, and you're the only person with time and energy that still wants to work ALOT to improve it. While you're still willing to do that I think it's obvious Open GL should become the way, and if some D3D guru with a ton of time and no wife and kids (and probably no social life) comes along later, then D3D can get re-enabled. :nod:
-
I greatly recomend to just break D3D, and focus on OGL, them in 1 or 2 years from now and ifa coder apear, you can simplty start which DX10... but remember is not the same thing that previusly, is a new API, so I not suse on how much a actual D3D coder can help which DX10ñ
-
Thank you for the details :D
But what difference between Ambient_factor and ogl_spec ??
-
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 :p.
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 alot larger, but also alot less evident?
-
I've just copied Taylor's info about -ogl_spec and -no_emissive_light to Wiki. Please check it (http://www.hard-light.net/wiki/index.php/Command-Line_Reference#Graphics) (I'm no expert and no native English speaker)
-
Your english is fine ;)
BTW, if or when someone revises it, please add that low values (starting somewhere between 5 and 10) cause artifacts. I'd do it myself, but I'm not the best with wording.
-
Break d3d, because you have done wonders for this game, and you're the only person with time and energy that still wants to work ALOT to improve it. While you're still willing to do that I think it's obvious Open GL should become the way, and if some D3D guru with a ton of time and no wife and kids (and probably no social life) comes along later, then D3D can get re-enabled. :nod:
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.
-
Personally, I use a -spec_static value of 1.5, -no_emissive_light, and an -ogl_spec value of 60. I tend not to change the default ambient light setting though, that all depends on the particular mod.
What's the difference between '-no_emissive_light' and '-ambient_factor 0' ?
-
Thank you for the details :D
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 :p.
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 alot larger, but also alot 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.
-
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.
-
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.
-
It was previously called Windows Graphics Foundation 1.0
-
Thanks again. Now, I have to play with command line value >_<
-
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 ?
-
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.
-
Ah, I see. Thanks for the clarification.
-
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 :yes:. (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.
-
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. :)
-
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.
-
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.
-
Nvidia cards are generally far better at openGL than their counterpart ATi cards.
-
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.
-
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 :rolleyes: :confused: :shaking: :nervous: :eek2: :mad2: :mad: :hopping: :no:
-
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 ;)
-
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.
-
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.
-
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.
-
that's the sort of efec I wanted that material system for.
-
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.
Self illumination is sorta possible with glowmaps - you draw the light/shadows cast by the engine into them.
As for light sources: I think we could differentiate the issue, for example allowing destroyers and above to have a single engine "light" attached to them. The code could also optimize by valuing lightsources, only drawing the most visible ones (render gurus should be consulted how such a thing could be effectivly calculated).
-
yeah, it was just wishful thinking, hoping that maybe when fighters flew past a capship, they'd cast some engine light onto it, considering the bright blue glowyness.
self illuminating engine glowmaps could be a fun side project from BTRL, but i have a feeling i wont pursue it very soon, considering my other side projects