Sign in to follow this  

CryEngine Terrain

This topic is 2213 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

While I understand the rest of the technology in CryEngine 2 and CryEngine 3 in detail, I can’t get any information about how they did their terrain at all.
Finally someone online said it was a mix between heightmaps and sparse voxel octrees. I asked for his source and he said it was in a German article he read (useless to me).

From [url="http://www.shacknews.com/article/60870/cryengine-3-released-to-devs"]this[/url] article I got that the ground is a heightmap and caves etc. are voxels, but this is not really the technical kind of discussion I was hoping to find.

If voxels are really only used for caves and overhangs, then I am still wondering how they got such huge visual distance out of their terrain.
Are they using ROAM? Chunks? Skirts? All of these, for me, still had too huge of an impact on FPS to be practical for such long viewing range.
Something new?

Any guesses on what they may have used, or any personal success stories from having used one of these systems before to achieve high frame rates over long viewing distances?


Thank you,
Yogurt Emperor

Share this post


Link to post
Share on other sites
If you use the search button perhaps you'll find multiple discussions about the voxel->polygon mesh conversion being done at preprocessing.

I cannot tell you any personal success story, but I can warn you by telling a story of failure. ROAM. Wasted effort. ROAM for generic meshes? Don't even get me started. Seriously. The scars still hurt.

Want to do LOD? Ok, either chunk or clipmaps (google "[url="http://research.microsoft.com/en-us/um/people/hoppe/gpugcm.pdf"]hoppe terrain clipmaps[/url]"). Both can scale to very large terrains given appropriate management. I'm actually more inclined to chuncking.

Extended view distance introduces a few extra problems however. [url="http://outerra.blogspot.com/2009/08/logarithmic-z-buffer.html"]Logarithmic Z[/url] is pretty awesome, but I don't know if it is doable for AAA games. Dual frusta techniques have in my opinion a few issues which perhaps can be worked out. In the past, I was planning to make an hybrid system using "far portals" and some render-texture but I didn't had the time to try it.

Share this post


Link to post
Share on other sites
I may find discussions regarding voxel-to-polygon conversions, but I would never knew to search that. My understanding was that they simply used voxels and polygons together, without conversion.
[url="http://www.gamedev.net/index.php?app=core&module=search&do=search&fromMainBar=1"]http://www.gamedev.net/index.php?app=core&module=search&do=search&fromMainBar=1[/url]

But basically you are saying they just convert voxels to polygons, so everything in the game is polygonal? That is helpful.

I get the same impression from ROAM, but [url="http://www.amazon.com/review/RZFJY1K80H3W1/ref=cm_cr_pr_viewpnt#RZFJY1K80H3W1"]this book[/url] talks about “new ROAM” and “ROAM 2.0- the latest in CLOD”. Any idea if these prove better than ROAM/your nightmares?


I am checking out [url="http://vterrain.org/LOD/Implementations/"]this page[/url] and can’t decide which has the most potential. I don’t have time to try them all since terrain is not the only thing on my slate. I need to get it right (at least the most promising foundation) the first time.
Chunked LOD looks good I think.

Also so does Clipmaps. Although I had my own ideas for minimizing space by storing the Y values separately from the X and Z, it wasn’t as simple as just putting them into a texture! That looks very promising and very fast. I am getting tons of ideas on how to vary this technique.

Log-Z is also an interesting idea. I don’t plan to have such a huge viewing distance, but I’m making a game engine, not a game. It needs to be capable of everything the users will ever want, so I will definitely add that.


Thank you,
Yogurt Emperor

Share this post


Link to post
Share on other sites
[quote name='YogurtEmperor' timestamp='1313133237' post='4848126']
But basically you are saying they just convert voxels to polygons, so everything in the game is polygonal? That is helpful.[/quote]
Yes. Almost all current games treat voxel terrain in this fashion. Unless you need to edit the voxels in realtime, polygon storage and rendering is a lot cheaper/simpler.

[quote]I get the same impression from ROAM, but [url="http://www.amazon.com/review/RZFJY1K80H3W1/ref=cm_cr_pr_viewpnt#RZFJY1K80H3W1"]this book[/url] talks about “new ROAM” and “ROAM 2.0- the latest in CLOD”. Any idea if these prove better than ROAM/your nightmares?[/quote]
That book is from almost a decade ago - ROAM was pretty dead even at that point in time. Chunked or clipmap approaches are standard these days for heightmapped terrain.

[quote]Log-Z is also an interesting idea. I don’t plan to have such a huge viewing distance, but I’m making a game engine, not a game. It needs to be capable of everything the users will ever want, so I will definitely add that.[/quote]
You can often get away with the much simpler [url="http://outerra.blogspot.com/2009/12/floating-point-depth-buffer.html"]swapped floating-point depth buffer[/url], if your requirements aren't too exacting (for example, it works fine for planet-sized terrain).

Share this post


Link to post
Share on other sites
I did a lot of investigation into the Crysis (cryengine 2) terrain technique and actually managed to implement my own version which was comparable, if not better, speed and quality-wise.

If you buy the pc version, you get Sandbox which is the editor and I've spent countless (and I mean countless) hours/days examining the wireframe terrain and how they did it - and also how they did the texturing or material painting.

The biggest heightmap they had was only 4096x4096 (the island level) and as far as I could tell, there was no asynchronous loading of the geometry, although that's certainly not the case for textures/materials.

If you look at the terrain in detail, it's chunked geomipmap style. They increase detail where it's needed and decrease it where it isn't based on some form of screen error metric combined with distance (or at least that's how I did it).

