[Mblackwell]

It was updated last year. But in reality the point is that it shouldn't need to be updated.

[Striker]

There's always Noesis, either way.

[icecoldduke]

 Mblackwell, on 14 July 2017 - 10:53 AM, said:

It was updated last year.

I stand corrected on that, in my notes when I used it last year it wasn't updated in quite awhile.

My point still stands. The FBX exporters are maintained by industry engineers, and have a fuck ton of tested man hours(since there are a bunch of shipped products using FBX). IQM is only used by small number of people(really small, like tens of people in the world), and I can attest to how fucked the general IQM exporter is(or at least was a year ago).

It seems like you guys are making the wrong choice, and for the life of me I can't see why .

[Mblackwell]

I don't really have any attachment to IQM, just not FBX.

I suggested SMD or DXM which Valve maintains good tools for. But everyone has their own preferences, and the real idea being suggested is that the format be something open and stable, that has tools and doesn't require intermediary steps.

[Mark]

Whatever format is in Eduke32's future, I'm assuming legacy support for md3 stays in. I'm very limited by the modeling program I use.

[TON]

In Github there is a IQM model loader made in lua that is licensed under MIT:

https://github.com/excessive/iqm

[Tea Monster]

 icecoldduke, on 14 July 2017 - 10:57 AM, said:

I stand corrected on that, in my notes when I used it last year it wasn't updated in quite awhile.

My point still stands. The FBX exporters are maintained by industry engineers, and have a fuck ton of tested man hours(since there are a bunch of shipped products using FBX). IQM is only used by small number of people(really small, like tens of people in the world), and I can attest to how fucked the general IQM exporter is(or at least was a year ago).

It seems like you guys are making the wrong choice, and for the life of me I can't see why .

Probably due to open source politics and the view that anything from Autodesk or Microsoft is part of some great, evil conspiracy.
Assimp is an open source solution used by the Doomsday Doom source port (that gives FBX and even Blender support). It is in itself open source and is 'mod proven'.

https://youtu.be/tmko85wtHss

[Spiker]

Don't try to invent a rounder wheel. FBX it is.

[Tea Monster]

Mark - Assimp also supports MD3.

There is a viewer and file converter, but I can't vouch for them as I've not tried them out.

[Mark]

I'm only concerned about it's performance in the engine. I'll continue to use my same old program to make stuff. And if it allows me to continue to make stuff for ICD's SW then all the better.

[Hendricks266]

 Mark., on 14 July 2017 - 11:18 AM, said:

Whatever format is in Eduke32's future, I'm assuming legacy support for md3 stays in. I'm very limited by the modeling program I use.

Absolutely. There is no way we would throw out support for every HRP and Polymost/Polymer mod ever.

 TON, on 14 July 2017 - 11:21 AM, said:

In Github there is a IQM model loader made in lua that is licensed under MIT:

https://github.com/excessive/iqm

Thanks for the suggestion! Unfortunately a library written in Lua is of no use to us.

 Tea Monster, on 14 July 2017 - 11:33 AM, said:

Assimp is an open source solution used by the Doomsday Doom source port (that gives FBX and even Blender support). It is in itself open source and is 'mod proven'.

ice has mentioned assimp before. I like that it's battle-tested and licensed as 3-clause BSD. Unfortunately, it's still massive, with support for tons of formats no one cares about that would bloat our EXE size.

 Spiker, on 14 July 2017 - 11:36 AM, said:

Don't try to invent a rounder wheel. FBX it is.

Dareth the ignoramus speak again?

[icecoldduke]

 Hendricks266, on 14 July 2017 - 12:21 PM, said:

ice has mentioned assimp before. I like that it's battle-tested and licensed as 3-clause BSD. Unfortunately, it's still massive, with support for tons of formats no one cares about that would bloat our EXE size.

Why do you care about exe size?

[Tea Monster]

Also, balance that off against the time and effort you would expend on having to write and maintain your own custom import solution.

[leilei]

Briefly chiming in on the whole silly fbx vs iqm debate, from my technical artist perspective:

