[Bobboau]

http://66.70.170.53/Ryan/nrmphoto/nrmphoto.html

I think that normal map generation method just screams "do this in a 3d package"

[Kazan]

coo

[Omniscaper]

You'd like this too, if you want CG sources for your normal maps...:

http://members.shaw.ca/jimht03/normal.html

[FireCrack]

I've seen that article before, nce one eh?

I thaught it was posted here originaly, mabye not.


I'm not entirely font of the method in the link omni posted, btter to use ATI's normal map generation utility or nVidias "Melody".

[Grug]

Kewl.

So when is Bump mapping due?

Next week yeah?

[Bobboau]

actualy, I am right now working on some of the extreem early requierments for the system that will allow it, there are a number of features we need internaly before the enigne is ready for it, wich means I need to reorganise how the high level graphics interface does a few things, the whole way we draw ships for example is little more than one giant hack, I need to seperate it out so that all the rendering passes are called from outside the api, in order to do this I have to make the external (to the APIs) code aware of the fact that there are multable texture stages, then I have to build an external state block system, then I have to implement a material system useing the state block system, then I have to make that into a table, then I have to integrate Cg, then I have to get a vertex shader system, then add that to the afore mentioned material system, then I have to workout any incompatabilities between them, then I have to add a pixel shader system, add it to the table, work out conflicts between the three, then I have to start seriously writeing shaders, first step would probly be getting a perpixel specular lighting model, then I can get started on more advanced features like bump mapping or paralax mapping or the two of them /*drools*/

and I have to coordinate all of this with someone working on the OGL side.

so it'll be the end of summer at the very earliest.
if you people want it faster, start paying me if I see a stedy supply of`$250 a week you can bet your ass I'll be on it every moment I'm not doing homework, sleeping, or eating, actualy, I'll probly still be doing it while I eat, and I have been to known to have dreams about codeing, and I never do my homework anyway.

[FireCrack]

End of sumer is much earlier than i could expect.

So i guess the current rendering engine is ****e? how exactly dows it work ATM?

[Grug]

lol.
I only know what half of that meant and I'm scared. Most of it would be pretty straight forward logical stuff.
But damn that's a truckload of coding.

Here I am fretting over a simple catalogue program.
How I hate the troubles of recursing methods... waa.

Mind you, a better understanding of how tree search and store design works would probably help me. Sigh.

Meh.

Good luck. Maybe I'll buy you some handwarmers or anti-sweat gloves. Maybe the whole SCP team.

[DaBrain]

This might be the Myrmidon bumpmap.
... I think it did everything according to he instructions...



Looks weird.

[Carl]

errr, DaBrain, it only works on real objects, because you can't shine a flashlight on a texture map.

[DaBrain]

Hehe, why not?

I'll kust have to redraw everything before I do so.

I just tested the bump map. It works pretty well for a cheap attempt.

This is rather intersting. I'll just re-draw all higher than zero orbjects, like plates and use a diffuse light source to bring in the shadows.

BTW the posted map has an error. I've just fixed it.

Edit:
Fixed.


I had to downzise and heavily compress it. It got too big.

Edit2: See for yourself. I think it more work intensive than this, but I think it can do it.




Edit: There is an easy way to see if you map works. Just test it and if you can see the light is moving around, it's working.

If it just switches between bright and dark your map is not working.

This is the preview of the standard myrm map. I can't see the light moving around the object...

[Kai]

wow! thats exactly what im waiting for;)

[Admiral Nelson]

Bob, is there any benefit to moving to DX9 during this process?

[Fineus]

Originally posted by Admiral Nelson
Bob, is there any benefit to moving to DX9 during this process?

Yeah, we can boast that FS2 now has a DX9 capable engine

[Bobboau]

yeah we can drop suport for a whole bunch of people still useing windows 9x.

[DaBrain]

They can still use OpenGL.

Will the OpenGL part keep up with the development?


Edit: Timewarp. Bob posted before me.

[WMCoolmon]

And people who like their Antialiasing.

[Gregster2k]

Well once the DirectX 8 rendering is done for the SCP, separate the renderer into two like Half-Life 2 did.

Half-Life 2 has practically three separate entire engines for DirectX 7, 8 and 9 respectively, and autoconfigures itself for the highest available one supported by the end-user's video configuration.

Once the DirectX 8 FSOpen Engine is "reasonably done" for all those without DX9, make FSOpen have a setting for DirectX 8 or 9 in the Launcher, separate from the OpenGL/Direct3D setting. When the user selects DX9, it renders using a completely different code base (a la Half-Life 2) so that future changes to the SCP to get DX9 bumpmapping features and stuff won't affect DX8 users negatively.

This would prevent removal of support for the 9x users, and you'd still be able to make updates to the DirectX 8 code in FSOpen if more bugs in it are found, without affecting the new DirectX 9 stuff.

Of course, you'd have to be careful that global bugfixes like interface changes and stuff are either separately designed around each DirectX format, or globally designed to be compatible with both so that fixing bugs in global things like the HUD and interface wouldn't break one or the other DirectX mode...

...but in the end, doing what I'm suggesting (modeling how to handle the switch after what Valve did with Half-Life 2's engine) would be a happier ending for everybody.

[Fineus]

Would I be right in thinking that by separating it into three separate rendering engines, you're creating three times as much work as you had before?

[WMCoolmon]

Originally posted by Gregster2k
...but in the end, doing what I'm suggesting (modeling how to handle the switch after what Valve did with Half-Life 2's engine) would be a happier ending for everybody.

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.