PDA

View Full Version : What do you experts think of this guys statement?



WhatEver
05-05-2002, 11:30 AM
First of all, the high-end video cards on the market right now aren't having a problem because of the number of triangles that Quake III draws. There are two other bottlenecks: fillrate, and bus bandwidth.

My card does fine with about 60 thousand triangles (with lightmaps) at 125 FPS, as long as it's drawing a static scene. In this case - and this is the case with Quake III maps - the geometry is sent to the card in a compiled vertex array. When it needs to be rendered for any given frame, the game doesn't have to send the triangles again.

Dynamic/moving/animated/whatever models need to be updated to the card each frame. That takes bandwidth.

That won't be the case with vertex shaders, which the Doom III engine will take full advantage of. You send the data once in a compiled vertex array, and for each frame, you send a little bit of data in a constant pool (keyframe stuff, timestamps) and have a programmed vertex shader animate the model for you on the card. You use very little bandwidth to animate a very highly-detailed model.

Another bandwidth killer is dynamic textures. Per-pixel shaders will move this from the CPU to the card.

So throw out your Quake III examples, because the Quake III/TA engine doesn't do those.

A related issue: the CPU will be doing less graphics-related computation because of vertex and per-pixel shaders, which could translate into another speed increase.

Another limiting factor (something that drops FPS) is overdraw. Having more detail on a model doesn't significantly increase the amount of overdraw (just a little because the model can be a bit more bumpy). So you can nearly forget that as a possible slowdown.

Something else you need to keep in mind: technology advances in speed - at least in CPUs and GPUs - are measured in the frequency in which the speed doubles. For instance, CPUs generally double in speed every 18 months. NVidia is expecting their cards to double in speed every six (yes I read that in an article but I can't remember where it is) - and it's doable because of how easy it is to parallelize its tasks. With NVidia's purchase of 3dfx, they've acquired a lot of that sort of technology.

You guys should know more than me about this. This guy is saying that DOOM 3 will have character models that are 250k each. At 60 fps just one model alone would require 15 million tris a sec!

What do you think? I'm having trouble finding this possible by the time DOOM 3 comes out.

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

Adrian
05-05-2002, 11:43 AM
There is no way the character models will be 250k each.

Carmack has said a Geforce3 will run Doom3 at about 30fps. With everything else going on I wouldn't expect the engine to be pushing much more than 6 million tris/sec which means the poly budget per frame is about 200,000. Maybe 50-100k for the level and the rest for the models.

Tom Nuydens
05-05-2002, 11:48 AM
Their source artwork (made in Maya) has been said to have about 250K polys/character. However, they simplify the model a lot for rendering, but the detail that gets thrown out is still preserved in the bumpmaps, thus making the quality hit less perceptible.

-- Tom

P.S.: Where's this quote from?

WhatEver
05-05-2002, 11:52 AM
You can respond to the guy here: http://www.burial-grounds.com/ubb/Forum1/HTML/008413.html

He is making me doupt what I know. Am I wrong???

Let me know so I can re-itterate what I know.

WhatEver
05-05-2002, 11:53 AM
Oh yeah, I'm WEAT over there, look for the yellow text. The guys handle is [AF]haste.

Gorg
05-05-2002, 12:11 PM
On this web site http://doomworld.com/files/doom3faq.shtml#What%20sort%20of%20engine%20will%20 Doom% 203%20use? (http://doomworld.com/files/doom3faq.shtml#What%20sort%20of%20engine%20will%20 Doom%203%20use?)

you can find some details on how they possibly do it. You need to scroll down where they talk about the details.

I am in way saying this is what id really does.


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

WhatEver
05-05-2002, 12:36 PM
Good read Gorg! The guys explanation is convincing...but how can they execute the calculation for one model with a lot of tris and then apply the result to a low tris model? I would think just that alone would be processor intensive....wheather it's the CPU or GPU.

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

R-C
05-05-2002, 01:10 PM
Originally posted by WhatEver:
[B]Good read Gorg! The guys explanation is convincing...but how can they execute the calculation for one model with a lot of tris and then apply the result to a low tris model? I would think just that alone would be processor intensive....wheather it's the CPU or GPU.
B]

