I was so excited to post a useless model that I forgot the best part of the post. The model comes with a qmdl script that you can use to fix the normals on models with complex skin maps which you have edited in QME. It uses some heuristics to determine which vertices are "meant" to be joined together, then unifies the vertices' normals. Cutting QME out and preserving the genuine normals is still prefereable, but this gives decent results and keeps things simple! 

that is a wild looking grenade launcher O_o 

Yeah, the drum's quite heavy compared to the rest of the model, which makes the thing look a bit unwieldy to say the least. It's too long ago to pretend I remember what I was thinking when I designed it...

Although I'm going to try and spread the models out over the course of days, I will put up a tool update while I'm at it.

Here is the version of md3tomdl which correctly decodes the vertex normals on md3 files, and so gets rid of the overly-bright looking models the previous version created.
http://tomeofpreach.wordpress.com/md3tomdl/
I'm gonna work through my models, reexporting them with this new version, and I'll share a link to the list of changed models once I'm done. 

cool, thanks for the update to the converter! been using that a lot lately! 

Time for another model and another update to one of the tools. Today we have a stake launcher (a la Painkiller). It's a bit of a weird design, but on the plus side it has a neat animation and a skin which kinda fits in with the palette of the classic quake weapons. Maybe if you've got a map with wide open spaces, you could swap the lightning gun out and include it as a sniping weapon.

http://tomeofpreach.wordpress.com/2013/09/11/stake-launcher/

Today's updated tool is the qmdl module:

http://tomeofpreach.wordpress.com/qmdl

Firstly the page has finally been fleshed out with a changelog and a proper examples page to get you started. Also v0.3 of the module is released, which has a very special extra function added to the Helper class: merge_vertices.

As the name suggests, it tries to merge as many vertices on the model as it can without changing the visuals (although it can be instructed that vertices with different normals are still mergeable). The feature I'm particularly proud of is that it will create seam vertices in order to perform a merge, if you have the correct front-and-back skinmap from a classic quake model.

It sounds like it wouldn't be useful very often but here's an example: Imagine you start with a classic quake mdl, and you convert it and import it into a modelling package. You add some animations to it then export it and convert it back to .mdl format. You probably had to export it via md3 or fbx, and so your end result now has a "complex skinmap", even though it doesn't use it in any way. This function will restore the classic skinmap, which I think is a first. 

No updates for tools today, I'm working on something but it needs more testing. As a change of pace from all these refurbished weapon models, here's a refurbished Helijet instead.

http://tomeofpreach.wordpress.com/2013/09/12/helijet/

It kinda feels like the helijet really belongs to it's own mod, but I think it might be handy as a random mapobject as well. 

Can that model be anyhow attached to a Path_corner, or turned into a func_?

At least in quoth?

Btw that yesterday launcher freaked me out!
Cheers! 

the heck man, that thing is awesome! the only problem is that i can't think of where i'd want to use a vehicle like that. it would have to be some serious open terrain otherwise you'd just bump into sky brushes. :( 

ohhh well, maybe if you put a grunt or enforcer in it... and then put on guns. lots of guns. would be a cool unique monster. 

ohhh well, maybe if you put a grunt or enforcer in it... and then put on guns. lots of guns. would be a cool unique monster. 

It could also drop troops, or just do flyovers like in q2. 

Yeah, I'd never given thought to using it as an enemy but I think there's potential. You could probably adapt the skin into a Rubicon style thing fairly easy, if you rusted all the gunmetal bits brown and muddied the paint with more texture and the correct shade of green. Then it could compliment those enforcers on the hoverpads, ether as transport or gunship.

And yeah, it's possible to do Q2 style flypast animations in Quoth with one. Since func_rotate_train entities are non-solid, you can use a .mdl format external model for one and it's just a matter of creating the right path corner ents for convincing flight.

So, on to today's stuff. I posted a fair bit about it in this thread recently, so it'll come as no surprise that I'm about to post the Qexpo tutorial:
http://tomeofpreach.wordpress.com/2013/09/14/the-return-of-the-qexpo-tutorial/
Well...I've still got 4 more to type up or recreate, but the first ones are restored. Thanks again to Madfox!

And what better model to go with it than the Fusion Cannon from tutorials 3 and 4, which I finally got round to finishing off during the downtime!
http://tomeofpreach.wordpress.com/2013/09/14/fusion-cannon/ 

I'm glad you got the tutorial back up. I remember reading that way back and i learned tons from it. 

The pace is maintained, another day, another model:
http://tomeofpreach.wordpress.com/2013/09/14/blinds/

This time you can create some beautiful windows, and give the illusion that you aren't blocking vis through them. Amaze your friends with the obviously fake HDR effect they create.

Also the final four parts from the tutorial are up if you want to brush up on your animation technique or the essentials of the mdl format.
http://tomeofpreach.wordpress.com/qexpo-tutorial/ 

