Syranide

Correct, I've misguided you. Graphic engine is just small dumb module of the engine (other modules are: physic engine, terminal engine, scripting engine, input engine, sound engine, network engine, etc).
All these sub-engines are controlled by Master Engine that has complete control over the powerful data-structure. Master engine is actually the only one that understands the data-structure.
Every sub-engine has access to scripting engine (which runs scripts in parallel) so terminal engine (used for Main Menu, HUD, virtual in-game 3d computers, road sings,...) can sometimes do something to the graphic engine (set some render special render variable)...
Also, scripting engine has access to all other engines: so if I want to draw some windows application withing my virtual 3d computer, I would do something like this:

...

Ah, that explains a lot. While I think it's a nice idea, and as being a developer it definately feels close to heart, "wanting to do everything". My personal experiences and "maturing" have really come to lead me on a different path entirely, I long held firm to the idea that "more = better" and that code should almost be treated as something holy, perfecting it over and over. This is all debatable and different situations require different approaches of course.


http://en.wikipedia....platform_effect

"The inner-platform effect is the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using. This is generally inefficient and such systems are often considered to be examples of an anti-pattern."


Is something I've become acutely aware of, looking back I've realized that, often rather than solving the problem once, it was easy to fall into this pattern of first creating a "class" that was really flexible and could do a lot more than I actually needed (but my brain said, "you might!"), and then create another tailored "class" that would expose a much simpler interface to the first class. And in the end, the first class was never perfect, it was never fully implemented, there were flaws and it made certain optimizations very hard... which made me never want to reuse it as-is in another project anyway, I would copy-paste it and refactor it simply because it made more sense.


To me it seems like you've something so generic that it doesn't really provide anything other than what a handful of 3D API utility classes could mostly solve (or you have indeed introduced lots of limitations). Instead you have now artifically limited what is practically possible, but not theoretically (and developers are bound to your framework)... it's hard to put into words, but consider instancing, something that is hugely important in SOME games and often easy to achieve, how do you facilitate that for all situations across completely generic "sub-engines" without making a mess. Another common side-effect is that "hard stuff becomes easier" and "simple stuff becomes slower". The generic nature means that you can rarely assume anything about anything, hence, a lot of optimizations goes out the window... performance is about cheating and shortcuts.

From my limited experience, these kinds of APIs often provide beautifully simple example code, but horribly degrade in practice when all the special-cases and quirks start to appear (and you have to start worrying about performance)... you start to slowly circumvent the API in order to provide functionality and optimizations the API is unable to provide.  And suddenly it has all degraded into a worse spaghetti-hell than the you were trying to avoid.


What I'm saying is, it seems to me that either you've made something so insanely generic and non-invasive that it could only possibly be a bunch of utility classes (which might not be a bad thing), or you have introduced an unknown number of limitations and pitfalls, and this is pretty much "the law". You cannot solve all problems with one solution, it is quite impossible, the larger you make the problem, the more convoluted solution you get... if you solve all problems with one solution, then you are back to where you started (inner-platform effect).

To avoid misunderstanding, I'm not hating on your engine, it's probably a very very neat thing you've made.
I just find that it can be very insightful to discuss various topics at times and there's no point being tippy-toes about opinions.

Let's stick to the graphic for a moment.
I can't really think of a case where performance of my engine would be more than 5% slower than anything that has been hardcoded into Crytek engine.
I mean, if we are using the same shader (only mine is in game data and their is hardcoded into engine) performance will be the same (presuming that we have the same quality state management, and I have all the traversal methods that Crytek has - which I have, and more). Post-process effects will run at the same speed in my and in their engine, and regular rendering also, only I won't have to bother with engine bugs because my code is closed - engine is EXE file that never changes, and game is in game data. 100 engineres can parallely try different things without affecting others - this can't be said for working with other engines.
Give my an example on something that you think wouldn't render as fast as in Crytek engine, and I'll try to explain how to properly configure engine to do so.
I've studied every angle (type of rendering, post-process) and simply can't find something that my engine can't efficiently render.


P.S. I'm sorry - I'm derailing the tread (but everything has been said so I guess it is not that big of a deal).

