PDA

View Full Version : new doom3 screens - wierd shadow on panel



okapota
07-30-2002, 11:31 PM
have you seen the new screen from doom3? it shows a man casting shadow on a control panel, and the control panel itesel (it's screen) is not shadowed. i wonder whether it is a bug or not.

JML
07-30-2002, 11:52 PM
okapota,

I haven't seen the screen shots, but it would be right to not shadow a computer screen, as it is an emissive surface. These surfaces hardly show a shadow in real life...

Jean-Marc.

Junkstyle
07-31-2002, 12:47 AM
http://www.bluesnews.com/screenshots/games/doom3/20020730/intro_00603.shtml

PH
07-31-2002, 01:03 AM
I was going to say that those screenshots were way too dark - increasing the brightness/gamma on my monitor, I see what you mean. I think it makes perfect sense - the terminal screen is probably supposed to be emitting light. I noticed this in the old MacWorld video too ( but with the lights ).

This is definitely on purpose and not a bug.

okapota
07-31-2002, 02:32 AM
it does makes sense, you are right. but it doesnt look natrual at all. the shadow is completly dark, and the contrsat is too clear. they have no ambient at all?

Mezz
07-31-2002, 03:28 AM
The bald guy's shadow is probably one of the worst I've seen - it's completely black and actually looks quite blocky. Maybe it's just because the shot is taken very close to it. I mean, when you look at the marine in the background his shadow looks far better in comparison.
There is definately a lack of ambient light.
Looking at the other screenshot there seems an unnatural cutoff on the front zombie's shadow on the interior of his arm too. Perhaps I'm just being picky.

-Mezz

davepermen
07-31-2002, 04:30 AM
not only the shadow looks bad (well, not the shadow itself, but the lack of ambient http://www.opengl.org/discussion_boards/ubb/wink.gif), but the guy sending out the shadow as well..
the face is quite good, but the body looks really not like some natural cloth but a very bad poligonal mesh of plastic..

this image shows somehow some very natural looking parts combined with some very crappy looking parts..

i think, after seeing too much dx9/nv30/r300 stuff doom3 isn't that spectacular anymore http://www.opengl.org/discussion_boards/ubb/wink.gif

Gorg
07-31-2002, 05:04 AM
The only reason why the marine shadow at back looks better than the scientist is because the scientist is being lighted by just one light and the marine is lighted by two lights or more.

The shadow cuts off the one of the light and so less light is added and it looks darker in the shadow.

dabeav
07-31-2002, 05:14 AM
I SOOO agree. First let me say, I am a DIE HARD ID fan. But I have noticed that ever since the release of Quake3, there engine capabilities are far better than there implementation of them. For example. Quake3, Wolfenstein, and Alice were all made with the Quake 3 engine. Quake 3, Was at first sight Visualy spectacular. But as you played it, you begain to see how all that visual mastery was simply the same old TextureMapping with slightly more interesting Textures. And the lack of any real game play was kind of a drag (not that there was no game play, but i mean RANDOM FRAGIN gets old after a while). Wolfenstein, had a GREAT plot idea, but it realy realy became repetative, and slow after a while, and once again the Visual was good untill you realy looked at the objects, and noticed there planeness. BUT look at alice. A game not written by ID, but using the Quake 3 engine, WAS VISUALY AWSOME. Very crisp. Also the plot and idea was totaly new, fresh, and never got (too) boring.

The problem is, that i see this happening with the new Doom3 engine. The CODE behind the new engine is BEUTIFULL. The things this engine will be able to do will make the head spin, BUT. Almost all the people that made there games SO greate have left the company. Dooms level designers, artists, and Game designers are ALL gone. Exept the lead programmer. Which IS why the Engine will rock, but the game may suck. I just hope that SOMEONE, will take the engine and put it to good use, that is if ID dosnt.

dorbie
07-31-2002, 06:10 AM
The screen has emission properties. I think to look more correct it should also be slightly reflective and this almost certainly could be handled in the engine but it would reduce the contrast of the display. I think it is roughly correct although a screenshot lacks the dynamic range of the real world and this is the underlying problem.

Take your desk light point it at your monitor screen and try to cast a shadow on your screen with your hand, I just tried this and it didn't cast a shadow I could see, the screen is too bright and the contrast sensitivity of my eye is not sufficient to see the shadow. With a bright light or a dark screen I would probably have seen something. In the Doom 3 shot I think you perceive that the display is not sufficiently bright to eliminate all shadow/illumination effects.

The shadow being completely harsh is a separate issue, there is no ambient light in the scene, it'd probably make the shaders look bad if there were, it'd flatten out bump maps etc, to get this stuff looking right you would need a full BRDF + global illumination.... or something approximating it which would be expensive to draw. Having fragment normals makes it hard to get ambient light looking decent, although a little bit might not hurt.


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

Gorg
07-31-2002, 07:16 AM
Originally posted by dorbie:

In the Doom 3 shot I think you perceive that the display is not sufficiently bright to eliminate all shadow/illumination effects.

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

Interesting idea, but if you use a stronger light you won't see a shadow in the normal definition. What I mean is that there won't be less light comming to your eyes.

But you will still see the shape of your hand, because the computer screen around your hand will be very "glary" and so you will have problem reading what's around your hand but not what's inside.

In the scene, the light does not seem strong enough(very subjective) to give glare on the screen. I think what is really screwing this up is just the lack of ambient.

dorbie
07-31-2002, 09:00 AM
You have missed what I said about contrast sensitivity, and what the original poster wrote, the post is unambiguously about the lack of shadow on the screen, or perhaps you just don't understand what I mean when I use that term. It's not about the absolute ammount of light coming to your eye but your eye's ability to detect it.

If you use a stronger light in the real world the magnitude of the reflected light vs the emissive light increases and you become able to detect the shadow. There are two factors, the brightness of the emissive screen and the brightness of the reflected light

Yes I agree there is another problem with the lack of ambient I think I covered that.

However if you look at the screen it's text on a black display. Now that display's black background looks grey not black. Some of the grey we are used to seeing as comming from reflected light, not emissive light. Switch your monitor off and you can see it's not a black surface. So the artist when he created the database cooked the grey monitor background into the display emission term thinking he was doing the right thing, but for the emission term he should probably have just cooked the text and given the material a slight reflective property in addition. OTOH maybe it's his intent to have the monitor backgound glow and he's 100% correct in doing this.

When I first saw this shot I had gamma correction on (I like my antialiasing to work, what can I say) and it was much brighter, if viewed with a gamma correction off you hardly notice the shadow problem on the screen so your mileage probably varies depending on your hardware gamma correction settings.

P.S. you are totally right about single vs multiple lights.

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

Junkstyle
07-31-2002, 09:42 AM
In response to the very first post I don't think the screen should be shadowed at all. Everybody complains about the razor cut shadows in Doom3 but time for a reality check guys this game has to run realtime and I don't think we have the computational power to do it, especially in a game where you have to do AI, physics, sound, etc. If you see movies of Doom3 it looks a lot better than still frames.

Gorg
07-31-2002, 09:52 AM
Originally posted by dorbie:
You have missed what I said about contrast sensitivity,

Yes, I missed it. It makes sense now.

Zeno
07-31-2002, 09:52 AM
Yea, like Junkstyle said, the game looks much better in motion. It's really easy to dissect stills.

However, I do wish they would use a few more polygons in some places. The extreme reliance on texture makes some surfaces look flat, and the zombie's arms (in the next picture) look almost like squares.

On the bright side, though, I think the reflection and transparency in the glasses and goggles looks great http://www.opengl.org/discussion_boards/ubb/smile.gif.

-- Zeno

Junkstyle
07-31-2002, 10:17 AM
The low poly count looks like such a crime. From what I've heard the models are formed with about a half million polygons and then put through some process to scale them down and put bump maps on them to make up for the low poly count. There are games out or coming out that have much higher polygon counts but they don't have the bump mapping and dynamic lighting to the extent that Doom3 will have (speculating). I'm guessing the low poly count was a performance trade off. Carmack said his next game engine after Doom3 was going to target the nv30 so that basically means Doom3 isn't targeted for next gen cards like the nv30 and r300. So you wont be seeing the latest and greatest technology with Doom3 I'm guessing, but in the end idsoft has to make a game that a fair amount of people can play.

Lurking
07-31-2002, 11:35 AM
in response to Junkstyle's reply. You have to keep in mind when development started for this engine. I remeber Carmack saying that he started development of the Doom3 engine when the rest of id was working on Team Arena. Think about the graphics cards at that time. That was 2000 (i remeber cause i talked to carmack at quakecon). The geforce3 wasn't even on the market yet and it was in testing phase! So to say that Doom3 isn't being aimed at the MOST current graphics cards you have to look at when he started the engine. I have been hearing alot about the low poly count my responce to that is this. Can you imagine the amount of polys on the screen at one time. Look at the amount of detail that is in the world. Also take in consideration on there plans for how many mosters/characters they plan on putting in a room at one time. If you remeber the old doom it had masses of monsters in on big room that came out of no where. So w/ a large detail world and lots of monsters plus ai and such the game is REALLY pushing on your system. also think of all the textures that are going to be used on the world and charaters to create the per pixel lighting effect. This is a great deal of work for them to tackle and i think it looks great. Can't wait to see what they show at quakecon2k2. The lack of ambient light i think is to make the game look really dark and evil. I think thats the main reason they didn't put any ambient light in the scene.

- Lurking

Zeno
07-31-2002, 11:44 AM
While it's true that engine development started a long time ago, I'm guessing most of the artwork is more recent. The engine's poly-pushing capability should scale up with the newer cards, and it seems (to me) that they would notice this and increase the polygon detail in their artwork.

Now, like you said, there are other excuses besides age of the engine that could explain the low poly counts. For instance, maybe they want it to run well on all GF2+ cards. Maybe there will be tons of monsters in some rooms. Maybe they have to use 9 passes to render some scenes so the visible poly count is misleading.

-- Zeno

MikeC
07-31-2002, 11:49 AM
Originally posted by Junkstyle:
The low poly count looks like such a crime. From what I've heard the models are formed with about a half million polygons and then put through some process to scale them down and put bump maps on them to make up for the low poly count.

Yes, although I don't know whether the geometry simplification is set in stone or whether the normal maps and geometry are created from "master" copies on the client, maybe at installation time. In the latter case you could reinstall with less simplification as faster hardware becomes available.

Those mountains out of the window do look pretty dire though...

PH
07-31-2002, 11:50 AM
There's a performance reason for not having ambient light in shadowed areas. This would require rendering all surface twice ( due to the way stencil is used to mask areas ). There's still ambient light in the lit regions ( just a tiny bit makes a huge difference ).

All in all, I think DOOM3 looks stunning as it is ( that reflective glass looks amazing http://www.opengl.org/discussion_boards/ubb/smile.gif ).

PH
07-31-2002, 11:54 AM
Originally posted by Zeno:
While it's true that engine development started a long time ago, I'm guessing most of the artwork is more recent. The engine's poly-pushing capability should scale up with the newer cards, and it seems (to me) that they would notice this and increase the polygon detail in their artwork.

Now, like you said, there are other excuses besides age of the engine that could explain the low poly counts. For instance, maybe they want it to run well on all GF2+ cards. Maybe there will be tons of monsters in some rooms. Maybe they have to use 9 passes to render some scenes so the visible poly count is misleading.


The "low" polygon counts make a lot of sense. Creating shadow volumes for the entire scene adds a lot of geometry ( Carmack mentioned 3x the original model is possible per light ). Then add in all passes for the lights ( 2-3x geometry per light on GeForce3 ).

dorbie
07-31-2002, 02:06 PM
The way rendering of light sources is accumulated to the framebuffer, Ambient could be drawn during the full scene z fill pass (I've described this in other threads). It would be almost free although I assume it would cost some texture for a purely indirect illumination light map to apply as the ambient value, rather than a dumb global value. I might be tempted to go with a light vector RGB + alpha intensity for this zfill pass to give some slightly dominant directionality to ambient on the diffuse term, but that's getting more complex than just ambient.

Nutty
07-31-2002, 02:13 PM
I did a rough accumulation light demo, for gf1+2. Per pixel difuse with faked specular. Upto 32 lights (66 passes http://www.opengl.org/discussion_boards/ubb/smile.gif )

I did the ambient like you say dorbie, on the 1st pass while laying down the Z buffer.
http://opengl.nutty.org/bumpy_spec.zip

P.S. A and D to inc/dec lights.

[This message has been edited by Nutty (edited 07-31-2002).]

Zeno
07-31-2002, 03:30 PM
Nutty -

Is there a trick to running your demo, like a command line parameter or something?

It simply quits on my machine (Geforce4, 28.32 drivers).

-- Zeno

dorbie
07-31-2002, 04:00 PM
It required DevIL libraries installed.
http://openil.sourceforge.net/

Wow! What a cool logo ;-)

Ah...... it starts off with no lights, I needed to press A to get one. There's barely any ambient in the scene to start with. If I crank up the monitor brightness I can make out the ambient... barely.

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

Zeno
07-31-2002, 04:14 PM
Originally posted by dorbie:
[B]It required DevIL libraries installed.[B]

Yep, that was it, thanks Dorbie. Nice demo Nutty http://www.opengl.org/discussion_boards/ubb/smile.gif I have been thinking about making a generalized per-pixel lighting model something like this. Still haven't worked out all the details, though.

-- Zeno

SirKnight
07-31-2002, 05:01 PM
I made a really cool light engine once, very easy to use and stuff. The bad thing is that it doesn't work. Haha! I still don't see wth is wrong. So thats why i'm re-writing it with a different approach (and with a better understanding on what im doing and how to do it) this time so maybe it will turn out better. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

NitroGL
07-31-2002, 05:23 PM
I like my multi-light demo (http://area3d.net/story.php?id=49), two lights with Specular (n.h^32 via dependent read), the only problem with it is that only the Radeon 8500 can handle it (ATM) in one "pass" (the GF3/4 would need at least 2, one for each light).

folker
07-31-2002, 11:29 PM
T think for a game like doom3 it is fine to use one single lighting and shadowing technique for everything. But it wouldn't be a good idea for a engine which you want to re-use also for different kind of games. For example, for scenes having daylight or bright rooms, you may want to combine precalculated radioisity lightmaps or vertex lighting with dynamic shadow-volume lights. I think that's one reason for a flexibly shader system, where you can plug together different rendering techniques as you need instead of a fixed rendering pipeline.

bpeers
08-01-2002, 02:24 AM
~While it's true that engine development started a long time ago, I'm guessing most of the artwork is more recent. The engine's poly-pushing capability should scale up with the newer cards, and it seems (to me) that they would notice this and increase the polygon detail in their artwork.~

Hm, this could be a problem.. The reduction from half a million to a few thousand polygons probably takes some time, so it would be done offline. They probably don't want to keep a high polycount version in memory at runtime, only to have it be onscreen in a 30% collapsed state 90% of the time (and having it cast shadows 50% collapsed 100% of the time), so, it'd be logical to make the polycount in which it ships not too high (and/or do a bunch of collapsing at load time based on performance 'estimates')...

So any scalability is not in the engine, but in the offline processing -- kinda like making all your textures in a procedural package, so you can batch-recreate the images in a higher res when you notice that GPUs these days come with much more memory than when you started..

In that sense the runtime component is actually less scalable than Q3's Beziers.. ?

PH
08-01-2002, 03:05 AM
Originally posted by bpeers:
In that sense the runtime component is actually less scalable than Q3's Beziers.. ?

Yes, curves in DOOM3 are tessellated in the editor ( to quote John Carmack: "before it even gets to the game" ). I don't think the engine even has runtime LOD selection - it'll make the shadows look terrible ( in the case of huge shadows from far away objects ). It might work in some cases but I doubt it's worth the effort to implement.

MZ
08-01-2002, 05:43 AM
Originally posted by PH:
Yes, curves in DOOM3 are tessellated in the editor No, Q3 .bsp files contain untesselated patches (tested)

PH
08-01-2002, 06:00 AM
Originally posted by MZ:
No, Q3 .bsp files contain untesselated patches (tested)


MZ, are you blind http://www.opengl.org/discussion_boards/ubb/smile.gif ? I said curves in DOOM3 not Quake3.

[This message has been edited by PH (edited 08-01-2002).]

MZ
08-01-2002, 07:01 AM
Originally posted by PH:
MZ, are you blind http://www.opengl.org/discussion_boards/ubb/smile.gif ? I said curves in DOOM3 not Quake3.Oh sith.
I'm not 100% blind yet, but I always thought these computers will make me need to wear glasses sooner or later...

You were talking as if you have *seen* the editor, so Q3 flashed in my tired mind http://www.opengl.org/discussion_boards/ubb/smile.gif