I posted a new version of qmdl earlier this week. It turns out the merge_vertices function is worth running even on models that have come straight out of the md3tomdl converter. I ran it on my ogre model and it went from 692 vertices to 666. Not only is that a really cool number of vertices to have, but it's a pretty good saving to make. md3tomdl follows the topology of the md3 model exactly, so I'm guessing that there are places where vertices are separated due to subtle difference in smoothing groups. Once we get down to mdl format the fine distinctions are erased, and there's no reason not to merge the vertices.

I also discovered a bug in merge_vertices - it doesn't cope with framegroups correctly. So if you are going to add framegroups, for now you need to run merge_vertices first!

No new model today, but I've gone through and updated all the old models that had weird normals created by the old version of md3tomdl. The list of updated models is at:
http://tomeofpreach.wordpress.com/2013/09/15/new-md3tomdl-qmdl-fbxtomdl-and-updated-models/
If you use any of the models in this post you should pick up the new version.

Also today sees a new version of fbxtomdl released which handles indexed skins in a simpler and more intuitive way(the same way that the helper in qmdl does). It's also got its own page now:
http://tomeofpreach.wordpress.com/qmdl/fbxtomdl 

 

Yeah, here's some more. Quite a few of the model this week have undeniably been random odds-and-ends that I just got round to polishing up and releasing. Today we've got a red-hot new model, created entirely this week.

It's a door pull mapobject for adding detail to your medieval and metal maps:
http://tomeofpreach.wordpress.com/2013/09/16/door-pull/
Nothing complicated going on, just a static model to make a plain door interesting.

On the tools front, I've got a slightly weird exclusive to func_ deal going:
http://www.quaketastic.com/files/tools/windows/model-compiler.zip

This is the little package I use to jump-start my model making. When I embark on a new model, I create a clean directory for it, and then drop these 4 files into the directory. If I export the new model with the filename "model.md3", running the batch file compiles it to a basic mdl with no other input required.

The files also have all the scaffolding needed to build the model properly as I go. For example, once I have the first skin on the go, I overwrite the "dummy" model.pcx file with it. If I need to add extra skins, there's an empty array called "skinlist" in model.py I can add the filenames to. Similarly as I add various animation to the file, I can add to the list of (name, length) pairs in the rename_frames list. I can even amend the last line of the batch file to give the model file a less generic name.

So to make use of it, you need to extract the files somewhere safe, and then make one very important change. Open the batch file and modify the first line to specify the full path to the location of your copy of md3tomdl (advanced users could instead add md3tomdl to their path). Anyway, I hope this helps someone out there get things done with a little less fuss. 

door pull model is very cool and can be very useful. i'd love to see more things like this-- subtle details that are not meant to be the center of attention; the hallmark of a good map object. 

Yeah, so I've about run out of tools and utilities to post about, but I will continue with a trickle of models to use. Today we've got a gas cylinder which I originally made for a top-down zombie shooting mod. So the idea was to try and make a model which looked interesting from above. Luckily I did skin the whole model so it can be used in 3D maps as well.
http://tomeofpreach.wordpress.com/2013/09/17/gas-cylinder/

Also, quick note on the republished vine model. Before this morning the "fixed" vine was missing the extra skins that the original came with. So you might need to re-download that one yet again... 

I have heard so much about beez.
Yet I never saw them in Quake1.
I have heard about a swarm entity,
but it is beyond my grasp.

Here I have some beez in beta state.
Thing izz... I can't kill them.
I even can't hurt them.

Help!
They hurt me, and kill me. 

any ideas for the model are welcome.
I can't loop the sound, although I ripped it with cooledit to loop mode. 

I have managed to kill the swarm. My hint is that to run your mod in fitzquake, and run the console command "r_showbboxes 1". You should then see where to aim, and it'll give you a clue what's gone wrong in your code.

Incidentally, I spotted a mismatch in the code at the moment. In the QC the pain animation is defined all the way to pain14, but the model only has 8 pain frames. This means the death animation glitches half way through. 

Can't check out what you've got there...

The RMQ swarm were distinct enemies, basically each bee was thinking in its own right. In theory with a collision they'd be kill able but this would ruin the shotguns - the code would only allow you to kill one bee of the swarm at once.... Unless you made an invisible explosion happen on the killed bee when hit by a shotgun.

You should be able to grab the swarm.qc from the RMQ SVN - it is almost completely nuclear as I remember, just needing a defs reference.

There's also a small qc maggot mod from idgames2 which could be useful, which is a micro enemy based off the Flesh Grub (I think). 

That's hillaric!
I thought I was a bad-aimer, but this cheats me.:P

Yes Preach, the bbox is out of order. It has to be in the center. The $painframe a typo.
I'm surprised I can easily walk through the bbox. That gave me the feeling I had to shoot one bee.
How does that bbox come up so left lifted?

@Ijed- always something new with that monster entity. When I started the swarm, I was afraid I couldn't make them too large because of that bbox. Now it seems it is just a tiny thing. 

Compare your line:
setsize (self, '16 16 16', '24 24 24');
to the setsize line of other monsters.