PDA

View Full Version : Doom 3 preview



ffish
11-03-2002, 05:35 PM
Hey all,

Long time no post http://www.opengl.org/discussion_boards/ubb/wink.gif

Just thought you'd be interested in a recent Slashdot post on a leaked Doom 3 alpha version. I guess it'll be all over the net soon but you'll find it for now via http://www.slashdot.org in the recent stories.

Bye

ffish
11-03-2002, 05:59 PM
Oh, BTW, I realize that it's illegal/immoral etc to download the alpha. I'm not condoning it, and I haven't downloaded it myself (I run a Sun workstation at the moment so I couldn't run it anyway). Just thought that some of you might be interested in quietly having a look at the technology "live".

IMHO the alpha won't do anything to hurt Id anyway, probably the opposite - free advertising - since the general consensus seems to be (in non-technical terms) it rocks.

jubei_GL
11-03-2002, 06:49 PM
ehh what is all this BUZZ about ILLEGAL crap .. I bet guys at ID are happy that this leak generates SO MUCH FREE BUZZ for them .. Hell they have nothing to be ashamed of, this LEAK ROCKs .. REALLY STUNNING work.......

I had leaked UT2k3 before, and I bought Retail version of UT2k3 when it came out. I saw leaked Doom3, and I will buy it when it comes out too .... So there FREE PRESS did not hurt anyone ..

and if ID would be MAD at someone about the leak, they should be more careful to whom they give their software to (the hero Jackass that leaked it on the net)...... They can't expect DOOM STARVED gamers to hold themselves from downloading early showing, months before final version will see the light .......

I say LET IT LEAK !!!!!!

B_old
11-03-2002, 09:42 PM
Hello.
This is new and interesting to me.
I only run a GeForce2 though so it won't really be so funny on my system I guess.

What is the alpha like? Do you get to play some 'real' levels, ready with scripts and all? In that case you would kind of spoil the shocking-effect for the retail, wouldn't you?

Anyway I think id-software does not need any bigger buzz about their product. It probably is at it's highest now, don't you think?
I'm currently sitting here and wonder what a REAL id fan would do. Eagerly grasp the unfinished work or patiently wait for Carmack and his friends to finish another piece of perfect art. http://www.opengl.org/discussion_boards/ubb/smile.gif
I think I go waiting anyway and drool over some screens.

I will defintitely get the retail, though, and most probably do some hardware shopping the same day.

Thanks for the info ffish.


[This message has been edited by B_old (edited 11-03-2002).]

davepermen
11-04-2002, 01:57 AM
it's essentially the e3 demonstration.. i have just no clue how they got it working that fast on the e3.. i bet it was a video http://www.opengl.org/discussion_boards/ubb/biggrin.gif doesn't work smooth on any gpu i've seen (thought, my radeon9700 has some weird hw settings currently.. you know, i can run it at 2 fps, both on 400x300 and on 1280x1024.. so it's the cpu.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif)

