CryENGINE 3

[MJP]

15fps on this scene with DoF, 17fps without. I'd really like to know how they've done it so cheaply.

Going from 15fps to 17fps means it's taking 8ms, which is hardly what I'd call cheap.

 

[NotTarts]

Going from 15fps to 17fps means it's taking 8ms, which is hardly what I'd call cheap.

CryENGINE 2's regular DoF had around the same (if not worse) performance hit, so I'd say it's still a pretty substantial improvement over what they had before.

Also, wouldn't it be something like 3-4ms at 30fps?

 

[MJP]

CryENGINE 2's regular DoF had around the same (if not worse) performance hit, so I'd say it's still a pretty substantial improvement over what they had before.

Also, wouldn't it be something like 3-4ms at 30fps?

Never measured it myself, but I really doubt that they spent 8ms doing a gaussian blur.

The cost of something won't change depending on the framerate. If it's 8ms at 15fps, it will take 8ms at 30 fps. The difference in fps will change, because fps is non-linear. So at 30fps spending an extra 8ms on DOF will bring you from 33ms to 41ms, which would bring you down to about 24fps. Or if you were at 100fps, it would bring you down to about 55fps.

 

[NotTarts]

Never measured it myself, but I really doubt that they spent 8ms doing a gaussian blur.

The cost of something won't change depending on the framerate. If it's 8ms at 15fps, it will take 8ms at 30 fps. The difference in fps will change, because fps is non-linear. So at 30fps spending an extra 8ms on DOF will bring you from 33ms to 41ms, which would bring you down to about 24fps. Or if you were at 100fps, it would bring you down to about 55fps.

Ah, ok. I was referring to different hardware (as in, hardware capable of running the scene at 30fps) but I guess that doesn't make sense here.

Anyway, I did some measurements on my old PC, both engines at the highest settings available and at 640x480:

CryEngine 3 (bokeh DoF):
With DoF: 14.2fps
Without DoF: 15.8fps
Cost: 7.7ms

CryEngine 2 (regular gaussian DoF):
With DoF: 19.5fps
Without DoF: 22.9fps
Cost: 8.7ms

I'm thinking that the CryEngine 2 DoF blur was just badly written or unoptimised (or it could just be a glitch).

 

[_phil_]

8.7 ms to do gaussian blur is completly insane.There is definitely something wrong here.

 

[Neb]

8.7 ms to do gaussian blur is completly insane.There is definitely something wrong here.

It's more than gaussian blur though. It would be best if debug stats are viewed. NoTarts, doubleclick on the console prompt in either CE2 or CE3 and then in the new cvar window type search term "debug"/"profile" to get which cvar shows render times for effects.

EDIT: Ah buggy CE2 editor with my drivers but DOF is less than 1ms on my 4890 for empty scene and max strength and whole viewport affected.

 

[L. Scofield]

Since talking about the leak is OK here, I assume this is permitted as well:

CryEngine 3 SDK Documentation
http://wenku.baidu.com/view/de6494db6f1aff00bed51e72.html

There's a lot of great stuff there

