 And A Post With Content...
#1 posted by Preach [81.153.85.180] on 2009/05/17 18:54:50
I tried to keep the title post nice and short in the hope that this thread is as long lived as the coding one. So here's a slightly longer one with more information (and also more of my opinions you've heard three times before)
The mdl format was one of the first 3D model formats for games, and naturally is a little less advanced than anything seen today. Here's a rundown of the most important mdl limits:
1000 vertices
2048 triangles
256 frames
The other important limitation of the mdl format is that the vertices are stored with a precision of 8 bits per coordinate axis. The vertices are in effect "snapped" to a grid of 256x256x256 points. This means you can't create intricate detail in your model without it being lost when it moves. It is worth noting that the origin and spacing of this grid can be specified, so the level of detail which can be retained is relative to the overall size of the model.
Editing
One of the greatest barriers to making models for Quake 1 is the lack of good tools. The best tool which works with .mdl format natively at the moment is QMe. You can grab the full 3.0 from:
http://www.fpsbanana.com/tools/254...
and you can upgrade it to version 3.1 with the patch in
http://www.xs4all.nl/~renep/quakem...
Although QMe is useful for this reason, I'd personally recommend working with the mdl as little as possible. It is generally easier(in my opinion) to create your model in another format entirely, preferably one with a powerful editor which saves the vertices at high precision. Then just export the model to mdl each time you want to test it, much like you compile a new copy of the BSP each time you add to a map.
QuArK ( http://quark.planetquake.gamespy.c... ) also handles .mdl format natively, as well as other more popular formats such as MD3. I've never been able to use it for any serious editing, but found it a useful tool for converting file formats. So it sits somewhere between working directly with the .mdl and just a waystation for converting files.
If you work in Maya, you are fortunate to have the most direct route to export to .mdl. Lunaren has written:http://lunaran.com/files/l...
One package which handles everything directly!
If you work in Blender, you can give a script for exporting to mdl directly a go:
http://www.btinternet.com/~chapter...
I wrote it a while ago, for blender 2.4.4, and I don't intend to ever revisit it. But it's written in python, so it should be straightforward for people to modify themselves. Alternatively, you can export your model to MD3, using either http://tremx.svn.sourceforge.net/v...
or http://cube.wikispaces.com/MD3+Exp...
Once you have an MD3 of your model, you can run it through QuArK to convert it to mdl. Alternatively (blowing my own trumpet here) you can use "MD3 to MDL"
http://www.btinternet.com/~chapter...
This is my new work in progress, and I welcome any feedback on it. It's a simple command line tool, requiring only a short text file and an MD3 to work from. I'm planning on extending the control file format to include things like model flags, multiple skins, named frame ranges and stuff, so suggestions of what could be useful will not go ignored.
Since MD3 is so well supported amongst editors, you can use the above to get to .mdl format from most major 3d modelling packages. If you don't have any of the more expensive programs (like me), then you could do a lot worse than getting a copy of Gmax. It's a stripped down version of 3d studio max intended for making gaming models, and it's free. Official support for the idea ended a few years ago, and http://www.turbosquid.com/gmax took over distribution. Make sure you also download the Tempest Game Pack, to get the md3 export you will need. Personally, I can't do without gmax...
This thread is pretty much a continuation of http://www.celephais.net/board/vie... , a thread I'd forgotten about until I started researching for this post. Hopefully putting all this information at the top of the thread justifies starting a new one.
Finally, if the low polygon requirements of Q1 seem constraining, take a look at:
http://boards.polycount.net/showth...
The things some of those posters do with 500 polys are just amazing.
 Good Thread
#2 posted by ijed [190.20.112.240] on 2009/05/17 19:03:35
 I Like How My Browser Autocompletes Arrrgh As A Post Title
#3 posted by Preach [81.153.85.180] on 2009/05/17 20:05:06
Lunaren's mdl export is at http://lunaran.com/files/lunmodelg...
I previewed to check which links worked, and then messed up actually fixing that one.
Also, to get the ball rolling on actual models, here's a pair of screenshots of the ogre I made ages ago based off metlslime's drawing:
http://www.btinternet.com/~chapter...
http://www.btinternet.com/~chapter...
Last time I posted it, it didn't have any blood splatters, and that criticism has been answered. One of the reasons the first version lacked them was that the entire skinmap was mirrored, and so any blood splatter on the chest ended up looking like a rorschach blot. So I carefully unmirrored a few polys here to do the chest.
The other reason I hesitated to do it before is because quite a few of the original id models rely on excessive amounts of blood to mask horrible UV failures. I wanted to make sure this model didn't do that anywhere, which is why the blood is a bit restrained. Hopefully he still looks like a butcher!
 I Must Say
#4 posted by meTch [69.183.71.111] on 2009/05/17 21:22:14
that ogre looks awesome,all it needs is a small amount of blood specks and splashes on its clean face and it will most likely be a widely used replacement
#5 posted by MadFox [84.26.168.11] on 2009/05/17 23:48:46
Thanks for the toppic.
After my own experience with quake models I must say you skinned the Orgue well. In the overall making of models I find the texture part the hardest.
I must admit that if i hadn't had Quark4.07 I couldn't change the dimensions of the model, nor manipulate groups of vertices.
One of my greatest concerns of QMLE is the texture part.
What do I do with tex triangles that are mirrored after imported in Qmle?
If I delete the triangle and patch the vertices again the triangle:
comes back with the same texture, so it's useless work
comes back with a extensive texture subdividing, so texturing can only be done by percisely following the lines untill they make squares.
 Mirrored Trick
#6 posted by Preach [81.153.85.180] on 2009/05/18 00:37:22
Here's how I avoid the problems with the mirrored textures in qme: I don't use qme for that model - at all!
Now this is something I'd like you to try MadFox. Have a go at making a quake model without using qme, and see how it goes. If you don't like it, then that's fair enough. But based on the problems you've posted, I think you will like it.
 Ha!
#7 posted by MadFox [84.26.168.11] on 2009/05/18 01:52:15
feels like asking how to learn riding a bike,
and then say don't use the bike. Start walking.
^^
I don't make the model with Qmle, I'm glad I can import them into Qmle with 3DS files. This goes with an animation programm which is more specificated. I have to change the export to one patch per polygon.
And as it only goes with squads, all triangles get doubled.
Then I'm confronted with importing the New Model from frame.
Saving this first frame also makes my skin frame.
Then I have the choise to turn this first 3DS frame by changing the skin adapture. According the import file it will be a front sight or a side one. So when a triangle gets mirrored I'm delivered to Qmle weary workarounds.
I already tried other ways, but the thing that knocked me out was the import/export to Max3D.
Everytime I seem to get two vertices more by exchanging.
 Just Make Sure
#8 posted by inertia [69.135.215.146] on 2009/05/18 03:49:10
to put it under a restrictive license.
#9 posted by MadFox [84.26.168.11] on 2009/05/18 04:04:15
Do you mean Qmle or Max3d?
Here's a new version of my Granito monster.
The first one was rather blocky.
http://members.home.nl/gimli/grani...
#10 posted by Trinca [194.65.24.228] on 2009/05/18 12:27:56
still need many fixes but is looking great!
 I Don't Wanna Be A Candidate For Vietnam Or Watergate...
#11 posted by Preach [81.153.85.180] on 2009/05/18 20:16:03
feels like asking how to learn riding a bike,
and then say don't use the bike. Start walking.
But the bike keeps crashing, mostly because it has bent wheels, no handlebars and a loose chain. Under those circumstances anyone would recommend you try walking!
I don't make the model with Qmle, I'm glad I can import them into Qmle with 3DS files. This goes with an animation programm which is more specificated. I have to change the export to one patch per polygon.
And as it only goes with squads, all triangles get doubled.
Yes! The point at which you start importing the frames into qme is the point where the problems arise. This is what I'm driving at. You can avoid that problem by creating an mdl with all the frames in first, and then open it in qme.
I'm not saying it's impossible to make a model importing it frame by frame in qme. But if you import frame 1 into QMe, then change the original model, then try to import frame 2 from it, then it's very likely to fail. The import system from QMe just isn't designed well enough to do that(if indeed such a thing could be made).
The only reliable method is to re-export all the frames from the latest version of the model, and import them into a fresh qme file. Since then you need to scale them all, reimport the texture each time, etc - EVERY TIME the source model changes, it becomes a huge hassle. But if you stick with just QMe for the conversion, it's what you must do.
 Pro Tip: GLQuake Flood-fills Skins
#12 posted by metlslime [173.11.92.50] on 2009/05/19 00:19:43
this has bit me in the ass twice, once a few years ago, and then it happened again until i realized what was going on:
If you are modelling something like a laser or fireball or something, the temptation is to just fill the entire skin with the color or pattern that you want to use as a texture. The problem is, glquake and most variants will flood fill black into whatever color is in the top left corner of your skin. So if your blue laser has blue all the way to the corner, that blue will turn black and you will be saying WTF when you see it in the engine.
Fix: for solid-colored skins, put a single black pixel (or other un-used color) in the top left corner.
 Errata
#13 posted by MadFox [84.26.168.11] on 2009/05/19 00:53:30
Trinca, thanks, but explain me the need of fixes.
Preach, don't care my foolish waistblam, it was just the first thing that came up to me. Being modelling so long on my own way made me more curious to other ways.
Hassling the first frame is because I want to have a good skin.bmp
When the basemodel is imported it can be on different sides. At that point my model is already done. So I can import them as one load, and the only problem I reach is some verticemeshes. The way I described it was somehow confusing. My fault.
Something else got my attention in trying to avoid the mirrored texture.
When I delete a triangle in Qml and add a new one the original count gets different. This seems odd as logically this shouldn't be so.
After that I can't add frames to the original.
But when the model is full of frames, these changes don't seem to bother.
 Triangles And Verts
#14 posted by Preach [81.153.85.180] on 2009/05/19 01:36:41
The reason why you can change triangles like that is because the first frame you import to qme is given special treatment.
When the first frame is loaded, the program loads the triangles and the vertices. The vertices are assigned numbers as they are loaded, and the triangles are recorded as sets of three numbers, each number corresponding to one of the triangle's vertices.
For all the subsequent frames, the triangle information is entirely ignored. All QMe does is load the first vertex from the file, and move vertex 1 to it's location, then load the next one, and so on. The list of triangles from the existing model is always used. You could import a frame from an entirely different model, as long as it had the same number of vertices.
The obvious danger is that your modelling program might not always export the vertices in the same order, particularly if you change the model somehow between two exports. This is how triangles can start to go astray. There's no way to control this kind of thing, which is why the import process can get frustrating. As far as the exporting 3d package is concerned, one ordering of the vertices is as good as another. But for the import, it's the only important thing!
 Clear
#15 posted by MadFox [84.26.168.11] on 2009/05/19 02:46:41
You could import a frame from an entirely different model
This reminds me to the moment I had the last death frame of granito,
and used the expand function in Milkshape to make all polyhedrons
wide out as an explosion.
It took me quiet some time to make sure I had the right count.
The frame imported the well, but when I closed qmle and reopened the old death frame came back again.
So it are the vertice count that need to match, not the triangles?
 Frogman
#16 posted by MadFox [84.26.168.11] on 2009/05/21 19:58:16
In my search to new monsters I'm fixed upon the need of some danger in Quake waters. Only the hartbreaking code part stopped me from doing. This doesn't avoided me to try and I came up with this creature.
In Quake defs it outranges the limits as it goes up to 507 verts and 957 triangles. But I still see it appear in Quake so my greatest concern is to have it good skinned.
http://members.home.nl/gimli/frogm...
 Ribbit
#17 posted by meTch [69.183.70.203] on 2009/05/21 21:24:31
;]
 HE WILL LIVE!
