Hello,
I know C++ and I programming an engine in my spare time (no, you cant use it or see it!). I know a whole bunch of engine programming pre-ps1.4 up to parallax mapping (only know the concept of pmapping, not the math and stuff). Engine uses DirectX, Microsoft Windows(for input and ... windows) and soon to be intagrated with ODE for physics. Oh, and I've been playing CT Versus since it was released.
XFire: Overstatement
if you had a choice of free 3d engines to use...what would u choose?
Have any experience with Unreal Engine? Would you understand how it works?
It really doesnt matter. Engine stuff like animation and other stuff you've never heard of are the same in any engine and shader stuff can be(usually are?) customized for graphics.
Irrlicht seems to have the best and understandable structure (for me) and is even starting a map editor. It would also have to have fast code to make up for the fact that it exclusively uses the DirectX draw command that every book and website I've read to avoid because its inefficient (DrawPrimitiveUP).
But OGRE has a cool website, lots of games built on it and support.
I dont have any experinces with other engines. So I would just understand the generic stuff.
also, a good read on relief mapping...
http://fabio.policarpo.nom.br/relief/index.htm
I prefer relief mapping over parallax mapping, because parallax mapping has an inherent swim to it. Plus relief mapping self-occludes. (I know some mathematical models of parallax mapping self-occlude.) A disadvantage to relief mapping is aliasing at severe angles, due to precision problems in the raycast testing.
Also, irrlicht looks great.
Did I mention my Geforce 4 ti-4200 cant run anything past ps1.3?
There is no reason for this game (mod? what are we calling it?) to not have fallbacks. I'm sticking up for the little people with old hardware!
Edit: I still program shaders in assembly. I'm an old dog.
Quote from: Overstatement on November 17, 2006, 06:48:32 PM
Did I mention my Geforce 4 ti-4200 cant run anything past ps1.3?
There is no reason for this game (mod? what are we calling it?) to not have fallbacks. I'm sticking up for the little people with old hardware!
Edit: I will program shaders in assembly. I'm an old dog.
Fallbacks are perfectly acceptable, as long as the framework is in place to allow for more advanced visual effects.
Modularity is going to play a key role.
from a character standpoint the game engine has to have for animators:
Ik/FK
Blendshapes
Vertex Coloring
Blend animations
Animate UVs
Grab objects (neck grab)
Programmer needs to be able to isolate and animate joints (spy changes vision animation)
Programmer needs to constrain and aim joints (DA spy looking in direction of camera)
Be able to do multiple things while in different animations (spy changes orientation while jumping/falling)
AND it has to be able to do this all, fast and online with 4 players in close proximity.
... with decent FPS on budget systems.
Quote from: goodkebab on November 20, 2006, 03:09:34 PM
from a character standpoint the game engine has to have for animators:
Ik/FK
Blendshapes
Vertex Coloring
Blend animations
Animate UVs
Grab objects (neck grab)
Programmer needs to be able to isolate and animate joints (spy changes vision animation)
Programmer needs to constrain and aim joints (DA spy looking in direction of camera)
Be able to do multiple things while in different animations (spy changes orientation while jumping/falling)
AND it has to be able to do this all, fast and online with 4 players in close proximity.
Ok, we will add whatever you want
you really think you got the time and energy to do all that? How many people you need to help?
Actually, I was just too lazy to answer fully but now you've asked for it!
IK/FK - Dont know about FK is or how it applies to games. IK has always seem like overkill to me. Who actually notices if a characters feet are touching the steps when walking up stairs? Not quite sure what ever they could be used for that would not look incredibly ugly. You could mean "we need an engine where my IK-driven animation can run" in which case it will because file exporters export joint keyframes, not effectors.
Blendshapes - Dont know what that is. It could either mean vertex animation or multiple bone weights which are both widely supported.
Vertex Coloring - Not an animation issue, also supported.
Blend animations - Not sure about this. Engines can easily compose from 2 animations whose joints dont overlap but blending? Meh. If you mean blend in / blend out of animations, supported
Animate UVs - Good to go
Grab objects - Not an engine problem. This we'll HAVE to program.
Programmer needs to be able to isolate and animate joints - See blend animations
Programmer needs to constrain and aim joints - Dont know what you mean. Lots of people are here because they cant play DA. Your DA references are not welcome. If you mean making the head of a model always looking at an invisible cube (or whatever), not sure.
Be able to do multiple things while in different animations - When does a spy ever rotate while in the air?
AND it has to be able to do this all, fast and online with 4 players in close proximity - Duh
Sorry if I misunderstood something. Artists and programmers have different dictionaries.
Edit: Damn right I can do it, we are going to have an army of programmer who can barely tell the difference between compile and link. Give them all the boring stuff.
By the way, how hard would it to be to program walking animations that emulate how CT spies do it (non-floorslipping speed-changing interpretive footsteps)?
Just in case you have forgotten how spies walk at vastly different speeds, I have included a video of me hugging the wall and walking at an angle to make my spy move very slowly, so the effect is very clear.
Video is encoded in Xvid, any generic Mpeg-4 decoder will play it (divx, xvid, etc...)
Quote from: MR.Mic on November 21, 2006, 03:50:35 AM
By the way, how hard would it to be to program walking animations that emulate how CT spies do it (non-floorslipping speed-changing interpretive footsteps)?
Just in case you have forgotten how spies walk at vastly different speeds, I have included a video of me hugging the wall and walking at an angle to make my spy move very slowly, so the effect is very clear.
Video is encoded in Xvid, any generic Mpeg-4 decoder will play it (divx, xvid, etc...)
It should be super-duper easy. Every animation thing has an update function so you can tell it how much to advance the animation according to the time past since last update(frame-indepentant animation). Without this, the animation would not take time into consideration and would move dependent on how quick frames are rendered. You can see this affect with old games that run really fast on modern computers (because modern computers process faster than the computers they were designed for). So just update with less time past, for slower animation. Link it to how fast the model is moving.
1.the engine we choose needs to be able to export IK.
2. blendshapes....we may not need them but it is worth knowing. basically...imagine a face of the character with different expressions being animated without joints. This done by moving vertices around in the 3d program and then exporting the different positions of the vertices.
3. constrain joints. in CT, when spy was on a pipe and upside down and using his tazer....the arm was constrained to the camera....same with back to wall and using tazer.
4. spys can rotate in air while falling in DA -this is a subtle but effective addition for spys that fall from extreme hights but want to do a ledge grab beneath them. Spys can jump forward AND backwards. We have to have an effective solution for spies to be able jump over a ledge and do an automatic ledge grab.
5. Blend Animations. When you link between different animations...sometimes there are an infinite number of possibilities that the animator cannot animate.
Namely the Head movement when doing a vision change. This is done during ALL animations of the spy....the programmer will need to be able to do this. Animator will simply animate the head movement...and programmer needs to attach the animation to spy running, walking, crouched, climbing pipe....etc etc.
6. I will be using Maya for the animations...so I will need an exporter for maya to the game engine, preferably an animation viewer so i can test the animations without needing the game engine itself. And, I will need to the limitation (number of joints and skeleton heirarchy etc.) of the rig that exporter can handle.
7. Our modellers and texture artists will probably be using 3dsMax. They will also need to see their models in a view to test the shaders....like normal mapping and environments maps.
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).
The viewing of shaders in 3ds can be extremely finicky, fucked up, or just non-working; a broken feature at best.
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?
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 (http://en.wikipedia.org/wiki/Abstraction_layer)(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).