well. i'll buy doom3.. i haven't ut2003 (i don't like it..)..

it looks much bether than the pictures i've seen somehow. i'm impressed. id, good job http://www.opengl.org/discussion_boards/ubb/biggrin.gif now just get it fast http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Ventura
11-04-2002, 02:03 AM
I managed to 'find' the doom3 demo. Its basically what was shown at e3, there are 3 small levels but it chugs like a goodun on my ath xp1900 with a gf3. at 640x480 it can run at a steady-ish 20fps but when you start shooting the monsters it can drop to less than 1fps. all Textures seem to be at least 1/2 res too.
Like carmack has just said, you cant judge the actual game on this, but i cant see what drastic steps he's going to be able to take for this game to be playable and enjoyable on anything less than a radeon 9700 http://www.opengl.org/discussion_boards/ubb/frown.gif

davepermen
11-04-2002, 05:07 AM
Originally posted by Ventura:
Like carmack has just said, you cant judge the actual game on this, but i cant see what drastic steps he's going to be able to take for this game to be playable and enjoyable on anything less than a radeon 9700 http://www.opengl.org/discussion_boards/ubb/frown.gif

less then 9700? *cough* *cough* i have two fps *cough* on my 9700.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

okay, if i disable shadows its fast. and it's not a fillrate issue. i'll check my pc with my friend next weekend to find out what buggers him.. poor pc http://www.opengl.org/discussion_boards/ubb/biggrin.gif

B_old
11-04-2002, 05:45 AM
But then again, what do you expect?
I know from a friend that late Quake 3-engine powered games won't run super-fluid on a XP1600+ & GeForce4 and some insane settings. And Doom 3 really takes it two steps further.
[I have a Athlon 1200 & GeForce2 now and most probably I won't update before Doom 3 is released. I always hated to be anxious about how good certain games will run, and will take no risk for Doom http://www.opengl.org/discussion_boards/ubb/smile.gif]

Mezz
11-04-2002, 06:20 AM
I did acquire the alpha via local contacts http://www.opengl.org/discussion_boards/ubb/wink.gif
It actually runs at a fairly consistent 20fps on my PC but I don't think I've got enough regular RAM for it, or something else is up coz I keep getting 'vertex cache overflow' errors. Really shouldn't discuss this though. But yeah, it looks pretty freakin' good.

-Mezz

SirKnight
11-04-2002, 06:50 AM
You have to remember too that this demo really doesn't have much or any optimizations, it's just to showcase the engine. According to Carmack this demo was also not meant to be played interactivly by people. Around that time (E3) John Carmack said the engine was pretty much complete feature wise, so now it's time for serious optimizations. He has about a year or so of doing that, it will be better. It's been quite a while since E3 so i'm sure doom 3 runs much much faster now. John also said that doom 3 _should_ run on a geforce 3 (with a good cpu of course) at high detail settings at around 30Hz. I'm sure he will live up to that. Assuming the user has at least a 1.5GHz and no less than 512MB of ram of course. http://www.opengl.org/discussion_boards/ubb/smile.gif

It sucks my dial-up is so damn slow. I only have 30MB of the alpha so far. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

-SirKnight

Ventura
11-04-2002, 07:37 AM
the thing that get me is i dont believe you can design a game engine and then throw in any major optimisations later.
I believe carmack is using a beam tree to cut out some of the shadow volume overdraw. then if youve got scissoring too, there arent many major optimisations left that he wouldnt have done in the previous 2 years of development of the engine alone.
So i cant see it getting _much_ faster at all. and you can fun the game as low as 320x200 http://www.opengl.org/discussion_boards/ubb/eek.gif but i guess we'll all have to wait and see.

Licu
11-04-2002, 08:00 AM
It runs at an average of 20 FPS on my system from work (1700+ AMD XP and Gf2 Ti 64 Mb). Whatís worrying me most is the stencil shadow effects on some surfaces like the faces of the characters where you can see sudden dark triangles when the character surfaces modify their orientation relatively to the light. Also, Iíve activated the wireframe and the portals rendering (is there any BSP in the scene?) and many of the surfaces are still visible even though they should be culled by the portals (like the monsters). Still more work at HSR? Anyway, I hope theyíll improve it until the release since there are some visible artifacts at surfaces joints (floating point errors?) and some depth-fighting like problems between surfaces in some places. John was saying that there was a lot of overhead introduced by the shadow volumes (mainly fillrate) but Iíve disabled the shadows and there were no significant change at the FPS. The physics is great but not for the characters. When shooting a dead character the same predefined animation is played. Anyway, a great game and I canít wait until the final release. Btw, how can I change the resolution?

Licu
11-04-2002, 08:02 AM
It runs at an average of 20 FPS on my system from work (1700+ AMD XP and Gf2 Ti 64 Mb). Whatís worrying me most is the stencil shadow effects on some surfaces like the faces of the characters where you can see sudden dark triangles when the character surfaces modify their orientation relatively to the light. Also, Iíve activated the wireframe and the portals rendering (is there any BSP in the scene?) and many of the surfaces are still visible even though they should be culled by the portals (like the monsters). Still more work at HSR? Anyway, I hope theyíll improve it until the release since there are some visible artifacts at surfaces joints (floating point errors?) and some depth-fighting like problems between surfaces in some places. John was saying that there was a lot of overhead introduced by the shadow volumes (mainly fillrate) but Iíve disabled the shadows and there were no significant change at the FPS. The physics is great but not for the characters. When shooting a dead character the same predefined animation is played. Anyway, a great game and I canít wait until the final release. Btw, how can I change the resolution?

Zeno
11-04-2002, 08:31 AM
Dave - there's something wrong with your card or system configuration, else my Geforce3/Athlon 1.3Ghz is about 10x as fast as your 9700. Heck, licu's Geforce2 is faster. I'm guessing you're simply out of memory or have a really low end CPU?

licu - there is a variable in the config file, I believe it's called r_mode, that you can use to adjust the resolution. 3 = 640x480, 4 = 800x600, etc. How do you enable wireframe mode?

[This message has been edited by Zeno (edited 11-04-2002).]

davepermen
11-04-2002, 09:35 AM
Originally posted by Zeno:
Dave - there's something wrong with your card or system configuration, else my Geforce3/Athlon 1.3Ghz is about 10x as fast as your 9700. Heck, licu's Geforce2 is faster. I'm guessing you're simply out of memory or have a really low end CPU?

licu - there is a variable in the config file, I believe it's called r_mode, that you can use to adjust the resolution. 3 = 640x480, 4 = 800x600, etc. How do you enable wireframe mode?

[This message has been edited by Zeno (edited 11-04-2002).]

well.. it runs at the same speed on smallest and on highest res.. so.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif it's _not_ the vpu.. but yes, the cpu has problems with the configuration currently, its a celeron2gig, and it tells me everywhere that it does not find l2 cache (except inteltools can find it http://www.opengl.org/discussion_boards/ubb/biggrin.gif).. and, if it's without, i understand why its slow in the shadowvolume generation code (as else, it is very fast, if i disable the shadows..)..

if i overclock to 2.66giga (runs for half an hour, then its too hot http://www.opengl.org/discussion_boards/ubb/biggrin.gif), i can get 3fps instead of 2.. if i am in an edge of the world, watching the edge (so that nearly everything gets culled and no cpu work has to be done anymore) i get fast fps again..

fillrate is no issue.. there are two problems on my pc: l2 cache bug, and it runs at agp 2x currently as my radeon is one of the first generation, and the mobo (8x agp) is incompatible with it.. i just got it to work (somehow) to run at 2x agp.. now its quite stable.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif (but i need an intel specification following mobo anyways to get my radeon working correctly.. at 8x agp, of course http://www.opengl.org/discussion_boards/ubb/biggrin.gif)

i have 256mb ram.. should be enough..

ToolChest
11-04-2002, 10:26 AM
where are you guys getting the demo?!? I checked out the links on slashdot and they went to shots and cfg hacks... http://www.opengl.org/discussion_boards/ubb/frown.gif Where to?

Thanks...

davepermen
11-04-2002, 10:50 AM
kazaa gets it more and more, others have some ftp connections.. i got it from a friend, over ftp.. i'm sure someone can contact you with some adress (i can't, at work currently..)

zed
11-04-2002, 11:07 AM
256mb ram is not enuf thats your problem davepermen,
ive only got 128mb (and the nearest town with more than 10,000 ppl is 3 hours drive away i can really expand that just yet http://www.opengl.org/discussion_boards/ubb/smile.gif) so im not even gonna try downloading it.
though from the screenshots doom3 definitly is getting better + better with each iteration (though this might be an old demo).
20fps does seem ok (what some ppl are getting i expect theres heaps of room for optimization)
at the same time though the fps is a bit of a killer whats the cause (stencil shadows?? im guessing)
i havent any shadows in my game (i want to add radiosity later) but i have no framerate issues at all (i can throw 20 lights on screen (prolly double what doom3 has) + the fps bearly hiccups (this on my celeron433 + gf2mx200 (which has no fillrate i do limit each mesh to maximum 13passes though otherwise fillrate does kick in))
true my lighting equation is 80% of doom3 (that last 20% takes a LOT more work + i figure 20% better quality for a fifth of the framerate, nah http://www.opengl.org/discussion_boards/ubb/smile.gif)
question for ppl that have done stencil shadows in a real (ie not a demo) application what hit are u taking?

are the stecnil shadows worth it? (personally they dont look to great cause of the low polygonness)

then again the framerate hit might be for the 'extra' lighting equations, physics who the f knows http://www.opengl.org/discussion_boards/ubb/smile.gif

ToolChest
11-04-2002, 12:44 PM
omfg...
http://slashdot.org/comments.pl?sid=44077&cid=4591655

Ya, the screen shots are nice, but Iím so tired of seeing people kiss his *ss... boo hoo... someone stole my demo... someone make a comparison to jesus in here...

I hope none of you subscribe to the Carmack group butt kissing.... http://www.opengl.org/discussion_boards/ubb/rolleyes.gif

Sorry... had to vent....

davepermen
11-04-2002, 12:46 PM
Originally posted by zed:
question for ppl that have done stencil shadows in a real (ie not a demo) application what hit are u taking?

are the stecnil shadows worth it? (personally they dont look to great cause of the low polygonness)

then again the framerate hit might be for the 'extra' lighting equations, physics who the f knows http://www.opengl.org/discussion_boards/ubb/smile.gif

the shadows worth it. doom3 is nothing without the dark deep shadows everywhere.. and you don't really note they are sharp, as there is a lot of smooth dark shading around..

i'm really impressed of it, the game has style. the pictures never really had.

the models don't feel lowres anymore, they feel natural (natural .. zombies.. yeah http://www.opengl.org/discussion_boards/ubb/biggrin.gif).. ut2003 looks like crap somehow against it, just so.. void. doom3 has depth in it, it feels.. somehow.. great job artists, great job carmack, great job all together..

the physics? well, ut has physics. doom3? hm.. those where animations i've seen. but they look, as all does, stylish good. they have stile. the ut ones look more like a rigid body demo of crashtestdummies http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Licu
11-04-2002, 10:30 PM
Someone was asking how to activate the wireframe, just use the function keys: F1 add a light, F2 delete the last light, F3 Ö you can show the portals, show the light-surface interaction, shadow volumes and even the no of polygons drawn. From the drawing of the portals it seems that there is no frustum clipping on portals (maybe there are used for light influences calculus only). Anyway some of the portals have a scissor rectangle around them for clipping. About the z fighting problems I have on the Gf2 system, there are no such artifacts on another Gf4 Ti4200 system Iíve tried it (maybe they are caused by the drivers or the additional rendering passes necessary for the gf2!?) Anyway, 256 megs is not enough, even though I have a Gf4 and fps above 40 sometimes I have song stalls due to swapping on a 256 RAM system on Win 2k.

Licu
11-04-2002, 10:33 PM
Someone was asking how to activate the wireframe, just use the function keys: F1 add a light, F2 delete the last light, F3 Ö you can show the portals, show the light-surface interaction, shadow volumes and even the no of polygons drawn. From the drawing of the portals it seems that there is no frustum clipping on portals (maybe there are used for light influences calculus only). Anyway some of the portals have a scissor rectangle around them for clipping. About the z fighting problems I have on the Gf2 system, there are no such artifacts on another Gf4 Ti4200 system Iíve tried it (maybe they are caused by the drivers or the additional rendering passes necessary for the gf2!?) Anyway, 256 megs is not enough, even though I have a Gf4 and fps above 40 sometimes I have song stalls due to swapping on a 256 RAM system on Win 2k.

5tardust
11-05-2002, 12:23 AM
Well, I tried it.
On my 1Ghz Athlon, 512 Mbyte RAM, with Radeon 9700 PRO, it runs at a steady 25 fps at both 640x480 and 1024x768, so I guess its cpu or memory bound. But it slows down 4-7 fps for each enemy on the screen, and sometimes (scripted scenes) my disk starts swapping like mad. So I guess memory is a big issue.

GPSnoopy
11-05-2002, 12:38 AM
With 768 MB I can just barely avoid swapping...
But my P3-700 (AGP 2X) doesn't seem to keep up.
Although it's funny to see it running at the same speed either at 320*240 or 1024*768, thanks to the good old GeForce 2 Ultra. http://www.opengl.org/discussion_boards/ubb/wink.gif

Hints: enable texture compression, except for bump, glossy and transparent map. It gives a good picture quality without too much performance hit.

Also use "exec runact" to launch the complete non-interactive demo, but before doing so remove the "exec intro, exec activate_demo[1-3]" from runact.cfg, otherwise it'll put everything in memory ( unless you have 1.5GB, avoid doing so). http://www.opengl.org/discussion_boards/ubb/wink.gif

FXO
11-05-2002, 08:14 AM
The demo eats a total of about 950mb memory.
I had to raise my virtual-memory file to 800 or most maps would hang.

The 1-2 fps thing has to do with memory-swapping, as far as I can tell, I got rid of it when I raised the vm.

Disabling sound also has a huge impact on memory-usage (although its a big sacrifice).
/s_noUpdates 1

I also lowered the /r_varmegs to 32 since much of it wasnt used anyway, according to meminfo.

Lowering the colorbits of textures to 16 and enabling compression on all textures helps alot to.

This is just what worked for me, on my: TB@1530 256RAM GF2MX200/190

FXO
11-05-2002, 08:41 AM
Before I get flamed:
I meant to say alpha, not demo http://www.opengl.org/discussion_boards/ubb/smile.gif

edit: forgot about the edit-feature on this site http://www.opengl.org/discussion_boards/ubb/smile.gif
I've gotten used to doom3.dk's forums.

[This message has been edited by FXO (edited 11-05-2002).]

zed
11-05-2002, 09:50 AM
cheers for the info dave,
another question about the shadows http://www.opengl.org/discussion_boards/ubb/smile.gif
does every light generate them?

this would explain the slow down when the user fires a weapon (which in turn creates a couple more lights which in turn create a lot more shadows)

also how many lights are onscreen roughly?

Nutty
11-05-2002, 10:20 AM
No, not all lights are shadow casters, only mainly the big ones, like overhead swinging lights. Subtle little glows dont need to cast shadows.

I think the slow down caused by firing is just because of the unoptimized collisions, and effects system they probably bodged in there, although it would cause more lighting passes on the surfaces.

Tom Nuydens
11-05-2002, 12:13 PM
What Nutty said. If you run the included demo rather than playing through it yourself, it performs much better, and hardly seems to slow down at all during action sequences. This suggests that it's CPU work that causes those slowdowns. Maybe this is a debug build we're looking at?

-- Tom

Funk_dat
11-05-2002, 01:58 PM
You guys do realize this is ALPHA software from more than a few months ago. Of course it has bugs, of course it's slow, of course it doesn't work on your 9700 that wasn't even RELEASED at the time.

The people that "play" this alpha are the same people scouring the internet for episode III spoilers and secret undercover shots of keanu from the next matrix.

I'd rather wait for the real thing as it was intended and judge/study/play it then.

oh wait, I just thought of another good ananlogy: this is like looking at a drawing and saying it's a bad painting. ;D

zed
11-05-2002, 05:41 PM
>>The people that "play" this alpha are the same people scouring the internet for episode III spoilers and secret undercover shots of keanu from the next matrix.<<

or they're graphics makers who want to check out the competition (in the losest possible sense in my case http://www.opengl.org/discussion_boards/ubb/smile.gif)

zeckensack
11-05-2002, 05:45 PM
davepermen,

I could have told you ...
friends don't let friends buy a Celeron http://www.opengl.org/discussion_boards/ubb/biggrin.gif

davepermen
11-05-2002, 11:48 PM
Originally posted by zeckensack:
davepermen,

I could have told you ...
friends don't let friends buy a Celeron http://www.opengl.org/discussion_boards/ubb/biggrin.gif

hehe. it's just till i have a 4.6 giga p4 at christmas or so.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

FXO
11-06-2002, 12:17 PM
When I turn sound off, and fire, my fps dont drop at all, 1 fps at most.
(from 14 fps http://www.opengl.org/discussion_boards/ubb/smile.gif)

I think this has something to do with the sound, they have enviromental modelling of it, perhaps its a slowdown there or its just a plain swapping issue, since the alpha uses >500mb of sounds.

Nutty
11-06-2002, 11:52 PM
Of course it has bugs, of course it's slow, of course it doesn't work on your 9700 that wasn't even RELEASED at the time.

IIRC, this very code that was used for the e3 demo movie _was_ shown using a radeon 9700.

No-one is disputing the fact that this is an unoptimized build. But it's still bloody nice!! http://www.opengl.org/discussion_boards/ubb/smile.gif

Nutty

knackered
11-07-2002, 12:11 AM
I recommend you all take a look at Battlefield 1942. Forget doom, make war!
The best game I've played in years.

GPSnoopy
11-07-2002, 01:48 AM
Playing at 640*480,
r_varsize at 32,
r_useNV20 to 0,
r_useStandardGL at 1

gave me a nice frame rate on my P3-700 GF2U (with no sound it's even better!).

Btw, a little OT, but does anyone know the code for opening the door in e3_2? In the E3 show it was 1, 2, 3 but this doesn't seem to work.

FXO
11-07-2002, 02:42 AM
9-2-4

bpeers
11-07-2002, 07:11 AM
So, are there any efforts yet anywhere on rendering the maps and/or the models ?...

NitroGL
11-07-2002, 07:52 AM
http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://evilman.netfirms.com/bla.jpg

bpeers
11-07-2002, 08:44 AM
Wow, nice !! http://www.opengl.org/discussion_boards/ubb/smile.gif
Is that the empty map, or just a backdrop ?

PS it looks like the .roq format did not change, plays back fine.

NitroGL
11-07-2002, 08:54 AM
It's just my own little room.

It would have had shadows, but I still need to find out how to fix the meshes so they are closed with out screwing up the UV coords.

GPSnoopy
11-07-2002, 09:15 AM
Originally posted by FXO:
9-2-4

Man, how did you find this? http://www.opengl.org/discussion_boards/ubb/smile.gif
Going to try it right now...

bpeers
11-07-2002, 10:22 AM
Hee hee http://www.opengl.org/discussion_boards/ubb/smile.gif
http://bpeers.com/bucht/e31.gif http://bpeers.com/bucht/e32.gif http://bpeers.com/bucht/e33.gif

Rml4o
11-07-2002, 12:08 PM
Just because doom3 is slow on your 9700 doesn't mean it is a bad card. As far as I know, current (public) drivers don't have the new 9700 extensions. So doom3 probably uses it like any 8500, that is no floating point buffer, no state-of-the-art shaders and other major improvements compared with the 8500.
Just wait for the beta drivers to leak ;-)

bakery2k
11-07-2002, 12:13 PM
I read somewhere that Carmack said the only thing which Doom does different on the 9700 from the 8500 is it uses 2-sided stencil.
Other than that, the 9700 and 8500 codepaths are the same. Both cards can evaluate the lighting equation in 1 pass per light.

ToolChest
11-07-2002, 12:30 PM
bpeers and nitrogl,

you guys work fast, how did you figure that out in a week? are the file formats based on q3a files? very cool...

John.

SirKnight
11-07-2002, 12:57 PM
you guys work fast, how did you figure that out in a week? are the file formats based on q3a files? very cool...


It's quite easy b/c Carmack now uses text files for most things now. Well except texture files but pretty much other than that...

-SirKnight

FXO
11-07-2002, 01:12 PM
Yeah, that was fast!

WhatEver
11-07-2002, 01:21 PM
OMG, how cool is that!!! I didn't look long enough to notice that they had lwo files http://www.opengl.org/discussion_boards/ubb/biggrin.gif. Wooo hoooo!

V-man
11-07-2002, 05:33 PM
Fudge! I cant find a downlaod site. Anyone know a speedy web site?

Is it really true that ATI leaked it? Does that mean some employee uploaded it or passed it to a friend who uploaded?


V-man

bpeers
11-08-2002, 04:43 AM
Yeah, the doom3 .map format is almost the same as the q3 .map format. The changes I see are
- replaced the 3 vertex points defining a brush plane with the plane equation -- finally http://www.opengl.org/discussion_boards/ubb/smile.gif
- patches have 2 extra numbers between dimensions and contents flags.
- two 1x3 vectors for UV instead of shift/rotate/scale. Looks like a 2D base defined on the brushplane, or maybe it's on the nearest axis aligned plane (a la quake).
Trickiest part will be figuring out the .mtr's I think, although it looks like .shader's.

Nitro, what's new in md5 compared to md3 ?

SirKnight
11-08-2002, 06:57 AM
two 1x3 vectors for UV instead of shift/rotate/scale. Looks like a 2D base defined on the brushplane, or maybe it's on the nearest axis aligned plane (a la quake).


Maybe it's similar to the Half-Life .map format. The HL format had 2 1x4 vectors and I think another number or two after that though. I don't remember exactly, id have to go look at my HL .map file loader to see.

-SirKnight

SirKnight
11-08-2002, 07:11 AM
Nitro, what's new in md5 compared to md3 ?


I'll answer this. http://www.opengl.org/discussion_boards/ubb/biggrin.gif It's a text file, so opening it up and taking a peek one can figure it out quickly. Also there is a post on flipcode where someone has posted some code to load md5s. Its under the 3d graphics programming/theory board. I don't remember the exact subject but it's close to the top (well it is now kind of) and it has the word doom 3 in it, or is it doom III, well either way you'll find it. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

NitroGL
11-08-2002, 07:58 AM
Originally posted by bpeers:
Nitro, what's new in md5 compared to md3 ?

Skeletal animation, bones, weights, that sort of thing.

bpeers
11-08-2002, 08:16 AM
Duh, ok, thanks http://www.opengl.org/discussion_boards/ubb/smile.gif

The texturing is a "new brush primitive mode", check out ComputeAxisBase in q3map. It's putting a 2D base on the plane, or something http://www.opengl.org/discussion_boards/ubb/smile.gif

Screenshot : http://bpeers.com/bucht/doom3.jpg


[This message has been edited by bpeers (edited 11-08-2002).]

SirKnight
11-08-2002, 08:56 AM
That looks pretty cool. http://www.opengl.org/discussion_boards/ubb/smile.gif Welp, looks like people have beaten me to it. A long time I ago I said to myself that I would be the first person to make a doom 3 map viewer. Well thanks to my slow 56k taking a week to get this doom 3 alpha I have been beaten. O well, I'll still make one anyway. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Nice work!

Hmm, so I guess that's what they meant in the q3map code with the "new style brushes" and "old style" or something like that. I'll take a look later.

EDIT: Dumb spelling. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

-SirKnight


[This message has been edited by SirKnight (edited 11-08-2002).]

SirKnight
11-08-2002, 09:09 AM
bpeers, are you planning on ever releasing the source to your doom 3 map prog there? It's not that I need it, I already have a map file viewer and converting to doom 3 would not take long at all, but I always like to see how others do things to maybe improve upon my designs. Or even help them improve theirs, whatever. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

-SirKnight

bpeers
11-08-2002, 09:11 AM
Heh, thanks http://www.opengl.org/discussion_boards/ubb/smile.gif I must say I cheated though, as I already wrote the q3 map viewer before. The trickiest part is parsing a .map and tesselating it, once you have that, it's not much work to fix the parser to eat BrushDef3 as well.
There's still materials, lighting and shadows to run for though http://www.opengl.org/discussion_boards/ubb/smile.gif

bpeers
11-08-2002, 09:15 AM
Hm, maybe some day if the thing stabilizes a bit.. though if you mail me I don't mind pasting bits of code. The UV thing I ripped nearly entirely out of q3map though http://www.opengl.org/discussion_boards/ubb/smile.gif And tesselation is probably the ugliest geometry code in existence. http://www.opengl.org/discussion_boards/ubb/smile.gif

LaBasX2
11-08-2002, 09:24 AM
What about sectors and portals? Are they also defined in the map files? I think that Carmack mentioned somewhere that sectors are built from hand but I'm not quite sure...

LaBasX2

thefirstbigd
11-08-2002, 10:41 AM
What are the material/shader files like?

bpeers
11-08-2002, 12:50 PM
It looks like portals are in the map as brushes textured with textures/editor/visportal, which is the only material with the word "areaportal" in it (invisible.mtr). I could be wrong as my GL_SELECT code seems a bit wonky http://www.opengl.org/discussion_boards/ubb/smile.gif

Pentagram
11-08-2002, 01:23 PM
All the nice stuff seems to be stored in the [mapname].proc files they "seem" to be the .bsp files of the quake games.
Just to get you guys on track http://www.opengl.org/discussion_boards/ubb/wink.gif (I plan to write a viewer but well I have lot's of stuff to do currently...)
They are ordered like
[surfaces]
[areaportals]
[nodes]
[shadowvolumes]
The surfaces are grouped by model, these are the doors and stuff and areas are also considered models named _area[x]
In the model they are grouped by texture.
Areportals are justa list of portals with front back area pointers
The nodes seem to be a bsp that's exactly the same format as all the other quake games... The leafs are areas...

The shadow volumes are just a list of vertices followed by a list of indexes (Group by three to get triangles if you ask me)
Nice stuff for who reads this board is the noCaps noFrontCaps stuff they seem to have (dunno how it works yet) so they seem to be saving fill rate by not always drawing the caps (we guessed that)
Well that's it get the viewers ready http://www.opengl.org/discussion_boards/ubb/biggrin.gif
I hope to hack it into Tenebrae someday but I need time...

Charles

SirKnight
11-08-2002, 01:37 PM
Welp I have about one more day of downloading to go to get doom 3 alpha (gotta love dialup). So I should have my first doom 3 map viewer (also will be an alpha http://www.opengl.org/discussion_boards/ubb/wink.gif) ready within a few days. I still need to fix my texture handling code in my older .map loader so that will delay me a bit. But I might just draw in wireframe just to get something drawing and worry about my texture handling code after that. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Eventually I plan on doing all the portal stuff, bump maps, shadows, etc to this .map viewer, which someday might get called an engine. http://www.opengl.org/discussion_boards/ubb/wink.gif I have all of that but the portals already done so that shouldn't take too long.


-SirKnight

bpeers
11-08-2002, 03:04 PM
Hm ! .proc certainly looks easier to digest http://www.opengl.org/discussion_boards/ubb/smile.gif I wonder if they contain everything, and if so, if d3 will still ship with the map files.. I think they said they would do that, but maybe that was before they came up with .proc. Tried deleting them to see if they were only a cache, but that didn't work too well (great FPS though) http://www.opengl.org/discussion_boards/ubb/smile.gif

WhatEver
11-08-2002, 06:23 PM
Here's my contribution http://www.opengl.org/discussion_boards/ubb/biggrin.gif!
http://www.spider3d.com/img/tech_door.jpg

Once I implement tri-strips it'll render even faster http://www.opengl.org/discussion_boards/ubb/biggrin.gif...no specular yet though :/.

Pentagram
11-09-2002, 04:09 AM
They'll still need the .map files since the entities are not saved in the .progs files (Probably thise sort of things will change by the time it gets released...)

Charles

LaBasX2
11-09-2002, 05:32 AM
So Doom is only saving the portals. Hmm, I'm wondering how portal culling is working if you don't store any sectors to which the portals belong. Or are the sectors somehow generated while loading the map?

LaBasX2

dorbie
11-09-2002, 06:14 PM
Texture input to shader list from a quick look at a few models:

<filename>.tga -> diffuse color
or
<filename>_d.tga -> diffuse color

<filename>_local.tga -> tangent space normal map

<filename>_s.tga -> gloss map (modulation for specular - some subtle color)

Varies on models:
<filename>_h.tga -> specular exponent map
or
<filename>_b.tga -> specular exponent map


I may have transposed _h and _s but I don't thinks so.

It looks like the normal maps are tangent space using the vertex coordinate frame.
Normal maps also don't look like they flood uncovered areas guaranteeing no normal map MIP mapping unless theres a morphological expansion on load. There is a seemingly redundant alpha channel on SOME normal maps that might imply a morphological flood is supported on load but I doubt it, it could be a generic mechanism for alpha texture clipping, used in some areas, or it may just be a side effect of the software used to generate the maps from the 3D model.



[This message has been edited by dorbie (edited 11-09-2002).]

NitroGL
11-09-2002, 06:45 PM
I don't think the _b.tga files are exponent maps.

Those are bump maps that get made into normal maps, then added to the local normal map (and renormalized of course), you can do that in photoshop too. It adds small details to the local normal map.

dorbie
11-09-2002, 06:55 PM
Ah I see that now the _b is a height based displacement style bump map, and the _local is a DOT3 vector based normal map. I assume this is to support different rendering modes on different extensions, either than or they were just lying around from earlier builds, I don't see them everywhere. I still think there are exponent maps there though in the _h files.

I've noticed that the lwo files contain a number of field preceeded with ascii descriptions for example :

LUMI  DIFF  SPEC  REFL  TRAN  TRNL  RIND  BUMP  GLOS - SMAN

There's also some examples with

<filename>_add.tga that appear to have emission maps.

dorbie
11-09-2002, 07:05 PM
So so far there's:

<filename>.tga -> diffuse color
or
<filename>_d.tga -> diffuse color

<filename>_local.tga -> tangent space normal map DOT3

<filename>_b.tga -> old displacement style bump map
or
<filename>_bmp.tga -> old displacement style bump map

<filename>_s.tga -> gloss map (modulation for specular - color)

<filename>_h.tga -> specular exponent map (or reflection modulation)

<filename>_add.tga -> emission map

I don't think the filenames are 100% consistent but that may just be the older bump stuff and base diffuse name.

[This message has been edited by dorbie (edited 11-09-2002).]

dorbie
11-10-2002, 01:34 AM
The lights directory has a lot of textures for projection with lights, it seems that there are only spotlights in the engine (not point lights) I may have mised some though. F1 adds a spotlight pointing out from the viewer F2 deletes. Seems like radiant is run here because I saw a message where it crashed when I deleted all the lights. There are many places where lights project simple textures and there is no apparent luminaire positions, it seems the artist is free to place lights willy nilly with associated projected textures and make the scene look good. It seems that in some places the artist has projected a texture to match the scene geometry (I'm thinking mainly of situations where there are spinning ventilation fans and texture shadows). It seems that all the lights I add with F1 seamlessly cast stencil shadows into the scene.

One minor nit pick is the player doesn't cast a shadow, I think this is a big omission but maybe it's difficult to get right or is just the demo. When the hellknight was kicking the crap out of me I noticed the shadow he cast and there was no me, maybe if I wasn't in god mode I'd have been dead before I noticed :-).

There reflections in glass seem to use a lower res render to texture, you can see the resampling of the image due to texture magnification.


[This message has been edited by dorbie (edited 11-10-2002).]

dorbie
11-10-2002, 02:59 AM
NitroGL I see what you're saying about the dual bump map, and I think you're right, the _b on pinky for example seems to have detail not present in the _local and it's in the game. It seems a bit redundant to not bake these two into one map by the time you get to production if they're the same resolution anyway. I assume these are precursor textures that get combined later as you say. There are parts with dot3 style and no emboss map, parts with emboss and no dot3 and parts with both.... it seems they are interchangeable and combinable in the engine. This is so artists can generate some types of detail intuitively in a paint package without laboriously modelling it in 3D but still do the geometry preserving simplification of their detailed base model. I knew this was done in some cases, but I guess I just expected them to be combined by this stage into a single map.

I've also noticed that at least some monsters don't self shadow in the demo, I assume it's an option I'm missing.


[This message has been edited by dorbie (edited 11-10-2002).]

Mezz
11-10-2002, 06:39 AM
Dorbie,

You're right - the player doesn't cast a shadow, but there is a cvar you can change so he does http://www.opengl.org/discussion_boards/ubb/smile.gif

You can also go third person on yourself and then see that there is virtually no animation done for the player model, it's quite funny watching yourself just slide around without moving legs or anything.

-Mezz

dorbie
11-10-2002, 06:49 AM
So what's the console variable?

Mezz
11-10-2002, 08:44 AM
Something like g_showplayershadow. cvarlist if that isn't it, or type g_show and then press tab to see the auto-complete list.

-Mezz

SirKnight
11-10-2002, 10:44 AM
All the cvars are listed in DoomConfig.cfg.

And I really like these .proc files, pretty cool. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Now if I can just figure out how to setup the areaPortal and node stuff listed in the .proc files like doom 3 does for portal culling and whatnot. :p


-SirKnight

[This message has been edited by SirKnight (edited 11-10-2002).]

Mezz
11-10-2002, 12:00 PM
What are the aasXX files for?

They look like visibility info, but I'm not that great when it comes to spatial partitioning stuff.

-Mezz

WhatEver
11-10-2002, 12:09 PM
If memory serves me correctly, aas files are for the AIs. It's the pre computed paths that they take to walk around.

zeroprey
11-10-2002, 03:26 PM
Originally posted by dorbie:

<filename>_h.tga -> specular exponent map (or reflection modulation)


I'm almost positive that doom3 doesnt do any sort of varible exponent. These _h files would stand for heightmap which would then be combined with the _local file which was created from his reducer. Most likely theyd just combine these in release but not yet. It was in his quakecon talk that he said something to the effect that way to extend the renderer for the next engine ireration would be to add a spec exp map. He said that about all thats left to add to the lighting equation. concidering his target for gf2-gf3 hardware a spec exp map would be a little premuture.

SirKnight
11-10-2002, 04:26 PM
Ya the _h map is just for extra detail on the monster like zeroprey said.

Just curious though, I was just looking at the _h and _local files and how would these two be combined? Would they just be multiplied together the way they are now or would one have to do some kind of computations to the _h map first? I have only used one normal map in my bump-mapping things, I have never used a detail map like what the _h files are.

-SirKnight

SirKnight
11-10-2002, 04:35 PM
Opps, let me retract one of my previous statements. DoomConfig.cfg doesn't contain _all_ of the cvars but it does have a lot, like the cvar to show shadows (the players shadow or any other shadows), player weapons, etc.

-SirKnight

zed
11-10-2002, 06:15 PM
question to those of you that have written a doom3 level loader.
how long does it take to parse a levels model data (rough figure).
a guy at flipcode seems to think it takes 90seconds to load doom3 on his computer cause doom3 uses ascii files http://www.opengl.org/discussion_boards/ubb/smile.gif

WhatEver
11-10-2002, 06:30 PM
I tell you what zed, if he's talking about running the actual scripted demo portion of that leak, it took my computer more than 2 minutes to load. I have a PIII 866 but you wouldn't think it would take THAT long.

I can't for the life of my remember how I ran that long ass scripted demo...it starts off with a spinning id logo.

WhatEver
11-10-2002, 06:38 PM
Ok, I got it. It's:

map e3/intro

It didn't take long to load at all either. It was execing activate_intro that took a while.

dorbie
11-11-2002, 03:07 AM
OK, so the _b.tga, _bmp.tga and _h.tga are all displacement style bump map detail supplements.

It makes more sense now, there seems to be a bit more consistency once you understand these extensions all apply to the same thing.

I've noticed on some models that the transparency is applied in the diffuse base map.

Pentagram
11-11-2002, 03:28 AM
If you look at the shader files you'll see the "_h" maps are added at load time to the normal maps. The command goes like this:
bumpmap addnormals(xxx_local.tga, heightmap(xxx_h.tga, 10 ) )
So they convert the heightmap to a normalmap using the scalefactor. I think they just add the two normalmaps togheter and then renormalize the result...

Charles

dorbie
11-11-2002, 03:47 AM
Thanks, I hadn't seen this.

I've noticed that you can run around adding the textured grate lights everywhere using the numpad 1 key.

The function keys are pretty useful too one lets you turn the portal highlights on and off (someone was asking about the portals), they don't seem all that sophisticated, just the usual box around doorways and major openings, looks like they can be opened and closed as you'd expect.

[This message has been edited by dorbie (edited 11-11-2002).]

SirKnight
11-11-2002, 06:42 AM
... bumpmap addnormals(xxx_local.tga, heightmap(xxx_h.tga, 10 ) )


Ah hah! So that's how they are combined. Ok makes sence. I didn't think to check the shader files. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

-SirKnight

dorbie
11-11-2002, 08:12 AM
Not all objects have shaders, are they referenced globally or is there just a default? It seems that there's some kind of default mega shader that does everything, with textures either present or absent to enable broad fixed path stuff like emission for example. I don't see where programmability is generally applicable especially looking at the in game rendering. Many of the objects and creatures with the bump maps have no shader file there. Although there's clearly some tokens embeded in the lwo, it looks like these are broad descriptions for terms in a fixed function path (using that term very loosely).

[This message has been edited by dorbie (edited 11-11-2002).]

bpeers
11-11-2002, 11:56 PM
quake3 had a system where every texture that does not exist as a shader, automatically triggers the creation of a dummy shader with the texture's name which had two stages, one with the texture and a lightmap pass blended over it. So maybe doom3 has something similar, doing a vanilla diffuse only thing, or maybe it defaults to a shader (material) with texturename+"_d" as diffuse, _s specular, etc.

dorbie
11-12-2002, 12:44 PM
I think it's a fixed function complex shader with texture slots enabled in the space following the related ascii keyword fields in the lwo file. The filename for the diffuse texture is in there and there are tokens in ascii that look like terms in that equation. I assume the other names are inferred by extension substitution.

JelloFish
11-13-2002, 07:54 AM
Do you guys think they are doing anything complex to combine the bump and polybump normalmaps? Like instead of just averaging normals, actually rotating the bump normals about the polybump normals?

dorbie
11-13-2002, 07:59 AM
I don't think it makes much difference with a tangent space map unless you have some really bent normals. This is just an artist painted map too remember so accuracy is not the major issue I think, but what you are suggesting is strictly speaking "the right thing" I think. In another thread there's a discussion of object space normal mapping where the rotation you're describing would be essential.

dorbie
11-13-2002, 10:43 AM
I just realized while writing in the object space bump mapping thread that after the transform to peturbed tangent space you then substitute the dot 3 vector with the transformed vector produced from the emboss map you don't add then renormalize.

JelloFish
11-13-2002, 03:42 PM
Wouldnt it be if either normal were really bent? I mean on the pinky skin in the legs the sections are pretty bent. Your normal map would get screwed up just from averaging a flag artist generated pixel with with the leg normals.

dorbie
11-14-2002, 12:47 AM
Jello, there's no doubt for me now that adding and averaging is the wrong thing, but generally it'd probably look OK for tangent space vectors to be added. The errors increase as the normal turns off center.

What you need to do is transform one normal using the other and use that vector as your DOT3 bump map. This is true for object and tangent space maps.

bpeers
11-14-2002, 01:05 AM
Hm, not _completely_ sure that is correct.. specifically if the tangent space is a non-orthonormal basis, you would get scaling/skewing on the light when you move it to tangent, _and_ on the normals as you move them from bump to tangent, so somehow the dot3 would be off.. so probably you need to renormalize the bump vector after transforming, or better yet, use the bump map to compute points "above" the surface in object space, transform those points and compute gradients in tangent space ? Or would that end up with exactly the same stuff http://www.opengl.org/discussion_boards/ubb/smile.gif

pocketmoon
11-14-2002, 01:14 AM
Has anyone tried setting use_nv30=1 and running with a tiny window with NV30 emulation drivers ?

I left it running for about 20 minutes last night and got a black screen with a light smudge in the middle. I *think* it might be the start of the 'in-fade'! Should have left it running another day or two http://www.opengl.org/discussion_boards/ubb/wink.gif

dorbie
11-14-2002, 01:18 AM
bpeers, no, you don't need to do this if you simply rotate, although a renormalize wouldn't hurt. It is orthonormal, because you should rotate the implied tagent & binormal of the vector map from s & t axes to surface local space to get an orthonormal peturbed coordinate frame prior to the transformation, I think you can formulate this without those axes. I don't think this is unclear. The addition and divide is obviously the wrong thing. If you have any doubts consider a normal well off the vertical or say 45 degrees off, it could happen, then consider your bump peturbation from an emboss vector. Say the vector from the emboss is a 20 degree peturbation from the vertical in the same direction. If you add and renormalize the peturbation would move in the opposite direction from the intent of the artist.


[This message has been edited by dorbie (edited 11-14-2002).]

bpeers
11-14-2002, 02:18 AM
Yeah, add is definitely wrong, and I agree you can use the simpler path if the tangent space is orthonormal; then indeed the transform is a rotation. I was just worried about the case where it is not a rotation; unless I seriously need more coffee this would give you transformed tangent and binormal that skew or otherwise mess up your bump gradient.. then again that is probably not a good idea anyway, and tangent space T should be tangent space S cross normal, regardless of what t coordinates say.

cass
11-14-2002, 05:51 AM
Originally posted by pocketmoon:
Has anyone tried setting use_nv30=1 and running with a tiny window with NV30 emulation drivers ?


Hi Rob,

Even if you are able to generate some pictures with r_useNV30=1, you should not draw any conclusions from it.

The leaked Doom3 has a very out-of-date nv30 path in it.

Ugh. I'm sure this won't be the last time I have to say this. http://www.opengl.org/discussion_boards/ubb/frown.gif

Thanks -
Cass

SirKnight
11-14-2002, 06:06 AM
Originally posted by cass:
Ugh. I'm sure this won't be the last time I have to say this. http://www.opengl.org/discussion_boards/ubb/frown.gif


Well Cass, if the situation comes up where you would have to say it again, instead give that person a good flogging with a salmon. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

[This message has been edited by SirKnight (edited 11-14-2002).]

MZ
11-14-2002, 07:47 AM
Originally posted by cass:
Even if you are able to generate some pictures with r_useNV30=1, you should not draw any conclusions from it.

The leaked Doom3 has a very out-of-date nv30 path in it.

Really? I can only wonder what unique capablity of nv30 migth be utilised by doom3 beyond just 8 texture shaders and ext-stencil-2-side...
I personally don't expect any big difference , except the speed of course.

davepermen
11-14-2002, 08:26 AM
the nv30 path works smooth on the radeon9700..

is that outdated enough? http://www.opengl.org/discussion_boards/ubb/biggrin.gif dunno how it works and what it actually uses http://www.opengl.org/discussion_boards/ubb/biggrin.gif

JelloFish
11-14-2002, 05:11 PM
I was looking at pinky's bump and normalmap. And while it looks like while alot of the bumpmap is artist generated a portion of it looks to be just a copy from the normalmap(the metalic leg section). I wonder why they would have it perturb a normal map(_local) by the exact same normal map(_b).

dorbie
11-14-2002, 05:26 PM
bpeers, I was just assuming that a polar coordinate style rotation from texture space to the new peturbed tangent space would do it. I think this is OK.

Jello, yea I saw that, it kinda threw me a bit when I was trying to figure out what each texture was. What you see on Pinky is the main reason I thought the bumps were old deprecated stuff or for another path at first. Maybe they think it adds a bit of punch to the model to accentuate the edges, it's the mechanical part that seems to have the most bumpiness replicated or maybe they're trying to compensate for the flattening you get when you naively combine the two maps. Not all emboss maps share this detail with the DOT3 maps. I don't think you're going to figure out for sure the why of this one :-)

JelloFish
11-14-2002, 08:39 PM
Yes we may never know, well that is we won't know until someone makes a d3t file opener for photoshop. http://www.opengl.org/discussion_boards/ubb/smile.gif

dorbie
11-14-2002, 09:41 PM
You're assuming that the person who makes that opener will know :-)

castano
11-15-2002, 06:14 AM
We used a darkened version of the normalmap in greyscale to help artist draw the detail bumpmap on top of it. That is, it is used as a reference only, and since it's been darkened it doesn't influence the result at all.

They may be doing the same.

SirKnight
11-15-2002, 08:47 AM
Originally posted by castano:
We used a darkened version of the normalmap in greyscale to help artist draw the detail bumpmap on top of it. That is, it is used as a reference only, and since it's been darkened it doesn't influence the result at all.

They may be doing the same.


That's exactly what I was thinking they are doing. But all I know, whatever they are doing it looks quite nice. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

JelloFish
11-15-2002, 09:04 AM
Well once we can open the images we can use some simple algebra to figure out how they are combining the images and what use having that extra copy of bump does for them.

rapso
11-17-2002, 02:42 PM
I've coded a doom3 .proc loader an I wonder why the geometry is that low poly...

rapso->greets();

SirKnight
11-17-2002, 03:47 PM
Well every surface has a bump map so even the map geometry will look low poly with out them. A lot of the map surfaces was modeled in lightwave and renderbumped to make the geometry made in DOOMRadiant look much better. I've noticed that in the game the hand rails and such look nice and rounded out but when viewed in Radiant or someones map viewer (that don't use the bumps) they don't even look rounded.

-SirKnight

JackM
11-17-2002, 04:45 PM
From my experience, setting .ini to use NV30 path automatically defautls to ARB/NV10 path, which can be checked by typing gfxinfo in the console.

[This message has been edited by JackM (edited 11-17-2002).]

rapso
11-17-2002, 05:11 PM
yes I know, bumpmapping is used on bether cards, but I've take a look at some (original) screenshots and the models look not as good as on other games, maybe they'll add displacement mapping?????

if my light-stuff looks correct, I'll try to implement this...

rapso->greets();

Dr Doom
11-26-2002, 05:48 AM
So... it's been a couple of weeks...

How is everyone going?

Let's see some more pics!!