Fbx,obj,3ds, basically any normal formats

[Collegia Titanica]

In this day and age of graphics, with the proliferation of wonderful standardized formats, scene sharing, substance painters and all, it's about time we move ahead of early 2000 technologies.

MD3 are ... lacking so to say.

>Download nash exporter and some gz exporter
>Oh, only a 10 MB model, no problem:)))))
>Import, rotate, select all , export as md3
>It shouldn't take this long, better get cofveve
>Still loading
>Check 8GB ram usage
>Le 92% 10 minute tryharding to save on 900$ pc
>Some spots appear fuzzy, it feels like some quality is lost

The other week, some materials support got added, just saying.
https://www.youtube.com/watch?v=oOfw6HNcmj8

[Chris]

There's not really much in the way of standard 3D model formats. Everyone seems to want to do their own thing. But I'd throw my hat in for glTF 2.0, which seems to be gaining some support.

[Marisa the Magician]

Actually, dpJudas has been working on an open model format that would better support gzdoom's features. I think it was called zmdl.

[Collegia Titanica]

That feeling when ...


What I expected


What I got

[dpJudas]

Actually, dpJudas has been working on an open model format that would better support gzdoom's features. I think it was called zmdl.

I haven't done any work on improved model formats. Only talked about it on Discord.

There's not really much in the way of standard 3D model formats. Everyone seems to want to do their own thing.

And that's what I suggest GZDoom does as well. The exchange formats offered by 3D modelling tools (i.e. collada, fbx or obj) are not fit for direct consumption by an engine. What I suggest is that GZDoom creates its own format and then the editing tools are left with the exercise of converting to it.

[Collegia Titanica]

Could work. It's crazy that something is being added to commits every single day, tackling this problem would greatly improve 3d modeling

[Chris]

And that's what I suggest GZDoom does as well. The exchange formats offered by 3D modelling tools (i.e. collada, fbx or obj) are not fit for direct consumption by an engine.

There are some formats intended to be used by an engine, more recent examples being OpenGEX and glTF2.0. The problem mainly comes down to support (there's not much reason to support a format that you still need to use an engine-specific converter to generate them from). It's a catch-22, though... few programs/engines look to support a standard format because modelling programs don't directly support it, and modelling programs don't support a standard export format because few programs/engines will use it. But where modeling programs are largely profit-driven, making decisions that will bring in the most amount of money from its users, open source engines can be more ideological, making decisions that would benefit the community or industry in general. As more engines/programs adopt it, modeling programs will be incentivized to follow.

[dpJudas]

The Open Game Engine Exchange (OpenGEX) format is a text-based file format designed to facilitate the transfer of complex scene data between applications such as modeling tools and game engines. The OpenGEX format is built upon the data structure concepts defined by the Open Data Description Language (OpenDDL), a generic language for the storage of arbitrary data in human-readable format.

This format is a competitor to FBX, not a format meant to be consumed directly by game engines (*). Remember that modern game engine editors do read stuff like FBX, but they all convert it for the engine itself.

Essentially the problem with standardizing model formats is that the game engine needs to load the data fast (text-based formats thus a very bad idea) and secondly the mesh data itself is highly dependent on the features of the engine itself. A material in something like 3ds Max has tons of features including countless maps and literally hundreds of settings for various texture map and BRDF types. The engine itself is only able to use a very limited subset.

A simple example would be "multiple vertex colors and texture coordinate sets per mesh" in the feature list for OpenGEX. Clearly any mesh using multiple texture coordinates will not work for engines like GZDoom that only keeps one UV pair. If GZDoom encounters a GEX file it is essentially left with the only option that it must ignore the other sets and throw them away. Vertex colors are supported by GZDoom, but other engines may not support that all. The exported model file will be full irrelevant data that it wastes time parsing (since it is a text format) and loading. Worse yet, the data as described might be completely incompatible with how it stores vertex or index arrays - so now it has to analyze the data and reformat before it can be consumed. It must do this every time the game loads a model.

*) If they really do intend it to be directly consumed by game engines then the format will fail. There have been countless such format attempts over the years and they all failed. Why should this one be any different?

[Chris]

A simple example would be "multiple vertex colors and texture coordinate sets per mesh" in the feature list for OpenGEX. Clearly any mesh using multiple texture coordinates will not work for engines like GZDoom that only keeps one UV pair. If GZDoom encounters a GEX file it is essentially left with the only option that it must ignore the other sets and throw them away.

That's the case regardless. If I make a model now in Blender or 3DSMax using multiple UV pairs, at some point I have to toss those extra pairs before GZDoom will like it. Just like if a model defines a normal map, the engine has to support normal maps for it to be effective.

However, making a custom format that fits exactly what GZDoom supports means the format needs to be kept updated whenever new features are added. Like the recent metallic/roughness/ao maps for PBR support, whereas previously only normal and specular maps were supported. With a standardized format, GZDoom would automatically support models that used those features by recognizing those data fields. Tools already support those features so people can start utilizing them right away in their usual model creation pipeline. A custom format would mean the format would needs updating after the features have been stabilized (going through discussions to reach an agreement among developers for the format update), and then the tools to create the custom file format would need updating; stuff that's already done for a standardized format.

FWIW, I wouldn't say OpenGEX is the best choice of format to support, given limited manpower to add/maintain format support. It seems to me glTF 2.0 is a better choice with the current amount of support it already seems to have and Khronos' backing.

[Nash]

OP - that model waaaaaaay exceeds not only the MD3 specs, yet a sane game-ready standard for game meshes. On top of that, you were trying to export 250 frames of animation (Blender defaults to 250), which is why it hangs.

Either get a better, more game-ready model or do the work needed to stay within the specs (regardless of whether GZDoom enforces the limits or not; the exporter should fail or export junk data if you attempt to export that much data). https://icculus.org/homepages/phaethon/ ... ormat.html

120k triangles for a tank model is VERY unoptimized and inefficient. Even in high-end engines, those models would go around 20 - 30k at most. For early 2000s standard, even lower - probably 10k max.

That said, I agree on a GZDoom-specific model format.

[Collegia Titanica]

Bonus question, why aren't the normal metallic roughness and AO maps loading for me ? I placed them in
mypk3/materials/normalmaps/auto
/materials/metallic/auto
/materials/roughness/auto
/materials/ao/auto
Default and map textures are the same name, it should work. Am I missing something ? Something about GLDEFS ?

[Apeirogon]

Import, rotate, select all , export as md3

Export it in parts, and then combine them in modeldef.

[Apeirogon]

Up just to ask, what is the party's line on this issue, in this time?

Md3 not bad format, but old.
And to fix errors on already converted model, which appeared because of export, it require soft from far far away 2000, which you firstly must find, then understand how to make it work on modern OS, and then try to find tutorial "how make X" on it...or press all buttons and undo it changes, until you accidentally find desired button.

[Graf Zahl]

Moving to "General", because there *IS* work being done, but this discussion is something that shouldn't be stopped by closing the thread.

[Apeirogon]

Hmmm....so....its new model format will replace md3 or no? Or it just extend limitation of md3 for more than 32 objects, 4048 polygons, how many there? vertices, etc?