personally i don't feel as if i'll ever be out of demand if people learn the same skills as me ... but then i'm secure about my abilities and skills.
doesn't take just being able to plot the lowest model and setting a pretty texture on it to make a decent modeller.
i've worked with so many newbies who believe thier talents make them, when having skill and passion is only the tip of the iceberg. Same goes for programming - you don't need years of industry experience to see that within the latest wave of "blockbuster" titles which appear to have relied on just pure visuals. sad really
there has been several demos, made within DarkBasic when the enhancements were released that demonstrated how with memblocks "frame" mesh deform animation was possiblt ... and a guy called Bryce made a sweet BVH (motion capture) importer. I found it easi to actually combine both of these techniques to give myself Skeletal animation - which the format was later changed to Milkshape skeletons because they were much easier to setup
the use of them isn't really "processor" intensive as such unless your start to use complex interpoling and eluar angle calculation to make the skeletons perfectly move.
which brings back the point of Quality Vs Speed ... its a snap decision that both an artist and the programmer should agree upon, usually based on use.
Something like skeletal animation you'd go with the cop-off which might look cheaper, but save alot of speed.
now i'm unsure to what demo you're talking about, but if it uses BSP then it is likely the visual tree beam is trying to go too far ... the reason why you always read that "leaks" are bad for BSP worlds, is because leaks are caps where the Visual Beam can slip through. As BSP gets its speed from working in an enclosed area by bouncing through the first 1-4 polygons and then Z buffer them based on the read order and collision.
So the further it has to check the longer it takes, and so as once it gets outside of the world the distance is the BSP or camera size (this is taking into account you've actually set it up).
When i say that 10,000 should be what you're working to ... this doesn't mean that you should HIT that, its actually more of a set max.
as far as i'm conserned Standard setups around actually are 200-400Mhz Mmx Processor | TnT-Based, GeForce2mx, Kyro or Savage4 8-16Mb Cards | 64-128Mb Ram
Generally everyone is on Either Windows 98 or XP Home with DirectX 8.1 (usually provided with games nowadays)
But you also have to guess they're using standard drivers, because only XP updates this automatically.
So that should be the range of PC you're aiming for because it isn't likely that highend users will touch it without sweet graphics, but then there are far more user with cheap'n'cheapful out of the box PC's
no one ever thinks of these people anymore, and its a shame cause they make up more of the market - because they don't upgade as it costs too much for a new computer and just as much to have someone install the new hardware. Most are computer illerate (apart from Internet) so they won't touch the hardware themselves
Now personally I think that is a VERY bad trait for someone to say that professionally they dislike something.
Your entitled to personally dislike something, however you must also know the benifits of using Hierachy based animation?
as well as a good artist is capable of making it work to some great effect ... - i've actually found that when i animated for a Quake3 Mod, the models i developed looked really crap as a single mesh. EVERYTHING bends and moves when you attach a skeleton, even if you setup the areas properly ... and something that will ruin a models look.
In my experience Machines works better Heirachy animated, and more to the point inanimate objects - which can't be achieved with simple skeletons. Once again you hit the Quality Vs Speed!
But in DarkBasic Std|Ehd|Pro you can use memblock to combine the techniques to produce some truely stunning animation which can even check for collision properly - so armour could be added like Unreal2's without loosing great heaps of speed.
now the reason why i constantly say that an artist should be working closely with (and not programming) is because although the artist does need to understand programming, his focus is on keeping works looking complete and consistance whilst also making sure it is appealing to those shallow people.
on my testing system you can get a good 150,000 polygon textured models, but then if you think about it... thats not a real test of the system.
Because there is a single texture as oppose to the 20-30 you should be using at any one time rendered
And you'd have far more mesh, each one would slow down the program as you have to initilise another render for them within the pipeline.
So a better test is 30 objects which make a similar bulk polygon count and texture load (yes even with the same texture) as a standard scene.
This is why its more exciting to alot of us about the new pipeline being able to handle hundreds of object per second faster, because alof of effects like spites also rely HEAVILY upon using lots of very uncomplex objects ...
you should allow for upto 500 sprite (you should NEVER need that many but atleast take into account this figure) which means 1,000 polygons
from 10,000 limit that is 10% already gone before any of the actual models are to be rendered.
you world if BSP should be given 3,000 (with perhaps a 500 poly buffer zone that you can decide per scene for use)
if you using Quake3 BSP then add on another 1,000! because of the adaptive spline surfaces.
so let say we're using Half-Life ... your now down to 6,000 polygons for the rest of your level.
so lets pretend cause we're using BSP its an FPS - so another 1,200. This might seem low compaired to other games like CS, but trust me a skilled artist can give you better looking weapons at that level - because you'd use a Visual weapon rather than a world weapon like Quake3.
so now we're down to 4,800 ... this isn't much to share between monsters and items as you'll agree.
say you have half-life grunts, 4 of them onscreen at once thats 4x800 (3,200) ... so now we have 1,600 for everything else - suchas wall health packs (which arn't included in the Vis of the BSP, are actually hidden dn show by distance from as all items are.
And suddenly 10,000 polygons for a screne doesn't seem to great.
Now to help eleviate this modellers and programmers deviced a system where futher away models have less detail, because this mean that polygon counts are less - which means less rendering type ... but more importantly give you more polygons to play with.
so you 800 poly grunt should now be cut down into 3 models (2 smaller poly models) ... which you should do at 20% intervals. This means the final model is over HALF the polygons of the original.
If once the game is finished speed appears to be there to spare, THAT is when you decide to up polygon counts - or add special effects like Bump Mapping etc...
But you have to always remember that Ai will cut 10-20% for anything good enough to make the player want to play, but not be so hard that he looses interest.
And networking also cuts down speed by about 15-20%, you tak on an extra 5% for dialup/usb modem users.
and don't forget the huge 10-25% that collision can take up
everything and aritst should be looking at is to keep as much free from the processing as possible whilst not destroying the visuals ... the job of the programmer should be to make sure that the controls and gameplay flow at a good speed.
As i've said... when you take away the main things from your polygon cache, then you relise how many you can have depending on the amount your going to see and thier required intelligence too (never forget that!)
however all this aside... it will also slow the game if the Ram of the card can't hold the models being rendered at the time, along with the textures and repitions (which actually make up th bulk) so you should be making this based on size, remembering everything gets converted in engine to the larger bitmap format or atleast 3-byte RGB image format.
it isn't AS important, however 16bit and 24bit renever also makes a difference on some systems as remember 16bit needs to be calculated whereas 24bit is a straight enough number
there are so many more things that an artist and programmer should be doing (and do when working professionaly) that the adverage user doesn't even bother getting to understand.
Normal Shading suddenly becomes and artists new best friend to eleviate texture needs.
now if you just making snake then these things are unimportant because really shouldn't be making anything the graphics and processor cant' easily handle.
but when you want to create a game which is greatly complex, suddenly these things become PARAMOUNT after the placemarker game is in place.
balancing performance with quality is a very fine art
and is better if everyone aim's lower than they'd like to, this way you do have a buffer gap for the just in case needs.
Anata aru kowagaru no watashi! 
