View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Ambient occlusion simulation for AAA projects

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

91 replies to this topic

### #21Syranide  Members

Posted 09 August 2011 - 05:15 AM

POPULAR

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".

### #22JohnnyQ  Members

Posted 09 August 2011 - 06:07 AM

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... then the only thing you have done is add another layer of abstraction, with some degree of performance degradation.

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).

### #23Syranide  Members

Posted 09 August 2011 - 07:41 AM

POPULAR

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.

### #24Krypt0n  Members

Posted 09 August 2011 - 08:02 AM

I think Syranide hit the point, having a layer that potentially can do everything everyone else can do is not a challenge. But even with a lot of people and having such a layer it takes a long time to create all those interaction and content and pipelines and tools... that's what makes the engine. Look for example at the Unreal Engine, it has a lot of middle ware, middleware that any other developer could license as well, but integrating everything into one consistent and working software is the real challenge.

Maybe you can project it to another topic, lets take sport. you, as a human have the potential to do all kind of sports, you can call arnold schwarzenegger, or maradona or schuchmacher or... to be "below average", because you could point out some weakness they have, but that 1. doesn't make your skills/strength etc. superior, just because you know which workout 'could' potentially lead to better results and 2. yes, nobody could show you anything that you couldn't potentially achieve with your body, does that put you on the same level as those people who won the highest championships or released the best looking game for years?

And that makes it immature from your side, it shows that you clearly lack experience and usually that's the most desired thing companies are looking out for. Making techs and knowing theories are just fundamental things, knowing the real world is something harder and if you really had an offer from crytek, you should have accepted it. 1. if you have really the skills, you could have moved the technology forward, you could present it and make a lot of developers use it like nowadays everybody uses some kind of SSAO 2. you'd for sure learn something as well, maybe the other side, not just the theory, maybe you'd even understand WHY they have been not interested in your technology, but wanted to give you a chance, it's for sure for a reason.

There are a lot of ppl that would probably work for free to have such a chance and throwing that away because you, without experience, judge the quality of their work to be inferior to your, doesn't put you in a bright spotlight, sorry.

### #25JohnnyQ  Members

Posted 09 August 2011 - 08:12 AM

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.

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:

To my 3D object that represents 3d computer terminal, I would assign script called "TerminalScript" which goes like this:

void TerminalScript()
{
SetTerminal(20, 20, "WindowsXPLook");
StartWindow(0,0, 10, 10, "My Window");
DrawButton("bla")....
if( ButtonPressed ("bla") )
{

}
EndTerminal();
}


So basically, my engine has only one object type that can be anything: planet, character, 3d computer teminal, camera, big space ship, ....
Everything is generic...
If I want chat window I won't hard-code it like everyone else - I will update script of a 3d object that represents camera (only sets camera matrix of the graphic engine) to draw small window to over HUD that will be used for chatting (same goes for the main menu).

This way I can make chat window in my "space ship" so that I can communicate with other space ship that has similar script on one of its terminals.

If I want VOIP I wont hard-coded it. If will take a "rock", put it on a programing platform (all in-game) and write send/receive network script for it that copies from wave-in buffer into send buffer and from receive buffer to wave-out buffer....

No hard-coding - completely generic engine design (not just graphic). 1000 developers can create new object types simultaneously all in-game...
----

OK - this is way off-topic - but you get my point...

I've attached 3d terminal picture that i started building - notice tile editor in one of the windows. That is the begging of a terminal that will be used to completely build custom space ships (interior and exterior)....

http://i.imgur.com/4rrhW.jpg

### #26Syranide  Members

Posted 09 August 2011 - 10:27 AM

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.

### #27JohnnyQ  Members

Posted 09 August 2011 - 12:30 PM

I must say, I'm really enjoying this thread and I'm very sorry it is a highjacked one .

I understand what you are saying, and must admit that a few years ago I was thinking the same things, but now I would like to explain why my opinion has changed about some things (especially about graphic).

