Licensing Question

[StrikerMan780]

Is (G)ZDoom compatible with this license by any chance? http://www.assimp.org/main_license.html

Reason I ask, is I may go ahead and implement FBX support, in order to finally get a more flexible, skeleton-based model format to work with.

[Graf Zahl]

Yes, the licenses are compatible.

The only requirement is that the license must be in the binary distribution as well which is no problem.

[dpJudas]

I wonder if it is a good idea to make gzdoom read .FBX files directly.

My personal experience with assimp is that this particular library has gone for quantity in supported formats over quality. At least that was the case when I tried it (a few years ago I admit). I had to abandon assimp in an earlier project because it just couldn't import files from 3ds Max reliably enough.

The other catch is that .FBX is a proprietary format controlled by Autodesk. The only reliable reader for FBX is thus the Autodesk FBX SDK, which may not be available for all platforms and compilers. The format also changes all the time as Autodesk see fit - there's a FBX 2014, 2015 and 2016 format, as an example.

Autodesk products also have a passion for using absolute paths in the FBX files, making it somewhat nasty to resolve the paths to textures and such referenced in the FBX files.

What I would suggest is making some simpler gzdoom model format that editors can export to. That would push any external format handling to the Doom editors that has a much better opportunity to prompt the user for how to link textures, materials, attachment points, ragdolls and so on, to the FBX file.

[Graf Zahl]

If you want some modern model format, use some open one, like MD5.
I won't link GZDoom to a proprietary SDK and neither to some half-assed implementation of a reader for one. If FBX is as bad as dpJudas says it's a no-go.

[dpJudas]

Does gzdoom support MD5 right now? If not, I'd suggest adding support for that.

I have some old FBX reading code that could be changed into outputting MD5 if the main problem is that there's no easy way to get a MD5 file.

[Graf Zahl]

No, it does not support MD5. The only model formats at the moment are MD2, MD3 and Doomsday's DMD.
The main problem with any kind of bone model is how it needs to be mapped to Doom's state system. To be honest, I have no good idea.

[StrikerMan780]

There is a format spec for FBX if one wants to make their own loader, without need of a proprietary SDK. There are some existing OSS libraries out there too, but they aren't always perfect.

A bone model can be mapped to Doom States the same way, through frame indexes. Though, if one were to go with MD5s... animations and models are in two separate files. (.MD5Mesh and .MD5Anim)

FBX is self-contained like the other formats, and has wide support in model editors, which was why I originally considered it.

Another format aside from MD5 I could suggest is IQM. or DAE (DAE is a very good alternative to FBX).

[Nash]

FYI: Blender ships with a nice FBX exporter (because Unreal Engine 4 + Blender is a popular combination) but an open format would be cool, too.

As for mapping-wise: I also suggested this before but there's nothing really different as far as time is concerned, because the animation still moves just like any other animation (frame-based). So mapping the animation frame of the skeleton to Doom states should be straightforward just like whatever is already possible today in GZDoom.

Can't wait for a proper skeletal format! Goodbye bloated vertex-animated models. :S Good luck, Striker! Keep us posted.

[dpJudas]

I tried googling for an official specification but came up empty. The only thing I found was an unofficial (reverse engineered) spec done by the Blender folks.

The way I look at it, the FBX format is a widely used exchange format that more or less has become a kind of defacto standard for what DAE was meant to do. All the big engine and model editors support it.

The problem with the format is that it describes a scene the way an editor tool would like to use it for import. Vertices, texture coordinates, and face indices are stored separately where the reading application is handed the task of making use of it. What that means is that gzdoom cannot just grab the vertices as-is and place them in GPU buffers - it has to work with the data first to make any use of it. At best this means slower load times, at worst it has an incomplete mesh description. How do you map a GLDEFS hardware shader to one of the FBX materials? How do you make the textures work with the texture manager?

I think this is why all engines I've ever seen the format from doesn't use FBX directly. Its data is morphed into a simpler format for the engine to consume. For Id games that has been the MDx formats.

Okay, that's the end of my rant on this subject. As always, it is the opinion of Graf that matters (our benevolent dictator for life! ). In any case, I think everyone would love if you can drop a FBX file in the doom editors and it would Just Work.

[Nash]

Hmm actually you're right dpJudas... upon closer inspection, it seems that Unreal Engine only utilizes FBX as an intermediary format; as soon as you drag and drop the FBX into the UE4 editor, it becomes some different format that the engine uses. This is invisible to "casual" users like me who'd easily be mislead into thinking the engine directly uses FBX. :P

So, yeah, perhaps any of the alternative formats Striker mentioned would be better for GZDoom.

[Gez]

I heard good things about Collada.