[Hendricks266]

icecoldduke, on 15 July 2017 - 05:22 AM, said:

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

"In argumentation theory, an argumentum ad populum (Latin for "argument to the people") is a fallacious argument that concludes that a proposition is true because many or most people believe it."

icecoldduke, on 15 July 2017 - 05:22 AM, said:

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

I've still never received an explanation for the "shadow brokers" directing your work on PolymerNG outside of public view and potentially being so easily upsettable that you edited entire pages of posts out of history.

icecoldduke, on 15 July 2017 - 05:22 AM, said:

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.

We know this. We have not perfomed optimization on the model loader yet, because it is not critical to anything we are working on.

[icecoldduke]

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

"In argumentation theory, an argumentum ad populum (Latin for "argument to the people") is a fallacious argument that concludes that a proposition is true because many or most people believe it."

That's not a valid counter to my question . You and I have a different opinion on what model formats should be supported in eduke32. I've said lets support FBX, and I've given valid reasons why(industry supported exporters for one). I'm curious what your reasons are for not wanting to support FBX?

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

I've still never received an explanation for the "shadow brokers" directing your work on PolymerNG outside of public view and potentially being so easily upsettable that you edited entire pages of posts out of history.

I really hope, that I've never given you the impression that we were on different teams. I hope your not using the idiots that found my personal e-mail and kept spamming me during PolymerNG, as evidence that I'm running some mass duke4 resistance movement. I've told you guys this before, I like coming here and I'm not trying to piss people off. Believe it or not, coming here relaxes me.

Can we please move on to having a logical back and forth on assimp and fbx? .

[Spiker]

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.

I've spit my meal.

[Hendricks266]

icecoldduke, on 15 July 2017 - 05:47 AM, said:

That's not a valid counter to my question . You and I have a different opinion on what model formats should be supported in eduke32. I've said lets support FBX, and I've given valid reasons why(industry supported exporters for one). I'm curious what your reasons are for not wanting to support FBX?

The burden of proof is on the affirmative, not the status quo. We can all agree that EDuke32 needs to support a more modern model format. No evidence has been produced in favor of FBX in particular, at least none that could withstand formal reasoning.

"Everyone else is using it" is not a valid reason. "There is literally no other choice" would be, but that is not the case.

Several people have chimed in that FBX 1) is only suited for transfer between Autodesk applications, 2) is impractical to be used by the game directly, and 3) has licensing issues. Meanwhile we have nominated a format, IQM, that is well-designed, well-targeted to us, and permissibly licensed. Your response is to propose an entirely standalone, non-portable utility to convert FBX into your own custom EDuke32 PolymerNG model format, which the game then reads from disk.

This should not even be a debate.

[icecoldduke]

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

Several people have chimed in that FBX 1) is only suited for transfer between Autodesk applications, not used directly and 2) has licensing issues.

You might be able to argue the Autodesk FBX SDK has licensing issues with build, but there is no licensing issues with the format. The AssImp library has a custom made FBX importer. If you look at the IQM standalone exporter, they also have a custom FBX importer. AssImp does not use the autodesk FBX sdk to import FBX's, so there is no licensing issues. FBX is suited for a lot more then just transfer of models between autodesk applications, every big engine supports importing FBX, and is industry standard.

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

"Everyone else is using it" is not a valid reason. "There is literally no other choice" would be, but that is not the case.

How is that argument invalid? Since everyone is using FBX, the exporters will be maintained in the foreseeable future. Can you guarantee the same thing with IQM? Can you say that the IQM blender exporter has the same amount of testing on it as the blender fbx exporter?

EDIT:
To be clear, I'm taking about adding assimp support to mdssprite.cpp. So no external exe.

[Hendricks266]

"Industry standard" means nothing more than "large corporations have a lot of bureaucratic inertia in this direction". You're still just restating the appeal to popularity.

If we really need to, creating our own exporters is not hard. We've done it before. If the IQM exporter is community driven then we could always contribute patches upstream. Plagman has contributed to SDL2 through his work at Valve.

[Tea Monster]

Here's a question - are any of the people who are advocating IQM actually making models for any EDuke32 projects?

[icecoldduke]

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

If we really need to, creating our own exporters is not hard. We've done it before.

Creating exporters is easy, maintaining them is the hard part. Why not let the industry maintain the exporters and you guys focus on further developing eduke32?

Tea Monster, on 15 July 2017 - 06:17 AM, said:

Here's a question - are any of the people who are advocating IQM actually making models for any EDuke32 projects?

Good question .

[Hendricks266]

Tea Monster, on 15 July 2017 - 06:17 AM, said:

Here's a question - are any of the people who are advocating IQM actually making models for any EDuke32 projects?

Nice appeal to authority. Do any of the people advocating FBX understand the implications of that decision beyond "it's all I use in my day job"? The reasoning isn't there. We're not going to give content creators the royal treatment at the expense of the quality of our own project. Save that for when you pay us full-time to work on your industry-standard demands.