#18 posted by ijed [200.111.70.236] on 2009/05/24 20:59:51
 Texture Question
#19 posted by MadFox [84.26.170.230] on 2009/06/18 23:51:21
I restarted the frogman again because the base frame had a bad texture error. By doing so I got messed up with vertice errors that went so far that now on my x-th frame I became a little nerd.
I wondered. If I look at the dragon.mdl of DOE it seems they have cut the whole monster flat on the texture frame. If I look at my base frame I get the picture of the monster front and back. If I cut the monster into pieces (sure, one day) Qmle gives me the well known error: vertices and triangles are not the same.
How do they do it?
 Right
#20 posted by MadFox [84.26.170.230] on 2009/06/20 22:39:19
found it. it has something to do with cheating qmle import and export abbilty's.
yes, this makes the texturing a lot more acurate.
 Crossbow
#21 posted by MadFox [84.26.170.230] on 2009/09/10 03:26:11
I plunged myself adding a new weapon in Quake1 and have come to the point I could compare it with the SuperNailgun. I added an arrow and add it to this weapon. Sofar sogood.
Then my perfektionistic habbits turned up and thought: how can I make this arrow fall to the ground instead of vanishing in space?
I'll stop because I want it's velocity not as fast as 1000 and I want it replaced by the axe and... so how make I fall it against a wall and it lies there for say a few seconds?
And post with content so here I go...
http://members.home.nl/gimli/cross...
#22 posted by necros [99.227.133.158] on 2009/09/10 03:58:08
i did this for my stake gun a while back.
essentially, you're going to go into the projectile touch function and get rid of the the lines calling remove(self) or SUB_Remove().
now, it's a matter of changing the movetype, so where the remove lines were, you put it self.movetype = MOVETYPE_BOUNCE.
now, you don't want the thing to stay there forever, so we're gonna put SUB_Remove() back in, but in a different way.
put in self.nextthink = time + 4 and under that self.think = SUB_Remove. this will get rid of it 4 seconds after it hits.
finally, you can add in some extra stuff like making it spin around randomly with setting self.avelocity to some random values or you could spawn a TE_GUNSHOT for sparks or something else.
 Thanks
#23 posted by MadFox [84.26.170.230] on 2009/09/10 21:26:12
necros, I will try it out.
But I was thinking, what if the arrow doesn't hit a wall but a monster?
Then it should disappear immediate.
#24 posted by necros [99.227.133.158] on 2009/09/10 21:33:22
you're quite right.
luckily, it's very easy to do so.
simply make a check:
if (other.flags & FL_MONSTER)
remove(self);
this will check if other (whatever it hit) is a monster, and if so, remove itself.
 Mf
#25 posted by ijed [216.241.20.2] on 2009/09/10 21:48:10
Look in the RQ code for nails.
 What The...
#26 posted by necros [99.227.133.158] on 2009/09/11 09:30:01
apparently you can have skin groups on models. o.o
#27 posted by Willem [24.199.192.130] on 2009/09/11 13:48:41
Yeah, I discovered that when fooling around with my model editor. Some cool stuff could be done like blinking lights on enforcer suits and blinking, glowing eyes on monsters.
 Yep
#28 posted by ijed [190.20.113.119] on 2009/09/11 13:52:09
Animated monster and weapon skins. You remember the 'talking' skins in Seal of Nehahra?
 Max 4 Though
#29 posted by ijed [190.20.113.119] on 2009/09/11 13:52:22
 Necros
#30 posted by MadFox [84.26.170.230] on 2009/09/11 16:24:49
I renewed the download with my additions.
Although I altered the weapons.qc with your advice on #22 the arrow seems to stick in the wall and slightly turn to left untill it meets the corner. Then it disappears.
I also added the grenade tumble but it doesn't append.
I only had one time it started raining arrows.
You can cheque it on the same download.
#31 posted by necros [99.227.133.158] on 2009/09/11 20:17:13
you put all the stuff in the if statement that checks if it hits sky, that's why.
 Statements
#32 posted by MadFox [84.26.170.230] on 2009/09/12 02:11:38
It was the first calling remove(self) in arrow_touch I came to.
I didn't realize it had to be the second one on the end of the script.
It's working well now, thanks!
 Am I Wrong
#33 posted by ijed [190.20.64.211] on 2009/09/12 02:18:05
But shouldn't just adding 'nextthink X' and leaving SUB_remove have this work?
The projectiles would still do damage while waiting to be removed, but not if their touch was changed / removed.
Argh. The definition of complex - lots of simple.
 G-Rail Gun
