(to devs) md2 vs md3

[Cleaner]

If I remember well I already posted this suggestion in the "Ideas" thread but it must have drowned within the mass of propositions...

I would really appreciate that we swap mapmodels format from md2 to md3, the reason for this request is that we do not longer use the Quake2 modeller but more advanced programs like Blender, MilkShape3D aso and for some reason (a_slow_old_man pointed this problem also on his new playermodel topic) on these programs when you import md2 they aren't centred on the axis and thus it becomes a pain for us if we want to work on these models...

Just as an example it took me about an hour just to make the snow model meet the barrel ingame (had to go back and forth from MS3D to edit mode)



One important thing that also should be taken into account here is that md3 models are way lighter than md2, the barrel for instance is 12,1Kb in md2 but only 5,09Kb in md3

In case you folks do us a favour and agree to that I will be more than happy to spend some time converting the concerned models since it would make it easier for us in the future.

[MykeGregory]

I would say F1 to this, i'm no modeller but it seems like it would help...
I remember asking something about player physics ingame a while back (Things like ragdoll)
I think iwas told it was not possible due to this md2/md3 issue. i think i was told it would be possible to have ragdoll physics if the playermodels were md3 format. So there is another possibility for having a change.

EDIT:
http://forum.cubers.net/thread-1522.html
My Mistake. Ragdoll would need md5. :(

[Dementium4ever]

Hm, I don't really understand your problem Cleaner.
You can use md3 if you want, or md2 if you want..
Md2 is just optional.....

[Snoosnoo]

He's suggesting to change the whole AC package to md3. From the points made it's a no brainer. F1!

[Cleaner]

Read my post again, you must have missed something.

[Mael]

If we're going to make the change I'd really like to see a detailed guide to making your own mapmodels in the .md3 format.

Edit: Are you asking that we just change the existing models to .md3?

[Cleaner]

If we're going to make the change I'd really like to see a detailed guide to making your own mapmodels in the .md3 format.

There is a tutorial for Blender >>> Here <<<

Edit: Are you asking that we just change the existing models to .md3?

Indeed, it's only a matter of centring them to the axis and export in md3.

[Dementium4ever]

Oh, ok, changing the existent models to md3.
Yeah, this should happen soon. In the next version maybe?
I'm a volunteer for changing the format, if the devs are going to do that.

[ExodusS]

Do we gain some FPS?

[Cleaner]

Do we gain some FPS?

Nope, it would only save about 500kb on the whole package

[V-Man]

The gain is actually a loss ;-) -- the AssaultCube package will "weigh" less and take less time to download.

[ExodusS]

The gain is actually a loss ;-) -- the AssaultCube package will "weigh" less and take less time to download.

So we can forgget about the .FLAC sounds. :)

[V-Man]