icecoldduke, on 15 July 2017 - 06:18 AM, said:

Creating exporters is easy, maintaining them is the hard part. Why not let the industry maintain the exporters and you guys focus on further developing eduke32?

Chicken and egg problem. It always helps to build momentum.

My problem now is less about throughput and more about obligations and backlog.

[Tea Monster]

No, I'm appealing to some common sense in that the people who create this stuff should have a say in what they need to get the job done.

[icecoldduke]

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

Nice appeal to authority. Do any of the people advocating FBX understand the implications of that decision beyond "it's all I use in my day job"? The reasoning isn't there. We're not going to give content creators the royal treatment at the expense of the quality of our own project. Save that for when you pay us full-time to work on your industry-standard demands.

What implications? How would adding FBX support to eduke32 compromise eduke32? Your making a lot of assertions without anything to back it up .

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

Chicken and egg problem. It always helps to build momentum.

Indies, AAA, and modders are getting used to the industry standard way of doing things. Why force a non standardized pipeline on people for no good reason?

[Mblackwell]

icecoldduke, on 15 July 2017 - 06:29 AM, said:

What implications? How would adding FBX support to eduke32 compromise eduke32? Your making a lot of assertions without anything to back it up .


Indies, AAA, and modders are getting used to the industry standard way of doing things. Why force a non standardized pipeline on people for no good reason?

For the first part of this you're increasing overhead to get things in the actual game, and creating a bit of a nightmare of potentially needing long term maintenance. If the formats can change beyond simple additions it means there's no guarantee that everything will work in five years let alone a decade.

On the second, it does not generally effect the work pipeline if there is a good export plugin and the resulting model when placed in game "just works". However as discussed FBX has some really hairy plugins that may not be compatible with either the game or future FBX formats. And considering you need a conversion step to even get it into the game the FBX proposal is the one that ruins the work pipeline the most.

[icecoldduke]

Mblackwell, on 15 July 2017 - 07:45 AM, said:

However as discussed FBX has some really hairy plugins.

Do you have a example? There are plenty of unity games were devs have exported FBX's from Blender. Maya and 3ds max have solid FBX plugins.

Mblackwell, on 15 July 2017 - 07:45 AM, said:

And considering you need a conversion step to even get it into the game the FBX proposal is the one that ruins the work pipeline the most.

As I mentioned in my previous post, I'll add assetimp support to mdssprite, so the game will just load FBX files without the need of a external conversion tool. The import pipeline would be, export from blender, max or maya, and that's it.

[TheZombieKiller]

For the record, Assimp only officially supports FBX 2011, 2012 and 2013, and it refuses to load anything older. There are still commonly used tools that can only export to earlier versions of the formats, such as Noesis.
My point being, if you export an IQM model from some software, it's practically guaranteed to be loadable in the engine. You can't say the same for FBX due to how different each iteration of it is, and the varying levels of support for each version in exporters.

[Tea Monster]

Again, do any of these people commenting on this matter actually make content for the engine?

It's not just EDuke. All the tools we use like Marmoset Toolbag, Substance Painter and other tools all use FBX.

[TheZombieKiller]

Tea Monster, on 15 July 2017 - 09:06 AM, said:

Again, do any of these people commenting on this matter actually make content for the engine?

It's not just EDuke. All the tools we use like Marmoset Toolbag, Substance Painter and other tools all use FBX.

Nobody is saying you can't use FBX with your tools, because that's what FBX is intended to be: an exchange format.
What is being discussed here is what the final format the engine reads should be, and it'd be a terrible idea for that to be an exchange format.

[Hendricks266]

Exchange your FBX into something that supports exporting IQM and you're gold.

[icecoldduke]

TheZombieKiller, on 15 July 2017 - 09:13 AM, said:

Nobody is saying you can't use FBX with your tools, because that's what FBX is intended to be: an exchange format.
What is being discussed here is what the final format the engine reads should be, and it'd be a terrible idea for that to be an exchange format.

Then why not pick a format that has a valid fbx converter? Tea Monster is right substance painter and a fuck ton of other tools will never aupport iqm. By the way there is no technical reason why you can't use a exchange format as your final format.

[Tea Monster]

Nothing supports IQM.

Unreal, Unity and other game engines and tools all support FBX as a final model format for game import.

[icecoldduke]

Tea Monster, on 15 July 2017 - 09:23 AM, said:

Nothing supports IQM.

Unreal, Unity and other game engines and tools all support FBX as a final model format for game import.

Correct then the engine converts the model to something that's faster to parse.

[Mblackwell]

Yes, so not saddling yourself with more technical burden, including support for large loaders with their own quirks and dependencies (which also affects building binaries and can introduce bugs that are more difficult to resolve, and limits your ability to make changes if you want to support future updates to the middleware), is probably smart. So instead you should go with a simple and stable format that is guaranteed to work basically forever even if unmaintained and is fast to implement.