- Blender's IQM exporter always worked. I'd say it's the best model exporting script i've seen made for blender because it's not made for satisfying a nehe tutorial and the model format doesn't change suddenly. Due to this, I use IQM as an exchange format with Noesis to export better PSKs, MD3s, etc. for other engines, i.e. UnrealEngine2
- I don't use IQM for my projects as an end model, but if I did, it'd be something i'd want control of skeleton bones for in a supporting engine like Darkplaces. I'd use it over MD3 if it's available and properly implemented in the engine/renderer.
- Ioq3's IQM support is crap. No tags, crashes, odd bone deformities, no LoDs; and if you've got an issue with it, submit a patch or get blocked forever. It's done for a feature bullet point. For that engine I export to Raven's MDR instead as the support in that is already finished and it's a much more efficient format than IQM (At the expense of skeletal hierarchy and precision, which doesn't really matter for a game that can't control a single bone, treating all models as if they were linear vertex morphs ducttaped together).
- The derigify checkbox in the iqm exporter is pretty cool at getting rid of excess bones on a rig (that is if you use rigify and have DEF/ORG prefixed bones of every bone, it exports only the DEF ones and ignores all your complex ik bone setups)
- FBX is not a game-ready model format at all, and the aforementioned license conflicts trumps all other concern

[icecoldduke]

 leilei, on 14 July 2017 - 02:29 PM, said:

- FBX is not a game-ready model format at all

Care to elaborate?

[leilei]

IQM was created because these "perfect" exchange formats all sucked for use in game engines as they were and the existing game model formats. PSK ate sharp edges/smoothing groups (automatically welding all verts so UE2's automatic LoD processor can work), SMD was hindered by strict usage rights of the Half-Life / Source SDKs, Collada had already overfragmented itself with incompatibilities and exporter regressions, MD5 has no vertex normals and the pipeline's a maya-biased nightmare with none of the previous id formats' elegance. FBX pretty much falls in the same line as Collada except for being far more Auto(head-into)deskier.

[icecoldduke]

 leilei, on 14 July 2017 - 05:46 PM, said:

IQM was created because these "perfect" exchange formats all sucked for use in game engines as they were and the existing game model formats. PSK ate sharp edges/smoothing groups (automatically welding all verts so UE2's automatic LoD processor can work), SMD was hindered by strict usage rights of the Half-Life / Source SDKs, Collada had already overfragmented itself with incompatibilities and exporter regressions, MD5 has no vertex normals and the pipeline's a maya-biased nightmare with none of the previous id formats' elegance. FBX pretty much falls in the same line as Collada except for being far more Auto(head-into)deskier.

All your stating is why you think these other formats suck, and not why IQM is better .

[TheZombieKiller]

 icecoldduke, on 14 July 2017 - 05:51 PM, said:

All your stating is why you think these other formats suck, and not why IQM is better .

IQM is better because it doesn't suffer from the issues that were mentioned with the other formats. I thought the post made that pretty clear.

[icecoldduke]

 TheZombieKiller, on 14 July 2017 - 06:11 PM, said:

IQM is better because it doesn't suffer from the issues that were mentioned with the other formats. I thought the post made that pretty clear.

The only technical thing he brought up was smoothing groups and vertex normals, both of which FBX has. The FBX exporters are fantastic, so my point still stands, I'm not sure how his post applies to FBX, or is he just saying IQM is better then the formats he listed? If so none of his post is relevant to why IQM should be choosen over FBX .

EDIT:
Didn't mean to down vote you. Evan it would be nice if you added a forum feature that allows us to undue voting.

[Striker]

Aside from the aforementioned licensing issues FBX has, I've had more trouble than any other format when it came to working with my current tools unless I restrict myself purely to 3DS Max. The main program I use, Milkshape 3D, has a terrible FBX Importer and Exporter. Only supports the 2010 FBX format, and only partially. The worst parts however, are that models are imported at the wrong scale and rotation, and exporting usually bungles animation (at least it does for me), and I'm lucky if it doesn't just crash during export of a detailed model with a lot of frames. The FBX import/export for Blender used to be really spotty for me as well, but I haven't touched Blender in about 4 years (The interface is god-awful, even after the restructuring, and the over-reliance on hotkeys is abysmal), so I can't really say for certain if it's still the same way.

[Mark]

+10 on the Blender review

[icecoldduke]

 Striker, on 14 July 2017 - 06:42 PM, said:

Aside from the aforementioned licensing issues FBX has, I've had more trouble than any other format when it came to working with my current tools unless I restrict myself purely to 3DS Max. The main program I use, Milkshape 3D, has a terrible FBX Importer and Exporter. Only supports the 2010 FBX format, and only partially. The worst parts however, are that models are imported at the wrong scale and rotation, and exporting usually bungles animation (at least it does for me), and I'm lucky if it doesn't just crash during export of a detailed model with a lot of frames. The FBX import/export for Blender used to be really spotty for me as well, but I haven't touched Blender in about 4 years (The interface is god-awful, even after the restructuring, and the over-reliance on hotkeys is abysmal), so I can't really say for certain if it's still the same way.

This also doesn't help the iqm vs fbx debate since there isn't a iqm plugin for milkshape : )

[Striker]

 icecoldduke, on 14 July 2017 - 07:03 PM, said:

This also doesn't help the iqm vs fbx debate since there isn't a iqm plugin for milkshape : )

