Engine Programmer

[Overstatement]

1. import...engines import data, not export. The only reason you need an engine to do IK is if you need to dynamically move effectors at runtime. If you are doing a simple wave animation in IK in whatever you use, IK information is not exported and it will be treated as a normal skeletal animation by the engine. So...why do you want IK?

2. Sounds like vertex animation to me.

3. Not sure how to do this. I've always thought the engine rotates some joint, making all it's children move around making it look like he is aiming.

4. If you are saying something like playing the walking animation while moving the model, every engine does that!

5. Should be supported in most engines....(not sure)

6. We will probably use some sort of popular file format (like MD3(MD4?!)) which you can download an exporter for. If you want an animation viewer, you will need the engine. How else could you see what it looks like in the game without the engine? Making the programmers make a seperate application would be a waste of time. If you really want to see how it would look like, just import and run it! In a perfect engine, it shouldn't look different then it Maya. Do programmers get an instruction limit when they start programming? Just do the lowest you can while making the models look good (its a balance).

7. Again seems like a waste of time. You can view shaders in 3ds max (its a new-ish feature).

[MR.Mic]

The viewing of shaders in 3ds can be extremely finicky, fucked up, or just non-working; a broken feature at best.

[goodkebab]

1. hmmm...my bad i think i worded that wrong.  But sounds like it wont be a problem when exporting to the engine (exporter bakes IK to every keyframe).

2.  blendshapes=vertex animation    sounds like simple vocabular lessons

3.  thats exactly how i think it is done  (programmer will have to constrain joint to follow aim reticle)

6. and 7.

i read up on Irrlicht and it seems to have a viewer for models and what not.  It is important to have this so we can just view the model itself and how it reacts to game lighting and how we need to tweak the shaders to fit.   We needed this while using RenderWare to find bugs in the animations and to get an exact idea of how the shaders would look....
//////////////////

finally,  we are letting the programmers decide what engine they want to work with...so what will you choose? 

[Overstatement]

If you really want it, but consider that rendering techniques will be changed often which means you'll get lots of updates. This is why I would rather have a map editor and a model viewer rolled into one, less updating for you guys. And that an out of date model viewer may screw up your models if you think it is being rendered good when in fact we already changed the code that breaks the models (ok, this probably wont happen. Models are models, do you REALLY need to adjust them to work well with stuff?)

As for the engine choice, I really dont care. I have no experince with either one of them (just read the source code a while). The discision is probably better made by how many programmers have experince with either one. Majority wins! It's not actually an immediate dicision anyways if we appy abstraction(which may be a good idea if lots of the programmers dont have experince with either one and not so keen on learning new stuff).