The explanation in Gorg's link pretty much explains WHY they're using the high-poly models. The HOW is almost certainly by using a technique called 'Appearance Preserving Simplification' - basically a preprocess which takes a high-poly model as input and outputs a low-poly model plus a normal map (or bump map, or whatever). There's the SIGGRAPH paper where this was introduced available at http://www.cs.unc.edu/~geom/APS .

Rich



[This message has been edited by R-C (edited 05-05-2002).]

WhatEver
05-05-2002, 01:19 PM
That's amazing!

I have a lot to learn still...but I guess it never ends http://www.opengl.org/discussion_boards/ubb/smile.gif

knackered
05-05-2002, 01:24 PM
It's similar to something I did with a waterscape. I ran a high-res tileable cycling water simulation over 256 frames, and saved the results into 256 normal maps. Then, at runtime, I run a low-res water simulation up to the horizon, using the animated high-res bumpmaps to do environment bumpmapping. The end result is something that looks strikingly high res.
They're using the same principle here, I suppose.

SirKnight
05-05-2002, 02:37 PM
I've always wondered how to do that technique. Thanks for posting the link R-C! http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

WhatEver
05-05-2002, 02:46 PM
So are they going to start incorporating some of these cool new methods into todays modelers? I just bought LW[7] and it sure doesn't render complex scenes real-time very quickly...or is the implimenation not compatible with a system that's designed to generate models?

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

R-C
05-05-2002, 03:06 PM
Originally posted by WhatEver:
So are they going to start incorporating some of these cool new methods into todays modelers? I just bought LW[7] and it sure doesn't render complex scenes real-time very quickly...or is the implimenation not compatible with a system that's designed to generate models?

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

By 'render complex scenes real-time', do you mean the interactive preview? If so, then this kind of stuff isn't of much use - the conversion times are likely to be of the order of minutes/hours (not seconds), so don't allow you to alter a model and immediately see results. There could be some use in using this kind of technique for objects that you're not altering (background scenery, for example), but in practice it's probably easier just to hide or only show the bounds of the stuff you're not interested in.

Basically, it isn't that its not compatible, just too slow - use as a preprocess, but not interactively.

SirKnight: You're welcome. If you're really keen, I've got the PhD thesis it came from .. http://www.opengl.org/discussion_boards/ubb/smile.gif

Rich

[This message has been edited by R-C (edited 05-05-2002).]

SirKnight
05-05-2002, 03:09 PM
SirKnight: You're welcome. If you're really keen, I've got the PhD thesis it came from ..


Cool, id like to see that too. http://www.opengl.org/discussion_boards/ubb/smile.gif The more graphics papers i can get the better. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

WhatEver
05-05-2002, 03:10 PM
I read some of the Appearence Preserving Simplification white papers. It sounds like a method that's used to preserve the models original shape without much loss of quality when reducing the triangle count.

The artical pointed out by Gorg mentions a method that uses a high res model but only uses it to generate the nessasary shadow and color information to apply to a simplified low tri model. So that way only like 1.5k models will turn out looking better.

That's how it sounded to me anyway.

All this stuff is very interesting.

WhatEver
05-05-2002, 03:12 PM
So the technique is something you do before hand...not real time? So it's something you would do in your modeler?

R-C
05-05-2002, 03:28 PM
SirKnight: PhD here (try any of the links in the top right corner; at least one usually works ..) http://citeseer.nj.nec.com/cohen99appearancepreserving.html Chapter 5 has all the bump map stuff; the rest is pretty much a prelude (LOD techniques, error metrics ..). Enjoy http://www.opengl.org/discussion_boards/ubb/smile.gif

Whatever: It's definitely something you do beforehand -
Modeller -> Generate LowPoly Model/BumpMaps -> Engine

You could conceivably add it as a back end to the modeller (run after completing the model, but before exporting it), which would at least give artists a way of specifying various parameters controlling the bump-map generation etc.

Rich

