[Flaser]

Moreover all recent builds seem to do better on OGL performance wise.
I good OGL overhaul (env-map transplantation, ect.) is good idea IMHO.

[Falcon]

I thought DirectX 8 did support bump mapping?

[aldo_14]

Originally posted by WMCoolmon


Sounds icky to me. We'd have OGL, DX9, and DX8.

But then, I think we already did something like that in the early days of the SCP.

It mostly depends what it involves. Everything in FS2Open is abstracted below a line, so instead of calling "DrawPrimitive" or "glBegin(GL_LINES)/glVertex" you just call "gr_line" and that handles everything. So if there are significant changes between the DX9 and DX8 API, those wouldn't be much of a problem. But if we're talking adding new effects, that could make the parts of the code that use those new effects messier, because they'd have to check that the current mode supported it.

HL2 has the advantage that it only has one general API set to worry about, DirectX, so they can directly call all the functions and use different rendering paths by directly calling DX functions. They didn't have to worry about abstracting between two different APIs.

It'd be best to upgrade OGL rather than keep Dx8 around, IMHO. FS2 could dominate in the Linux games department. There's simply nothing that compares.

Is there a reason for having seperate DX and OGL based engines?  Or is it simply because of the old codebase (that was what, Glide, Software and DX5?) was divided up in a similar way? (NB:  isn't Glide a subset or precursor of OpenGL?... I thought I read something along those lines, anyways)

[kasperl]

Well, if you don't abstract the engines somewhere, all of the highlevel graphics calls would look like
if(API==OGL)
{
  OGL stuff;
}
elseif(API=DX8)
{
 D3D stuff
}

It's a lot easier to do simply say "draw a line" then to say "if you have a pencil then sharpen it, and draw a line using a ruler, or if you have a pen, take a ruler with an ink-edge, and draw a line".


At least, that was what my C++ book thought me about abstraction.

[Grug]

Does FS2 have a class diagram?

[Bobboau]

not realy, but if it did it would look sort of like one of those pictures of the internet. FS2 was made in little more than normal old C, it doesn't realy use classes exept for a few places though some of the newwer code has been more oo.

[Bobboau]

I'm not 100% sure, but I think I can get away with not needing DX9 for the shader system I want, I'm going to use Cg and it is API independent, and I think compatable with DX8.

[aldo_14]

Originally posted by kasperl
Well, if you don't abstract the engines somewhere, all of the highlevel graphics calls would look like
if(API==OGL)
{
  OGL stuff;
}
elseif(API=DX8)
{
 D3D stuff
}

It's a lot easier to do simply say "draw a line" then to say "if you have a pencil then sharpen it, and draw a line using a ruler, or if you have a pen, take a ruler with an ink-edge, and draw a line".


At least, that was what my C++ book thought me about abstraction.

Problem comes if you have one feature that can use another in some way, I guess.   That's a general way... Obvious problem is that you have a sudden mass of  code jumping up, and at some point you need to go back and check you've got all the switches in the right place.  And if you add another rendering method, then you may need to add new switches all over again....

I think a better way is to use subclassing / interface implementation to hide the details altogether, but I'm not sure how amenable the current FS2 structure is to that.

(i.e. pass in some object/s representing the draw methods; this object conforms to an interface defining render calls, but the specific method is hidden to the callee)

i.e. (pseudo-java)

Code: [Select]


public Renderer r;

public void setRenderer(Renderer r) {
  this.r=r;
}

public void draw(Stuff)  {
  r.draw(stuff);
  //where Renderer is an interface defining the  method draw(stuff)
}


and you'd have something like

Code: [Select]


if(Api.equals(OPEN_GL)  {
   fs.setRenderer(new OpenGLRenderer());
}
else if(Api.equals(DIRECTX8){
   fs.setRenderer(new DX8Renderer());
}
else if(Api.equals(DIRECTX9){
   fs.setRenderer(new DX9Renderer());
}


...of course, you'd need your interface class to define the methods for all renderers, and probably provide a default abstract class that defined the 'null' behaviour; i.e. what to do if the Renderer object doesn't provide that functionality (the Renderer extending the abstract class and subclassing the methods it does provide)

Don't think you can do this for FS2, though; IIRC it's pretty 'flat'.

[Bobboau]

FS has a structure with a bunch of funtion pointers, FE2 though uses the interface method you mention.

[DaBrain]

I think we'll have to move on to DX9 anyway...

[Carl]

Originally posted by DaBrain
Hehe, why not?

because a computer application will look at the light and dark values for the hightmap, so when you use a 3D light source on a bump map, it'll see the brighter parts of the map as higher and the darker parts lower. therefore, using that process on a texture map instead of on an actual object will do absolutley nothing but make it silly colors.

[DaBrain]

That's the reason I took the Myrmidon map.

It's my version of the map. I've added some nice shadings to simulate higher and lower parts.

Of course it won't work this way.
You'll have to redraw high parts like I said before.

But the method I used will work for some tilemaps.
Tilemaps that are 'flat'. So method is just used to add some structure on the model.

Edit: I just ran another test.
It works exactly like I guessed.

This is a part of the Myrmidon maop, or well the bumpmapped part of it.





I just redraw them with white, added some shading to the lower areas and used the same method as before (but this time a diffuse light!).
Then I just added the new layer with the shaded stuff on it as blue channel in the normal map.
I think the shading is too smooth, but I can do it better next time.

Doing this to all textures will be much work. Much more work than the shinemap stuff...

But I think I can get some so-so bumpmaps of my maps if I just place my 'lines' layer in the normal maps blue channel

[Deepblue]

Get a render of those maps on the myrmidon model...

[DaBrain]

Which 3D render software allowes the use of normal maps?

AFIAK 3DS supports only greyscale informations.

[Flipside]

Well, what I do is turn the bump map into a 3d model with about 1/2 million polies upwards. and then normals/shadow maps etc can all be generated from that

[DaBrain]

You'd have to redo the UV mapping that way, right?

[Flipside]

Nope, it's the actual UV map I convert.

Normal mapping assumes that the light is coming from 'above' no matter where on the model you are looking, so as far as I can see, it has to be done on the UV Map.

I use a landscape program which can convert grey images into height maps, and then export that heght map as a DXF. What you end up with is a ultra-high poly model of your UV Bump map. Lightwave will let you generate the normals for that (or would, if I could figure out how to stop it crashing) as can 3DS Max.

It's also good for surface baking, as you can add 'fake' bumps, simply by adding the colour UV map to the model and baking the whole lot into a final texture, so all your shadows are cast by physical bumps on the UV, not by a computed bump-map Down-side to that is that shadows made that way don't move.

[Deepblue]

FYI Max does normal maps.

[DaBrain]

Ok, as I don't have the time to rework the whole map right now, here is a render of a box with the alread done part.
(Two light postions.)

I think that's enough to show it's working.

[Carl]

Originally posted by Flipside
Well, what I do is turn the bump map into a 3d model with about 1/2 million polies upwards. and then normals/shadow maps etc can all be generated from that

is the bump map use use the original texture map? because if it is, then that's like printing out a word document, then scanning it with a scanner, then saving the file as a .bmp file. It's completely uncessesary and won't do any good.