Model cause epileptic seizure in opengl mode

[Apeirogon]

Drop it
https://drive.google.com/file/d/1ARcGBs ... sp=sharing
at the gzdoom and type in console "summon bug".

First, gzdoom dont render model correctly, despite all md3 programs tell that this is valid md3 model.
Second, in opengl render mode it will cause graphical glitch, as on video
EPILEPSY WARNING

In all other render more it just a partly textured model. It also happens only when "flawed" model have more than one frame of animations.

[Cherno]

Not really a GZDoom issue, as I had this issue before with md3s that were not created correctly.

[Nash]

Can you post the .blend file too? Something seems to be exported incorrectly here.

Although that still doesn't explain how a model can corrupt the entire video display. o_O

[EDIT] can confirm that the bug happens to me too exactly as how Apeirgon describes it. Holy shit that gave me a headache!

[Graf Zahl]

Not really a GZDoom issue, as I had this issue before with md3s that were not created correctly.

The clobbered matrices are surely a bug, even if the model is broken.

[Graf Zahl]

Fixed the glitched graphics. This was caused by a skin-less surface in the model. It has 18 surfaces but from the looks of it only the first one has a skin defined.

[Cherno]

Sounds right. I encountered this when experimenting with multi-skin models.

[Apeirogon]

Fixed the glitched graphics. This was caused by a skin-less surface in the model. It has 18 surfaces but from the looks of it only the first one has a skin defined.

Yes, I forgot to add textures for banner.
But even without it model must looks like

Or gzdoom expect to find textures for second surface and because it dont find it, it start show its analog of "ERROR STOP EKS ZERO_ZERO_ZERO_ZERO..." BSOD?
Or model was broken in export time!?

[Graf Zahl]

What happened was that it encountered a skin-less surface and aborted rendering, but forgot to reset the render state to normal so it started glitching like crazy.

[Nash]

So it's not my exporter's fault then. I wish people would stop throwing fake accusations "hurr durr nash md3 exproter doesn workt!!!" and, you know, actually learn how to use it properly.

You either use SurfaceSkin to properly assign all meshes a valid skin, or you FOLLOW THE EXPORTER SPECS and name each Material (for every mesh) in Blender the full path to the texture. The latter will cause my exporter to properly embed the texture paths into each mesh group, as per the MD3 specs.

[Apeirogon]

But then I must read stuff. And learn it.
AND THIS IS HARD!!!!!
I DONT LIKE HARD((((((((

Plus, blender dont know about lost, long forgotten, if not banned, technology of the ancient one, friendly user interface. So for every my action must walk through blood and suffering.
AND I DONT LIKE BLOOD AND SUFFERING((((((

[Graf Zahl]

But then I must read stuff. And learn it.

Indeed you must. That's life. Deal with it.

[Apeirogon]

[Nash]

This is how you properly embed texture paths into separate objects/mesh groups/surfaces with my MD3 exporter. The name of the material slot is the full path of the texture that is inside your project's PK3. In this image, my door is made of 2 objects, the door, and the frame. The door's material name is "models/doors/door01/door01.png" (not pictured) while the frame has "models/doors/door01/door01f.png" as its material name. This is all that's needed. Omit the "Skin" property inside the MODELDEF; GZDoom will attempt to load the embedded texture paths.

There is nothing wrong with my exporter and there is nothing wrong with this workflow, I have been using this for years and am still actively using it for a big, model-heavy project. =P

[Marisa the Magician]

Ah, so with this fix now it behaves just like UE1 models, where missing surfaces are just skipped over.

[Clay]

This happened to me as well and it was indeed a missing skin issues. Also another that I causes me problems is scale. For me I have to make sure the model dimensions are at least 5x5x5 blender units in scale.