zed
05-06-2002, 12:50 AM
carmack posted recently on the poly counts of doom3 (i forget but i think it was about 100-200,000 polys a level (ie not per frame)
unreal 2 will have higher poly counts but looks a lot worse (in fact i can hardly see the difference from ut)

its not a question of polygon counts, more a question of what u do with them!

dbugger
05-06-2002, 01:58 AM
I think Doom3 will be using some advanced LOD-algo, at least for the characters. The bumpmapping-technique used in D3 sounds interesting.
Btw. nice thread!

WhatEver
05-06-2002, 04:40 AM
Thx dbugger. I had two things in mind when I created this thread. First it was to get some answers on the subject, and the other was to provoke some thinking for me and possibly some others.

R-C, I understand now about the poly reducing method, thx for clearing it up.

lgrosshennig
05-06-2002, 07:56 AM
Interesting... In the interview the guy also stated that the high poly models are actually used to calculate light- and shadowsmaps in game.

I wonder how often those are calculated since one 500k poly modell weights in a couple of megabytes and hence trashes the caches for good let alone bringing the memory subsystem to its knees.

Sure they most likly use octrees or something similar when they do that but I am just thinking what will happen when there are mulitple players/bots/modells "onscreen".

Hmmm good food for thoughts I think http://www.opengl.org/discussion_boards/ubb/smile.gif

LG http://www.opengl.org/discussion_boards/ubb/biggrin.gif

LaBasX2
05-06-2002, 11:04 AM
Have a look at what Crytek will be releasing soon:
http://www.crytek.de/polybump/index.php?sx=polybump

That will definately be a cool toy for any modern engine that supports per pixel lighting http://www.opengl.org/discussion_boards/ubb/smile.gif

WhatEver
05-06-2002, 12:34 PM
LaBasX2, that HAS to be what DOOM 3 is going to use. That is REALLY cool!

jwatte
05-06-2002, 06:58 PM
lgrosshennig,

I think those light and bump maps for models are calculated exactly once: at export time. Once the game loads the data, it's already much lower res, with the difference made up in the maps applied.

lgrosshennig
05-06-2002, 10:49 PM
jwatte I agree with you on the bumpmaps, calculating those take some time but how would you precalculate the lightmaps for the model?

From what I have seen so far every lightsource effects a model in Doom3 as well as every object casts shadows on every other object.

From what I have read in FAQ at doomworld the guy says that they use the highpoly model inside the game as well as the lowpoly model (the highpoly model is used for lightmap and shadowmap computation at runtime). IMHO what would require one hell of an optimization job or an very clever algorithm (if the guy wasnt mistaken what I think is the case).

Its worth thinking about that for a monent if its:

a. makes sence
b. would increase image quality
c. is possible at all on current hardware (assuming a decent framerate)

Well I personly doubt that it would make much of a difference quality wise (the bumpmaps make the difference) on the other hand I havent tried that yet.

Anyway as I said, its good food for thoughts nevertheless.

zed
05-06-2002, 11:17 PM
>>jwatte I agree with you on the bumpmaps, calculating those take some time but how would you precalculate the lightmaps for the model?<<

easy u have a 100,000 tri model + a 1000 tri model right?
thus each lowres tri has approx 100 tris in it, (which means 100+ vertices inside the 3 verts of the triangle) each of the these verts can be uses as a height sample extrapolate the in between ones for the rest + u have a bumpmap.
hmmm did u understand that?

btw im doing something similar with displacement mapping + have changed my tune, displacement maps are quite a bit better looking than bumpmaps http://www.opengl.org/discussion_boards/ubb/smile.gif

lgrosshennig
05-07-2002, 12:51 AM
Well I understand that. But actually we are talking about 500K & 1500 tris per model.

the 500K one takes approx 12MB of RAM (assuming around 250k verticies) going through that takes some time and cant be done on a per frame basis (it probably takes some seconds for the reduction). Havent tried it yet though.

Anyway you need the high poly model in the game. If you want a shadow that looks realistic you have to calculate it from the highpoly one since the bumpmaps only fake the details and the shadow casted by the lowpoly model would not match its visual apperance, right?

Tom Nuydens
05-07-2002, 01:16 AM
lgrosshennig, there is no precalculated lighting in Doom3. They precalculate bumpmaps, but no actual lighting.

As mentioned above, what they do is simplify the high-poly model offline, and generate bumpmaps on which they recreate the discarded details. From then on, I don't see why the high-poly one would ever need to be touched again.

It's the low-poly one that gets rendered in-game. Because the bumpmaps don't affect the model's silhoutte, it's perfectly okay to let the low-poly model cast the shadows.

-- Tom

dorbie
05-07-2002, 01:24 AM
If you think about it, when you look at a low polycount model with a bump map reconstructing the high resolution version, the silhouette of that object is a low polycount silhouette. So it's not just the shadow that suffers, but it doesn't seem to matter too much. There's a limit but you get away with many fewer polys than you need in the high resolution model. I'd say the shadow shape is probably the least of your worries, an approximation should be fine, especially if the visible outline of the object is acceptable.

Mazy
05-07-2002, 01:45 AM
did i miss some link or something, or what program or techique do they use to translate the highpoly model to textures and give the texturecoords to the lowleelmodel?? seams like a dull job (hope that someone allready have done this :-)

lgrosshennig
05-07-2002, 01:56 AM
Before I look like a complete fool:


Now, the hi-poly is user for shadow/bump calculations. Since it's not being rendered, it doesn't need all that skin data, but the model keeps eating a fair amount of RAM.

Anyway, we have 2 models. The hi poly model is being hit by the lightrays in the game, resulting in both shadow/highlight pixel values, and bumpmap results.

Have you ever seen a really good texture job in a model? It generally makes up for the jaggy edges. Now, taking this data in account, the textures will be upgraded by both the shadows and the bumpmaps in real time, as I explained in my article. But this time the position data comes from a MUCH MORE ACCURATE model, meaning that the result will not match the low poly mesh, but actually looking better.

So is it just my weak Englisch or is he saying that they use the highpoly model for certain computations in the game (sure they DONT draw it)?

Pentagram
05-07-2002, 04:53 AM
How would they use the high poly models to cast shadows without ever drawing them? You use stencil shadows and then you have to render them (twice even), or you use a shadowmap and then you render them + readpixels.
I don't think that this is possible with multiple 250k models.

lgrosshennig
05-07-2002, 05:04 AM
That is EXACTLY my point.

I know how its "usally" done today, I appreciate the effort but I dont need to be educated in this area anymore.

Just because everybody is doing it "that" way people tend to think its the "only" way (if the only tool you know is a hammer, then every problem looks like a nail) http://www.opengl.org/discussion_boards/ubb/wink.gif

I was trying to tease people to come up with new ideas looks like I failed.

O well, we will see how and what they do when Doom3 comes out.

Thx for nothing.

Gorg
05-07-2002, 07:44 AM
Originally posted by lgrosshennig:
Before I look like a complete fool:

So is it just my weak Englisch or is he saying that they use the highpoly model for certain computations in the game (sure they DONT draw it)?

I believe the guy is talking out of his ass on this one. He posted other comments on the forum. He seems knowledgeable, but not very technical.

They are in no way drawing it, because they don't need to. Shadows can look nice from low-poly objects. Just look at operation flashpoint.

zed
05-07-2002, 11:08 AM
>>Just because everybody is doing it "that" way people tend to think its the "only" way (if the only tool you know is a hammer, then every problem looks like a nail) <<

not me mate, ive explored at least 6-8 different methods of producing shadows + ive prolly only just scrapped the top of the barrel.
as ive stated before on these forums, i dont believe doom3 is using stencil shadows ( a red herring), we're gonna have to wait and see to see if im RIGHT

knackered
05-07-2002, 11:39 AM
Carmacks reversal?
I don't understand why you think they need to toss a red herring into things.

davepermen
05-07-2002, 12:03 PM
if you think logical then you get those results:
they create highresmeshes in the editor
they sample them down and generate like that lowresmeshes with bumpmaps etc..

they use those meshes in the game

everything else is just not possible on a simple pc with a simple gf3

they use stencil shadow volumes
thats why carmack worked so hard to get a perfect solution (and found carmacks reverse)

there are no other ways for getting shadows more or less easy for pointlights. there are no cubic shadow maps possible without a lot of hacking around on todays hardware.. and carmack did not made that sort of hack (else we would see demos of this and descriptions how to do this..)

and i think it will not look _THAT_ impressive after all.. http://www.opengl.org/discussion_boards/ubb/smile.gif

hope it'll be fun to play.. the most important part for me..

lgrosshennig
05-07-2002, 12:18 PM
Originally posted by Gorg:
I believe the guy is talking out of his ass on this one. He posted other comments on the forum. He seems knowledgeable, but not very technical.

They are in no way drawing it, because they don't need to. Shadows can look nice from low-poly objects. Just look at operation flashpoint.


Wow!!! Knowlegdeable **** man I am flattered!

The forum is all yours dude.

What I wanted to say was that they of course dont draw the hipoly model (I have to admit I placed the question mark at an odd place it was intended for the sentence before the brackets).

That "Sure they DONT draw the hipoly model" was meant to be a statement not a question.

I never said lowpoly shadows look bad but if you would take the time and review the footage about Doom3 (the mpeg file not the crapy asf file) you would notice that the shadows look awesome and dont look like projected from a low-poly model (but I am probably just talking out of my ass again).

Gorg I prefer to do/think about new stuff, so you do what ever suits you.

CASE CLOSED

dorbie
05-07-2002, 12:29 PM
Dude you'll only look like a complete fool when you get defensive and insist on defending a position that is obviously incorrect and has been demonstrated to be so by the underlying principal of the method being used.

Once again, if when you draw the low polycount object the silhouette is acceptable then it should be more than enough complexity for your shadow. Most other calculations like collision, shadows etc actually require less poly complexity than the primary visual representation IMHO. Feel free to form your own opinion and code accordingly.

You're not fooling anyone pretending to be the one with the open mind. You and your thoughts should be able to stand some friendly scrutiny (knackered's comments aside).

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