Well, from what I can tell, you haven't really made a 3D engine (comparable to Crysis), you've made an abstraction layer on-top of your graphics API. What I mean is, to me it sounds like you are abstracting shaders, vertex buffers and such, then you have done little more than added some make-up to the graphics API... you have not really made an engine. Please correct me if I'm mistaken.

Crysis is a bunch of textures, shaders and triangles... but what the actual engine supports a voxel/heightmap-based terrain, occlusion culling, animation, realtime destruction, procedural vegetation, HDR, multiple lights, realtime radiance transfer, approximated global illumination, etc, etc. This is what I would consider the 3D engine, to support these things, efficiently and with a simple API. And I'm confident that they employ a lot of optimizations specifically tailored for their overall environment and game priorities. That is, an engine is no good if it says "you can do all of those things, but you need to implement them yourself", add to that that sometimes you may want max performance, sometimes you may want steady performance, etc.

To be clear, I don't consider something to be an engine if you need to build an engine on-top of it. That is, Ogre3D is an API in my opinion (which sounds like what you are talking about), logic normally shouldn't interface directly with Ogre3D, it should go through your own engine that sits on-top of Ogre3D. I've tried Ogre3D and for a lot of things it is certainly great, but for a lot of things it's just too much and too convoluted, and for some things it's simply not enough, requiring you to extend dozens of carefully designed classes to implement something that should be simple. And for other things, the interaction with it becomes unnatural and cumbersome. Ogre3D is so generic that nothing is actually easy to do with it, it always feels like building a spaceship... unlike an 3D FPS engine that may be super easy to work with, but may make it harder or impossible to go outside what is provided. It's a trade-off.


Again, derailing the thread really but I find this interesting... but shout and I'll stop.

Don't mean to derail the thread... which seems quite silly to me really... the algorithm is used in a game, but you can't tell which, but you want to make it free, but want it to be featured in a game first? And won't show anything to actually prove it? No performance figures, no quality comparisons. I'm not even sure what you would gain by having it used in some big game if you intend to make it public anyway, BF3 is not going to be called "BF3: AO by dummynull". If you want recognition, wouldn't it simpy be best to just compile useful information on what you have and talk at SIGGRAPH or something like that? If it really is as good as you claim and useful, then developers will take notice and it will be used.

I do admit they have done some amazing work with the shaders. It is most impressive, but everything else is just average (somethings even below average)...
Engine design today is just awful (not just Crytek, but every mayor player including Carmak and the rest). Engines are very limited and most of the development goes into graphic efects which in my opinion shouldn't even be part of the engine.

Consider this graphic engine design and compare it with how things are generally done and then make conclusion if thing that Crytek is doing is advance or not:

