[Scuddie]

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]

[Taristin]

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.

[quadrophoeniX]

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....)

[Goober5000]

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.

[Herra Tohtori]

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:



 

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. 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...

[taylor]

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.

[Scuddie]

-ambient_factor 7 -spec_exp 7.0 -spec_tube 5.0 -spec_point 5.6 -spec_static 9.8

-no_emissive_light

And oddly enough, after applying these settings, my framerate went up.

[Huggybaby]

Maybe because they cause less drawing than the defaults?

[MetalDestroyer]

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 ?

[taylor]

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.

[Bobboau]

-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.

[taylor]

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.

[neoterran]

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 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. 

[ShivanSpS]

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ñ

[MetalDestroyer]

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

[Scuddie]

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 .

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?

[ARSPR]

I've just copied Taylor's info about -ogl_spec and -no_emissive_light to Wiki. Please check it (I'm no expert and no native English speaker)

[Scuddie]

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.

[karajorma]

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 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. 

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.

[Col. Fishguts]

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' ?