SnowKrash
05-07-2002, 02:01 PM
Zed:

You seem a little paranoid with this red herring talk. In my mind, John Carmack has always been honest and as open as commerically possible regarding the directions he takes with his engines. There is ample information linking the DOOM3 engine and stencil shadows (eg http://www.shacknews.com/onearticle.x/15230/ ). He did say, maybe in a .plan, that he was considering taking another look at shadow maps but it stands that he considers stencil volumes a viable method, to the degree that he's spent time optimising for static cases (gamespot video interview).

Oops, I missed daveperman's reply. I can definitely concur that cube map shadow maps are hacky given present format/rendering restrictions.

[This message has been edited by SnowKrash (edited 05-07-2002).]

davepermen
05-08-2002, 02:39 AM
Originally posted by lgrosshennig:
I never said lowpoly shadows look bad but if you would take the time and review the footage about Doom3 (the mpeg file not the crapy asf file) you would notice that the shadows look awesome and dont look like projected from a low-poly model (but I am probably just talking out of my ass again).

show me the mpeg file where you can actually see the shadow sharp! i never found one running on 1024x768 without lossy compression.. and when its running on 320x240 with compression i'm sure you would not even recognise the difference between the used model and a goldeneye-model (350 faces)

you're really talking bull****.. how do they want to generate shadows without drawing the mesh? there IS NO WAY.. if you do it projected, you have to project the mesh, if you generate volumes, you have to generate the volume from the mesh, if you generate shadomap, you have to render the mesh onto the shadowmap

and BY NO CHANGE even one of those meshes run smooth with all the geometry on a simple gf3..


you don't know anything about shadowing as it looks like

and..

as they possibly use 5000faces per mesh for the game, this is a pretty high res shadowvolume they generate from this.. never seen such an accurate shadow before!


and they use shadow volumes. if you would read the papers from carmack, if you would read papers about how to do shadows in general you would know what you're talkin about

but the way you act you can only get flamed, sorry..

knackered
05-08-2002, 03:23 AM
Dorbie, discounting my comments will be your loss. http://www.opengl.org/discussion_boards/ubb/smile.gif

Carmacksutra
05-08-2002, 04:32 AM
Originally posted by davepermen:
you're really talking bull****.. how do they want to generate shadows without drawing the mesh? there IS NO WAY..

Horizon Mapping
http://research.microsoft.com/~cohen/bs.pdf


[This message has been edited by Carmacksutra (edited 05-08-2002).]

Gorg
05-08-2002, 07:12 AM
Originally posted by lgrosshennig:
Wow!!! Knowlegdeable **** man I am flattered!

The forum is all yours dude.

What I wanted to say was that they of course dont draw the hipoly model (I have to admit I placed the question mark at an odd place it was intended for the sentence before the brackets).

That "Sure they DONT draw the hipoly model" was meant to be a statement not a question.

I never said lowpoly shadows look bad but if you would take the time and review the footage about Doom3 (the mpeg file not the crapy asf file) you would notice that the shadows look awesome and dont look like projected from a low-poly model (but I am probably just talking out of my ass again).

Gorg I prefer to do/think about new stuff, so you do what ever suits you.

CASE CLOSED


I am not sure how you got that I was talking about you lgrosshennig.
I was talking about the guy that wrote the original segment of the FAQ in link I gave and I was talking about the doomworld forums.

BTW. I do not dismiss anything you say or anything he said. I am just saying that he could well be talking out of his ass because in his other posts (about the same time he posted those things) there we other "supect speculative assertions".

zed
05-08-2002, 12:44 PM
>>You seem a little paranoid with this red herring talk. In my mind, John Carmack has always been honest and as open as commerically possible regarding the directions he takes with his engines. There is ample information linking the DOOM3 engine and stencil shadows<<

true, carmack has always be4en honest + all the evidence opoints to stencilshadows, all im saying is ppl should keep an open mind. there are a lot more ways of doing shadows than shadowbuffers + stencilshadows. eg IIRC carmack mentioned something a while ago about doing lighting with 3dtextures http://www.opengl.org/discussion_boards/ubb/smile.gif. myself ive tried a lot of different ways from projected shadows all the way up to global illumination. IIRC before quak3 there was also a lot of false speculation from ppl about how things were gonna be done.

zed (writing from my new rented house in dunedin the cloudy city http://www.opengl.org/discussion_boards/ubb/smile.gif)

lgrosshennig
05-08-2002, 01:13 PM
Gorg: I am sorry I had a bad day and for some reason felt offended by your post.

Dave: I know what I am talking about. I tried shadow volumes and shadow maps but dropped them.

You want to know why? Ok here is an example (you can use shadow volumes or shadow maps it doesnt matter):

1.) You take a bumpmapped object
2.) You take another bumpmapped object that casts a partial shadow on the 1st one.