• graphic engine without  limitations - fully generic graphic engine (doesn't try to understand the data just how to send it to the graphic card) - can be written in less than 2000 lines of code and there you go, you have the holy grail of engine design and no one will ever be able to write better (DX11) graphic engine. You can send it voxel data, triangle meshes, sparse voxel octrees, + anything else that will be invented and you newer have to change a single line of code because the engined doesn't care about the data - it just cares about the rules for calculating appropriate rendering technique for the supplied geometry data, material data and render mode (lighting, depth, color, z-prepass..) - all this + the shaders can be put in game data (not engine). NO ONE DOES THINS LIKE THIS - everyone is harcoding effects/passes into their engines which is too much work and more and more limited. I hate when they do tech demo of some new graphic engine and then spend 15 minutes showing graphical effects. The moment they do that, I know that their graphic engine is crap. Instead, show my how flexible it is - will it be able to run something that will come up in 3 years from now without me having to "heavily modify it" (I hate when they say that) or buy new version of the engine.
• Camera Space Shadow Mapping was developed as a single line of code implementation for shadow that will never fail you and will work for every case (even big pointlights). Basically it is just one function that generates 3 shader parameters. If at one point in time we decide to user sparse voxel ocrees or something else - no problem - in our shaders we just ignore those 3 parameters. With other engines multiple shadow algorithms are implemented and they take on most of the graphic engine code that will eventually be obsolete. The moment you implement some other shadow algorithm (cascaded, cube, volumes...) you've made assumption about how things will be render and that means that your graphic engine is not generic any more - it is not all-powerful and it will soon be full of old useless code....

Don't get me started on physic engine limitation, network limitations, spatial limitations, logical limitations... It will newer be able to run a game with land-able dynamic planets big spaceships and some decent multilayer (I expect nothing more than peer-to-peer MMO in completely dynamic world with out of scale objects). Basically it is designed for small things - small static levels where you can only shoot at things and that is all you will ever be able to do...

There's this thing called research (theory, lots of papers) and then there's the reality (practice, lots of games)... everything you mention is very good in theory, but sounds to me like crap in practice. You CANNOT create a top-quality and top-performing engine without optimizing for specific purposes OR you end up not making an engine at all... that is, you just invent another API layer, which is what DirectX is. Like with GUIs, one solution rarely fit all problems, so far GUIs can be either retained and immediate-mode, neither can be considered best... and both can't be unified or implemented by the other without sacrificing something, to some degree.

The visual quality and performance of crysis is testament to the work of skilled developers and engineers.
Could it be improved?... certainly could.
Would it be improved by making the entire 3D engine generic?... no.


EDIT: If your solution to a problem is to describe the entire problem, then you haven't solved the problem. That is, if your solution to making a 3D engine is to have it support every single game type and feature equally well... then the only thing you have done is add another layer of abstraction, with some degree of performance degradation.

Doing a lot of web development, I often hear people cry and call murder over rounding corners with images "it's semantic garbage!" and then proceed to convince everyone that people with browsers that don't support rounded borders get what they deserve. Which is rediculous... sacrifcing quality, end-result and often performance for some "very nice in theory"-argument about how things must be made... rather than just solve the issue, "make rounded corners with images".

suppose there is a possible to speed up their method.. at the moment they they its running entirely on the CPU but are in the process of moving at least some of it over to the GPU if this gives them the performance boost they need who knows it may become a viable solution.

seems to me that a hybrid could more easily be useful  (as mentioned before) polygonal for animation and physics, and unlimited detail (whatever it is) for scenery and levels.

they still have a huge way to go though in terms of beauty... I mean look at cry engine 3... click me, they won't want to drop visuals like that in a hurry, so if in a year they cannot produce something like that in terms of shaders, textures, lighting etc. then they gonna be dead in the water... games are deffo more and more about atmosphere and being visually stunning over just a plain old need for more and more detail... what's the point in infinite detail if it looks shite right?

Think it will have support for more interesting lighting/reflections/refraction/and all that sweet stuff? If it is a form of ray-tracing then I suppose it should look as good if not better.. but am not sure that it is? :S

The problem with what you are saying is that, large non-repetitive areas is where the entire technology currently falls flat, it simply can't handle it and I doubt there is doing to be some magic solution for that anytime soon, if ever. And don't forget, theri demo is showing each voxel having at least position and color... with shading, it would at MINIMUM have to be another byte on there specifying what material it is... and then you might need normals and a bunch of other parameters. And I don't know the details, but it might not even work out that well.

To my knowledge, UD pretty much is a form of raytracing (except on voxels instead of shapes), so while you should be able to do reflections, shadows, refraction in the same way as raycasting, it is equally expensive. The cost in UD comes from tracing a pixel, higher resolution, the cost goes up linearly... now, every bounce/etc is another trace (that most likely isn't cache coherent). So while you certainly could do some raytracing-esque impressive stuff, the performance would degrade even further. The performance is already quite crap, and I would assume it's running on a highend CPU.

From what I can tell, what UD excells in, polygons are more than capable to do more than well enough with tesselation when backed by really good artists (which you need anyway).

Right, there are arguments against their marketing approach. But what about the technology ?

Polygons are great for rendering something between big surfaces or flat faces, and extremely detailed and irregular shapes (like vegetation, rocks, clouds...). For the latter, you eventually get to render polygons that are smaller than a pixel. In that case, voxels/point clouds used in conjunction with a sparse voxel octree data structure (I regroup these under the term "voxels" in what follows) are better, at least in theory, for a few reasons :

1) the sparse voxel octree is very efficient for rendering. This explains how they could obtain that frame rate without GPU acceleration

2) the sparse voxel octree is in itself a compressed data structure

