Version 0.01 of lunmodelgen.exe and .py:

[ http://lunaran.com/files/lunmodelgen.zip ]
[ http://lunaran.com/files/lunmodelgen.txt ]

The .txt should explain everything, but only if you read everything in it. I also included an unfinished example monster! 

 

i found a useful utility that will deform a mesh into the shape of your UVs. you can use relax and pelt mapping now for quake models. :)

http://slidelondon.com/iv

when you use it on a mesh, it creates a new mesh with a morpher modifier on it so you can go between the unfolded mesh and the original. now you can just export the skin from with the unfolded mesh, then use the morpher to bring everything back together, slap a skin modifier on top and start animating! (if you use the original mesh and then try to combine it with the unfolded mesh, the vertex numbers will be screwed up) 

So I can finally have the skins painted properly without all the annoying black space outside. 

OK, stupid question (well, stupid person...);

How is the skin information in Quake different to normal texture/skin information in 3d apps?

I'm curious as to whether I can use the funky new 3d painting shiznat in PS CS3 Extended to skin quake monsters (or at least, a combination of PS and maya/lun's script) 

There are two types of UV vertices in a quake model, onseam and offseam. The offseam vertices are the ones not on the perimeter of any shape on the skin. These are exactly like UV coordinates in any other app: each such vertex on the skin is paired with one on the model, and every triangle which meets that vertex will have the corresponding triangle meet it on the skin.

The difficulty arises once you get to a vertex on the edge of a piece on the skin. You don't want all of the triangles which meet at that vertex on the model to join onto it at that UV point on the skin, because you would like to unfold them as separate pieces.

The quake mdl format allows such vertices to be designated "onseam". Then two copies of this vertex will be made on the UV map (but not the model) - one on the left hand side of the skin, and another half the skinwidth to the right of it. To determine which triangles connect to which copy of the vertex, each triangle in the model has a flag "facesfront" which is set by the model compiler. If the triangle faces front it is connected to the left hand vertex, otherwise it connects to the right. As you might guess, the original quake model compiler calculates this based on whether the face is front or back facing, which is why you get the front/back pairing on the original skins.

The alternative, which I support despite always listing it's negative effects, is to make none of the vertices "onseam", but instead make actual duplicates of those vertices in the model which are on the edge of a skin segment, so that they can be moved where you like on the skin. This allows for much better packing of the skin, since you can do things like mirroring halves, devoting more space to things which face front, all the tricks basically. 

Preach, that gave me more perceptive!
Point is I gave the granito.qc three pain sessions so
the self.th.pain = granito_pain_decide
I can change it but how do I calculate the other three pain session?

a closer watch:
http://members.home.nl/gimli/granito.qc 

It looks like most of what you need is there. First thing I would try is change all those pain finished things to equal time + 5, if it's meant to be a really powerful monster.

There's a small bug which means the first pain animation won't ever be called, you should change

if (r < 0.66)

to

else if (r < 0.66)

otherwise when r < 0.33 it's also < 0.66 so the second pain sequence overrides the first one.

To make the pain animations less likely to happen, you could change to something like

if(r < 0.05)
{ first sequence...}
else if(r < 0.1)
{ second sequence...}
else if(r < 0.15)
{third sequence ...}


That way if r > 0.15 none of them happen. You could even finish that with:

else
self.pain_finished = time + 0.5;

so that if it doesn't go into pain that time, don't even bother to check for the next half a second, which would defend it against pain from nails/lightning a bit more.

You may find putting all these things in might go too far the other way, I'm just throwing them at you so you have the options. 

That goes great!

First I copied the shambler's part of the sham_pain, but then I lost the other two pain sessions in the self.th.pain statement.

But indeed it has more power now. It can't be shot so easily and that's what bothered me in the first place for an end boss.

Hey, thanks for that splendid cham_pain explanation! 

wouldn't gl engines copy the vertex anyways for rendering? 

Yeah, but that copy wouldn't count towards the limit of 1024, only the ones that are loaded from the mdl structure count for that. 

Was just browsing Polycount and someone made a script like the one necros posted for Maya:
http://boards.polycount.net/showthread.php?t=55987
Thought it might interest someone maybe. 

do I create the last death frame of a monster,
so its death scene leaves in another skin index? 

just add self.skin = # in the last frame function.

but seriously, madfox. post this stuff in the programming thread. :\ 

thanks for advice.
nice thread. 

if anyone's interested in modeling and uses milkshape i have a tutorial i wrote that might help you out.

it's here: http://z10.invisionfree.com/Quaked/index.php?showtopic=4