Yeah right the part from the 1st object that falls into the shadow of the 2nd looks like crap (it looks like it wasnt bumpmapped at all).

If that is ok with you, fine stop reading here.

That doesnt suit my needs though.

Since I realized that, I was thinking about how that could be done in a different way.

And finaly Camarksutra pointed me to the right idea. The pdf about horizon mapping only covers selfshadowing bumpmaps, but how about using a shadowmap to alter a bumpmap instead of just blending it with the shadowmap?

So the shadowmap would change the normals in the bumpmap. That means the "shadowmap" redirects the covered normals in the oposite direction from the lightsource (to a certain extend).

(Hmmm I hope my Englisch was good enought for this, sounds a bit strange though)

Before you flame away, I dont care about todays hardware I am focused on tomorrows hardware.

Dave, no offense but you only seem to know the hammer.

Did it ever crossed your mind that meshes that have a certain spatial density can be viewed as a pointcloud (at a given range of scale)?

So what I am doing to create shadowmaps from objects with a high vertex count goes like this:

I generate the lightsource matrix multiply it with the modelmatrix (for simplicity I cancel out bone animation for now) and do a crute and bruteforce (oldschool) CPU transformation that results in a black pixel for every vertex in my shadowmap.

The first completly unoptimized SSE version that came straight out of my (insert what ever you want) took less then 20ms to generate a 512x512x32 shadowmap for an object with 200K verticies. After some optimizations I got it down to less then 10ms on a 1.5Ghz P4 and I still see room for improvements.