3) you get rid of the real burden of polygons : UV-maps/textures/displacement mapping - especially heavy if you consider highly irregular surfaces, clouds, vegetation... Instead, you just store colour information with the voxel.

The real limitation is that animation is virtually impossible with that technology. So the question is not : which is better ? but rather : which is better for what application ?

You are assuming that these things can't be done with properly with polygons given sufficient performance (and enough allocated performance budget). Dynamic clouds can today be drawn very VERY realistically with GPUs, but it's costly... and this technology is hardly more performant or capable, so it's often dismissed in favor of allocating the resources to more important areas. It's all very good to render a cloud using pointclouds... but, what about the shading and all that? I for one would prefer beautifully rendered dynamic clouds.

The same is most certainly very true for grass and most other things, everyone seems to assume that grass must be individual textured polygons when it most certainly could be very beautifully rendered with some raycasting pixel shader as is done with fur or using other tricks... it's costly, and the grass looks good as it is, so the performance is allocated elsewhere. Just look at how good "speedtrees" have become.

#3 is of course a big plus, but that statement sounds wacky to me, we make it a burden for artists to do those things today because we want to squeeze every bit of quality and performance we can... if we wanted we could have tools do all of those things for us but the quality and performance would suffer to some extent... so UD instead says, let's throw quality and performance out the window entirely, but look there is unlimited detail and it's easy for the artsts! So, is that a plus? Most of the things UD promises, polygon engines and tools COULD do, but performance would degrade, storage requirement would shoot up and nobody would actually notice it anyway when playing games (or rather, games would be uglier overall, so they would notice). When was the last time you stopped and put your face against the grass or a tree and tried to discern the polygons in any game (other than because of your interest in computer graphics)?

The statement about 25% number more triangles every year is rediculous... even though it may be true, the performance of GPUs is shooting through the roof, why the "low" polycount? Because shading is where it's at, that's where the quality comes from. Most people don't realize how fugly games would look today if you removed all the shaders, lighting and particles... oh wait, it would look like UD! It doesn't matter if UD CAN do those things if the performance isn't there. They could just as well be trying to promote raycasting.

I just had a look and found Dawn of War 2 at least does have a map editor, and for texture painting you can select upto 8 pairs of ground/cliff textures so I assume it does as you both hinted at and Syranide touched upon- uses one automatically depending on slope, and the other otherwise. The more detailed sections do appear to be just meshes, but interestingly in some cases seem to take the underlying texture of the terrain, for example, if you place a mesh based rocky outcrop over a section of terrain that is half desert and half urban texture then the outcrop textures itself using the texture set of each of these using both the ground and cliff textures of those sets- could be a little more complicated to implement but interestingly done nonetheless!

Starcraft 2 has the same thing, I'm pretty sure it's something a long the lines of storing the texturing data in a large texture, and the shaders then determines the appropriate texture to sample from that... additionally, any custom mesh can also use the same shader to imitate the terrain below.

It does however allow for splats of individual decals too, which is what I suspected, and these seem to be able to be placed arbitrarily across the landscape, rather than at specific vertices on the terrain and so forth, so whether these are stored as some kind of list and just rendered seperately from the terrain but on top of it I'm not sure. It also allows spline placement mode where you can define paths and such, which presumably work in  a similar way. Any hints as to how this sort of thing is likely to be handled and drawn in code?

As for the paths, it's most likely just the usual curved line rendering but textured... with some special case for intersections. That shouldn't be any major issue once you find the proper algorithms for triangulating the curves.

For the texture decals, I'm not familiar with how that is usually implemented, but it's common enough that I can't see how it would be a problem to implement.

I'd bet that most of the visual quality comes from really good and well distributed foliage... trees, bushes, grass, etc. It really brings a scene to life. As well as making sure the ground textures are really good, that is, not just splatting a single texture, but having many layers to them.

Also, something that may be easily looked past is that there is rarely "grass, mud and rock", there are many variations of grass, mud and rock used to nuance the terrain. So a lot really comes to down to procedural stuff (having grass look different depending on the slope, where it is at, varying foliage, etc) and good artists... and lots of tweaking.