#34 posted by MadFox [84.26.170.230] on 2009/09/20 15:10:29
I followed the code of Dr.Shadowborgh to make a new weapon in Quake1. I added the Q2 g_rail gun and assigned it to the double shotgun.
So far so good.
Now my concern is starting a game with the g_rail.mdl.
Although this weapon is coded on the doubleshotgun (3) it loses its touch when I switch to the shotgun.
So when I still have enough cells to shoot, the game only offers me the railgun again when I collect the DS.
So stop shooting is gone gun.
I am forced to add a double shotgun too before I can acces the railgun again.
Is there a model-code to solve this?.
example:
http://members.home.nl/gimli/grail...
 Erratum
#35 posted by MadFox [84.26.170.230] on 2009/09/20 15:16:06
assignement is 8
replacement thunderbolt.
 Coverting Q1 Mdl File Into Some Format Readable By 3ds Max
#36 posted by necros [99.227.133.158] on 2009/10/13 00:27:45
normally, i would just do a dxf export from qme and import that into 3ds, but for what i want to do, i need a fully animated model (with all it's frames in order).
i have a .mdl converter (mdl.exe) but it's about the dumbest thing i've ever seen as the program outputs all the frames as seperate meshes into the .3ds file it outputs. so when you import it, you get like 150~ duplicate meshes, all different frames.
am i sol for this? any utilities i'm unaware of?
 If You Find One
#37 posted by ijed [190.20.104.33] on 2009/10/13 01:58:45
Post it.
I've been hunting but have drawn a blank so far.
 Necros
#38 posted by MadFox [84.26.170.230] on 2009/10/13 20:39:31
Don't you have the Q2MDLR9B, I searched for it but it's one old Q2 mdl converter with also Q1 models. It exports into 3DS very easily compatible toMax3D.
Here's a linkhttp://members.home.nl/gimli/q...
 Oopsh...
#39 posted by MadFox [84.26.170.230] on 2009/10/13 20:40:07
 Thanks, But
#40 posted by necros [99.227.133.158] on 2009/10/13 20:45:29
no luck, sadly. q2mdlr exports each frame seperately as well. :S
#41 posted by necros [99.227.133.158] on 2009/10/13 20:54:50
i think maybe the solution is in 3dsmax and not the exporters... there might be some way to create a vertex animation out of multiple copies of a mesh as long as the vertex # are consistent.
the thing that jumps out immediately would be to use the morph modifier with 1 channel for each frame, and to incrementally toggle each one on and off on the appropriate frames, but that would be extremely annoying and there might be a limit to how many morph targets you can have.
 Nope
#42 posted by ijed [216.241.20.2] on 2009/10/13 21:48:43
Morph would do it, but be very time consuming.
A nastier problem would be that each model would be its own object, and so have the verticies number individually - there's no way to manage this in max.
Normally with morph you use instances of the same object so that the verts have the same numbers - different objects would most likely get interpolated all over the place.
Bones is the way to go - but that means recreating all the monsters as such :P
 In Fact
#43 posted by ijed [216.241.20.2] on 2009/10/13 21:52:05
It wouldn't take much time really - what's needed is a decent morph plugin that allows more vert control - morphing via position as opposed to number.
Will be looking around.
 Two-Step
#44 posted by Preach [94.192.82.29] on 2009/10/13 21:53:16
My usual route is to convert it to md2 format using QMe, and then importing that with an import script(this is gmax, but I'm pretty sure that the same script can be found for 3dsmax). I do worry that some animation quality is lost in the conversion. It is potentially avoidable, by choosing the scale to be the same in each frame of the md2 you can get a lossless conversion, however I suspect that QMe does not do that.
If the fidelity of the animation proves to be a problem, then I might be able to knock up a python script or something which does mdl->md2 lossless conversion(modulo the skin, which would just get mapped index for index).
#45 posted by necros [99.227.133.158] on 2009/10/13 22:12:53
the gmax md2 importer script here: http://www.scriptspot.com/3ds-max/... works with 3ds max 9. i was able to import some stock q2 models in with full animations in.
next i'll try converting to q2 from q1 format.
 ...annnndddd
#46 posted by necros [99.227.133.158] on 2009/10/13 22:15:24
success! thanks for the help! ^_^
 Great, Just Great
#47 posted by spy [92.46.24.221] on 2009/10/13 22:20:30
 Will Give It A Try
#48 posted by ijed [216.241.20.2] on 2009/10/13 22:46:35
If it works with 9 and gmax then in theory it'll work with all versions since gmax was discontinued a few years ago (?) so it should be alongside the .3ds format - one of the few things they don't fuck about with on a version by version basis.
 Amphibian
#49 posted by MadFox [84.26.170.230] on 2009/10/25 19:36:23
I have come this far with my amphibian monster.
It stands on land and in water and starts its attack as soon as the player is in vieuw. The landmonster will start shooting and follows it into the water where it turns into swim behaviour.
The watermonster will go into swim position vieuwing the player, but only starts its attack when agitated. Also it hardly shoots as its position is somehow dull.
Point is I can't get it out of the water.
I'm trying to see with my hard-egged qc cramp what's going on but must admit I'm a dumbass.
Here's an example of the model:
http://members.home.nl/gimli/harpi...
#50 posted by necros [99.227.133.158] on 2009/10/26 02:44:31
didn't look at the code, but for the (uncompleted) monster that was supposed to do what you are describing, i settled on making special monster jump triggers.
essentially, you would make your trigger in the area you wanted the monster to jump out of the water and you'd just set speed and height just like a normal jump trigger.
the only differences were that:
1. it didn't affect any other monsters
2. if it was a 'get out of water' trigger, it would do nothing if the monster was on land (and if it was in the water, 'get in the water' triggers would similarly do nothing).
it makes coding it a lot easier, but it kind of takes away from the monster by making it dependent on the mapper. (imagine if fiends only jumped where mappers put triggers, for example).
you could take a look at the code that makes the player jump out of the water. this could work but it could be troublesome.
the player code is run every frame, so it doesn't miss chances to jump out of the water.
but a monster not only is running it's code slower (0.1 seconds) because of movetogoal, it will never really be flush with walls unless it gets lucky.
otoh, if all you mean is you can't get the monster to walk out of the water on, say, a ramp, the trick is to take off the FL_SWIM flag early.
every frame of your swim function, run a test of the pointcontents over the monster's head (say 16 units over the monster's origin) and use that point to determine when to swim or walk.
 Btw Madfox
#51 posted by necros [99.227.133.158] on 2009/10/30 09:34:31
i wanted to ask you how you combined the legs, torso and head of the skeleton from quake3 when you converted it to quake1. i can't think of a way to do that in 3ds max while preserving the animation. :S
 Well..
#52 posted by MadFox [84.26.170.230] on 2009/10/31 09:56:41
I must admit I have only converted one frame of the deathscene,
where it stands straight with all limbs in line.
From there I made a 3ds file of it, which I used as baseframe.
Then in am2000 it is possible to make the model act with sepperated limbs and export the 3ds.
Then I bunched against the 1000 verts limits of Qmle, and had to substitute the torso with all the fine parts for a much simpeler one,
and then I could import the 3ds into QMLE.
It sounds simple, but I tried the knight in Max3d and must say the way it handles bones is much more specific I could give my patience.
Which programm do you use to convert the model?
I searched, as it was in answer of my question
how to convert q3 maps to Q1.
Something like Q3map2 :
http://shaderlab.com/q3map2
 Bspc
#53 posted by MadFox [84.26.170.230] on 2009/10/31 10:27:00
mapping help #6458
#54 posted by necros [99.227.133.158] on 2009/10/31 19:37:47
after 2 days of trial and error, i figured out a way to do it.
http://necros.quaddicted.com/temp/...
(hunter was always my favourite ^_^ )
the process is roundabout and exceedingly headache inducing. :P
also, if you want to do this, read my whole post first.
step 1: we need to get the 3 q3 md3 files (head, torso and legs) into 3ds max (in my case).
for this, i used this script: http://www.scriptspot.com/3ds-max/...
surprisingly, it worked in 3ds max 9 (usually most scripts this old would never have worked).
if you follow the instructions on that web page, it will work properly: use the script to import upper.md3 first, then lower, then head. this will make sure the tags link up with the body parts.
(pre) step 2: involved transfering the animation key frames from the torso tag onto the torso mesh itself.
the torso doesn't actually move, it only has vertex animation; it uses the tag to make sure the torso is properly oriented with the legs but in order to export the animation, both the translation and rotation must be on the torso mesh object.
step 2: select your torso tag and go to file -> save animation.
save the file with a name of your choosing some place convenient.
now, select your torso mesh and unbind the mesh from the tag.
go to file -> load animation and select the file you saved earlier.
you will get a message box "No tracks are mapped. Create map file?" and click yes.
you'll see 3 list boxes, two on the sides with the middle one empty. Ctrl+Click on both the sides the item that says "Exposed World Transform" then click the button with the arrow "<-"
this tells max to use the world transform from the save file on the selected object. Click the "save mapping" button on the bottom and save it somewhere (not really important, it just doesn't let you load the animation without saving first) then click "load motion".
if everything was successful, your torso should now be moving on it's own, without being linked to the torso tag.
step 3: redo step2 except for the head.
step 4: now you need to rearrange the uv mapping. originally, head textures take up the same spot on uv maps as the body does, but when you are combining all of this into 1 model, you will have overlapping uvs for the head on the body area.
for a quake3 player model, the body is 256x256 and the head (in the case of hunter) comprised of 2 128x128 textures (the face + the feather hat).
i chose to make a 512x256 texture, with the body on the left, and the face+hat stacked on top of each other right next to the body. this leaves a 128x256 empty area we can use for the weapon.
step 5: before we can export, there is one final step to do. the thing that drove me crazy for the longest time was that the head would never export any frames, even though it had keyframes.
the problem is that the tool i had to use to convert the 3ds max models back to md3s (http://www.quakeunity.com/file=48... only looks at *vertex* animation when deciding if there's a key frame there or not. so what you need to do is go into the head at vertex sub-object level and add a key frame to any 1 vertex at the end of the animation. (i just move a vertex an incredibly small amount).
step 6: delete all the tags (they aren't needed) and export the whole model as an ase file. make sure you have it set to export keyframes every frame.
step 7: open up npherno's md3 compiler (http://www.quakeunity.com/file=48... import the ase file but only select 1 component. export the single component back into md3. close, reopen the program and do the same for the torso and head.
step 8: use preach's md3tomdl converter (http://www.btinternet.com/~chapte... to convert the 3 pieces into mdls.
step 9: (these next steps are the 'dumb' parts) open qme and open up the legs. then, using import object, import the torso.
qme, annoyingly, has no options with what to do with incoming object's skin mapping, so although the nice uvw maps were preserved from the original md3 files, they will be placed next to each other.
 Haha, Ran Out Of Characters......
#55 posted by necros [99.227.133.158] on 2009/10/31 19:37:59
step 10: open quark 4.07 (yes, really). load your combined model. you'll notice your actual skin now is absolutely massive (i think it was 1536x256) because qme just kept adding stuff on the sides.
what you need to do in quark 4.07 is select the torso verts on the skin mapping editing window and slide them way over to the left (where the legs verts are).
for the head verts, i wasn't able to slide them over next to the body verts because they were considered 'on the other side' and so werent' allowed past the mid-point of the skinmap.
so i slide them just to the right of the mid-point.
finally, (still in quark) go into the edit -> model properties menu. change the width to 512 (make sure the 'right' radio button is selected so it will remove stuff from the right side, not the left).
this should place the head verts right next to the body verts and everything should be perfect. if not, the gods have not smiled uopn you and you are SOL, sorry.
Save.
step 11: now all that's left to do is to name your frames which you can do easily in qme.
yay, you have a q3 player model in quake with uvw and animations preserved. :P
note 1: i'm not sure if you could skip the 3dsmax process for the legs and torso, since the only real modification we had to do was with the head (regarding the uv mapping change).
note 2: there may be a way to collapse all 3 components into a single mesh object. the problem is that simply attaching the mesh objects together discards their vertex animation with no way of reclaiming them.
the other method involves using boolean with unify operations but you can't export frames that way because the key frames of the boolean operands don't count and the md3 compiler will only see 1 or 2 frames. (although this method does at least preserve the vertex animation)
so yeah, anyway, in most ways, it's probably better to do it the way you did madfox, import a single frame, combine it all into a single mesh, re-weight the vertices with new bones and animate it again yourself. this is the more logical way, i suppose, but i really wanted the original animations as well. :P
 Bah. Links Broke.
#56 posted by necros [99.227.133.158] on 2009/10/31 19:41:21
 Md3tomdl Improvements
#57 posted by Preach [94.192.82.29] on 2009/11/01 02:00:38
The handling of multi-component models in md3tomdl isn't very sophisticated, but could be improved fairly easily. Once you've parsed the md3, you can grab all the components, and there are only two barriers to just shoving them all into the mdl.
The first barrier is accounting for separate components possibly having different skin files. Since this is rubbing up against a technical limitation in quake, I think the solution I'd advocate is to just bung all components into the same space on the skinmap. So you'd need to prepare your md3 in advance to ensure those parts don't overlap. Still, anyone making a quake mdl has to do that at some point. You might as well do it in your md3 editor, since it's probably more capable than any tool for an mdl.
The second barrier is that different components may have completely unrelated animations. This could be overcome with the same blasé approach as the first barrier: We assume that the md3 has already been edited so that for each frame on the torso, the corresponding animation desired for the legs has the same frame index. This certainly would be easiest to code!
However, I would be open to maybe in the future allowing the controlling text file to define sequences of frames from each component. For example:
component_1: 1-36
component_2: 1-6,1-6,7-18,7-18
would use all the frames in component_1 in order, but repeat component_2 sequences. This might be to match the sequences in the torso with running/standing loops in the legs.
Although this would be more work to create, it would be useful outside just converting multi-component models, as you could grab subsets of the full animations on models with only one component. So it is of wide enough use to be worth attempting.
I might try doing the blasé approach in the next few days though, because it should be straight forward to add, and sounds like it would save a lot of pain...
#58 posted by MadFox [84.26.170.230] on 2009/11/01 02:22:19
I.m convinced necros you're aproach leads to the most pure way to extract a Q3monster to Q1!
In my case I more felt out of choice because I didn't expect three animations for one model.
Then the fact Q3models contain much more verts than A Q1 model made my plan for converting a rather silly idea.
As I have only Max3d 4.3 I'm furious looking to get the 9th version to check your method.
Suburp model, hunter!
 Re: Md3tomdl
#59 posted by necros [99.227.133.158] on 2009/11/01 03:08:45
the whole process i followed was so convoluted, i lost track of why i did certain things.
i do remember having problems when i originally had all 3 mesh components exported into an md3 with md3tomdl crashing.
also, it would be more useful to be able to control frame naming.
like:
name_frame_0 "stand"
name_frame_8 "walk"
name_frame_20 "run"
just name the frames in incrementing order until it gets to a new label, then switch to the new one.
The first barrier is accounting for separate components possibly having different skin files. Since this is rubbing up against a technical limitation in quake, I think the solution I'd advocate is to just bung all components into the same space on the skinmap. So you'd need to prepare your md3 in advance to ensure those parts don't overlap. Still, anyone making a quake mdl has to do that at some point. You might as well do it in your md3 editor, since it's probably more capable than any tool for an mdl.
i knew going in that i'd only have 1 skin file, and so adjusted my uv mapping accordingly. this is something i'd say you can pretty much assume. unless you wanted to try something fancy like auto combining pcx files next to each other for each different skin and then offsetting the uv coordinate appropriately. i mean, that would be pretty awesome, but it's not like you can't do that in 3ds max.
The second barrier is that different components may have completely unrelated animations. This could be overcome with the same blasé approach as the first barrier: We assume that the md3 has already been edited so that for each frame on the torso, the corresponding animation desired for the legs has the same frame index. This certainly would be easiest to code!
in my case, at least, i didn't even think about it: i automatically aligned the proper head/torso animations with the leg animations. honestly, unless there's some reason i'm not thinking about, i'd say you can pretty much assume if a multi-object mesh is being converted that the frames have been properly aligned.
ps: madfox:
if your only purpose is to work on old games stuff, i'd actually recommend you try version 6, 7 or 8.
there were a lot of good plugins and scripts made that haven't been upgraded to run in version 9+.
if you use version 6-8, you can use pop_n_fresh's md3 exporter which is a lot easier than using the damn md3 compiler by npherno. :P
 Autocombining Skins
#60 posted by Preach [94.192.82.29] on 2009/11/01 13:52:03
I know necros is in agreement with me here, but thought I'd say this:
Autocombining skins can be done. Automatic combination which is nice - low skin wastage, power of 2 skin dimensions, scale preservation - is almost impossible except when it is trivial. If you have two 256x256 skins then putting them side by side is straightforward, but if you have a 128x128 head as well, you're in trouble. And I know that quake can take irregular skin dimensions, but the reasons no other games do that still apply to hardware quake rendering.
On naming frames: it is something I'll probably include in the end, since the hardest part of coding that is writing c++ which will parse the list out of the text file. The reason it's low priority is that the engine doesn't use frame names for anything. Possibly when I add support for framegroups, there will be more reason to have this. You would define the frame sequence names, then have a second list of which of those frames should be framegroups.
Wild though for the day: Since I'm the person so in love with the edicts command, I invented another feature for it. When you get edicts info for an entity with a model, the value listed in "frame" should be the name of the frame pulled from the model, with the actual frame number in brackets.
 Mulit-mesh Progress
#61 posted by Preach [94.192.82.29] on 2009/11/02 10:20:42
I had a look at the code last night, and was a little surprised to see that the code already iterates over all of the components during the mdl export process, in the manner I suggested above (mapping everything to one skin and presuming the frames align). So far, so good.
The problem actually appears to be in the md3 loading code, which fails in the case of 3 or more components, although I believe it should work with 2. Hopefully I will be able to fix this very quickly and then release version 2 as a bug fix which enables many features...
 "arrgh" Still Autocompletes As A Func_ Post Title
#62 posted by Preach [94.192.82.29] on 2009/11/03 23:23:32
So I think I may have discovered one of the contributing factors to the bug. While reading the header for the MD3, I skip over the number of tags that the model has, since they aren't used in Q1. You can get away with ignoring some data when parsing an MD3, because it helpfully gives you offsets within the file to the various frame/tag/surface chunks. Unfortunately I forgot to do the corresponding code to skip the bytes representing the tags offset in the header, and so was reading that value into the surfaces_offset instead.
The only reason I ever got away with this is because usually I use the program on models with no tags, since there's no point adding them to models for Q1. Any time you try to import a model with tags, it chokes by trying to use tag data as vertex counts, which often end up being negative values. So hopefully with that fixed, I can close in on the bugs with multiple surfaces instead...
 4 Posts In A Row
#63 posted by Preach [94.192.82.29] on 2009/11/04 12:19:57
http://www.btinternet.com/~chapter...
Version 0.2 with proper support for multiple surfaces. As it turned out, not one character was wrong with the mdl exporting code from v0.1 with regards to multiple surfaces. It was all errors in the md3 loader which I think are now squashed. Comments welcome!
#64 posted by necros [99.227.133.158] on 2009/11/04 22:48:36
don't think it's unappreciated! :) i will see how it goes with klesk tonight.
 Serpent
#65 posted by MadFox [84.26.170.230] on 2010/02/22 19:56:55
When I saw the serpent in the Qtest map I thought it looked like a bad imported dxf file. One that appears after bad im/exporting.
So I decided it could look better, but after my first attempts I realized how difficult it is to import a good dxf/3ds file into QMLE.
Always the skinfile looks damaged with triangles appearing mirrored. When I finnaly had a good one I thought to be right.
Obviously the skinfile tends to keep its mirrored habbit.
What to do about it?
http://members.home.nl/gimli/Base....
 Well..,
#66 posted by MadFox [84.26.170.230] on 2010/02/23 01:01:27
after replacing all distorted triangles I ended up with a meshed skinfile.
Then I loaded the model into q2mdlr9b and imported the skinfile in pcx.
It loaded well in qmle after redrawing the verts on the skinfile.
I had to know this before, after all the time I spend in QMLE correcting skinfiles.
 So
#67 posted by MadFox [84.26.170.230] on 2010/02/23 06:35:09
here's my result of the serpent.
I only construct the model, the skin is one of androidart.com I lately saw here on the board.
Sure is a fine skin texture piece.
http://members.home.nl/gimli/serp0...
#68 posted by metlslime [173.11.92.50] on 2010/02/23 06:36:47
pretty nice... it'd be cool to see a flock of these swarming around a map.
 Yep Looks Good
#69 posted by nitin [124.168.7.215] on 2010/02/23 13:26:56
 Wow Very Nice
#70 posted by sock [78.131.32.151] on 2010/02/23 14:13:39
Madfox, that is very good stuff :) You should really use that as a new monster type. Would look awesome as a flock swirling around high above the player before attacking.
 Or...
#71 posted by generic [67.233.178.130] on 2010/02/23 14:25:00
just as ambient creatures that fly about.
Very nice, indeed!
 C'mon
#72 posted by ijed [216.241.20.2] on 2010/02/23 14:43:37
It's Quake - they should be trying to kill you.
 Manta
#73 posted by MadFox [84.26.170.230] on 2010/02/23 20:02:33
Thanks for your attend.
While I'm learning to understand what makes monster developement so hard I'm mostly surprised by the way I'm struggling with QMLE.
I've spent months on Bones trying to correkt verticemeshes. Thing is: QMLE imports from the baseframe. If this baseframe is allready in the model.mdl the program tends to import dxf/3ds files corrupted.
Me being glad to have the model in Qmle didn't mind to go frame by frame updating all corrupted vertices, with the habbit Qmle always picks up the wrong one.
Untill I found out when importing the fresh baseframe and then at one stroke all frames importing delivered a clean model.
My god... !
Then the skinproblem appeared.
When an imported basefram is in QMLE, and not all trianles are visible (which is always the cause) the imported skinfile will be partly mirrored on the unseen triangles.
It took me almost ten years to conclude this.
Now looking back it comes to me as if the serpent model in Qtest is a kind of distorted imported model. Although they (ID) had to take of as less verts as possible they made some good models with these limits.
The Qtest-serpent has 90 verts and 178 tris.
Mine ended up with 95 verts and 190 tris.
Can't help seeing the reminisence with the later dragon models.
 MadFox
#74 posted by spy [92.46.19.181] on 2010/02/23 20:45:04
congrats dude, its very cool model :)
 Qme Source
#75 posted by ijed [216.241.20.2] on 2010/03/18 21:41:32
Anyone know if this was ever released?
basically I want to remove the 'helpful' auto-UV map feature that breaks my UV's and makes them shitty Quake front/back projection when importing non .mdl stuff.
I realise having the source might not help me still so am going to try the model exporter from Spirit's bounty as well.
Doubt that'll work either though since Qme only imports frames in .dxf - importing udner two distinct formats will probably renumber the verticies and corrupt the mesh.
 Qme And Texmex...
#76 posted by metlslime [173.11.92.50] on 2010/03/18 23:38:02
two apps that would be nice to be open sourced.
 Baker Will Be Back Soon
#77 posted by meTch [69.183.34.100] on 2010/03/18 23:46:37
so he can go on a rant on how all of quakes stuff should be open sourced, at least form this point forward.
and then ill be back later to agree with what he said
 I'm Proud
#78 posted by ijed [190.20.98.208] on 2010/03/19 04:38:42
to be part of Baker's army on that front.
Non-open is death. Even the most dedicated are only human. A binary is a slow death.
 An Easier One:
#79 posted by ijed [216.241.20.2] on 2010/03/19 13:20:04
What's a decent way to convert to the Quake palette from full colour in Photoshop?
Metslime, what are the changes that you'd make to TexMex? It seems to do pretty much everything needed, for me. Just curious.
 Ijed --
#80 posted by metlslime [173.11.92.50] on 2010/03/19 20:24:19
there's at least one crash bug that i hit periodically, plus it doesn't remember folder names from previous export/open/save operations, also, maybe some better fullbright handling.
 Fullbright Management
#81 posted by ijed [216.241.20.2] on 2010/03/19 20:48:26
Would be nice.
#82 posted by necros [99.227.131.204] on 2010/03/19 21:44:21
ijed, are you asking what will yield the best conversion result?
the only thing i'd say is to check each of the different dithering options. some types of textures will look better with one type of dithering pattern, and others will look awful.
also, unless you want fullbrights, make sure the palette you're using to convert has the fullbright colours blacked out.
 Pretty Much Yeah
#83 posted by ijed [190.20.119.160] on 2010/03/20 00:52:00
Thanks for the info.
 Further Conversion Tips
#84 posted by Preach [94.171.242.186] on 2010/03/20 03:09:09
If you find the image you're converting has different "textures" within it, you may notices that a type of dithering works well on some parts but not others. In quake, this can be particularly apparent when converting an image with colours outside the usual range - often a less dithered conversion will alter the colours more significantly.
In this case, I've found it useful to do each type of dithering on copies of the original image, all moved to different layers. You can then use one as a base and create a hard-edged mask on the other layers. This way you can get the best of both conversions fairly quickly.
#85 posted by necros [99.227.131.204] on 2010/03/20 03:53:36
hadn't run into a case where multiple dithering methods were needed, but this is a good thing to remember, thanks ^_^
 Will
#86 posted by ijed [190.20.119.160] on 2010/03/20 11:35:46
Be trying these out today - my skins are typically pretty ugly thanks to bad conversion.
 Skin Group Animation
#87 posted by necros [99.227.131.204] on 2011/01/10 07:40:04
limited to like 6 or 7 frames? i have a 12 frame skingroup but it seems to loop before playing the whole thing. T_T
option to manually animate is available, of course, but i finally found something to use that stupid skingroup thing and it's broken. :P
 Correction
#88 posted by necros [99.227.131.204] on 2011/01/10 07:57:25
DP has this bug fixed, or was it a limitation in the original glquake?
i can't run that engine to check. :S i'm using quakespasm.
it's not an actual frame thing-- manually animating the 12 frames works fine.
 I Think It's Totally Broken On Glquake
#89 posted by metlslime [67.188.81.46] on 2011/01/10 08:00:49
and might only accept 1, 2, or 4 skins in a framegroup. Or maybe even worse than that. I'm pretty sure 4 works.
Fun fact: fitzquake probably hasn't fixed this.
 Model Of The Week: Waterfall
#90 posted by Preach [62.30.197.42] on 2011/07/25 21:17:32
Today I'm launching a bi-annual feature called "Model of the Week" where I offer a new quake model for use in maps. This week: waterfall.mdl
http://www.btinternet.com/~chapter...
This model comes with a demonstration map, which uses quoth's mapobject_custom to add the model to the map*. Extract the map into quake\quoth\maps and the model into quake\quoth\progs. I recommend viewing in winquake first, and then in stock fitzquake to see the "progressive enhancement".
Usage:
waterfall.mdl is a 32 polygon model, measuring 64 units wide and ~192 units tall. The origin lies dead centre of the bottom of the waterfall. Place it in your map accordingly, with angles facing outwards, and set the frame to 6 for the loop animation. The model comes with 5 skins:
Freshwater(0)
Effluent(1)
Molten(2)
Blood(3)
Toxichem(4)
This covers the main fluids in quake maps, but if you need something unusual or a better match for your water texture, the model is easy to customise. Simply inserting the desired water texture as a skin will create a reasonable effect, although adding "waves" to the top and bottom is strongly recommended so that the flow can be read easily.
Care has been taken to ensure that no visual artifacts can be seen behind the waterfall, but if you want to let players get behind the waterfall you may want to look at the flowflat sequence, which is not as tall as well as being flattened, so that it can be used for the back-face.
Advanced usage:
If you poke around the model you'll probably notice the spring and dryup sequences. These two animations were actually a happy accident, they were a byproduct of creating the main loop which I realised could be useful about half way through modelling.
If you want to use them to create a waterfall that starts and/or stops you will need to tweak the model a little bit. The important thing to do is to ungroup the flow animation. This lets you line up the frames so that the interpolation and waves move consistantly. To make the animation smooth always transition from spring7 to flow1 and from either flow8 or flow16 to dryup1.
So Preach, I don't want a 3 page diatribe on how you made this thing work but...would it be possible to make a custom-designed waterfall model with a more complex flow within a static model?
We really shouldn't be talking here, but I know somewhere more private - e-mail me.
*Just to note use of quoth is just me doing the laziest thing that would work - the quoth mod is not doing any clever behind-the-scenes stuff to enhance the effect. It simply precaches the model and displays it in the map.
wtb Quoth 3 with emitters for steam and splashes and things :P
Also, looks neat to me :)
#92 posted by Trinca [89.154.57.89] on 2011/07/25 23:06:19
love the blue one... the rest not that much...
blue is fucking awesome!
 Usefull!