I dont expect you to believe this so I gonna put an paper/example together (crap I did not want to reveal anything before my engine was ready, but sh!t happens).

Have a nice day!

davepermen
05-09-2002, 11:17 AM
horicon shadowing can't cast shadows of objects.. its thought for heightmaps (as well as bumpmaps) as a hard approx (light very far away. don't try to use this map for lights on your landscape like a fire or something..)
okay i've realised horizon mapping can be used for arbitary meshes, but its only for the mesh itself... its cool looking anyways

shadow maps are NOT useful as long as you can't use cubemaps.. this fact is true and will always be true. the lights i've seen on the video are not directed, so they CANT be done by a shadowmap..

are your shadowmaps maps of an object or depthmaps? if its the first, its stupid anyways cause its never a general solution for a whole scene.

the whole shadowmap then means you have a readback and writeback of the whole shadowmap? i guess in this case it would be more efficient to draw the mesh overthere directly http://www.opengl.org/discussion_boards/ubb/wink.gif (use GL_POINTS mode.. http://www.opengl.org/discussion_boards/ubb/smile.gif)

why using bumpmaps at all then? you see as well on the screen that those bumps are wrong cause not displaced. and on most cases, this is much more of a problem in my eyes.. except if you do terrible fullblackshadows, wich is bull**** anyways.. shadows are a good, but normally most of the time subtle effect, and should not be used to fill the screen.. they should add realism, and for this you have to use them wise.. if you use them like that, you don't even realise that they are there and so you don't care about the bumpiness of the shadow..