And then of course, lighting can often play an important role although it can be very hard to deduce what exactly makes the terrain look as good as it does, in many games... it just looks good. Layering some fake cloud texture over the entire terrain can be a cheap trick to reduce the "flat look" that might ruin the look of the terrain.

Also, in the renegade ops screenshots, it's quite clear that they don't just blend between different textures, they use some additional texture for the blending area that creates interesting features rather than just a linear gradient. I'm guessing the basics of that is some texture which contains "an interesting gradient pattern" and then use that for deciding from which texture to sample from.

Hi Syranide! Thanks for the reply!

Anyway, as for your actual problem, it seems like you forgot to consider the X/Y-scaling of the different heightmap LODs as you compute your normals... remember, one LOD further away, means each quad is twice as wide (but not twice as high!), which also means you have to consider this when computing your normals.

You've spotted the problem precisely! The XY-scaling doubles as the LODs get farther away. My ScaleFac variable doesn't take it into account. Unfortunately the error was only in the problem description I've posted here. My code snippet was wrong. Sorry! In fact I calculate the ScaleFac as

uniform float2 ScaleFac = float2(-0.5/2^L,-0.5/2^L);      // L is the clipmap index increasing for the LODs farther away

For the posted image I'm drawing 4 LODs with the squares of the closest LOD being 1x1 units big (2x2 units for the next LOD, than 4x4 and finally 8x8).

First  off, I would recommend that you implement your normals using textures  instead, this will allow you to vastly improve the graphical quality of  your terrain, without increasing the vertex count. You can easily use  normal maps with 2-3 times higher resolution (than the heightmap), and  it's really really cheap.

I'm not sure how to combine this LOD method with normal maps. As the LOD heightmaps are calculated at run time on the GPU with only incremental updates for being provided by the CPU as the camera moves. Normal-mapping the LODs with the double or tripple resolution would require some efficient update scheme. Right now I'm just trying to get the basic method work.

EDIT:  I'm not sure what's going on in your wireframe-screenshot... it look  likes the LODs get coarser and coarser, and suddenly, some of them get  finer... and then coarser again?... those look like the LODs that are  incorrectly colored as well.

The LODs don't get finer, only coarser. I'm drawing 4 LOD rings. For each successive ring the size of the squares is doubled. They may seem to get finer but that's just the screenshot.The incorrectly lit area is exactly at the border between 2 rings.

Anyway after you hint I've double checked my normal scaling factors. They seem to be correct but the problem is not solved. I'm still looking for help.

Using textures for normals is really simple, just treat them as you do with the heightmap... of course there are some things to take care of, such as there being additional LODs for normals and normal LODs "moving faster". But performance shouldn't really be a problem, I did a naive implemention myself for this, and while I could see the CPU spiking with really high detail normal maps being streamed to the GPU. That had a lot more with the unrealistically fast flying movement  I had, which may not be obvious at first, my issue really was because I was literally streaming tens of megabytes per second because I was moving so fast (although it didn't seem like it).

Anyway, your choice, but I really would recommend them in the long run... if you want to keep it simple for now, you could just copy the heightmap code and use the same resolution for heightmaps and normalmaps (literally copy-paste, although you need to compute the normal maps). You could even bake the heightmap and normalmap into the same texture, although, it would only be a temporary solution.

Also, looking at the incorrectly colored image above... something else seems amiss... I seems to me that there are two distinct blue colors up there, not one. So the normals seems correct (the shading of it all), but it seems to transition between two different colors? Or rather... like the it transitions from some mixture of RGB, to just B. Messed up the RGB-components somewhere?

Additional info: normal maps calculated for all LODs. The X and Y components are encoded in the red and green color channels. The Z component is supposed to be always 1.


It is obvious that all the textures except the first one have a strange discontinuity along the border. The reason for this is still not clear to me.

I would assume the discontinuity is because you are computing the normals, but you don't actually sample outside of the boundaries specified by the target texture (as is required)... although, the pattern on the edges doesn't really seem ordinary... perhaps the edge normals get computed from some irrelevant data outside the texture? I'm not sure if you've noticed it, but the edge at the top and the bottom are equal or near equal... it would seem like the edges wrap around when sampling the normals?That would also explain why the first image looks correct, because it tiles.