flachdrache

Well, that might was poorly worded - rick suggests pure object orientation with the camera being an object, the "only" other option would be self aware/containing objects ( with a own camera using disable old/ enable new ). Now, in le2 framework I "must" use the later because the ears ( listener ) are at the main cameras position "always" - fobaring positional audio e.g. light humming etc ... that's was what I wanted to point out - if you want to have it extensible ... or as a base etc. for beginner : sorry'bout all the "" ... le2 programmer know ( or should remember ) all the little issues we had ... and still have tbh.

Le2 framework has its listener bound to the main camera which made it difficult iirc - you don't get any sound issues with positional audio ?

That's correct - its just about interaction and defining rules. The mover just follows a path along an origin = the axis center point. The mover does not need collisions because the lift comes in as complete, extern, model with parent child relation. However - You ask for and josh suggests so called "brush models" ... which is valid too. PS: such mover is just a point in space like 1x1 or how small you can go ... but in such case the extern model needs to be positioned to such point correctly and might have an offset.

PS: keep going - you just missing the background course your younger .. I pretty much rebuild all this basic functionality based on what I learned from quake2 ... and hammer is based on quake functionality AFAIK.

Traditionally this is done by just moving one, non collider, brush along an origin - the lift etc. is then added as a sub model e.g. the model itself which does contain collision's.

You could use ambient GI cubemaps as additional approximation for static geometry too. Just light maps often fight specular highlights sadly ...

The old way is to draw models two times with one being slightly larger, black and with inverted normals - making it a hull but that just used to be for character models.

Well its a depth based shader AFAIK and has been (tried) done before but the terrain was too smooth to look good. Some user might revive it, if you status update for it ... but tbh its well known and there are free and legal versions 'out there'. However I am not familiar with current state of post processing and the foliage seams to be a 'special case' e.g. second pass render.

and really ... people should know to differ good from not good.

... ripping assets from games is the new pop - i post a link to every such stolen content to the support/publisher of the game in question ! very few offer free/legal content with good quality tbh ... might good to go.

stealing - like everybody else. ;d

OK - such a list I meant ( GPU specs ) ...'http://www.leadwerks.com/werkspace/topic/8034-steam-wont-launch-leadwerks/'.

Doupts here too but you'll better check driver release notes on Win-vista+ ,for your card, on nvidiaCom.

All levels can't be big an blocky like HL. should not but must still ... you cant expect that random sticks and stones do give you a desired result i am afraid. Navmesh extractors aint that good (currently afaik). Thats an issue i had with eki one and tree models ... and clouds of navmesh in the leaves:d. Rather pointless to build AI without a final map if you ask me. For "Le3" i think it would be good to suggest josh - to have a special material for CSG which can be used to block-out your level. Its nothing more then a collider for your AI agents at the end and details just slowing and bugging the navmesh extractor. Having ai-collider materials is what q3a uses for its area-awareness-system. PS: not just an id fanboy - the terrain in my xna engine used a terrain processor with a virtual material ( no texture ) for its collision mesh too.

Actually - we had 5,6 topics about that including staircase issues, how to deal with lod if the AI needs to update etc. - however, those might got overlooked