I retraced the grenadelauncher from a flat vertice mesh in the hope it would get the UVWrappers attention.

Doesn't make a lot difference in detail though.
And gmax handels it as a sepperate file so I have to search on.
Thanks for the reply though!

I wondered, is it possible to place the verts behind eachother, sparing skinsize?

v_launch 

I wondered, is it possible to place the verts behind eachother, sparing skinsize?

Should be (it's common practice), unless Quake has some funky limitation. 

Are typically generated by Qme, which does back/front mapping without any controls for stacking or packing the UVs.

Not sure what the original models were made it, but they set the precedent. 

Yes, the quake model format does support this, but like ijed says, the main editor that handles .mdl format has exactly one way of making skin layouts. It loads files which are more creative though - there's an example of a dome model which overlaps vertices here:

http://tomeofpreach.wordpress.com/2012/12/20/dome/

While I'm throwing out links to my blog...

http://tomeofpreach.wordpress.com/2012/11/24/a-modelling-pipeline/

...describes one way you might go about making such a .mdl file. The "madfox care package" linked a few posts ago has a ready-made setup for the first half of the article, which gives you a .mdl file to work with. 

ijed et al, what is the preferred format to export uvw maps?

3dsmax's is a binary format and I guess proprietary... :\
that wouldn't be much fun to decode... 

@spiney - I placed the verts behind eachother and it worked. First skinsize had 194x220 and this one gets 184x195 smaller.
Three objects won't layer I suppose as one gets stick in the middle.

@preach - I managed to get the object attached in Gmax now. And it also collides exact to the torso, more than I could animate myself.
Only bad point is that the attached model don't want to export. It keeps asking about modifiers. 

Can you screencap the error message you get? 

I honestly don't know - I just export to whichever format works. I prefer not to use proprietary formats since it just closes doors on collaboration. And you never know when they'll change the format.

I know that the .obj format is universal, supports UVs and can be imported into just about anything.

However it doesn't support animation, so typically I use FBX, which supports everything and is well supported and stable.

It seems popular with everyone here as well.

As to what UVW format it uses internally... IDK sorry.

Let me know if you need any testing done.

I also have another request... IQM format.

Skeletal as opposed to vertex animation just looks better. Strangely enough was only implemented in the 4th version of MDL / idtech as well. 

You can get dev kits from Autodesk for the format, just need to plug the code into your codebase and it should work.

http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7478532

Also FBX is not limited to triangles, you can store stuff in quads which is a lot easier for modelling when everything is not a huge mess of triangles. 

oh so you guys import UVs by importing a whole model then? ok, that works too.

I already have OBJ and FBX is plain text too, so not too bad to figure out how to deal with it.
I know sock has trouble with OBJ in lightwave so it's probably a good idea to get FBX in anyway.

Is IQM plain text?
I doubt I will touch skeletal modelling, at least for a while. there's a lot of new stuff to take into account there. 

It's binary. Here's the site: http://lee.fov120.com/iqm/

But yeah, probably something for (current version + 1). 

An inherent flaw in how Quake treats animation I was fighting with the last night.

Having all the animation lumped together is a big cause of the dodgy frames issue. You know the one, where the animation continues fine but at the end or start of the loop one additional frame makes the monster (or whatever) pop into some unwanted pose.

Qme had fairly good tools for naming and ordering the frames, and hunting down errant ones.

3dsMax at least doesn't have anything, so I end up counting the frames manually.

Having said that, there probably is a plugin somewhere... 

This could help:

Animation > Track View > Note Track 

I can export the model from Gmax to md3 and Noesis can convert it to a mdl. An mdl file in Noesid exported to md3 Gmax won't capture.
So far so good.

There is only the thing of attaching the launcher to the model. When I import the launch.dxf and try to attach it to the legs my animation gets lost.
Whwn I attach it to the torso, the uvw file also gets attached to the torsos-kin and ends up in a distorted skinfile

I can scale this part th fit into the already excisting skinfile, but the loss of texture also scrambles the launcher
Also think I had to skip some double objects while exporting as the vert/tris count gets much too high.

So it is a case of a proper attachement of the launcher to the original file without the loss of the uvw skinfile.

I tried the othe way around by just merging the launcher.mdl into the converted md3 model in QMLE. That way I also get a skinfile, but at least the proportions are in a usable manner

I loose all my animation so I have to stretch 218 launchers to make the file fit.
Didn't expect it to be such a hussle! 

Don't do that! Once you've correctly organised your UVs on the rocket launcher, delete all the non-rocket-launcher parts from than object, and import the rest of the model as a new object. You can export multiple objects to the same md3 file, so there's no need for them to be combined any more. 

I come sofar, every attempt to attach it will scramble the skinfile of the corresponding file.

http://members.home.nl/gimli/norb.jpg 

Having all the animation lumped together is a big cause of the dodgy frames issue. You know the one, where the animation continues fine but at the end or start of the loop one additional frame makes the monster (or whatever) pop into some unwanted pose.

Qme had fairly good tools for naming and ordering the frames, and hunting down errant ones.

Yeah, that's annoying. When I was making the models for Sock, I would have to manually go into the model and rename frames each time otherwise he had no way of knowing what was what.

Ideally, I'd like to eliminate that. My original intent was to import seperate OBJs as 1 frame each. This lets you name files and give the frames names inside the model. FBX looks like it's more geared toward storing a whole animation in one file though. 

It�d be nice to have discrete files for each loop - I waste so much time just ordering stuff to get rid of a single bad one.

Without moving to a new file format I can�t think of an elegant way of doing it though. Possibly it could be done with IQM, will have to talk to the author.

Having seperate files per from is also how QME does it - but it becomes almost as time consuming to manage as counting the frames in a 3D app.

I remember someone not versed in Quake passing me such a collection of frames, animated at 30 FPS. I got the original but exporting frame by frame was the only option I knew at the time.

It worked, but drove me slightly insane.

...PS: For a creature called �BOSS2� 

This keyboard is missing four keys. 

Yeah, I guess I can see how it's not ideal either.
All the monsters in Quoth were exported manually frame by frame... that was painful.

With Sock's monsters, I wrote some maxscripts for myself that automates everything but I can appreciate that it's not always an option if you don't know how or your 3d package doesn't have scripting.

I just don't see a solution outside of individual files per frame. 

I'm glad I have Gmax as my version of max3d 4.1 won't help me out with this skin problem. Forcing the torso part to attach the launcher distorted the skin file. Then I realized I could use the material editor to add the launcher skin again.

idle

Thanks Preach, I really would have added the launcher animation manual, but the way it now collides is perfekt! 

Wow, this is great... but weird :P 

Now it gets as bad as Quoth's RocketEnforcer,
the one that made me fear so much. 

While playing I wondered.., the rocketlauncher has three puffpipes.
In game the player sees them in front, so it looks as if the launcher is turned back.
The v_model shows it with the pipes behind.

Is it mirrored or am I shooting with the wrong way out? 

who shoot's who