Each 'chunk' appears to be 32x32 vertices and, IIRC, that generally equated to 32mx32m at the highest LOD level. The lowest LOD level is 8mx8m (ie 4 vertices squared). Each chunk has an error metric associated with it which denotes its complexity and is compared at various distances against the screen metric to determine LOD level.

4096x4096 in 32x32 chunks is 128x128=16384 chunks/drawcalls (if you were able to see every chunk) - way too many per frame obviously. What I did here was to make the patch size 512x512 by creating a 512x512 vertex buffer (which is the only vertex buffer needed). This as per normal geomipmapping, gets translated into position for each of the 8x8 positions (64 draw calls max). Obviously frustum culling comes into play here so you only draw a 512x512 chunk (herein patch) if it's in view.

So here's the trick... I still base the terrain on 32x32 'chunks' but these are all part of the parent 'patch', so there are 16x16 chunks per vertex patch. Each frame I determine what LOD each 32x32 chunk is and then do a straight memcpy to build the 512x512 index buffer. This may seem like a lot of processing but unless you've got a super complex terrain, you may only need to blat a handful of high LOD 32x32 chunks within the 512x512 patch. Each LOD level index buffer is precomputed and so when creating the overall index buffer, you're just essentially building up the index buffer from a selection of index buffer LODs. You just keep track of the offset. Frustum culling also comes into play, if a 32x32 chunk is outside the frustum, you just don't copy index buffer indices for that chunk position.

So there's only ever one vertex buffer and one index buffer. The only downside is that you need to lock the index buffer each frame several times but this doesn't cause me any issues. You could create a palette of index buffers and only lock each one once but don't think I tried that.

When you combine this with the screen error metrics and distance to the camera, it looks identical to the crysis terrain and speedwise, I did a lot of comparisons between mine and crysis (albeit in sandbox mode so bound to be a bit slower) and even with stitching on the gpu (check my other posts for how I did this) mine was constantly 25-30% faster fps-wise and they literally look identical. I can load and fly around the Island crysis map with the same crysis base textures and from any angle it's quicker than Crysis (obviously on the same machine).

The material rendering is even more in-depth so if anyone wants to know how I did it (probably slightly different to cryengine but identical results and speed), let me know and I'll write something up.

Of if you're interested in this approach and want to know more, or if I haven't explained anything properly (haven't revisited the code in like a year), let me know, I'd be happy to share my ideas...

I meant to add, it would be very easy to stream terrain patches in at distance, just load 512x512 patches at differing mip levels. I also forgot to mention that I just load a 4096x4096x16bit (32mb) heightmap at the start (and into the shader) and use vertex displacement.

Share this post


Link to post
Share on other sites
I dont think Crysis draws same size chunks like in usual geomipmapping, the Lod system is quadtree based, if you use the console command "e_terrain_bboxes 1", you can see the bounding boxes.

Share this post


Link to post
Share on other sites
This is all good information.

I had chosen to go the Geo Clipmapping route but Geo Mipmapping may also be worth an implementation.
I would be interested in any tricks they may have used here-and-there.


L. Spiro

Share this post


Link to post
Share on other sites
I don't think they used anything like geoclipmaps because with that technology i don't think you have the ability to show complex details where needed at distance, eg a rocky mountain range in the distance would need more complex geometry than a flat plain.

If I can fraps working on my desktop (never used it before), I'll post up some video of my implementation. I guess it depends on what type of game/simulation/app you're aiming it, mine required detail at distance where needed so the crysis setup seemed perfect.

The bounding boxes on the crysis terrain might be something to do with the PVS - I implemented a rudimentary line of sight PVS on mine which worked well enough for my needs. I'd also be very interested in any disclosure as to how it was actually done though....

Share this post


Link to post
Share on other sites

This topic is 2213 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this