[GZDoom/Blender 2.79] MD3 Export, Size Reference Template

[Nash]

Updated 08 April 2017 download link, click here to download

First up, I have modified a script for Blender that works perfectly for exporting GZDoom-ready models with correct scale.

This is a modified version of the MD3 export script from
http://www.katsbits.com/tools/#md3

It has been modified for GZDoom-friendly exporting.

Tested for Blender 2.66a (works great!)
Update 10/10/2018: Also works perfectly with Blender 2.79

How to install:

Copy io_export_gzdoom.md3 into the scripts\addons\ direction. For example,
C:\Program Files\Blender Foundation\Blender\2.66\scripts\addons\

Then start Blender, go to File -> User Preferences

Go to the Addons tab

Scroll down the Addons list and look for Import-Export: GZDoom .MD3 and tick
the checkbox to enable GZDoom export. You will find it under File -> Export ->
GZDoom .MD3.

(To avoid having to redo this everytime Blender starts up, click the "Save User
Settings" button in the User Preferences window)

PLEASE NOTE:

- Models must not exceed 512 in size in Blender units, in any axis... otherwise the exporter will fail. So to be safe, make sure your models dimensions are < 512 Blender units (you can see this selecting your object, pressing N on the keyboard, then look for "dimensions" in the properties panel)

- All objects MUST have a UV map or export will fail!

- For multiple objects, you can embed the texture paths directly into the objects, and then omit the "Skin" property in your MODELDEF so that GZDoom will load the textures embedded into the object directly. This is the only way to assign multiple skins in 1 model! There are 2 ways to do this. USE EITHER ONE ONLY:

A) Under the "Object" panel, make a custom property called "md3shader" and input your full texture path (as per your PK3)
B) Select the object, and name the material your full texture path



GZDoom Size Reference.blend



This .blend file can be used for your reference with regards to scale, when you are making your models for use in GZDoom. The dimensions are setup such that they will export with a 1:1 Blender - GZDoom scale. So for example, a 64 x 64 x 64 cube in Blender will export as a model that fits a 64 x 64 x 64 sector in Doom map units. However, one little detail needs to be observed:

GZDoom squashes models down on the Z axis by default, so to truly achieve a 1:1 scale, you have to use the following scale parameters in your MODELDEF:

Code: Select all

Scale 1 1 1.2

So model your objects around my references, apply 1.2 scaling on the Z axis on your MODELDEF, and you will achieve 1:1 Blender -> GZDoom scaling. :)

Oh and also, 1 more thing. By default, this script exports the .md3 with the object facing the wrong angle. To fix this, apply this in your MODELDEF:

Code: Select all

AngleOffset 90

And you're good to go!

Gun reference temporarily removed; I plan to re-do this completely

Have fun!

[Enjay]

Okay, not exactly 1:1 because remember that GZDoom squashes models down on the Z axis by default...

Is it not more accurate to say that (G)ZDoom stretches everything else by 1.2 in the Z axis (which is the Y axis in many other applications) but leaves the models at 1:1:1?

[Nash]

Well... yes and no. The code that draws the models does this in gl_models.h:

Code: Select all

#ifndef __GL_MODELS_H_
#define __GL_MODELS_H_

#include "gl/utility/gl_geometric.h"
#include "p_pspr.h"
#include "r_data/voxels.h"

#define MAX_LODS            4

enum { VX, VZ, VY };

static const float rModelAspectMod = 1 / 1.2f;    //.833334f;
 

This is confirmed back then when I was using 3ds Max, whose units match those of GZDoom's much closer.

When I built a 64 x 64 x 64 cube in Max and brought it into GZDoom... if I placed the cube side-by-side with a 64 x 64 x 64 sector in the map, the cube actually appears to be shorter.

I had to apply the 1.2 scale on the Z axis in the MODELF so it matches the sector.

[Enjay]

Hmmm, yes and no it is. Yes because it does squish it but no because all that squishing is doing is returning it from 1:1:1.2 to 1:1:1 right?

I too have done similar comparisons with 64x64x64 and 128x128x128 model cubes and the thing is, the cubes really are cubes and everything else in the world has that funny 20% bigger in the vertical direction going on. As you said, applying a scale value of 1.2 to the vertical component makes then the same height as a 128 unit tall block/sector of game architecture.

Do I recall you making a version of GZDoom with a 1:1:1 ratio display? If so, how did that look? Better? Worse? Merely different? Obvious? Barely noticeable?

[Nash]

With my 1:1:1 renderer, the difference of the model height is still there. A 64 model sitting next to a 64 sector still appears shorter.

In addition to making the renderer draw 1:1:1 pixels to the screen, I had to change that code in my previous post to 1 (remove the "divide by 1.2f" part).

