Fbx,obj,3ds, basically any normal formats

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Fbx,obj,3ds, basically any normal formats

Re: Fbx,obj,3ds, basically any normal formats

by Apeirogon » Thu Jan 17, 2019 5:27 am

Ahhh...
I thought it already time when you dont need to create wall of text in modeldef to make simple animations from two steps.

Re: Fbx,obj,3ds, basically any normal formats

by dpJudas » Wed Jan 16, 2019 7:54 am

No, I abandoned that thing. Short version is that I changed my mind and decided the iqm format is a good enough fit. There's nobody actively working this, though.

Re: Fbx,obj,3ds, basically any normal formats

by Apeirogon » Wed Jan 16, 2019 7:33 am

Ahem...
This gzdoom model format still on development?
Because the search for the "model" keyword through gzdoom github repository finds nothing relatively new, only handling for unreal engine models.

Re: Fbx,obj,3ds, basically any normal formats

by Apeirogon » Thu Jun 07, 2018 11:22 am

So, new model format will be in the next gzdoom version, right!?
Just to know, I must wait a little and push bunch of models in new format, with bones and animations, or try to "have night full of love" with converting them to md3 format.

Re: Fbx,obj,3ds, basically any normal formats

by wildweasel » Fri May 18, 2018 11:52 am

Apeirogon wrote:Anyway, where I can get zdml converter, to play with bones and animations, if it now avaliable for the general public?
Or only after new stable gzdoom release?
As I understand it, the format is still being developed.

Re: Fbx,obj,3ds, basically any normal formats

by Apeirogon » Fri May 18, 2018 11:40 am

Graf Zahl wrote:GZDoom isn't Quake 3
...but it would be nice, if gzdoom have something from quake 3.

Anyway, where I can get zdml converter, to play with bones and animations, if it now avaliable for the general public?
Or only after new stable gzdoom release?

Re: Fbx,obj,3ds, basically any normal formats

by Rachael » Fri May 18, 2018 2:13 am

Graf Zahl wrote:Ironically, yesterday somebody was complaining on Github about including the Unreal model submission!
Seriously, people! It's great that some people are willing to add support for other formats. Even if it may not be that wildly used, if it just gives people the option to use such files if they have them is a plus.
What in the goddamn hell? I had to actually look for it, but sure enough, there it was. In the interest of not tossing more kindling on the fire, I did not respond to that directly on that Github thread, but I don't think I have to say how nice I would NOT have been to that guy. I am VERY disappointed in him, who until now I once considered to be very reasonable.

The point to include UE1 model support is "because we want to." It's the same reason we mod Doom, go to work/school every day, and argue over pointless shit like this.
Graf Zahl wrote:For bone models the most important step is to get them in in the first place! Once the feature works it is time to see if other existing formats can be used as well. But having those formats for other engines dictate the limitations of model support is just insane. GZDoom isn't Quake 3, it also isn't Sauerbraten. It has different needs and different limitations imposed by how Doom works. So a new model format needs to be able to work in that framework - and if that requires a custom format, so be it!

And please think about why there currently is no bone model support! The fact that all potential formats come from other engines and do not translate well to Doom is a big part of it.
Well said.

Re: Fbx,obj,3ds, basically any normal formats

by Graf Zahl » Fri May 18, 2018 1:17 am

Ironically, yesterday somebody was complaining on Github about including the Unreal model submission!
Seriously, people! It's great that some people are willing to add support for other formats. Even if it may not be that wildly used, if it just gives people the option to use such files if they have them is a plus.

For bone models the most important step is to get them in in the first place! Once the feature works it is time to see if other existing formats can be used as well. But having those formats for other engines dictate the limitations of model support is just insane. GZDoom isn't Quake 3, it also isn't Sauerbraten. It has different needs and different limitations imposed by how Doom works. So a new model format needs to be able to work in that framework - and if that requires a custom format, so be it!

And please think about why there currently is no bone model support! The fact that all potential formats come from other engines and do not translate well to Doom is a big part of it.

Re: Fbx,obj,3ds, basically any normal formats

by Rachael » Fri May 18, 2018 12:58 am

Alright, enough with the file format drama. dpJudas is being very nice giving us what we're getting here and that's that. Blender is cross-platform and the script will be able to handle it - so simply import your work into blender and export it with the exporter that we'll be getting.