But I also can more easily convert it's supported formats to IQM and back via Noesis and still not be tied to 3DS Max if I want to fully utilize the format.

[Tea Monster]

You guys are still using milkshape?

Why don't you use assimp and wire up the MD3 (shudder), IQM (gag) and FBX importers to EDuke. Three formats isn't too much, we have three 2D formats, and the people who want to use IQM can be happy and you can put a call out on somewhere like Polycount for people to help with the mod and they won't be horrified by being asked to use tools and formats from the bronze-age of game modelling.

[Hendricks266]

EDuke32 will support FBX models as soon as it supports PSD images.

[icecoldduke]

For my branch I will be adding assimp(which can load milkshape 3d files out of the box, no need to convert). I will keep the current MD3 loader as is, and just add assimp support.

Also Evan, looking at the model loader in Eduke32, its very inefficient, its doing a bunch of small reads rather then one big read.

[Mark]

Cool. My modeling program of choice outputs md3 and milkshape. I'm a happy camper.

[icecoldduke]

 Hendricks266, on 15 July 2017 - 12:06 AM, said:

EDuke32 will support FBX models as soon as it supports PSD images.

I'd like to have a technical back and forth on this issue Evan. I can't argue with your beliefs, but I'm hoping I can convince you with evidence . My question still remains the same, why do you not want to include assimp into eduke32?

[Hendricks266]

The only argument you've been making to support FBX is the bandwagon fallacy. My analogy with PSD is airtight. The MS3D format falls into the same category so it's clear you're pandering to your supporters.

Assimp includes a bunch of formats that we actively want to avoid supporting. Fortunately we can toggle individual formats, but have you confirmed that their MD2 and MD3 support is actually fully featured and debugged? This library doesn't solve loading KVX or IQM either.

The logic of our model loading is perfect. TX and I are skilled at optimizing and cleaning existing code. There are no factors here pushing us away from that code entirely.

[icecoldduke]

 Hendricks266, on 15 July 2017 - 05:07 AM, said:

Assimp includes a bunch of formats that we actively want to avoid supporting.

Let's start there. Why would you not want to support FBX import if it comes standard in the asset import library?

 Hendricks266, on 15 July 2017 - 05:07 AM, said:

The MS3D format falls into the same category so it's clear you're pandering to your supporters.

I don't have supporters Evan. Were on the same team.

 Hendricks266, on 15 July 2017 - 05:07 AM, said:

Have you confirmed that their MD2 and MD3 support is actually fully featured and debugged? This library doesn't solve loading KVX or IQM either.

You should leave the md2, md3 and KVX support as is. The asset import library does not support vertex animation, only skeletal animation. Which is why I said earlier, I would leave the existing md3/md2 support as is.

 Hendricks266, on 15 July 2017 - 05:07 AM, said:

The logic of our model loading is perfect. TX and I are skilled at optimizing and cleaning existing code. There are no factors here pushing us away from that code entirely.

Look at md3load, all those calls to kread and klseek causes the harddrive to do a bunch of unnecessary head movement(with SSD's obviously this issue is less important), doing one big read and having a memory reader class of kind would speak up that function drastically.

It's always best to do one big read then a whole bunch of small reads. If you know that great, I'm just pointing out that code is not optimized at all.