Quake .mdl

[Galaxy_Stranger]

So Nash wrote a shitty exporter?

[Dark-Assassin]

I use a different MD3 exporter that works fine in any regard I can think of, even embedded texture paths. Though I'm completely outdated.
Blender MD3 Import/Export 2.42 from http://www.katsbits.com/tools/#md3

[Nash]

So Nash wrote a shitty exporter?

I use a different MD3 exporter that works fine in any regard I can think of, even embedded texture paths. Though I'm completely outdated.
Blender MD3 Import/Export 2.42 from http://www.katsbits.com/tools/#md3

A) I did not write it; I just edited an existing Quake 3 exporter script. Can't remember exactly what I changed but it just made the files more relevant for GZDoom. I didn't change much of it anyway. I think it was more related to object scale, model orientation and things like that.

B) The script I based my work off is exactly the one from that Katsbit link, which means embedded texture paths were already working all along for GZDoom exports.

C) Even if I did write the code for my own GZDoom exporter - why the fuck would I bother with bounding boxes if GZDoom isn't going to use them? :P

[Kappes Buur]

This --> http://forum.zdoom.org/viewtopic.php?f= ... 5&p=674776
may be relevant for some.

[MetroidJunkie]

C) Even if I did write the code for my own GZDoom exporter - why the fuck would I bother with bounding boxes if GZDoom isn't going to use them?

Even just the ability to have length and width instead of just "radius" for the Doom bounding box would be nice rather than require all Doom objects to be squarish from the top.

[Nash]

That's a Doom engine problem and I don't think that's easy to change at all, short of just writing a new game engine.

[MetroidJunkie]

Fair enough, guess I should just be grateful that the more advanced source ports have height actually matter so they aren't infinitely tall.