Anyway, UPDATE: after some rigorous testing, I found out that the MD3 exporter script is doing weird stuff to the exported model's scale: it seems to scale everything down to the size of the default Blender cube.

I can make a cube ANY dimension (2x2x2, 200x200x200, it doesn't matter) but the output MD3 will ALWAYS be downscaled to match the dimensions of Blender's default cube.

Because of this, I am temporarily taking down my template file until I can figure out what's going on. Sorry for the mess!

[Enjay]

With my 1:1:1 renderer, the difference of the model height is still there. A 64 model sitting next to a 64 sector still appears shorter.

I wonder why that is? Given that making a 64x64x64 cube and then applying scales of 1:1:1.2 to it in modeldef makes it exactly the same size as a doom crate made with sectors, the result in your 1:1:1 renderer is surprising. I don't suppose that you left in the bit of code that squishes the models down from 1.2 back to 1.0 did you (thereby actually making them 1:1:0.8333)?

[Nash]

The code that renders the pixels to the screen, and the one that draws the models are separate.

You can try this yourself. To get the renderer to draw 1:1 pixels in the viewport, open gl_scene.cpp, look for #define RMUL (1.6f/1.333333f) and change it to #define RMUL (1.0f)

Now you will have 1:1 scaling in the 3-d view, but the models are still being squashed vertically in gl_models.h unless you apply that change I mentioned a few posts back... OR apply 1.2 Z scaling in the MODELDEF.

I chose to fix it in the source (gl_models.h) so that I don't have to apply this 1.2 Z scaling to every actor I define (in other words, leave out the "Scale" property from MODELDEF entirely)

For generalized gzdoom.exe modding however, we don't have the luxury of modified source, so there is no other choice but to use the MODELDEF fix.

[Enjay]

You can try this yourself. To get the renderer to draw 1:1 pixels in the viewport, open gl_scene.cpp, look for #define RMUL (1.6f/1.333333f) and change it to #define RMUL (1.0f)

I may try that - especially as it is such a simple change. I've been intrigued by the idea of seeing 1:1:1 ratios in (G)ZDoom for some time.

[Nash]

I have fixed the MD3 export script so that it finally exports the models without messing with the scale. You will now be able to truly export models from Blender to GZDoom with a 1:1 scale (1 Blender unit = 1 Doom map pixel). First post updated.

[NeuralStunner]

Question 1: Are you able to add a system to set up HUD weapon models?

Question 2: Could you tweak this script to be Quake compatible as well?

Question 3: Why the shit does Blender break API compatibility all the time?

[Nash]

Question 1: Are you able to add a system to set up HUD weapon models?

Question 2: Could you tweak this script to be Quake compatible as well?

Question 3: Why the shit does Blender break API compatibility all the time?

1: Okay I'll get around to this and update the first post when I'm done.

2: The original script was meant for Quake 3 so if you want to edit for that game, I think the stock script works fine. Or were you talking about the auto scaling when your model is below a certain size (which the script does by default, and what my version fixes)?

3: I know right? This is so annoying.

[Nash]

Added a HUD weapon reference for Blender. Useful for making HUD models. Test model has the size of the default Doom pistol.

[NeuralStunner]

2: The original script was meant for Quake 3 so if you want to edit for that game, I think the stock script works fine. Or were you talking about the auto scaling when your model is below a certain size (which the script does by default, and what my version fixes)?

I wanted to use it for Quake (DarkPlaces) if possible, hopefully with character/weapon size references for that too. And the rescaling does sound annoying, yeah.

[Nash]

http://www.katsbits.com/tools/#misc has reference blocks for a lot of game engines (Unreal, Quake, etc).

I don't have any Quake engines installed and I'm not particularly interested in modding for them at this time so I don't think I'm able to make any reference files anyway.

[Enjay]

I meant to attach this earlier and just didn't.

http://www.mediafire.com/download.php?9klk7ja169bljkr

It may be useful for illustrating the scaling thing that Nash and I were discussing.



Its a map and a simple box model. The box, according to the model editor, is 128x128x128. It has been used for two actors. In one actor (using the Baron marble face texture as a skin) it has a scale ratio of 1.0 1.0 1.0. The same model is used again with a ratio of 1.0 1.0 1.2 and uses the other (archvile?) marble face. In the map there is a box made from sectors that is 128x128x128 Doom units and has the pentagram marble face on it. In the map you can see that both models match the width and length of the Doom sector boxes but the 1.0 scaled Baron one is shorter whereas the 1.2 scaled archvile(?) one is the same height as the sector box.

The model-based actors have been left as non-solid so that you can wander around more freely looking at stuff. You can also see some nice z-fighting on the inside of the box.