#93 posted by MadFox [94.215.210.233] on 2011/07/25 23:43:08
My last map has green water, so for a waterfall I exchanged all "+fall6" blue pix into green. A rather dull experience, thanks!
 Ooh
#94 posted by rj [82.10.220.211] on 2011/07/26 00:27:31
that is brilliant. do they stack easily? could one theoretically use lots of them together to create a kind of niagara falls type wall of water?
and yes, needs splash sprites!
 Rub 2
#95 posted by jt_ [174.252.240.41] on 2011/07/26 01:02:33
Has splash sprites. or particles.
 Splashes And Stacks
#96 posted by Preach [62.30.197.42] on 2011/07/26 01:44:00
Yeah, I actually messed around using a func_togglewall with particles to create a spray effect at once point. It looked very cool, but I took it back out to keep the focus on what the new model can do and not the existing features of quoth(if used in a novel way). Certainly something for people to experiment with in proper maps.
I'm not sure that stacking horizontally would work too well for a few reasons, although tweaks to the model may overcome these. The first is that the random sync flag is set on the models so the waves would not come down together on adjacent falls. Even if they were in sync, the fact that the waves sweep diagonally means that they wouldn't align. Finally the texture itself does not tile in any direction so you'd see a seam without changing it.
Stacking vertically would be ok, but I'd warn against anyone who was intending to carefully tile the flat waterfall effect end-to-end to build a long one. Firstly you'd again not be able to tile the waves correctly because they hit the bottom 2-3 frames before emerging at the top. Secondly the animation is supposed to have faster falling water at the base than the top. Tiling would create a stop-start effect.
A better plan would be to create a stepped waterfall with simply two or three regular falls feeding one another. You could create height variation by having one intersect a second somewhat(although the wave-splash would be somewhat lost) or by duplicating and scaling the animation.
Can I just add how nice it is to get feedback like ^^^^^. I've been tweaking the model on-and-off for a week to the point where it didn't do that for me, and I was worried I'd overworked it and lost what was so great about it at first. So thanks to all you guys for casting fresh eyes on it. Sounds like nobody's cracked out their model editor to find the easter egg though...
 Preach
