Author Topic: Model formats  (Read 3098 times)

0 Members and 1 Guest are viewing this topic.

motorsep

  • Hero Member
  • *****
  • Posts: 905
  • Karma: +72/-126
  • Artist
    • View Profile
    • Kot in Action Creative Artel
Re: Model formats
« Reply #15 on: May 28, 2015, 04:17:58 PM »
maybe another possibility is to add a new model format for specific situations and left md5 for skeletal animation models, create something like a md7 format with vertex weights and vertex blending targets, for the facial animation of the characters and other uses that go beyond the possibilities of md5, maybe even enhance the md5 with those features and then call it md7, so no compatibility is lost for existing mods, and newer mods and TCs can use md7 for everything.

It would be much easier to add (if not already existing) a version to MD5 files, and if version is whatever it is now (or no version in the file' header) then use original code path for MD5. If there is "version 2" (or whatever it might be) in the header of MD5 files, use code with support for vertex colors and such.

This way it's less work to implement and it will avoid massive code duplication. And keeps backward compatibility. Blender exporter would have to be enhanced with new features too.

Does FBX include some sort of compression? or is it binarized in some way?

There are 2 versions exist, ascii and binary.  Blender exports both. You can't use FBX for real-time game engines as it's not designed to be efficient for real-time rendering (or rather you can, but it will be incredibly inefficient and ugly :) ).

BielBdeLuna

  • Full Member
  • ***
  • Posts: 242
  • Karma: +8/-20
  • Doom Newbie
    • View Profile
    • my Github repositories
Re: Model formats
« Reply #16 on: May 28, 2015, 04:40:36 PM »
I guess that in a 3D format that aims to be used in a real time environment the most important thing is efficiency in uploading it to the GPU isn't it?

what would be the best way to have an open format, that we could create, that we could left the door open in order to support future features?

maybe an ascii format that in the future someone could alter it's written tokens in order to expand it's functionality? or maybe we could use an ascii format that when we distribute we could binarize, and so the importance form the point of view of future features could be in the importing of that ascii code and binary code? idk, what are your ideas guys? 

motorsep

  • Hero Member
  • *****
  • Posts: 905
  • Karma: +72/-126
  • Artist
    • View Profile
    • Kot in Action Creative Artel
Re: Model formats
« Reply #17 on: May 28, 2015, 06:54:26 PM »
I guess that in a 3D format that aims to be used in a real time environment the most important thing is efficiency in uploading it to the GPU isn't it?

RAM and VRAM

what would be the best way to have an open format, that we could create, that we could left the door open in order to support future features?

You don't need to create one :) MD5 is a good format for the engine. Expanding it shouldn't be hard. There are also IQM (which has its cons) and OpenGEX (http://opengex.org/)

The (major) problem you are facing implementing those is that the engine is designed for MD5 and implementing something else will be tedious and complex. At the end you'll probably look back and wonder why didn't you expand MD5 instead ;)

maybe an ascii format that in the future someone could alter it's written tokens in order to expand it's functionality? or maybe we could use an ascii format that when we distribute we could binarize, and so the importance form the point of view of future features could be in the importing of that ascii code and binary code? idk, what are your ideas guys?

Again, MD5 is ascii, well documented / researched and BFG engine binarizes it. IQM is the same way except there is external tool to binarize ascii version, or Blender writes binary right away. Note that neither Maya nor Max nor anything else support IQM.

EDIT: Just remembered that IQM comes with FBX to IQM converter. It could be a good foundation for FBX to MD5 converter.
« Last Edit: May 29, 2015, 12:12:11 AM by motorsep »

trebor

  • Jr. Member
  • **
  • Posts: 94
  • Karma: +14/-7
  • Boomstick Veteran
    • View Profile
Re: Model formats
« Reply #18 on: May 29, 2015, 06:15:27 AM »
MD5 is a good skeletal model format. Is easy, fast to render and simple to implement. It only lacks support for custom normals to support smoothing groups and LOD information.
Adding support for custom normals should be easy.

motorsep

  • Hero Member
  • *****
  • Posts: 905
  • Karma: +72/-126
  • Artist
    • View Profile
    • Kot in Action Creative Artel
Re: Model formats
« Reply #19 on: May 29, 2015, 09:13:25 AM »
MD5 is a good skeletal model format. Is easy, fast to render and simple to implement. It only lacks support for custom normals to support smoothing groups and LOD information.
Adding support for custom normals should be easy.

