CryENGINE 3

Billy Idol said:
thanks for the link!, there is even a direct timeing comparison of the scene for Xbox and PS at the end of the paper.

Can someone maybe explain me (in a way I can understand :) why the PS3 beats the other challengers in the categorie "LPV Lookup"? Lookup on PS3 is so fast that it catches up in timings and even overtakes the Xbox in the "no occlusion" test.

Is it solely due to the weak PS GPU that it gets beaten up in the rendering categorie, or are there any other reasons?
Click to expand...

The devil is in the details. In Crytek's previous PDFs they noted a quality drop on one of the consoles to make give it comparable performance...
 
Joshua Luna said:
The devil is in the details. In Crytek's previous PDFs they noted a quality drop on one of the consoles to make give it comparable performance...
Click to expand...

Do you imply that the PS3 scene got downgraded? I did not read the actual paper carefully enough, but I can't remember that they mention it here that the scene for PS3 got downgraded. They did not state either if the test uses solely the GPU of the consoles, or if for instance CELL was used to help out lazy RSX?!?
 
Crytek implies it ;)
And the final LPV rendering stage is much faster on PlayStation 3 because we use half-resolution rendering mode with MSAA remapping trick.
Click to expand...
From there previous presentation here
 
liolio said:
Crytek implies it ;)

From there previous presentation here
Click to expand...

Ah, ok. Thanks for the link!
Do you think that this is applicable to the actual paper as well?
As they did not discuss the timings in this paper, they did not state (if I did not missed it) differences in resolution.
 
Billy Idol said:
Ah, ok. Thanks for the link!
Do you think that this is applicable to the actual paper as well?
As they did not discuss the timings in this paper, they did not state (if I did not missed it) differences in resolution.
Click to expand...
I guess as the figure (in ms) from one presentation to another are the same. Anyway let not blow this out of proportion as in the end it might not get noticeable to human eyes ;)
 
Last edited by a moderator:
liolio said:
I guess as the figure (in ms) from one presentation to another are the same. Anyway let not blow this out of proportion as in the end it might not get noticeable to human eyes ;)
Click to expand...

Why wouldn't they do it on all versions if it's not noticeable?
 
this teaser mentioned in pdf is there online video somwhere? im very curious to see this crazy math in action.
 
liolio said:
Crytek implies it ;)

From there previous presentation here
Click to expand...

at Figure 9, the author said the light bleeding is caused by discretization error and filtering, I wonder if it has something to do with they numerically recover the GRADIENT of radiance not the FLUX of the radiance, since at discontinuous surfaces or grids, the gradient isnt the precise way to describe how lighting changes along the interfaces
 
homerdog said:
Why wouldn't they do it on all versions if it's not noticeable?
Click to expand...
It has to be noticeable what I meant was that "standard" people would not notice it. It was also to prevent some possible derailing of this thread, let's wait for the final product.
Jonsoncao said:
at Figure 9, the author said the light bleeding is caused by discretization error and filtering, I wonder if it has something to do with they numerically recover the GRADIENT of radiance not the FLUX of the radiance, since at discontinuous surfaces or grids, the gradient isnt the precise way to describe how lighting changes along the interfaces
Click to expand...
I was not trying to sund cleverer than I'm, I already have a tough time TRYING to understand what Crytek do :LOL: but I'm sure some members will answer you ;)
 
Does anyone know why the LPV stage is so much slower on the GTX 285? I assume its related to the RSM size being larger? Same for the propagation stage?
 
 
Last edited by a moderator:
The biggest advantage to Crytek's method is that it allows them to enable destructible environments with proper lighting. With the Unreal engine everything is baked in, so Epic will have a terrible time trying to do realtime destruction AND have the lighting look even remotely correct.

If I'm not mistaken...even Unreals AO is baked in, no? Seems like they are lightyears behind Crytek in this department. Don't get me started on id software....they appear to be going backwards not forwards in interactivity. Great for static scenes, but I think full dynamic realtime everything is going to be necessary in the near future for a viable engine.

Now...I hope Crytek will start showing its tech demos with updated assets....what's with the 5 polygon tree trunks and hideously squared off jeep :)
 
CNCAddict said:
The biggest advantage to Crytek's method is that it allows them to enable destructible environments with proper lighting. With the Unreal engine everything is baked in, so Epic will have a terrible time trying to do realtime destruction AND have the lighting look even remotely correct.

If I'm not mistaken...even Unreals AO is baked in, no? Seems like they are lightyears behind Crytek in this department. Don't get me started on id software....they appear to be going backwards not forwards in interactivity. Great for static scenes, but I think full dynamic realtime everything is going to be necessary in the near future for a viable engine.

Now...I hope Crytek will start showing its tech demos with updated assets....what's with the 5 polygon tree trunks and hideously squared off jeep :)
Click to expand...

Most Unreal Engine 3 games I've seen use some form of light maps.

But I think you need to appreciate that a technique being dynamic doesn't automatically make it "better" than a technique that pre-calculates some portion of the lighting equation. Their technique will cost them in terms of run-time performance and quality for a feature that most games don't need. It makes sense as part of their full editor/engine package where you have real-time updates, but whether that package is better than something like maya + light bake step is up for debate.

There are also techniques like PRT that assume static geometry to pre-calculate a portion of the lighting equation, but still allow you to change the overall lighting conditions. This lets you do things like dynamic time of day, but with a cheap run-time cost. So you don't always have to choose between "all dynamic" and "all baked".
 
You must log in or register to reply here.

Similar threads

S
Point light shadows work wrong, how can I debug it?
Replies
2
Views
912
JoeJ
J
Shortbread
Phil Spencer Interview: Redfall Reviews, Activision Deal - Kinda Funny Xcast Ep. 137
7 8 9
Replies
175
Views
12K
trinibwoy
T
S
NPD January 2022
Replies
1
Views
1K
Deleted member 11852
D
F
Shader Compilation on PC: About to become a bigger bottleneck?
46 47 48
Replies
955
Views
162K
Krteq
K
S
NPD December 2019 Results
Replies
0
Views
953
Silent_Buddha
S
Back
Top