The LOL is included in your Windows message !? 

I wish it was! More OSes should make fun of you during normal usage. 

Windows is much too serious for that. 

I think the issue is that QMe won't install on 64 bit processor machines, because the program is 32 bit but the installer is 16 bit. This was a common technique in the mid 90s, so you could at least display a message to people in the 16 bit world that the program wasn't compatible. 

Probably my last noob question ... why does the walltorch auto animate? I'm looking at it in QME and I don't see a flag or whatever that would tell Quake to animate it.

The QuakeC doesn't seem to initiate it so ... bluh?

https://dl.dropboxusercontent.com/u/161473/Misc/TorchQuestion.jpg 

*sigh* Frame Group ... NOW I see the little circle on the torch frames. Sorry! 

Hey preach, support for framegroups would be awesome. :P 

Well, other programs can view these shots just fine, so the palette is stored in there somehow. 

Yeah, I had been thinking that was the one bit of support missing. Here's a version with support for them (but literally zero error checking if you do something stupid like overlapping ranges, backwards pairs, invalid syntax, etc)

http://www.quaketastic.com/files/tools/fbxtomdl-0.4.zip

The switch is -g, used like

fbxtomdl -g 1-6,17-25,40-45

Groups have to be constructed from contiguous frame ranges, and animation speed is automatically 0.1. If you want anything fancier you need to install python and check out qmdl. Test it out and if you don't run into bugs I'll make the release proper. 

Are you using warren? 

MODO 

Ugh ... So qME tried to start up and couldn't find the previous model I had open (I deleted it). This prompted it to bugger it's interface.

This may be blindingly obvious, but how do I get the 3D viewports back? I can't seem to make it happen:

https://dl.dropboxusercontent.com/u/161473/Misc/QMEWTF.jpg 

My version here is a bit wonky so I can't test properly right now, but it should just be clicking the camera button up there in the top left.

That's the frame editor view, and there's the same inside the view menu.

Not sure about version differences, but it looks like you're missing the buttons to reset the viewports to default. One in particular is an eye, which centers the camera on the model itself. 

FFS, that was it. Thanks! The camera button fixed it... 

Just tried opening another version I have and thanks to not being able to modify my own (work) PC I cannot close it down.

90's software XD 

What's the point of using such ancient tools nowadays? 

 

Exactly. It's not like anybody WANTS to use QME ... there's just nothing else. 

And now that my vacation week is over I suddenly think of a program that needs writing. :P 

was my only reason for the internet. 

well, if anyone wants something to start with for a model editor: https://github.com/necros0/ne_modelEditor 

Blarg ...

Preach, can you look at this?

https://dl.dropboxusercontent.com/u/161473/MDLBugs/base.fbx
https://dl.dropboxusercontent.com/u/161473/MDLBugs/skin0.tga

That model gives me this error when converting:

Traceback (most recent call last):
File "fbxtomdl.py", line 189, in <module>
File "C:\Python33\lib\site-packages\qmdl\helper.py", line 22, in save
File "C:\Python33\lib\site-packages\qmdl\mdl.py", line 828, in write
File "C:\Python33\lib\site-packages\qmdl\mdl.py", line 413, in write_vertices
File "C:\Python33\lib\site-packages\qmdl\mdl.py", line 394, in write
struct.error: argument out of range

It's only 144 triangles ... so I don't know what the problem is. :-/ 

When you get errors in the vertices stage of the export, that points to being problems in the UV coordinates. According to the output of the fbx module, you have some extreme UV coordinates in your input file like

3.882966888774369e+17 47382.390625

1709638.625 0.9035763144493103

-244233.234375 0.9035763740539551

qmdl doesn't actually mind UVs outside the usual range of 0...1. If you want to say "fuck software quake! I want a tiling skin" and have coordinates outside the skinwidth then the program will do what you ask and not raise an error. At some point I will get round to giving the helper module a couple of "clamping" functions to bring all uvs into the range of 0...skinwidth but they'd be optional and fbxtomdl would skip them to retain the potentially useful flexibility.

So why the crash? Well, some of those coordinates are literally so large as to overflow a 32 bit integer. Python, retaining it's title as Awesome Language 2014, handles these arbitrarily large numbers without actually breaking. But at the end of the day they have to be packed into a 32 bit field for the binary format quake reads, and at this stage Python signals an error rather than truncate them.

Long and the short of it, fiddle with your UVs and get the program which is exporting fbx to double-check what it's doing... 

Oh ok. Yeah, it doesn't have any UVs that I've fussed with at all. That would explain it! Thanks for the quick response!! 

Just to wind up the person who downloaded it last week, a new version of qmdl just went up.

http://tomeofpreach.wordpress.com/2014/10/26/qmdl-v0-4/

Main feature is support for the Md3 format, weirdly enough. Along with a module to load Md3 files there's a script that recreates md3tomdl in python. That latter bit's not in a user-friendly way at all right now - even the paths to the source files are hard-coded. Think of it as a proof of concept.

It is probably the bit I'm gonna rework for the next release though, as it'll provide lots of flexibility that md3tomdl.exe can't deliver. Stuff like being able to change the way coordinates are mapped (perhaps to keep integer vertex coordinates), or to combine the separate UV maps of different surfaces in a creative way, will be made possible. The kind of stuff that's simpler to express in code than any amount of command line switches.

Also there's a few other nice bits of polish for the mdl side of things. The Mdl class has two new generators basic_frames and basic_skins. These let you iterate over all the "poses" in a model, treating framegroups as a succession of individual frames. This fixed the issue that the Helper module's merge_vertices method failed on a model with a framegroup.