Why would you want support for custom normals? Currently engine reconstructs normals based on the normal map.

So for example, if you want a flat sided cube, simply make exported model all smooth, and "hi-res" model (same low poly cube) flat, and bake normal map. In-game the cube will appear flat, as if you had 6 smoothing groups.

I wanted custom normals too, but then I figured out how to make that with basic normal maps without going for actual hi-def meshes and I don't think I need it any longer :)

BielBdeLuna

  • Full Member
  • ***
  • Posts: 242
  • Karma: +8/-20
  • Doom Newbie
    • View Profile
    • my Github repositories
Re: Model formats
« Reply #20 on: May 29, 2015, 06:54:04 PM »
maybe with custom normals you could do without normal maps in some specific models.
also with custom normal maps you could do convincing polygonal trees with flat surfaces but modified normals, isn't it?

motorsep

  • Hero Member
  • *****
  • Posts: 905
  • Karma: +72/-126
  • Artist
    • View Profile
    • Kot in Action Creative Artel
Re: Model formats
« Reply #21 on: May 29, 2015, 10:10:55 PM »
maybe with custom normals you could do without normal maps in some specific models.
also with custom normal maps you could do convincing polygonal trees with flat surfaces but modified normals, isn't it?

Correct. Custom normals are only needed in cases where don't use normal maps. So it's pretty much irrelevant nowadays.

What I am saying you can make 2 low poly models. One with smooth normals that will be exported for the engine use, and one with modified normals. Bake normal map using modified normals model as "hi-poly" and bake active to selected in Blender. A low poly with smooth normals and that normal map will appear as if it has no normal map and custom normals in-game.

The biggest benefit is that there is no need to do invasive and potentially breakage-prone changes to the engine, and still have the look you are after.

BielBdeLuna

  • Full Member
  • ***
  • Posts: 242
  • Karma: +8/-20
  • Doom Newbie
    • View Profile
    • my Github repositories
Re: Model formats
« Reply #22 on: May 30, 2015, 10:50:12 AM »
maybe for trees we could use a height map for the leaves and use the normal map of the method you described for the actual distortion of the planes of the tree that conform the leaves textures?

BielBdeLuna

  • Full Member
  • ***
  • Posts: 242
  • Karma: +8/-20
  • Doom Newbie
    • View Profile
    • my Github repositories
Re: Model formats
« Reply #23 on: May 30, 2015, 10:53:02 AM »
but anyways if we could gain that functionality would be even better,so we could have even more options, and introducing new stuff to the engine can always be an interesting challenge, the troubles doesn't scare me, if any, with time can be sorted out.

The Happy Friar

  • Happy Happy Joy Joy
  • Administrator
  • Hero Member
  • *****
  • Posts: 772
  • Karma: +30/-4
  • Semi-Newbie.
    • View Profile
    • EarthQuake
Re: Model formats
« Reply #24 on: May 30, 2015, 11:09:50 PM »
(also because modders dropped the ball on most of idTech based games; and artists need programmers)

I missed a lot in a couple days.  :p 

The only idTech games that almost never has anything new is Doom 3/Rage.  Doom, Quake, Q2, & Q3A have new content at least monthly.  D3 has almost nill (Bladeghost & Oneofthe8devils keep on trucking!).  I just want to say it's because of the "entry barrier" for content but I don't believe that.  I belive it's what you (Motorsep) said: people just don't want to work with modern idTech engines any more, they want UDK/Unity instead.

2.48 dates back to 2008. In 'CG Time', that is about 50 real years old. The basic Blender file format isn't compatible unless you save as. Also, all the colour directions of normal maps are backward to everything else. It's a pain in the ass.

Yet more Doom 3 content was made then vs now, so nothing new has helped D3 modders.  It's sad really: in the Blender 2.48/9 era we learned show much about the D3 engine and once people learned how to make content they didn't.

motorsep

  • Hero Member
  • *****
  • Posts: 905
  • Karma: +72/-126
  • Artist
    • View Profile
    • Kot in Action Creative Artel
Re: Model formats
« Reply #25 on: May 31, 2015, 11:01:12 AM »
It's really about how much stuff was made with the engine. There were only 3 single player games made using idTech 4 in its pure form - Doom 3 and XP, Quake 4 and Prey. Wolf used D3D renderer for single player and was not moddable. Brink and ETQW failed miserably as game experience goes, thus whatever crowd they attracted didn't have enough modders to push through. Brink was not moddable on top of that. Plus when all those games came out (except Brink maybe), the hardware requirements were steep. Hell, I had to play Prey in 320x240 just to get decent framerate (which dipped badly in places).

