Fbx,obj,3ds, basically any normal formats
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49074
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Fbx,obj,3ds, basically any normal formats
Reading the commit log may give you some enlightenment.
Re: Fbx,obj,3ds, basically any normal formats
So it already in dev build!?
This looks very promising,
Take off my hat, as a sign of respect.add bone animation support to models
This looks very promising,
- leileilol
- Posts: 4449
- Joined: Sun May 30, 2004 10:16 am
- Preferred Pronouns: She/Her
- Location: GNU/Hell
Re: Fbx,obj,3ds, basically any normal formats
if I saw this thread earlier i'd say something evangelizing IQM a bunch because:
- Free open source format with no crazy legal encumberances
- Lightweight (no big DLLs or really long pieces of code necessary)
- Skeletally animated
- a very very very solid blender pipeline where blender has no problems exporting to it because the author knows how to write an export script (when you're an artist not giving into the autodesk monopoly this is a big plus)
- a smd->iqm pipeline also exists for Source lovers
- Noesis can also perfectly convert to it
- Made for game engines ("normal formats" and big bloated broken exchange formats like FBX and DAE won't help you here)
But the "QUAKE!!!" part and "Where iqm models for download" probably turns off some. Yes it's true that you can't find 300k poly IQM models from Turbosquidwhatever and yes it's true it's relatively unknown because it's not backed by Autodesk.
- Free open source format with no crazy legal encumberances
- Lightweight (no big DLLs or really long pieces of code necessary)
- Skeletally animated
- a very very very solid blender pipeline where blender has no problems exporting to it because the author knows how to write an export script (when you're an artist not giving into the autodesk monopoly this is a big plus)
- a smd->iqm pipeline also exists for Source lovers
- Noesis can also perfectly convert to it
- Made for game engines ("normal formats" and big bloated broken exchange formats like FBX and DAE won't help you here)
But the "QUAKE!!!" part and "Where iqm models for download" probably turns off some. Yes it's true that you can't find 300k poly IQM models from Turbosquidwhatever and yes it's true it's relatively unknown because it's not backed by Autodesk.
Re: Fbx,obj,3ds, basically any normal formats
What About GLTF?
https://www.khronos.org/gltf/
glTF (GL Transmission Format) is a royalty-free specification for the efficient transmission and loading of 3D scenes and models by applications. glTF minimizes both the size of 3D assets, and the runtime processing needed to unpack and use those assets. glTF defines an extensible, common publishing format for 3D content tools and services that streamlines authoring workflows and enables interoperable use of content across the industry.
https://www.khronos.org/gltf/
glTF (GL Transmission Format) is a royalty-free specification for the efficient transmission and loading of 3D scenes and models by applications. glTF minimizes both the size of 3D assets, and the runtime processing needed to unpack and use those assets. glTF defines an extensible, common publishing format for 3D content tools and services that streamlines authoring workflows and enables interoperable use of content across the industry.
- Dark-Assassin
- Posts: 742
- Joined: Thu Mar 19, 2009 3:40 am
- Location: South Australia
Re: Fbx,obj,3ds, basically any normal formats
The one that supports animations and has a great import/export plugins (or internal) for a range of 3D modeling programs would be the one to go really.
If only obj supported animations... Well, guess I can glare at IQM.
However with all the problems people are having with MD3s, I still use an old Blender with an old MD3 Import/Export plugin that works with animations (even exporting skeletal animations) and doesn't mess things up.
If only obj supported animations... Well, guess I can glare at IQM.
However with all the problems people are having with MD3s, I still use an old Blender with an old MD3 Import/Export plugin that works with animations (even exporting skeletal animations) and doesn't mess things up.
Re: Fbx,obj,3ds, basically any normal formats
And, how about OBJ for Static Models?
They(simple obj sequence) could be animated through actor/modeldef though..
http://quetoo.org Quake2World ditched md2/3 and implemented obj model format
They(simple obj sequence) could be animated through actor/modeldef though..
http://quetoo.org Quake2World ditched md2/3 and implemented obj model format
- Chris
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: Fbx,obj,3ds, basically any normal formats
I already suggested that. But other people seem to want a custom format with a converter from FBX or something.HAL9000 wrote:What About GLTF?
Re: Fbx,obj,3ds, basically any normal formats
@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.
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.
Re: Fbx,obj,3ds, basically any normal formats
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.
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
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.
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
That's the plan, yes. I already wrote a FBX->ZMDL converter and Gutawer offered to write a Blender export script.Apeirogon wrote:Also, dpjudas, you create standalone fbx-gzdoom model format converters AND blender import-export script?
- leileilol
- Posts: 4449
- Joined: Sun May 30, 2004 10:16 am
- Preferred Pronouns: She/Her
- Location: GNU/Hell
Re: Fbx,obj,3ds, basically any normal formats
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.
Also doesn't FBX have some restrictive usage rights applied?
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.
Also doesn't FBX have some restrictive usage rights applied?
Re: Fbx,obj,3ds, basically any normal formats
So they created a second custom model format. Exactly how is that different from what I'm doing? Oh, right, there is no difference.leileilol wrote:Eventually IQM was created for both Darkplaces and Cube 2
Re: Fbx,obj,3ds, basically any normal formats
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!
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!
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49074
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Fbx,obj,3ds, basically any normal formats
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.
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.