So let me start:
Over the last 10 years things have changed dramatically in the graphic department. Today all the heavy stuff happens in shaders so it really doesn't matter if shader came with the game or the engine. If the shader is well written it will perform equally in both cases (specially post-process effects). On the CPU side you have a lot of repetitive stuff when dealing with graphic. For example, when you change render targets (switching to some other rendering mode), first you must remove the old ones, bind them with their appropriate shader textures (will be used later) and set the new rendering targets, possibly modify viewfrustum. This is one of the boring operations that happens a lot so I will lay it down through the configuration like this (simplified deferred rendering):

- render target N
- used as shader texture: _tNormalMap
- dim = 1920x1200
- format = RGBA

- render target C
- used as shader texture: _tColorMap
- dim = 1920x1200

- render target D
- used as shader texture: _tDepthMap
- dim = 2048x2048
- format = F32

- render target L
- used as shader texture: _tLightMap
- dim = 1920x1200

...

- render mode ClearBuild
- render target 0 =  C
- render target 1 = N
- assigned renedring technique = ClearBuild

- render mode Build
- render target 0 = C
- render target 1 = N
- [list of rules for determining appropriate rendering technique for different combinations of geometry and materials]

- render mode ClearDepth - used for shadow mapping to clear shadow map texture
- render target 0 = D

- render mode LightDepth
- render target 0 = D
- [list of rules for determining appropriate rendering technique for different combinations of geometry and materials]

- render mode Light
- render target 0 = L
- draw quad = Y -- or some special geometry for certain light type

- render mode FinalPass -- this will do: _tColorMap*_tLightMap and send it on the screen
- render target 0 = NULL


So how would a simple deffered rendering script look like

void RenderingScript()
{
StartRendering(); // Does nothing in DX11
SetRenderMode(ClearBuilld); // this will draw quad that will resed color and normal scene map
SetRenderMode(Build); // This only prepare rendering to use rules "Build" for rendering geometry (it doesn't render any quad)
RenderFrontToBack("SOLID");  // This is Main Engine function that will go through every visible objects and call rendering of their meshes. Main engine doens't know what mesh is (it only knows its ID and send that to the graphic engine + some info - position matrix, rendering distance, ....)

// At this point we have scene color map and scene normal map...

Now we need to render shadows and lighting:
RenderShadowAndLighting("ClearDepth", "LighDepth", NULL, "Light"); // Third parameter is NULL because it is only used for forward renderers
// This function will go through every qued light - for those that have shadow it will create shadow map using ClearDepth i LightDepth techniques and accumulate light using Light technique into render target L
// Of corse i didn't have to use this function - i could have done everything manualy but why (I have CSSM <img src='http://public.gamedev.net/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

SetRenderState("FinalPass");  // This will compose final scene: sceneColor*sceneLight

SetRenderStare("TransparentRendering");
RenderBackToFront("TRANSPARENT");
EndRendering(); // Does Present in DX11
}


Here I've implemented simple deferred rendering system and I didn't have to to all the boring stuff (set shader variables, render stares, render targets,...)
This is all done in the background.,
There is no much code.
There are no errors.
Everything is simple.
Surprisingly, engine doesn't have any overhead. The same would be done in Cryengine but with a lot of hardcoding.

OK, I haven't explained how rules for determining correct rendering technique work but it is extremely optimized rule processing system.
State management happens in the background.
Instancing won't work in the first frame because engine still doesn't know what to expect - but in the next frame it has a lot of information and if rules are configured correctly it will know how to pick appropriate technique.

Also, this all seams to constricting, but it isn't. In 99% of cases will work quite fine. In remaining cases we can overwrite everything with scripting. We have scripting on level of mesh, geometry, material and even vertex definition (indexed vertex blending can have script that will set bones for the current object + mesh offset matrices).
Scripting is our friend - specially if you have extremely powerful and fast scripting engine like we do.

Huh, that is just small explanation for how graphic can be configured to be completely part of the game, and not the engine (except configuration file - and even that can go through script - but then it would be too messy to find because you would have to dig through game packages)...

