Technical information for player models

[leileilol]

problem is, nexuiz uses .zym which has a different way of animating models than what .psk and .dpm do because every frame number is a complete sequence itself.

[KadaverJack]

problem is, nexuiz uses .zym which has a different way of animating models than what .psk and .dpm do because every frame number is a complete sequence itself.

That's not a problem, since we want to get rid a zym anyway

[letmedoo]

Hello, I'm a newbee there!
I'd like to model 4 that game, and I'll do it!
I have a lot of things to learn : that's great!
See you soon!

[SavageX]

I found some information about how to do Quake III player models (segmentation, animation names and lengths etc.). Notice that we'll do normalmapping and most likely use a skeletal animation for the different parts to save memory space. I think that document gives a nice overview, though.

http://www.workspace-unlimited.org/beel ... Player.pdf

Edit: That document describes the process in Maya but I'm sure similiar things apply to Blender as well.

[leileilol]

segmenting is ugly

we're better off having to bother lordhavoc to add bone controller support via qc

[SavageX]

btw, here is the current model source (slightly outdated, but you get the idea - still the same animations and meshes) so you can get an idea how a .smd centric workflow is working with the conversion tools.

http://sourceforge.net/project/showfile ... _id=192474

[ihsan]

.md5 is not supported by DP engine. However there is md5 to UT2k4 psk/psa converter made by Riot (have to find link though) and DP engine supports psk/psa format. That can be good workaround and we can replace .dpm with psk/psa. So there would be no need to use md3.

I endorse this product or service

zym has to be replaced by a better supported format, at least until a proper set of tools are available (blender smd exports choke on zmodel).

From an ARTIST's point of view: The interest is there, the tools aren't. I'll put it in Unreal.
From an CODER's point of view: Just install a SMD exporter, configure separate tool via a TEXTFILE and execute via COMMAND LINE. How could you get easier than that? Lazy artist.

[nemyax]

I'd like to clear up a few questions:

• How many joints must the skeleton include?
• Do models need to be segmented? Does it even matter?
• Is there a limit on how many joints a vertex can be weighted to?
• Does the weight of a vertex have to be 100%?
• What kinds of animation sequences are required?
• How many frames long must the run cycle, walk cycle etc. be?
• Are you sure 1200 triangles is enough? The current models are heavier than that, and Doom 3's characters are between 2000 and 6000.

[SavageX]

I'd like to clear up a few questions:

• How many joints must the skeleton include?
• Do models need to be segmented? Does it even matter?
• Is there a limit on how many joints a vertex can be weighted to?
• Does the weight of a vertex have to be 100%?
• What kinds of animation sequences are required?
• How many frames long must the run cycle, walk cycle etc. be?
• Are you sure 1200 triangles is enough? The current models are heavier than that, and Doom 3's characters are between 2000 and 6000.

Uh, good questions:

Overall the skeleton should have about as many bones as the current one:

http://sourceforge.net/project/showfile ... _id=192474

I can't answer the weighting questions atm... I'll ask LordHavoc, he'll know.

All animation sequences Quake 3 had should be present (We'll be using basically the same animation system and the model-making process for Quake 3 is pretty well documented). We'll segment the models just like Quake 3 did (head, torso, legs) to enable looking up/down and sideways strafing. This has the advantage that every part can play different animations, too.

See http://www.workspace-unlimited.org/beel ... Player.pdf for a list of animations.

1200 polies indeed may be too slim. If possible we'd like to reduce the poly count compared to our current models to have faster shadow computations and overall smoother framerate. I guess > 2000 polies would be okay as well - depending how much detail of the high poly version can be cramped into the normalmaps.

The overall idea is to model very high poly, then use mesh reduction and code the difference into the normalmap.

[puffie]

Hiya!

I have done some professional work in the past for game studios via Turbosquid...

I have very good knowledge on how to use QERadient, Unreal ED, and HAMMER for HL2...

I own Zbrush 2, and can create the monsters you need.

I like to make static things as well, for my environments and maps.... this is what i am best at.

One thing I might ask is that you guys consider using the open collada format for your models and static meshes.

Collada can be imported/exported from Blender with ease. the MD2, and MD3 and MD5 exporters all really suck... I would have to install my old copy of milkshape.


here is some nice renderings I have done in the past:
http://s91842597.onlinehome.us/NEXTGEN/neptune.html
http://s91842597.onlinehome.us/NEXTGEN/Bigguy2.html
http://s91842597.onlinehome.us/NEXTGEN/ ... Final.html
http://s91842597.onlinehome.us/NEXTGEN/doctor1.html

sorry about my broken index page... I have not done casual artwork in quite some time