I really don't want to, a year from now, be lamenting not getting nice things just because a year ago we were so fucking busy bikeshedding over this and driving GZDoom's primary feature developer away. If you want GZDoom to recognize other formats, YOU code them in!

Re: Fbx,obj,3ds, basically any normal formats

by dpJudas » Thu May 17, 2018 10:30 pm

leileilol wrote:Eventually IQM was created for both Darkplaces and Cube 2
So they created a second custom model format. Exactly how is that different from what I'm doing? Oh, right, there is no difference.

Re: Fbx,obj,3ds, basically any normal formats

by leileilol » Thu May 17, 2018 5:01 pm

GZMDL sounds like repeating history to me.

About a decade ago, Darkplaces already went down this DPM/ZYM model path (a custom model format of its own that almost nobody ever used (really early Nexuiz builds only used it)), then a push for an existing format was done (UnrealEngine2 PSK) but barely anyone used that and that also had issues (especially regarding split edges). Eventually IQM was created for both Darkplaces and Cube 2 and that resolved a lot of issues regarding asset creation, since well.... it doesn't depend on Maya or Milkshape to produce SMDs and PSKs for a tool to use. :shucks:

Also doesn't FBX have some restrictive usage rights applied?

Re: Fbx,obj,3ds, basically any normal formats

by dpJudas » Thu May 17, 2018 2:13 pm

Apeirogon wrote:Also, dpjudas, you create standalone fbx-gzdoom model format converters AND blender import-export script?
That's the plan, yes. I already wrote a FBX->ZMDL converter and Gutawer offered to write a Blender export script.

Re: Fbx,obj,3ds, basically any normal formats

by Apeirogon » Thu May 17, 2018 1:53 pm

Dpjudas right, every engine use its own model format.
You can look into any game which supports "deep" modding, like stalker, half life, dawn of war, or any other game from first page of most popular mods on mod db, you see that they use its own format/s.

Also, dpjudas, you create standalone fbx-gzdoom model format converters AND blender import-export script?
Because, for some reason, how I would not try blender always corrupt fbx files which I convert in 3d max.

Re: Fbx,obj,3ds, basically any normal formats

by dpJudas » Thu May 17, 2018 9:00 am

There seems to be some misconception here that I'm willing to implement any format. My position is that writing my own simple format is the easiest way to get a better model format (format is already 95% done by the way). I've given my reasons in the past, but I can summarize it as me preferring a format specifically tailored for the engine than a generic format that the engine needs to adapt to. If proper FBX and Blender converters are written such a format is just as good as any other format.

I do not like universal exchange formats because generic is incompatible with being specific. If a model format supports a specific layout, and that layout is unsuitable for the engine, then it becomes the engine's problem at load time. I.e. IQM allows the normals to be missing - suddenly the engine now needs to try create that as it is actually a requirement for GZDoom to have normals. What if the UV coordinates are missing? IQM allows that too. Sure, you could declare that a IQM model must have UV coordinates in float format to be a valid mesh, but now suddenly the generic format isn't so generic anymore and the converter creating the IQM file can't just create it any way it wants to. Then add a standard where 100 people gets to play chef and before you know it you're fighting one of those beasts like Windows Communication Framework that can theoretically send web services over pigeons, but in actuality only works if everything is in a specific undocumented configuration - that's what COLLADA became. Will that be the fate of GLTF too? I don't know, but I am sure as hell not going to be one of those bleeding trying it out. When it is a generally accepted and used exchange format by all the major modelling tools and major game engines, maybe THEN it is time for a hobby game engine like GZDoom to use it.

This is just my 5 cents. Feel free to disagree with my position. Anyone else is more than welcome to write model loaders for other formats (assuming Graf accepts the PRs), but I won't be the one doing the work.

Re: Fbx,obj,3ds, basically any normal formats

by HAL9000 » Thu May 17, 2018 7:20 am

@Chris, I agree with your suggestion, Imo I personally think that GLTF is perfect file format.
More and more 3Dsoftware and companies (natively) support this file format.
It is easy to use and it is universal.Better option than FBX, IQM,or classic MDL/MD2/3 or some other "custom made format" made with converted FBX


With GZDoom's PBR support GLTF is perfect.
I just wonder how hard is to implement this into GzDoom.
Maybe Graf Zahl could give us some opinion on this?

I don't mind using MD3 atm though, I perfected my workflow for Animated MD3 and it's working just fine for me.
The only problem I have is the lack of proper Hitboxes/Hit detection.

Top