To conclude - if I prove to you that graphically speaking I can generically achieve identical rendering (in speed and look) like in Cryengine (down't to a single render state and render target change) then you must admit that this engine is much better than Cryengine because it can do everything that Cryengine can + every than any other engine will be able to do - and I don't ever have to change a single line of code in my engine.

Hooh - that is about graphic.

I could go about scripting (I'm greatly disappointed how others are working) and physic (every physic engine today has one mayor limitation that just bugs me) and network (I have p2p MMO in completely dynamic world with out-of-scale dynamic object and let's face it - that is at least 3 generations above what everyone else has).

Damn, I like to talk about my engine so much

... and that is why I couldn't force my self to work in Crytek - I'm opening my own game development studio in a few months. Their engine can't do 5% of what my engine can. I couldn't work on such inferior technology - no way...

### #28Katie  Members

Posted 09 August 2011 - 12:38 PM

"mire 4.5K euros a month"

You turned down E54k a year? E54k a year is a pretty good salary. And for games development??? Blimey. Again, most people here would kill for that sort of offer -- it's the aspirational goal of their life.

"working on technology that is more inferior than my home projects"

There's a lot more to games than the graphics engine. Look at this year's surprise hit. His characters have corners...

### #29Katie  Members

Posted 09 August 2011 - 12:47 PM

"So let me start:"

I can't see where the magic technology is. I can see that you've implemented a "hard and soft layers" architecture involving scripting to connect component parts together. Could you be more specific about what it is I'm missing?

### #30JohnnyQ  Members

Posted 09 August 2011 - 01:14 PM

There's a lot more to games than the graphics engine. Look at this year's surprise hit. His characters have corners...

Exactly, but Crytek doesn't know this. They think graphic is everything...

### #31JohnnyQ  Members

Posted 09 August 2011 - 01:38 PM

"So let me start:"

I can't see where the magic technology is. I can see that you've implemented a "hard and soft layers" architecture involving scripting to connect component parts together. Could you be more specific about what it is I'm missing?

The magic thing is that graphic engine can accept any kind of data: voxels, standard triagnlular meshes, sparse voxel octrees, minceraft data, that erosion layers like in "From dust", It doesn't matter. Why make an engine that can do only simple heightmap and small level rendering when you can, with much less code, write graphic engine that virtually has no limitation? It is just bad programing. But that is just graphic engine.

Look at gameplay at Crysis 2. In that whole game you can shoot at object or pick them up and throw them. That is all - that is all interaction with the world - that is it - practically nothing more.
500 developers and that is all they have come up with in 4 years of development!!!

End not only that engine doesn't even have dynamic loading of stuff. How lame is that? Beating it in a graphic department would be so easy. Yust give it a bigger map with more stuff and it would die because memory couldn't handle it. I mean, even the simplest engines have some sort of dynamic loading - you have libraries today that will handle that for you.
No - in Crytek you have loading screen and you have to wait... Even Carmak realized that something like that is not excusable these days.

### #32ryan20fun  Members

Posted 09 August 2011 - 01:44 PM

hardcoded into Crytek engine.

and what makes you think that it is hardcoded ?
Never say Never, Because Never comes too soon. - ryan20fun

Disclaimer: Each post of mine is intended as an attempt of helping and/or bringing some meaningfull insight to the topic at hand. Due to my nature, my good intentions will not always be plainly visible. I apologise in advance and assure you I mean no harm and do not intend to insult anyone.

### #33JohnnyQ  Members

Posted 09 August 2011 - 02:10 PM

and what makes you think that it is hardcoded ?

Just look at their homepage... EDIT: They've changed it a bit from the last time but you can still figure things out.

Any engine that brags about particular effect clearly states that that is internal part of it.

To quote my self: "It is OK to brag about the shaders in the context of the GAME. It is not OK to brag about the shaders in the context of the ENGINE."

That way you are just admitting that you are nothing but hard-coder and that the engine is limited to just that what you've presented.

### #34Syranide  Members

Posted 09 August 2011 - 02:36 PM

The magic thing is that graphic engine can accept any kind of data: voxels, standard triagnlular meshes, sparse voxel octrees, minceraft data, that erosion layers like in "From dust", It doesn't matter. Why make an engine that can do only simple heightmap and small level rendering when you can, with much less code, write graphic engine that virtually has no limitation? It is just bad programing. But that is just graphic engine.

Look at gameplay at Crysis 2. In that whole game you can shoot at object or pick them up and throw them. That is all - that is all interaction with the world - that is it - practically nothing more.
500 developers and that is all they have come up with in 4 years of development!!!

End not only that engine doesn't even have dynamic loading of stuff. How lame is that? Beating it in a graphic department would be so easy. Yust give it a bigger map with more stuff and it would die because memory couldn't handle it. I mean, even the simplest engines have some sort of dynamic loading - you have libraries today that will handle that for you.
No - in Crytek you have loading screen and you have to wait... Even Carmak realized that something like that is not excusable these days.

I see nothing wrong with Cryteks approach, they set a goal, reached it and vowed people. They implemented what they decided was needed, made the tools to allow the artists to go crazy and spent loads of R&D on new shading techniques and optimizations.

Beating Crysis in visual quality is probably a tough job, but definately doable... beating Crysis in the performance department is also very much doable... doing it both at the same time? No API or engine in the world will help you with that, unless it was made specifically for that purpose. And perhaps Cryteks approach was simply to design an engine, be done, copy what they need for the next project, and continue. There is absolutely nothing wrong with that in my opinion... abstracting for the sake of abstracting is research territory.

From what I can tell, it sounds like a really nice and competent engine you've got there, but so far it's just talk and nice in theory... even though your engine can do anything anyone would ever want, as long as it is a generic piece of engine, then you may be able to recreate everything everyone else makes... but never achieve the same performance... doing subsets and limited demos are easy, bringing it all together is a very different story (storage, memory, performance, scale with hardware, etc). You give Crytek flak for not creating a reusable engine and a bunch of other things, it's easy enough when you're not on a deadline and not doing the actual work.

I'm pretty sure they have a toolbox of classes and utilities that provide most of the gruntwork for their engines... then they add the features. That is their engine development. What I'm trying to say is, your approach is to make an engine that has the capability to do everything, design a framework that can handle it, etc, etc, and then your game has an engine on-top of that. Crytek decided that DirectX is their framework and they implement only what they need, giving them complete control over their engine, no redundant features, no redundant work. Two very different approaches, and I really don't see anything wrong with Cryteks approach. You have to remember that now, as I mention above, they can copy-paste and throw out whatever they want... relying on an engine means they are stuck with it, they can't just throw it out without starting all over.

I just don't believe in "do it all"-middleware, specialized middleware is great if you have an idea and want to put it out there, but in that case, you want it to do what you want, and fast. You don't want to build an engine on-top of the middleware, read lots of documentation, create the tools and tutor the artists. If you want to push the boundaries you often need to drop the middleware in favor of your own engine. Anything in-between is in my opinion probably best provided as standalone libraries/utilties.

and what makes you think that it is hardcoded ?

Just look at their homepage... EDIT: They've changed it a bit from the last time but you can still figure things out.

Any engine that brags about particular effect clearly states that that is internal part of it.

To quote my self: "It is OK to brag about the shaders in the context of the GAME. It is not OK to brag about the shaders in the context of the ENGINE."

That way you are just admitting that you are nothing but hard-coder and that the engine is limited to just that what you've presented.

My point being, this is exactly what people looking for middleware wants... that's why they are buying it. No point in saying, "this engine can do everything, You just need to implement it!". Then they'll go somewhere else, they want a list of features, and then proceed to use those features and the tools that allows artists to work with those features.

### #35MJP  Moderators

Posted 09 August 2011 - 02:56 PM

I'm not showing screenshots, videos and other stuff because it would be easy to to find out which game use this technology, so everyone could disassemble it. Isn't that enough reason to keep this in secret?

Let me ask you this: just what exactly do you think it is that you're going to gain by keeping your technique a secret?

### #36Jason Z  Members

Posted 09 August 2011 - 03:08 PM

Nothing against the O.P., but I honestly can't see why so many people are posting on this thread (I guess I just did it too ). There is nothing presented here - absolutely nothing. I read about 6 or 7 of the posts, and I don't even know what the original post is asking for? Do you want something or are you trying to share something or are you trying to keep it secret???

I don't want to be negative, but I just don't see the point to this thread.

Jason Zink :: DirectX MVP

Direct3D 11 engine on CodePlex: Hieroglyph 3

Games: Lunar Rift

### #37JohnnyQ  Members

Posted 09 August 2011 - 03:10 PM

My point being, this is exactly what people looking for middleware wants... that's why they are buying it. No point in saying, "this engine can do everything, You just need to implement it!". Then they'll go somewhere else, they want a list of features, and then proceed to use those features and the tools that allows artists to work with those features.

I agree with everything you've said.

But consider MMO game that will last 10 years.
Will you really buy an engine that will bi obsolete in a year?
Also, if you expose scripting and ability to create new objects to the players (even if only 1% of players contributes) your game will be unmatchable.
No development team will be able to take your game on because you have as many developers as players.
If you are like Crytek and the rest and have engine that has only 10 different object types then that game will become boring very quickly - won't last for 10 years.

For example - if I in my game build a Space Ship building station.
Everyone can come there - compose a ship to their like to the very detail (interior/exterior/terminals, pack it up with their friends and fly from one planet to another - fight - explore - discover/script new technology...
They can even make it look like Enterprise from Star Trek - and nobody can't sue us because it is p2p MMO - we don't have control over the game - in fact every client can host their own instance of the game with just a few players - or milion players if you like.
This game will clearly be more fun than lets say EVE ONLINE (that has maybe 2% of the features)...

I'll leave you to think about that...

OK - I'm going to bed now.
It was nice discussing things with you all.

### #38Tournicoti  Prime Members

Posted 09 August 2011 - 11:06 PM

@IvicaKolic
Engine design today is just awful (not just Crytek, but every mayor player including Carmak and the rest)


Really ? Just that ? Don't you think this is easy to say, and maybe just a little bit pretentious ?
Whatever are your skills/experience, that's not a thing to say, sorry

### #39dummynull  Members

Posted 10 August 2011 - 12:59 AM

MJP
>Let me ask you this: just what exactly do you think it is that you're going to gain by keeping your technique a secret?

Money. If the game project is interesting for me (jrpg f.e.), then moral satisfaction is enough. All business is based on idea to be the first one against competitors.

Jason Z
>Nothing against the O.P., but I honestly can't see why so many people are posting on this thread (I guess I just did it too ). There is nothing presented here - absolutely nothing. I read about 6 or 7 of the posts, and I don't even know what the original post is asking for? Do you want something or are you trying to share something or are you trying to keep it secret???
I don't want to be negative, but I just don't see the point to this thread.

Read first post: "Could someone describe how to contact with developers if their public e-mails are never read (for sure) or not available at all? Is such technology (dx9 requires at least) may be interesting or it doesn't matter (for consoles especially)? What is the time period before official game release date, when developers are unable to modify the engine code any more?"
From the posts here it seems everybody trying to find out what the technique is and how it works by confusing me, don't you think?

### #40Hodgman  Moderators

Posted 10 August 2011 - 01:14 AM

>Let me ask you this: just what exactly do you think it is that you're going to gain by keeping your technique a secret?
Money. If the game project is interesting for me (jrpg f.e.), then moral satisfaction is enough. All business is based on idea to be the first one against competitors.

In that case (if you want to make money), you're going to have to set yourself up as a serious middleware company and make a professional sales pitch (instead of just 'some guy' trying to contact developers). Part of this pitch will involve proving to them that your tech is useful for them, which should probably include it running on actual game console hardware.

Your competitors in the area of lighting-middleware include Enlighten, Lightsprint and Beast.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.