(to devs) md2 vs md3
#1
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)

[Image: snowo.png]

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.
Thanks given by:
#2
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. :(
Thanks given by:
#3
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.....
Thanks given by:
#4
He's suggesting to change the whole AC package to md3. From the points made it's a no brainer. F1!
Thanks given by:
#5
Read my post again, you must have missed something.
Thanks given by:
#6
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?
Thanks given by:
#7
(16 Dec 11, 03:16PM)Mael Wrote: 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 <<<

(16 Dec 11, 03:16PM)Mael Wrote: 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.

Thanks given by:
#8
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.
Thanks given by:
#9
Do we gain some FPS?
Thanks given by:
#10
(16 Dec 11, 05:05PM).ExodusS* Wrote: Do we gain some FPS?

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

Thanks given by:
#11
The gain is actually a loss ;-) -- the AssaultCube package will "weigh" less and take less time to download.
Thanks given by:
#12
(16 Dec 11, 08:42PM)V-Man Wrote: 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. :)
Thanks given by:
#13
Much to the chagrin of tipper and GeneralDisarray. :-(
Thanks given by:
#14
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?
Thanks given by:
#15
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.
Thanks given by:
#16
Any chance .obj will be supported by AC?
Thanks given by:
#17
Hm, as it exists in Cube2, I'd say yes :)
Thanks given by:
#18
@ 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)
Thanks given by:
#19
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?
Thanks given by:
#20
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.
Thanks given by:
#21
After a few experiments conclusions are that, "barrel" model used as example:

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



Thanks given by:
#22
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).
Thanks given by:
#23
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
Thanks given by:
#24
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.
Thanks given by:
#25
Might save you some bandwidth on the downloads :P
Oh wait nevermind I forget the game's on Source Forge (?)
Thanks given by:
#26
I have this exact same problem cleaner with the md2 files when importing to Blender, I completely agree.
Thanks given by:
#27
(21 Dec 11, 12:30PM)Mr.Floppy Wrote: 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.

(21 Dec 11, 12:30PM)Mr.Floppy Wrote: 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.

Thanks given by:
#28
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.
Thanks given by:
#29
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.
Thanks given by:
#30
(18 Jan 12, 11:22AM)DES|Cleaner Wrote: 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.
Thanks given by: