[GZDoom/Blender 2.79] MD3 Export, Size Reference Template
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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/ ... export.zip
I also think this thread should be moved to Software -> Asset Manipulation because it is a Blender plugin
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/ ... export.zip
I also think this thread should be moved to Software -> Asset Manipulation because it is a Blender plugin
-
-
- Posts: 17933
- Joined: Fri Jul 06, 2007 3:22 pm
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
Does your change play nice with custom smoothing groups? I usually have the edge split modifier to explicitly define where I want hard faces.Talon1024 wrote: On the other hand, I made my own modification of this script to account for smooth and flat-shaded faces.
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.Some older Blender scripting features that this script relied on were removed in Blender 2.80.
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)
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
As far as I can tell, yes it does. The script applies modifiers when converting the objects to meshes for export.Nash wrote:Does your change play nice with custom smoothing groups? I usually have the edge split modifier to explicitly define where I want hard faces.
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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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?Talon1024 wrote: 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.
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.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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.Nash wrote: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?
Go ahead.Nash wrote:If it's okay with you, I'd like to merge in your face smooth/sharp fix.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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. :)Talon1024 wrote: 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.
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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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...
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.
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...
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.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
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.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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?
Anyway, how did you make GZDoom show you the normals for everything you can see?
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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!Talon1024 wrote: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?
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).
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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.
As much as I hate 2.8, I'd like to see if it's possible to do a port with minimal work.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
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.
-
- Posts: 27
- Joined: Fri Mar 08, 2019 5:11 pm
- Graphics Processor: nVidia (Modern GZDoom)
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
Why does orientation always change when exporting animated ones? It happens to me all the time with single model too. Am I doing something wrong?
evidence:
https://youtu.be/TbclS_D9zUs
evidence:
https://youtu.be/TbclS_D9zUs
-
- Posts: 356
- Joined: Wed Aug 02, 2017 3:01 pm
- Location: Illinois
Re: [GZDoom/Blender 2.79] MD3 Export, Size Reference Templat
Sorry for the bump... but is there an updated version of this? It isn't working on Blender 2.92