#97 posted by necros [99.227.131.204] on 2011/07/26 01:46:06
that is surprisingly effective! i think i prefer that than fading in water falls like i did before. especially since it has a proper start/stop animation.
 Ooh, One More Thing
#98 posted by Preach [62.30.197.42] on 2011/07/26 10:58:22
http://www.btinternet.com/~chapter...
If you edit and save the model with QMe or similar you might notice that the model starts looking odd and flickery in-game. This is because the vertices are disconnected on the face edges, and so the normals don't always point the same way, even if the faces appear adjacent.
The above perl script fixes this by setting all the vertex normals to the same direction in every frame. The script is lazy to the point of hard-coding the model name but it does work. Turning it into a better designed generic perl script is on the cards...
 Rub 2
#99 posted by [128.243.253.103] on 2011/07/26 17:04:01
just used standard blue particles, yeah. they looked kind of cute i guess, but would be much better if replaced with proper animated droplet sprites (they'd start as a single blue drop, then separate into multiple smaller droplets and eventually single pixels, fading to white) and then thrown out of an emitter entity in a similar fashion
to be fair it doesn't sound like a taxing task and is something i've been meaning to take a stab at for a while (although i have zero experience in sprite editing)
as for the falls themselves, i'll see how i get on with stepping and whatnot; it might entail a slight design change. but there is a chance i may drop you an email at some point preach :)
 ^me Obviously
#100 posted by rj [82.10.220.211] on 2011/07/26 18:27:20
 Nice
#101 posted by ijed [190.22.17.70] on 2011/07/27 02:32:20
That works great.
Slimeflows coming up.
 Wanted: New Animations For Player .mdl
#102 posted by OneManClan [58.168.229.115] on 2011/08/01 11:17:17
Hi all.
If you would like to create something that will be seen (and appreciated) every week by a bunch of TF maniacs, I have two requests:
1. A new animation for player.mdl, where he has his arms outstretched, kind of like this:
http://images.sodahead.com/polls/0...
I need 1 Standing, 1 walking, and 1 pain.
2. A new player .mdl which is a giant, deformed version of the normal player.mdl. Twice as tall, with a deformed head, as seen at 0:23 at:
http://www.youtube.com/watch?v=4f7...
He needs: giant_stand, giant_walk, giant_swing_a_club, giant_pain, and giant_die.
I'm not sure how this forum works, it seems to be one long thread(?), please contact me at adonis_paradise@yahoo.com if you can help
thanks,
OneManClan
ps, quick ad: BIG TF games every Sunday at 22:00 GMT, check it out:
www.attackersgored.com
#103 posted by necros [99.227.131.204] on 2011/08/03 02:56:22
where is that baron.mdl model that is in nehahra from? i seem to recall it was a converted q3 model or something? is there any way to get the original version to be re-converted? the nehahra version has massive amounts of vertex dancing; more than there should be.
 Converted Q2 Model
#104 posted by nitin [203.214.42.184] on 2011/08/03 03:29:27
 Although
#105 posted by nitin [203.214.42.184] on 2011/08/03 04:12:05
I've always thought his TheForgottenOne model would also work well in quake.
 Fantastic
#106 posted by necros [99.227.131.204] on 2011/08/03 05:29:56
and thanks for pointing me towards theforgottenone as well!
i can also see exactly why there's so much vertex dancing in the neh version: there's a sequence where he shoots a laser out of his eye which they probably deleted after it was converted.
interestingly, i can see that the main improvement of md2 over mdl is that the vertex 'resolution' is per frame, not per model hence why evilbastard could get away with the eye laser animation in q2.
 My 2 Cents
#107 posted by spy [92.47.253.63] on 2011/08/03 14:54:59
its seems that the infantry dude from q2 and modified to bastion by kinn is extremely underrated . hes so awesome. and fits the base theme very well
 Hm
#108 posted by necros [99.227.131.204] on 2011/08/03 21:19:02
looks like evilbastard did some extra frames for the nehahra mod as the original ddz baron model lacks those. hmmm not as useful as i had hoped....
it's too bad we didn't know as much about mdl format and vertex resolution that we know now. simply deleting the 'eye laser' frames before converting to .mdl would have increased fidelity by like 400% :(
 Necros
#109 posted by nitin [180.149.192.133] on 2011/08/04 03:13:28
theforgottenone (at leats the non-winged version) has the same torso as the ddz model. Although the animations may be diffeerent, might be worth looking into that md2.
#110 posted by necros [99.227.131.204] on 2011/08/04 04:15:19
i'm currently looking into what options i have atm...
i considering just re-rigging the q2 model and doing my own animations, since i enjoy doing that. first, it would allow me to just add a sword (which the q2 model is lacking) and do some proper melee swings and such.
i figure i can just use the nice uv mapped q2 model and then try out preach's method of going through the md3 format on the way to mdl and if i can't figure that out, at least i can go to md2->mdl instead.
i'm a little wary of trying to do theforgottenone since the wingspan of that model is fairly large at times. might result is pretty bad vertex dancing and i'd still need to add a melee weapon and melee animations.
when i saw the baron model, i kind of assumed that the sword was part of the original model and that he just held it in his offhand like that q3 model that looks like a crazy hellknight.
 Dark Knight?
#111 posted by nitin [203.214.42.184] on 2011/08/04 15:28:56
love that model.
#112 posted by necros [99.227.131.204] on 2011/08/04 19:25:50
yeah, it's awesome. seems like no matter which model i choose, i'm still going to have to end up re-rigging and then re-animating them.
Are there any models of trees around I could use? Preferably via quoth custom objects :E
Are there any models of trees around I could use? Preferably via quoth custom objects :E
 Hexen 2
#116 posted by jt_ [68.42.82.10] on 2011/08/07 03:23:32
Has one or two tee models, so does soul of evil iirc. I think quoth might even come with a tree model, you might want to check the pack.
 Definitely Does
#117 posted by Drew [76.75.125.184] on 2011/08/07 16:47:47
 It's Back
#118 posted by Preach [94.171.245.254] on 2011/09/07 01:15:25
So model of the week took a big hit when I lost internet for the first half of August. Still, I didn't waste all of those hours idly, so here's a non-model "model of the week" with modelling applications:
http://www.btinternet.com/~chapter...
It's the threatened perl script for manipulating mdl files. Details on how to use are in the readme.
The future:
Future goals include:
• Adding some code for handling the mysterious vertex normals - including the vertex normal table and finding the index that best approximates a given normal.
• Creating a companion to mdl::list_framedata which provides a list of skindata which ignores whether a skin is in a group or not.
• Including more example scripts.
• Creating a companion module which will load MD3 (then maybe MD2) models into a similar perl structure. Then include example scripts for loading an MD3 and outputting a MDL.
The last one ought to be useful in practice. I was at one point working on a new version of md3tomdl with expanded options for how the conversion would be performed. I abandoned this when the challenge became parsing the config file rather than performing the conversion. Instead I began looking for a scripting language which handled binary files and there perl was...
Anyway, the plan is NOT to have all three model formats load into a single common structure. The thinking is that how you resolve the differences between the structures is the most important part of the conversion, and there's no one-size-fits-all solution (especially when it comes to combining multiple segment MD3s with independent animations). Instead the plan is to start from a basic conversion script each time and customise it in all the relevant places to suit the model in question.
 Waterfalls
#119 posted by MadFox [94.215.210.233] on 2011/09/12 08:37:30
Rather intrigued by Preach I tried the waterfall model. I opened it in qmle and saw it were all film files. As it is a one patch line I couldn't use it in normal Quake. It just disappears.
So I decided to make one that turned round frames like a coil, so it can be used to simulate waterfalls or taintracks.
The screenrecorder went chunky so I made a gif to illustrate the principle.
http://members.home.nl/gimli/wfall...
...and now I'm on it I might as well turn you the file, maybe you get texturing inspirations for a praxinoscope like me.
http://members.home.nl/gimli/rotaf...
:D
 Seeing Double
#120 posted by Preach [94.171.245.254] on 2011/09/14 00:33:53
Glad to see it getting used MadFox, certainly the watery realm in your map looks like the perfect home. To bind that model in with the perl stuff above, here's a quick script I just cooked up which offers another way to solve your problem.
http://www.btinternet.com/~chapter...
It takes an input model and makes all the polygons in it double-sided, so you can see it from front and back. Here's the output when you run it on waterfall.mdl:
http://www.btinternet.com/~chapter...
Just remains to say that I didn't write the script just to help with the waterfall, it should also come in handy with the next model in the pipeline. You heard that right - this isn't even model of the week! (what an ugly tease...)
 A Vine Model
#121 posted by Preach [94.171.245.254] on 2011/09/19 23:22:02
It's time for Model Of The Week, only a day late. Or if you prefer, bright and early at the start of this week!
http://www.btinternet.com/~chapter...
Time to plant some vegetation in your map! This model will decorate bare surfaces in your map, making your medieval walls look vibrant or your base maps overgrow and abandoned. And at just a shade over 40 triangles per model, why not add two!
The model comes with 7 poses for the vine, and the following 4 skins:
Tropical Vine
Poison Ivy
Desiccated
Autumnal Tips
The model is designed to tightly hug a wall in your map, and so the polygons only face in one direction. To get the right placement, position the origin of the model 8 units away from the wall it will be rooted to. In the case of the 'limp' frames, the origin should be 64 units from the ground, and in the case of the 'creep' frame 32 units from the second wall that it wraps around.
The script in the previous handful of posts in this thread would also be useful here, if you would rather create free-hanging vines which you need to see from both sides. Bonus points if you can adapt the script to make it instead clone the triangles in the model and make a single vine model with multiple creepers. You'll save entities!
 Turbulence Waterfall
#122 posted by MadFox [94.215.210.233] on 2011/09/21 01:23:08
Fine piece of artwork there, Preach. Wish I had these when making my venividifuzi level.
Roman art would like that, as well as the vine texture.
I wanted to add some turbulence to the waterfall, as it is a bit strange to see so much water falling in a peacefull water.
Also made the length somewhat longer.
http://members.home.nl/gimli/hfall...
 Yup
#123 posted by roblot [216.106.107.248] on 2011/09/21 01:48:09
Those vines isa useful, thanks man.
 Big Wave
#124 posted by Preach [94.171.245.254] on 2011/09/22 01:05:51
I had worried about the bottom of the water in the same way, but decided to go in a different direction for the next models and return to it later, so I've been beaten there! I hope you plan to share the model once it's finished. It probably could stand to have some particles along with it in a map to add noise to it, but it certainly creates turbulence.
At the base of the splash you have a wave washing over, which makes me wonder if you could make the entire splash section loop around in the way that the main waterfall does, and so create a series of waves. The problem I can anticipate is that it forces the waves out in just one direction, but it might still be worth exploring.
#125 posted by MadFox [94.215.210.233] on 2011/09/22 02:37:06
Glad you like it.
Not a case of beaten, just an idea involving by cherrishing it up! I also was thinking for a sprite with buble but that changes in view.
Fog also would do, but that's kind of hazzard trying shaders.
http://members.home.nl/gimli/water...
Two models, the starting one as in the gif file, and another one I tried to make the wave bigger and more floating off. Funny to see the waterbulb go under the normal wayer surface.
I already tried to make the vertices change directions, but you can make a try by dobbling the vertical one and change it in front of it.
lol
 Puf Statics
#126 posted by MadFox [94.215.210.233] on 2011/10/03 22:45:15
#127 posted by gb [46.142.27.9] on 2011/10/03 23:12:28
Ahaha, awesome!
 Skip For Models?
#128 posted by MadFox [94.215.210.233] on 2011/10/13 22:23:31
The idea just came up to me if it would be possible to use skip on model.mdl files?
The way it is done with mapping is clear to me.
 How About...
#129 posted by metlslime [159.153.4.50] on 2011/10/13 22:35:10
just delete the triangle if you don't want it to be rendered.
#130 posted by necros [99.227.131.204] on 2011/10/13 22:51:28
models and BSPs are totally different. i don't think there's any way to reconcile the two systems.
but metl's right, deleting the triangles is the only way to make faces not appear.
Quoth had (iirc) 3 seperate models for the polyp stealth activation where Kell went and deleted successively more and more tris.
 Greebles
#131 posted by MadFox [94.215.210.233] on 2011/10/14 01:18:42
Yes, I was suspecting something like that.
I understand deleting the triangle creates an opening, but there's no way to make it look transparent, than by texturing a blooming surface.
 Ah
#132 posted by ijed [190.22.68.248] on 2011/10/16 16:58:08
Gradual transparency.
I don't think there exists a method for that in Quake, although DP has some stuff that does it.
 Spritely
#133 posted by Preach [94.171.245.254] on 2011/10/19 22:06:54
I was gonna ask some advice on using sprites in quake but instead I'm just gonna moan. Fitzquake really spoils you with it's proper support for sprites. I had a model-sprite combination working beautifully in fitz, and then tested it in a few classic engines just to be sure. GLquake doesn't support "facing upright" sprites and just uses the facing code. Winquake is equally unsupportive in a different direction, shrinking the unusually large sprite down to about half the desired size.
I'm pretty much betting that there is nothing that can be done but if anyone knows a fix for one or the other it's gladly heard. Otherwise back to the drawing board...
 Also
#134 posted by necros [99.227.131.204] on 2011/10/20 00:15:09
the sprite offset stuff doesn't work at all in DP, so make sure, if your sprites animate, that they are centered in the image.
 Model Of The ... Er ... Quarter I Guess
#135 posted by Preach [77.98.165.95] on 2011/12/10 02:44:43
So yeah, not really putting out a model every week. Which isn't to say I've not been making them at that kinda rate. But I've made a few that I don't think are worth releasing, or are ready for show just yet, and had that tree project which got eaten up by technical hitches. After that I started making a series of models in a theme, more about that later.
Today though I took inspiration from the explosion effects in TF2 and tried my hand at making a particle effect, which was good practice in using all the gmax animation controls I'd learnt about for the aborted models above.
http://www.btinternet.com/~chapter...
The file contains the model and a quick test mod plus full details on how it works, but give it a quick spin and let me know what you think.
So back to the series of models I mentioned at the top. I was thinking if the best way to handle a pack like that would be to post individual models here as soon as they are working - beta quality if you like. Then I can tweak them based on any feedback offered and release the pack with all the refined versions at the end. Sound alright?
 Great Sparks!
#136 posted by MadFox [94.215.210.233] on 2011/12/13 01:04:58
I noticed them only with the GL, but as closer to the wall the appearance get better.
This way it's easier to add emitters like the extra-mod.
Are you making a new pakfile with monsters like I did in The Hangar?
 Gomjabber
#137 posted by MadFox [94.215.210.233] on 2011/12/13 01:08:33
 Stop, Grenadetime
#138 posted by Preach [77.98.165.95] on 2011/12/13 16:50:13
Are you use you don't mean the Rocket Launcher, the mod uses stock effects on the grenade! I'm not working on any new monsters right now, mostly my new models are mapobjects (and now special effects) that other people might want to incorporate into maps. Expect a few more particle systems soon because they're quite fun to make!
#139 posted by necros [99.227.131.204] on 2011/12/13 19:46:57
meant to comment earlier but forgot.
the effect looks quite good. hexen2 has a few good examples of ways to make effects out of models too, if you are looking for inspiration.
 Super-duper-multishotgun
Got the idea from ne_ruins mod, and blocked some models. Im not really sure how to setup a camera to simulate 1st person view.
http://i.imgur.com/p091p.jpg
http://i.imgur.com/qlPcq.jpg
One is just random, and another one based on this concept http://gamersblock.net/gamefluid/w...
#141 posted by necros [99.227.131.204] on 2011/12/18 01:08:19
those are pretty cool man... should try to get them skinned and such.
for positioning, just grab one of the regular gun models and export it as a dxf file. then, in your editing software, just import the dxf and match your gun to it and then get rid of it when you've got the right position.
 Well
 Nice One
#143 posted by negke [31.18.185.172] on 2011/12/19 10:58:54
Time for an all-shotgun Quake with single- up to eight-barreled shotguns.
#144 posted by gb [46.142.44.190] on 2011/12/19 12:25:35
pretty cool, relatively hi-poly for Quake though. Compare to vanilla shotguns.
 Really Quick Hackjob
 #145
#147 posted by rj [128.243.253.118] on 2011/12/19 13:51:10
i want one!!!
 @ 147
#148 posted by ijed [186.107.134.181] on 2011/12/19 22:07:54
I fight you for it!
That looks great.
 Lightmill
#149 posted by gb [46.142.30.207] on 2011/12/20 10:36:52
A scrag is only about 150 tris :)
You don't make small maps with 200 r_speeds only because id's levels are like that.
#151 posted by necros [71.99.4.38] on 2011/12/23 16:15:43
that tri-barrel looks great! i'm not a fan of the skin though. i'd rather see it match with the other guns (brown and blue metal).
nice mesh though!
#152 posted by gb [46.142.38.11] on 2011/12/23 17:07:25
What my comment was trying to get at is:
If you want to use it together with the vanilla weapons, there will be a visible difference in polycount.
Maybe that is more understandable.
|