Much to the chagrin of tipper and GeneralDisarray. :-(

[Mr.Floppy]

Well, Cleaner, that's going to be a lot of boring converting work to do and I'm afraid you're going to face some unexpected trouble here and there.

Though, that's not a bad idea in general. In fact, the .md2 format is quite weird and it seems like every editor "interpretes" it differently. Therefore I'd say, give it a go if you've got some time on hand. In the end, you could just focus on models, which are most likely taken for any sort of modification.

On a site note. I always wondered whether static models, read not animated models, need an animate-able format. Is there something like a real simple/thin model format, which is broadly supported by editors?

[tempest]

There's OBJ, it doesn't support animations, but I wouldn't say it's much simpler. However, it's a standard format and widely supported.

[Mr.Floppy]

Any chance .obj will be supported by AC?

[Dementium4ever]

Hm, as it exists in Cube2, I'd say yes :)

[Cleaner]

@ Floppy, don't you worry about the time it would eventually take since it will eventually also take 'some time' before the next version to come out XD

Honestly I think one small bit of the community will benefit from it and the other part won't even notice the changes but I do believe that for the reasons stated above it is well worth the effort.

About format, my guess is that keeping just a single valid format for both static/animated models is wise unless there is real advantage to turn to another one like OBJ or so (dunno about that, haven't compared it and not even sure our engine will swallow it)

[Mr.Floppy]

Well, as far as I know .obj is supported by Blender without additional scripts. In fact .obj is supported by default on MilkShape and Ultimate Unwrap. I guess it would make things a little easier for modellers, since you won't have to mind the at-least-one-frame thingy form the .md formats. ;)

If it could be implemented easily, I would be happy to use it. In case it would require the revision of fundamentals of the rendering code, then I'd say we rather stick to .md format, rather than creating another bunch of bugs. ;)

Tempest, what's your opinion on that?

[tempest]

Wouldn't be that hard to do, although I believe Sauer's code has diverged too far to be of much use except for reference.
Just don't rely on me, I'm way too busy until February at least.

[Cleaner]

After a few experiments conclusions are that, "barrel" model used as example:

obj = 15ko
md2 = 13ko
md3 = 6ko

[tempest]

Of course it's a little fat, it's a plain-text format. What surprises me though is that it's not significantly larger than md2. Yes, it would increase the size of the download, whereas md3 would decrease it (however, I'd have to do some tests on how effective compression is on those rather repetitive plain-text files).

[SKB]

Yeah, Cleaner, if you can, gzip all those models and then compare the sizes. IIRC gzip is already implemented in ac, so whichever comes out the lowest should win. :D

[Mr.Floppy]

Oh, didn't expect the file sizes to be that volatile from format to format, to be honest.

Decreasing the load by 50%, while "simply" switching from .md2 to .md3 is quite a hit. Though, I'm not sure about the total impact on download size, given the amounts of models isn't that huge and the skin files surely go by higher bit values, don't they?

Besides that, my main argument for .obj is maintaining compatibility to as much editors as possible. Therefore, getting rid of .md2 in the long run,sticking to .md3 for animated models, whilst providing an easy to use static format. That's the idea. You still can use .md3 for static models, of course, but if one's troubling with this format he can easily use the idiot-proof .obj as well. ;)

However, that's not a matter of urgency, at all. Let's just keep that in mind for a future release. Until then Cleaner can look into converting the stuff into .md3, I'd say.

[Felix-The-Ghost]

Might save you some bandwidth on the downloads :P
Oh wait nevermind I forget the game's on Source Forge (?)

[Viper]

I have this exact same problem cleaner with the md2 files when importing to Blender, I completely agree.

[Cleaner]

skin files surely go by higher bit values, don't they?

In the octet hunt skins used by multiple mapmodels (like can & can2, barrel & barrel2 for example) could be send onto the textures folder and just add the loadskin command in the .cfg file.

Besides that, my main argument for .obj is maintaining compatibility to as much editors as possible. Therefore, getting rid of .md2 in the long run,sticking to .md3 for animated models, whilst providing an easy to use static format. That's the idea. You still can use .md3 for static models, of course, but if one's troubling with this format he can easily use the idiot-proof .obj as well. ;)

The .md3 format is (as far as I know) compatible with all 3D editors, is of very simplistic handling and files are way lighter than .obj, but then again I've never worked with .obj so I can't say if it's implementation would definitely be a plus.

[SleepKiller]

Blender does not suuport .md3 without a plugin and I've yet to meat an editor that needs a plugin for .obj. Heck some game engines support converting their specilized format models to .obj.

[Cleaner]

Right! Almost done, only a few bits and pieces and tests left to do and that's it.

So far it's 60% lighter than before and while we're at it there is another issue I found out whilst going through all these files...

Quite a few mapmodels are actually using the same skin.jpg files, barrel and barrel2 for example have both the exact same image file in each folder.
A significant amount of Kb could be save here if we could only use a single image file for multiple mapmodels.

I was thinking of something like (I've seen this in other games) having a "mapmodels" folder in the textures folder(*) and using a command in the model's cfg like "loadskin textures/mapmodels/barrel skin.jpg"

I have searched the docs to find something about it without success, if this is feasible I will happily fix that as well while I'm finishing sorting the conversions.


(*) Or a "textures" folder in the mapmodels folder whatever as long as it compiles all the images folders.

[Mr.Floppy]

I was thinking of something like (I've seen this in other games) having a "mapmodels" folder in the textures folder(*) and using a command in the model's cfg like "loadskin textures/mapmodels/barrel skin.jpg"

Have you tried whether the loadskin command would work like that. Like the barrel2 model will load the barrel(1) skin from it's folder?

If that worked (I doubt somehow, as usually it only scans the actual folder for files) removing the redundant skin file won't be a big deal. Though, I haven't thought through all aspects about this yet, to be honest.