idTech 4 definitely requires higher skill level than old Quakes and Dooms. Not to mention there are no good tutorials that can be used to get you mod up and running.

There are still folks who fiddle with old Doom 3 and Doom 3 BFG on Steam (and least trying to get mods running with BFG), but there is no organized force behind it.

Nowadays, to bring Doom 3 modding back, Doom 3 BFG has to become moddable out of the box; MAX/Maya need working exporters (or someone needs to make FBX > MD5 tool based on FBX >IQM app) with tutorials and examples of how to use it; new quality tutorials need to happen on YouTube with some well organized wiki with examples; small content pack to help modders to jump start modding. One useful thing that will not happen is Steam Workshop. Having that would help a lot bringing idTech 4 modding back to life.

I am not going to get into importance of tool development :) It's a waste of time when there is no larger active community modding any game.

The Happy Friar

  • Happy Happy Joy Joy
  • Administrator
  • Hero Member
  • *****
  • Posts: 772
  • Karma: +30/-4
  • Semi-Newbie.
    • View Profile
    • EarthQuake
Re: Model formats
« Reply #26 on: June 09, 2015, 08:21:29 AM »

motorsep

  • Hero Member
  • *****
  • Posts: 905
  • Karma: +72/-126
  • Artist
    • View Profile
    • Kot in Action Creative Artel
Re: Model formats
« Reply #27 on: June 09, 2015, 09:03:46 AM »
iqe/iqm & md5 converter/creator: http://www.moddb.com/mods/r-reinhard/addons/iqebrowser-v210

Nice one, except "Any 3D model can be saved as IQM (a binary format) or IQE (a text format) file". So it's no use, since it won't save as MD5 format :(

The Happy Friar

  • Happy Happy Joy Joy
  • Administrator
  • Hero Member
  • *****
  • Posts: 772
  • Karma: +30/-4
  • Semi-Newbie.
    • View Profile
    • EarthQuake
Re: Model formats
« Reply #28 on: June 09, 2015, 09:56:16 PM »
Ok, I guess I should of typed more.

It's another reason to support IQM/IQE in id games vs other model formats.  If that format was supported in every id GPL engine then all the engines could use the same assets and most common formats could be converted for use.

MrC

  • Newbie
  • *
  • Posts: 49
  • Karma: +6/-22
  • Doom Newbie
    • View Profile
Re: Model formats
« Reply #29 on: July 22, 2015, 01:44:13 PM »
Sorry if replying to this topic is like picking at an old head wound but it seems too big an issue which stems throughout the community as a whole when you think about it, if getting content into an engine is a major pain no one is going to even consider it especially when it doesn't seem to work right anyway, like us poor max users, hell even setting up Maya (which is the engine's native asset pipeline turned up nothing but dissapoint. I applaud the work over at TDM for getting that to work and supporting that pipeline, maybe it's something I should try again but I'd really rather export once, even if that means running command-line stuff as an intermediary step hence why I love the idea of IQM, mostly the fact that it compiles from major supported formats, sure there's an extra step in between (unless you use IQE) but I'd rather export to FBX or even SMD and you at least have options across the board plus that's what batch files are for so it's just as easy as hitting export, run batch->run's game and you're already in-game testing (basically what exportmodels does).

Unfortunately there are only a handful of people capable of implementing IQM properly afaik and even then where does it actually get implemented? Just in a vanilla offshoot? Just in BFG? Both? I guess this is where having one major community fork would have been great but that just never seemed to happen, it was looking good at first with the CDK but I guess that died or never happened, or maybe it was a joke, who knows.

Also, sorry for the tone if I'm coming across as hostile, just feels like someone took a big piss in my cornflakes this morning after trying to get an animated model into doom 3, mostly with what started as a shits and giggles sort of thing but then vibrations got nasty and soon a seemingly simple task became a puzzle and then a mission, and before I knew it I felt like I was climbing fail mountain barehanded and buck nude. Also the model worked fine in UE4, Unity, and Source.

Anyway after all this I suppose my question would be is the dream of seeing some sort content importing like IQM dead or has this happened/happening still and I just couldn't find it anywhere?

Alternatively, are there any new MD5 exporters for Max 2014 that work by any chance? Any other Max users here that have found a process that works relatively painlessly?