bether don't bump at all if you don't like this cause the scene does not look bumpier like that (the meshes i mean). i know this fact, you know this fact as well. so use a displacement map instead. for now i'll suggest you go for slicing, but on nextgenhardware we can fully program it ourselfes, so it will be quite soon be found a general fast solution.

but thill then i'll stick with lowres meshes..

and you'r demo will never run on my pc. first i would get my girlfriend back.

impossible

[This message has been edited by davepermen (edited 05-10-2002).]

Carmacksutra
05-10-2002, 05:53 AM
Originally posted by davepermen:horicon shadowing can't cast shadows of objects.. its thought for heightmaps (as well as bumpmaps) as a hard approx (light very far away. don't try to use this map for lights on your landscape like a fire or something..)
okay i've realised horizon mapping can be used for arbitary meshes, but its only for the mesh itself... its cool looking anywaysI wasn't thinking of Horizon-Mapping as standalone shadow algorithm, but as additional contribution to shadow result.

In this way it would fit to the Doom 3 speculations in this thread (the statement on generating shadow data from High-Poly-Model) :

1. Take High-Poly-Model and generate:
. a) Low-Poly-Model
. b) Displacement-Maps
2. Take Displacement-Maps and generate:
. a) Normal-Maps
. b) Horizon-Maps

Now render combined light & shadow from all 3 sources:
1. Low-Poly-Model (standard depth-map/stencil/projected/...)
2. Normal-Maps
3. Horizon-Maps

Gorg
05-10-2002, 08:26 AM
Since we are on the subject of the Doom 3 engine.

Is just me or it seems like there is no ambient component in the engine?

From the 2 movies, you see that if there is a shadow, nothing else is drawn under it. There are a few scenes when you can see color under the shadow, but it looks like it is a shadow from a semi-transparent object.

LaBasX2
05-10-2002, 08:38 AM
If you use ambient, the bumpmapping effect will be less visible, since unlighted pixels are still more or less bright. Personally I prefer having no ambient, especially for a dark industrial style game like doom3 since that will give a much better atmosphere.

DFrey
05-11-2002, 06:58 AM
I kinda suspect the cam's white balance setting was incorrect. That could hide any dark ambient term.

davepermen
05-11-2002, 07:07 AM
come on guys, the whole video is crap in quality. i have seen bether stuff yet, just because i don't see those fancy features really in that crappy video.

wait for e3. then we get screenies,videos etc en masse..

and i say: they have simple bumpmapped meshes with shadowvolumes. not fancy spherical harmonics to have cubemaps perpixel etc. simple normalmaps dotted and specular. why? they need a lot of lights smooth. that means nnot the most accurate lighting but fast lighting. fast perpixel lighting. that means: phong. at max..

dorbie
05-13-2002, 05:09 AM
knackered,

I would never discount your comments. You obviously know your stuff, I was referring to the 'friendly' part, but either I was mistaken or you deleted a comment I had in mind. I'm not going to pour over the thread again looking for what I might have been referring to at the time.