There are also links (I won't post them unless a mod gives approval) to the scripting manual and the technical doc (things about lighting, animation,e tc...).

 

[Arwin]

Since talking about the leak is OK here, I assume this is permitted as well:

CryEngine 3 SDK Documentation
http://wenku.baidu.com/view/de6494db6f1aff00bed51e72.html

There's a lot of great stuff there

There are also links (I won't post them unless a mod gives approval) to the scripting manual and the technical doc (things about lighting, animation,e tc...).

Interesting read indeed.

This version of the document looks somewhat old ... Also, I get a strong feeling that they at the very least didn't implement any vertex culling or anything like that on PS3, since they specifically say that in order to keep things with decent performance on PS3, you need to keep under 2000 drawcalls.

 

[Neb]

Also, I get a strong feeling that they at the very least didn't implement any vertex culling or anything like that on PS3, since they specifically say that in order to keep things with decent performance on PS3, you need to keep under 2000 drawcalls.

I dont see how you can extrapolate that no vertex culling is used based on a limit of 2000 draw calls. What comsumes draw calls most are shader effects, amount of unique non instaced objects, particles and more. In Crysis the shader effect to make vegetation procedurally sample terrain color to get vegetation object color more grounded to the scenery was between 500-1500 draw calls. Though that effect for Crysis 2 (if used for consoles to) will be cheap as there is very little vegetation compared to Crysis.

 

[Ruskie]

What the "feck"?20 ms for geometry?

 

[AlNom]

since they specifically say that in order to keep things with decent performance on PS3, you need to keep under 2000 drawcalls.

You always want to keep drawcalls to a low amount.

 

[Lucid_Dreamer]

Since talking about the leak is OK here, I assume this is permitted as well:

CryEngine 3 SDK Documentation
http://wenku.baidu.com/view/de6494db6f1aff00bed51e72.html

There's a lot of great stuff there

There are also links (I won't post them unless a mod gives approval) to the scripting manual and the technical doc (things about lighting, animation,e tc...).

Great post!

Does anyone know what is meant by, "Use all 4 SPUs again for ParticleUpdates..."? Does their engine only use 4 SPUs? Also, it says that shadow occlusion culling on PS3 can peak >20ms stalling other physic tasks!

I see a lot of fixes for multithreading issues. Did they mention having multithreading difficulties with their engine?

 

[Arwin]

I dont see how you can extrapolate that no vertex culling is used based on a limit of 2000 draw calls. What comsumes draw calls most are shader effects, amount of unique non instaced objects, particles and more. In Crysis the shader effect to make vegetation procedurally sample terrain color to get vegetation object color more grounded to the scenery was between 500-1500 draw calls. Though that effect for Crysis 2 (if used for consoles to) will be cheap as there is very little vegetation compared to Crysis.

Because they say so specifically in the document, just as that they say that this is a specific RSX bottleneck.

 

[L. Scofield]

Since no mod said no, here are the other two documents:

SDKDOC5-100234-15136.rar (1.96 MB) (scripting manual)
http://www.multiupload.com/9WNTIY7N7D

SDKDOC4-102931-15140.rar (4.53 MB) (Technical documentation)
http://www.multiupload.com/U424E31P63

I love the IBL. No more boring uniform albedo diffuse as ambient lighting, now it supports what basically amounts to skyboxes with ambient specular, hell yeah!

 

[forumaccount]

Since no mod said no, here are the other two documents:

Pretty impressed with their SPU setup. It's pretty similar to the Codeplay Offload middleware but all done in-house. It's a great strategy for generating lots and lots of relatively-poorly performing SPU code without a huge amount of programmer time.

In a cross platform engine the sheer amount of code this technique lets you offload onto the SPUs will usually make up for the poor performance of said code. Mostly, though, it's impressive because of the amount of infrastructure a strategy like this requires.

Someone asked about the 4 SPUs above... they reserve one for graphics buffer work and only give four to the job system. If you're wondering about the leftover SPU, it's used for low priority tasks and middleware which is what most games do.

 

[KKRT]

Since no mod said no, here are the other two documents:

SDKDOC5-100234-15136.rar (1.96 MB) (scripting manual)
http://www.multiupload.com/9WNTIY7N7D

SDKDOC4-102931-15140.rar (4.53 MB) (Technical documentation)
http://www.multiupload.com/U424E31P63

I love the IBL. No more boring uniform albedo diffuse as ambient lighting, now it supports what basically amounts to skyboxes with ambient specular, hell yeah!

Hmm interesting all assets from CryEngine 2 can be transfered to CryEngine 3, except textures that have to be converted first. It shouldnt be long time when we'll see custom maps from CryEngine 2 working on CryEngine 3.

 

[L. Scofield]

A few images to show off/compare the IBL vs regular diffuse ambient:

No direct lighting

Diffuse ambient
http://www.abload.de/img/ibl_off_01ucsz.png
IBL on (diffuse)
http://www.abload.de/img/ibl_01a4o4t.png
IBL on (diffuse + specular)
http://www.abload.de/img/ibl_01b0svt.png

Direct lighting

Diffuse ambient
http://www.abload.de/img/ibl_off_02ghpw.png
IBL on (diffuse)
http://www.abload.de/img/ibl_02ahc3q.png
IBL on (diffuse + specular)
http://www.abload.de/img/ibl_02b9dj5.png

Direct lighting + light bounce

Diffuse ambient
http://www.abload.de/img/ibl_off_033e5f.png
IBL on (diffuse)
http://www.abload.de/img/ibl_03aoezd.png
IBL on (diffuse + specular)
http://www.abload.de/img/ibl_03byfvf.png

 

[Arwin]

Also gives further confirmation that:

Backface Culling
Usually backface culling is a no-brainer for graphics programmers. Depending on the triangle orientation (clockwise or counter-clockwise realtive
to the viewer), hardware does not need to render the back-facing triangles and we get some speedup. Only for some alpha blended objects or
special effects we need to disable backface culling. With the PS3 this topic needs to be reconsidered. The GPU performance when processing
vertices or fetching data for vertices can be a bottleneck and the good connection of the SPUs to the CPU allows to create data on demand. The
overhead for SPU transformation and testing triangles can be worth the effort. An efficient CPU implementation could do frustum culling,
combining small triangles, back-face culling, mesh skinning and even lighting. This however is not a simple task. Besides maintaining this PS3
specific code path, the mesh data needs to be available in CPU memory. At the time this article was written we did not yet do this optimization
because of the shortage of main memory. We might reconsider this once we have efficient streaming from CPU to main memory (code using this
data might have to deal with one frame latency).

 

[_phil_]

A few images to show off/compare the IBL vs regular diffuse ambient:

No direct lighting


Direct lighting



Direct lighting + light bounce

You know , this is really classic stuff...
It's just a cubemap lookup.Diffuse is last mip map ,what you call diffuse + specular is just full rez of the same cubemap and this is not really specular just the sun rendered into cubemap .

 

[Arwin]

Mind you it is still a great engine (fake, partly fake or not fake at all, the lighting is almost Gran Turismo like in its accuracy) with killer tools. If I were Sony, I would probably take a high profile first party studio and licence this engine to make a game with it, and then optimise the bits that Crytek themselves have already indicated could be significantly optimised and give that code back to Crytek so it can be used in all Crytek licenced games.