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

[Talon1024]

This won't work with Blender 2.80. Blender 2.80 is an entirely different thing. Some older Blender scripting features that this script relied on were removed in Blender 2.80.

On the other hand, I made my own modification of this script to account for smooth and flat-shaded faces.

https://www.ciinet.org/kevin/myimages2/doom/misc/gzdoom_md3_export.zip

I also think this thread should be moved to Software -> Asset Manipulation because it is a Blender plugin

[Gez]

I believe there was no Software and Ports subforum, let alone the editors/asset manip subsubforum, when the topic was created, so editing resources was what made the most sense then. But moved now.

[Nash]

On the other hand, I made my own modification of this script to account for smooth and flat-shaded faces.

Does your change play nice with custom smoothing groups? I usually have the edge split modifier to explicitly define where I want hard faces.

Some older Blender scripting features that this script relied on were removed in Blender 2.80.

Wow, yet another reason for me to not even consider using 2.8. :) As I've stated many times in the past, 2.79 does everything I ever want it to do as far as modeling work in GZDoom's context is concerned. I have no plans to switch over, especially not when I have currently-in-progress GZDoom projects and my model export pipeline is already working perfectly.

Anyone who wants a GZDoom exporter for 2.8 should just rewrite the entire damn thing from scratch, to be frank. And while they're at it, lift the various artificial Quake 3 limits that GZDoom does not impose (the dimension limit, the weird 90-degrees-downwards normal bug, the angle offset, probably a few other things as well)

[Talon1024]

Does your change play nice with custom smoothing groups? I usually have the edge split modifier to explicitly define where I want hard faces.

As far as I can tell, yes it does. The script applies modifiers when converting the objects to meshes for export.

EDIT: After taking a closer look at the MD3 file format, it seems the 512 unit limitation is due to the fact that vertex positions are stored as signed 16-bit integers, which are divided by 64 by the game engine MD3 importer code.

[Nash]

EDIT: After taking a closer look at the MD3 file format, it seems the 512 unit limitation is due to the fact that vertex positions are stored as signed 16-bit integers, which are divided by 64 by the game engine MD3 importer code.

I noticed this earlier, too, from the exporter-side at least. So I suppose it isn't enough to just update the exporter, GZDoom's MD3 loader needs to be updated too?

Anyway, I have decided to clean up the exporter from the ground up, and this time do incremental changes so that I can keep track of my progress. It's not fully ready yet, but here's the link if you (or anyone else) is interested.

https://github.com/nashmuhandes/io_export_gzdoom_md3

If it's okay with you, I'd like to merge in your face smooth/sharp fix.

[Talon1024]

I noticed this earlier, too, from the exporter-side at least. So I suppose it isn't enough to just update the exporter, GZDoom's MD3 loader needs to be updated too?

Yes, if you want to change the data type and size for MD3 vertex positions, then both the Blender exporter and GZDoom importer will have to be updated. But then, these "MD3" files will not be compatible with other programs.

If it's okay with you, I'd like to merge in your face smooth/sharp fix.

Go ahead.

[Nash]

Yes, if you want to change the data type and size for MD3 vertex positions, then both the Blender exporter and GZDoom importer will have to be updated. But then, these "MD3" files will not be compatible with other programs.

Hence why I rebranded the exporter as "GZDoom MD3" right from the start - GZDoom works so differently that this exporter shouldn't be used for other MD3-supporting games. :)

I just now fixed the angle rotation* so that - for example - Suzanne's default facing angle matches GZDoom's actor angle. This change alone would mean if you used GZDoom MD3 exporter in other games, the angle will come out wrong. I think this is acceptable.

By the way, regarding your script edit, it seems the normals are still wrong for this top face:




It's just the default Blender cube set to "flat".

* I'm not sure if doing object rotation is a good idea. Ideally, it should apply the matrix rotation in the normal encoding step (the part that writes the MD3Vert) so that your Blender objects don't get modified, but I suck at 3D math.

[Nash]

Sorry for the double-post but I think this is important.

I've fixed a long-withstanding oddity with every MD3 exporter ever created (even the ones that aren't this one) where for some weird reason, polygons that are facing straight-down (90 degrees) would have the wrong normals encoded.

Nobody, NOBODY noticed this in GZDoom because, well, model normals were never rendered before dpJudas saved us all. :P Anyway, after a little digging around the MD3 specs, I found this little gem...

Two special vectors are the ones that point up and point down, as these values for z result in a singularity for acos. The special case of straight-up is:
normal <- 0

And the special case of straight down is:
lat <- 0
lng <- 128
normal <- (lat shift-left 8) binary-or (lng)

or, shorter:
normal <- 32768

Well, that at least confirms that there is indeed some weird fuckery going on with straight-down faces. With this knowledge, fixing this was as easy as commenting some lines out.

Here are before and after results.





If you're one of the people reading this having to ask, "well why is this important". Well, the normals are important in determining how a polygon gets lit. If you've experienced problems like dynamic lights not lighting your models correctly in-game, that is the result of broken normals, something a lot of cheap exporters tend to do. :) As far as I'm aware, my customized exporter is currently the only one that produces 100% correct normals that GZDoom can render accurately.

[Talon1024]

GitHub really streamlines the development process, eh? I've sent a pull request that fixes the normals on the default cube.

Anyway, how did you make GZDoom show you the normals for everything you can see?

[Nash]

GitHub really streamlines the development process, eh? I've sent a pull request that fixes the normals on the default cube.

Anyway, how did you make GZDoom show you the normals for everything you can see?

Thanks! I'll just merge this and test it right away with a few models, besides the default cube. :P Should be okay, but need to make sure. [EDIT] works perfectly, nice!

To show normals in GZDoom, type gl_ssao_debug 4. SSAO must be enabled first for this to work at all (even the "low" setting would suffice).

[Nash]

Talon1024, you said some scripting features were completely removed. Do you know what exactly they are?

As much as I hate 2.8, I'd like to see if it's possible to do a port with minimal work.

[Talon1024]

This script uses tessfaces and tessface_uv_textures, which were removed in Blender 2.80 and replaced with loop_triangles. In addition, Object.to_mesh was changed in a way that makes it incompatible with previous Blender releases, and does not allow modifiers to be applied in the process.

[Nash]

That's annoying. Why do these developers even do this? I understand deprecating old features to encourage use of new ones, like loop_triangles, but the modifier thing? Jeez.