posted 02-15- 04:31 AM               

since I just linked the interview on the patch at our world-at-war.com site (for those who didn't read it yet, go to http://www.world-at-war.com/interviews/sdoepatch/index.shtml ), I'd like to ask you a question about the new renderer used in the OPS 2000 screenshots.

I am getting into OpenGL myself, yet I cannot quite get the hang of the nice specular lighting that you show in your screens. Do you use the usual OpenGL specular lighting method, or do you employ light maps and such? Could you tell me approximately what numerical values you use for light and material specular, ambient and diffuse components?

I'd be very grateful for your advice,

-Gecko =FC=

posted 02-15- 08:36 AM               

What you need to do is implement the seperate specular colour extension, fortunitely its an easy one, no getting function pointers, just a couple of new enums. Just use this

code:

---

#define    LIGHT_MODEL_COLOR_CONTROL_EXT 0x81F8
#define    SINGLE_COLOR_EXT             0x81F9
#define    SEPARATE_SPECULAR_COLOR_EXT  0x81FA

---

and then use it like

code:

---

glLightModeli(LIGHT_MODEL_COLOR_CONTROL_EXT, SEPARATE_SPECULAR_COLOR_EXT);

---

As for values, there is a document somewhere that lists good values for specular, emissive etc for different materials. Sorry I can't remeber where I saw it

Easy eh

------------------

Wings with Wires

[This message has been edited by Bryan Russell (edited 02-15-2001).]

[This message has been edited by Bryan Russell (edited 02-15-2001).]

posted 02-15- 09:16 AM               

Thank you very much for your reply, that was exactly what I needed! I don't think I would have ever figured that one out (I wouldn't even know where to look for this!).

Is there any site where one could learn more about these extensions?

posted 02-15- 12:06 PM               

One thing that interests we is whether this sort of spectacular lighting can distinguish between the reflective properties of different surfaces. Obviously looking at the P-47D in the screenshots the degree of reflected light is the same for the polished metal as it is for the olive drab anti-glare panel. Now different surface have differing reflective properties and will not look, for want of a better expression, equally shiny.

CFS2 (using D3D) manages to find a very nice balance and does seem to distinguish between surfaces. For instance the aircraft and buildings look to have a satin or matt finish whilst the cockpit canopies are highly reflective.

If it is not possible to vary the reflective properties of differing materials / surfaces, is it possible to vary the overall reflectivity of all surfaces. What I am getting at is whether a compromise level of reflection can be reached.

I'd be interested in your views.

posted 02-15- 03:04 PM               

Thanks again, Bryan!

-Gecko

posted 02-15- 05:21 PM               

Yardstick:

D3D or OpenGL really make no difference, they are (supposed to be) just low level API's in the hardware.

Its possible to have every poly with a different level of "shinyness" (its more than just shinyness but that will do as the term ), in fact I'm not sure but it could probably be done at the vertex level, and it would be easy to make some areas shiny and others dull. For somethings its a fixed quantity, for example, tires will always look like rubber, and glass will always be glass, etc etc.

For painted areas its a little trickier. For a non-modifiable game, the artist can just make shiny bits shiny and dull bits dull, and when the texture is applied to all looks great.

For a open format like SDOE or CFS2, this is a problem, unless you have an interface for the artist to specify what was shiney and what wasn't.

The other alternative is just to make a compromise on the painted bits, which I guess is what CFS2 and others have done. IMO it can't be made to look as good, but thats what a compromise is really

In the P47 shots I had, I wasn't even thinking about varing the shinyness, I was just getting the stuff to work. It looks kinda funny when in game to see a very shiny terrain reflecting back at you while you fly around

One of the things we were considering were extra poly flags to specify visual material properties, rather than the physical material proerties that are there now. One of the possibilities was to have a seperate "shiny map" which wouldn't effect online matching, but would allow someone to specify the right "shiny" properties to match a particular skin.

This is all just off the top of the head stuff, we haven't really thought about this in much depth yet.

Bryan

posted 02-15- 10:47 PM               

All these chickens look the same to me

At least I got the 'G' right.

posted 02-15- 11:24 PM               

I'm going to upgrade in a few weeks and I have been leaning towards the GeForce but the screen shots in General showing SDOE in D3D are pretty ugly. If the future of SDOE is not Glide it will make my decision easier. SDOE is about all I have time for at the moment but I have to think about the future too.

posted 02-16- 03:02 AM               

quote:

---

Originally posted by Bryan Russell:
sorry I mean Gecko.

All these chickens look the same to me

At least I got the 'G' right.

---

Hey, I was the first one to misspell your first name, so I guess we're even then .

posted 02-16- 03:11 AM               

Hopefully that work will include fixes to the defects that D3D has.

I would also like to see the glide res fixed, I think it was in a beta patch.

We should really bring this up in the patch forum.

posted 02-16- 07:27 AM               

Excluding FSAA and not talking about framerates, there is no reason that D3D would look any better than glide or OpenGl or the other way around.

The main D3D graphical hitches in SDOE are Z-buffer artifacts, which are pretty much a constant curse with a 16bit Z-buffer with any sort of decent view distance. There are several ways to help, one is the W buffer, which is supported by Glide, D3D and OpenGL, and another is clipping bands, which as a technique is API independant.

SDOE uses clipping bands in both D3D and Glide. My guess is that they are broke in SDOE'e D3D implementation. I can't say for certain, but thats my guess.

The shot of the Albatross over the airfield in the patch announcement topic is openGL running 24bit Z-buffer and 32 bit Colour. With a Z range of around 16M as opposed to 65,000 or so, its the brute force approach to fixing it

The long and the short of it is that if SDOE were to never change, and it is all you play, you are probably better off staying with Glide. It seems to be the renderer given the most attention in SDOE, like alot of games of that era, or at least the era of the original release date

At the end of the day, it is going to be much better to concentrate on one renderer and get it right, rather than try and maintain two or even three. becuase of the Propriatary nature of Glide, I would have to say that any major work put into the SDOE renderer would not be directed at the Glide engine. Any project that we where to put out in the future would probably have no support for glide.

That isn't to say that simpler things like the Glide resolution can't be fixed up (BTW the resolutions are currently hardcoded, not read from the card)

All IMO of course

The reason I did the new prototype render in OpenGL was becuase the current SDOE G3 graphics engine mimics OpenGL quite alot, so it was very easy (to a point!) to do a one for one API match in alot of cases. Of course not every G3 inplmentation does what you think it should! I've worked with D3D more before that so it wasn't really a case of liking one APi or the other...