Unreal 3 Engine and SM 3.0
- Thread starter Ashaman52
- Start date
Well, this is engine technology, not a game demostration - its in Epics best interested to have a flexible engine to make it attractive to as many clients as possible. What features they support in their own game is up to them.
You're totally right, it's only that it looks like 3 different engines are packed into one, and you have to wonder how well each individual approach is developed and optimized.
I've looked at the screenshots again - no sharp shadow edges anywhere, but some look like AAd or post processed stencil shadows cast on the ground here:
http://www.unrealtechnology.com/screens/RagDoll.jpg
I've looked at the screenshots again - no sharp shadow edges anywhere, but some look like AAd or post processed stencil shadows cast on the ground here:
http://www.unrealtechnology.com/screens/RagDoll.jpg
Static light, static object:
precomputed light occlusion term either per vertex or texel (if mesh is uniquely unwrapped)
Static light, dynamic object:
per object shadow depth buffer, resolution based on the screenspace size of the shadow bounding sphere
Dynamic lights:
stencil shadow volumes
The different approachs work together nicely as they only contribute the light occlusion at a given pixel which is then used by the lighting shader so the only visual difference you see is the amount of fuzzyness in the shadow. The reason for mixing the three approachs is that neither of them alone would be sufficient for the kind of vivid environments we want to create.
-- Daniel, Epic Games Inc.
precomputed light occlusion term either per vertex or texel (if mesh is uniquely unwrapped)
Static light, dynamic object:
per object shadow depth buffer, resolution based on the screenspace size of the shadow bounding sphere
Dynamic lights:
stencil shadow volumes
The different approachs work together nicely as they only contribute the light occlusion at a given pixel which is then used by the lighting shader so the only visual difference you see is the amount of fuzzyness in the shadow. The reason for mixing the three approachs is that neither of them alone would be sufficient for the kind of vivid environments we want to create.
-- Daniel, Epic Games Inc.
Laa-Yosh said:
I suppose anything that uses Unreal Engine 3 is running around 25 to 35 FPS on the new cards .... I mean, whether the app. is a demo or a game would not make too big of a difference, IMO, if they are both using the same engine (Unreal Engine 3).. of course there will be differences, (i.e.: games might be calculating more physics and AI, while demos may be slightly more shader intensive, etc.).. (also, depending on the tech demo, I suppose the demo might have less objects/characters on the screen at one time, than a game would have) ............ also, note that "25 to 35 FPS" is quite a large range (i.e.: 35 FPS is 40% more performance than 25 FPS)pc999 said:
Mirrors for the Unreal Engine 3 E3 2004 demonstration video:
http://download.beyondunreal.com/fileworks.php/demos/unreal3engine_e3.zip
http://www.sonsofvanu.com/dl/pafiledb.php?action=file&id=24
http://www.hardwired.hu/dl.hw?id=2300
It's cam footage, not direct feed and it's a 160MB MOV. Some of the parts in the video are "old" GDC footage but there's also lots of new AMAZING stuff showed. This new video is much more of an experience than the old crappy quality GDC cam. Too bad the pre-recorded narrator is not Tim Sweeney
The picture quality is good. This is definitely worth a download
http://download.beyondunreal.com/fileworks.php/demos/unreal3engine_e3.zip
http://www.sonsofvanu.com/dl/pafiledb.php?action=file&id=24
http://www.hardwired.hu/dl.hw?id=2300
It's cam footage, not direct feed and it's a 160MB MOV. Some of the parts in the video are "old" GDC footage but there's also lots of new AMAZING stuff showed. This new video is much more of an experience than the old crappy quality GDC cam. Too bad the pre-recorded narrator is not Tim Sweeney
The picture quality is good. This is definitely worth a download
DemoCoder said:
Actually, it's not (EXT_depth_bounds_test). It's a comparison using the depth value stored in the (static) depth buffer. The depth buffer acts as a "volume mask" if you will.
Code:
This extension adds a new per-fragment test that is, logically,
after the scissor test and before the alpha test. The depth bounds
test compares the depth value stored at the location given by the
incoming fragment's (xw,yw) coordinates to a user-defined minimum
and maximum depth value. If the stored depth value is outside the
user-defined range (exclusive), the incoming fragment is discarded.
Unlike the depth test, the depth bounds test has NO dependency on
the fragment's window-space depth value.I agree, which is why I said "likely". Sometimes devs dont show off their progress, till the last year or so. Like HL2, until this time last year, we didnt have any movies, or screen shots of it. While its still not out, it was kept secret for a long time, since they began working on it right after the first HL was released.
vogel said:
Thank you for your answers. A few more questions
- are stencil shadows hard-edged, or is there some post-processing blur on them as some people have speculated?
- have you looked into Zbrush2 for creating normal map detail? I`d expect it to cut the high-res model creation time in half...