[icecoldduke]

Mblackwell, on 15 July 2017 - 09:42 AM, said:

Yes, so not saddling yourself with more technical burden...

This is where I think the disconnect is, your way will cost you more time in the long run. Exporters will stop working with newer versions of modeling software, newer devs won't come on board because our pipeline is non standard. Anyway I get it, you guys won't take this CL, but I plan on using assimp in my branch.

[TerminX]

icecoldduke, on 15 July 2017 - 05:22 AM, said:

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.

The parts that were actually slow when profiling are optimized.

icecoldduke, on 15 July 2017 - 05:22 AM, said:

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.

In reality, that would only happen if your hard drive was, like, 100% fragmented. It would have to be so fragmented that a .md3 ended up in multiple spaces all over your drive. This is not a realistic scenario. In any other case, the drive would just read a big chunk of data into its internal cache (often 64 or 128MB these days), and all of the small reads will be completed from the cache at the same speed as what you're proposing instead of actually hitting the disk again.

It's literally a made up argument.

[Hank]

Tea Monster, on 15 July 2017 - 09:06 AM, said:

Again, do any of these people commenting on this matter actually make content for the engine?

It's not just EDuke. All the tools we use like Marmoset Toolbag, Substance Painter and other tools all use FBX.

What? Who is we? I do not use bloated software.

Unity 3D can import models directly from Blender. Unity 3D uses FBX internally.
Cryengine imports models directly from Blender. Cryengine uses collada, internally.

Texture: The preferred format for the Cryengine is an uncompressed tif file. This can be created in The Gimp and Genetica. Unity supports most common image files, again, those can be created in the Gimp and other non-bloated software also.

Unreal, no clue. To the best of my knowledge they too, cater to everyone, big and small.

Thus, my camera, Genetica Pro, The Gimp do NOT use FBX!

[Hendricks266]

Tea Monster, on 15 July 2017 - 09:23 AM, said:

Nothing supports IQM.

Unreal, Unity and other game engines and tools all support FBX as a final model format for game import.

[bandwagon fallacy intensifies]

icecoldduke, on 15 July 2017 - 10:22 AM, said:

This is where I think the disconnect is, your way will cost you more time in the long run. Exporters will stop working with newer versions of modeling software, newer devs won't come on board because our pipeline is non standard. Anyway I get it, you guys won't take this CL, but I plan on using assimp in my branch.

TX came up with the solution: Write your FBX processing tool, but use IQM as the format between it and EDuke32. If your work is any good, we'll merge IQM support, and then your tool can quickly be forgotten once the IQM exporters are shored up.

[icecoldduke]

Hendricks266, on 15 July 2017 - 01:01 PM, said:

TX came up with the solution: Write your FBX processing tool, but use IQM as the format between it and EDuke32. If your work is any good, we'll merge IQM support, and then your tool can quickly be forgotten once the IQM exporters are shored up.

You are very bad a motivating people to do work for you Evan . Saying I should do something that will be "quickly forgotten" is frankly a terrible thing to say. Regardless, IQM support is not in your depot. I'm going to add assimp support to my depot, and if you get IQM support in, I'll consider doing the tool, but this is the best way forward for my mod.

[Mark]

I'm not quite sure how to word my noob question. If ICD attaches assimp to his eduke32 based SW project, will it attach just as easily in regular eduke32 or are there major differences because his is SW?

[leilei]

Tea Monster, on 15 July 2017 - 06:17 AM, said:

Here's a question - are any of the people who are advocating IQM actually making models for any EDuke32 projects?

Being limited to MD3 changed my mind to contribute to the SWHRP several times over the past almost-decade (most of this time Noesis had not yet existed to work around pipeline issues).
Blender MD3 exporters were always crap in some way or another (broken normals, requiring 0,0,0 origins, etc). The latest one can't even export bounding boxes (necessary for visibility calculation). It's also terribly inefficient for 1-5k tri animated characters (which I would have been doing)


IQM existed for years and has matured well enough to work well where it is supported (i.e. not ioq3) and there's no corporate deadlock on it. The only places I've seen ruling against it are 2.5D shooter communities...probably in fear of using something outside of Milkshape's stock exporter list, not familiar on why the IQM format was made in the first place.

[Mark]

Well if a staple of the communities and games like md3 has gotten left behind and now glitches in importers and exporters of major programs, whats to stop the same broken support for the lesser known IQM from happening as new versions of those major programs are released? No format is safe. We have no guarantees of third party people keeping the importers and exporters up to date.

[Tea Monster]

... Which is why you should stick with something that everyone else uses. There will be more tools, more exporters, even more tutorials.

If you have a problem with IQM, you can go on Google and the response will be "Huh? What's that?"