the devkid seems finished, here some engine details which leaded me in the last three weeks to a new working/mapping and modelling style, the text is snipped out from a conversation so it might be inconsistent and maybe some things twice time mentioned, however, let me start:
the actual devkid can handle a nearly unlimited (*) amount of entities and simple entities, so in the new dessertmap i use to 90% simple entities, all buildings, all shadowcaster. why:
-the brush-shadow caster used significant more CPU than the entity shadow caster !
-the brush renderer DID NOT use LOD models!
-i did not work with lightmap (real sun)so i experiment currently with simple entities as buildings, which are mostly not throw shadow (**), i use invisible shadow thrower which have muchLESS polygons (because the shadowcaster uses the whole polyamount from building!! stencil shadow is in CE1 is not working like described!).
(*) with unlimited i mean instead of original ~40-50 something around 10.000
(**) and if yes, the new devkid will use the LOD1 model as shadowcaster, if existent! it seems there are 3 simultan shadowcalculations at work: vegetation, entities, brushes ! with turned off brush shadows i have nearly all time much higher FPS than with activated one, EVEN IF THERE IS NO SINGLE BRUSH IN NEAR ! with that new working style i dont have to use scalemode anymore! but its important to have all the LOD models for simple entities -.- but once you have it, and work with the new shadowsplitter and casters, you can achieve those extreme good looking optic with realtime shadows shown in latest dessertmap pictures/videos.if you try out to use simpleentities for highpolyscenes be sure to uncheck rigid body+rigidbody active and check if the building should be allowed to autohide at far distance (this is the coreidea of this new system: every 2.5 seconds the engine looks in his entity table if a entity is in near and if yes, it unhides it, if not, it hide them (if the autohide is active for this entity). (the hide / unhide sender events are still working!). every 2.5 seconds this entitytable is new build from scratch, so new, spawned entities, will be known. thats why the quicksave take so long: hidden objects are not saved by cryengine, so devkid have to unhide first all objects on the map, save then the game and hide them again.
this all is flawless working and also tested in very very heavy loaded level environments 
it gives a significant FPS boost on bigs maps with thousends of physicalized (!) rigid body entities and AI, for example in standart farcry i have with it about 6 FPS, once they was activated (seen) one time, and now we have only the actual visible polycount and physic calculated, everytime!
btw, LOD models with no physic are good for engine !
in desertmap i use only brushes for very lowpoly objects which does not should throw shadow or only if the user really have enough powerfull CPU ressources. but it's the first time that i work in that style. i use brushes for big covering rocks, for example, which does not have to throw shadow.
the problem is the not working LOD routine for brushes! LOD's only used for entities and vegetation.
maybe you notice on a heavy loaded map, if you press strg+G in editor, that it needs 2-3 seconds until the FPS "comes back", that is the time where devkid build the virtual entity table and hide and dephysicalize all not in range entities. in the little statusfield on left screen side you see the amount of hidden AI, vehicles and entities. those are currently not processed and responsible for the now higher framerates (after those 3 seconds at start).btw, if you use brushes and generate a lightmap: dont forget after that operation to turn off all the shadows from brushes! because they are baked into the lightmap! but the engine do this not automaticly!
the pro for lightmap is, that you can, once shadow is generated and baked in to the lightmap, switch off shadowcast for brushes, which gives a big perfomance boost.
the original crytek working style was using brushes for 99% of the map and generate lightmaps and they achieve very high FPS with that! but i have played lately some original indoor levels with F3 (info) and was surprised about the polycount: mostly ~20.000-30.000 (!!!)
in my level i have with deactivated shadows ~500.000 , with brush+entity shadow caster ~1.200.000. if i would use the same buildings as brushes, so no LOD would work, i would have with deactivated shadows ~800.000 ... so i was simply forced to use simple entities.i don't want to persuade you to use simple entities at all, but for me it elaborates in last 3 weeks by finding out the LOD bug and inserting the new shadow management as very usefull and workable- together with the need of realtimeshadows (so lightmap was ne a option for me) it seems its a better way.but the negative side is, the AI triangulation ignore entities and visareas, it works only with terrain and brushes! (thats why we have to use AI points indoors, or use clearing indoortrigger, its not so effective like visarea but do almost the needed job! maybe i have to insert a "kill crytek sun" switch, which i have simply forgotten, but you can combine it with enter-leave event with proxytriggers and insert in script line e_sun=1 and e_sun=0 ).
so placing forbidden areas around buildings or walls is now more important.conclusio:
realtimeshadow + high poly buildings (19.000 each) need simple entity + LOD levels, if the building throw his own shadow than LOD1 object will be used in devkind, that means if LOD1 have still 8.000 polys we have 27.000 poly for a building if its simple entity and 38.000 polys if its a brush. (plus the recive shadow poly amount!!)
currently i use simple entitie which does NOT throw his own shadow, i build mostly very very lowpoly plane shadowcaster which do the job and have then instead 8.000 polys maybe 12 polys. its all in all a little more work in 3dsmax but otherwise i can't achieve those good looking environment with active realtime shadows with "acceptable" FPS and good viewingranges in a open world with much volumetric particle fog -.-
Edited by: pvcf
