(to devs) md2 vs md3

[Think3r]

Cleaner why not open the md2 model save it as md3 model on milkshape and then edit the md3?

[tempest]

EDIT: Oh wait...

You can add something like [cubescript]md3skin * "../barrel/skin.jpg"[/cubescript] to the md3.cfg. For example, if you do this in "models/blabla/md3.cfg", it will load "models/barrel/skin.jpg".

[Cleaner]

Though, I haven't thought through all aspects about this yet, to be honest.

Please do so, maybe there is some coding involved since i'm struggling to get this working.

Cleaner why not open the md2 model save it as md3 model on milkshape and then edit the md3?

I have already converted all md2 models onto md3 and thus obviously experimenting this with md3

You can add something like [cubescript]md3skin * "../barrel/skin.jpg"[/cubescript] to the md3.cfg. For example, if you do this in "models/blabla/md3.cfg", it will load "models/barrel/skin.jpg".

I have tried a few md3skin commands in the cfg but it doesn't seems to work although I don't get any error messages on the console, I keep trying tho.

EDIT: I will also try with naming the material skin.jpg within MilkShape.

[Mr.Floppy]

Cleaner, it works exactly like tempest wrote. I've just tried. ;)

- edit -

I had another think-through and I can't see no problem using one skin for any derivate, as long it's "linked" to a model contained in the official package. In fact, it should become the standard method in order to kill redundants.

Just to take up on the example from your very first post in here. You should assing the "official" skin to the barrel mesh and only add the snow texture to your package.

[Cleaner]

I had another think-through and I can't see no problem using one skin for any derivate, as long it's "linked" to a model contained in the official package. In fact, it should become the standard method in order to kill redundants.

Just to take up on the example from your very first post in here. You should assing the "official" skin to the barrel mesh and only add the snow texture to your package.

Needless for me to say that the whole shubbeng was converted based on the latest SVN version, sorry for me bringing up a custom screenie in the discussion.

Next I will get in touch with tempest so that he can explain me his trick because as far as I went in fiddling commands in cfg I couldn't avoid "path to the texture is recursive to the location of the md3.cfg" dilemma

[Cleaner]

Ok, thanks to tempest who explained me the "../" get out directory it is sorted.

[Cleaner]

94 of the mapmodels are now converted into md3.

Just to make sure everything is fine I now need another pair of eyes to double-check them and report to me if/when you notice a bug.

>>> Download converted mapmodels <<<

Thanks in advance for helping.

[Cleaner]

OK! I have personally checked, double checked and triple checked the whole shubbeng...

barrel2 skin fixed
bench axis fixed
cleaner...rails...railsbent axis fixed
...railsstraight blending fixed
dumpster cfg fixed
elektro axis fixed
gastank axis fixed
ladders x7 axis fixed
x8 axis fixed
x10 axis fixed
x11 axis fixed
x15 axis fixed
ladderx15_center3 axis fixed
laptop1 skin fixed
locker axis fixed
gutter_v axis fixed
minelift skin fixed
nocamp uv mapping fixed
picture1 axis fixed
sail axis fixed
snowsail axis fixed
strahler axis fixed
signs arab axis fixed
biohazard axis fixed
caution axis fixed
flammable axis fixed
maint axis fixed
speed axis fixed
Toca milkcarton skin fixed
powermeter axis fixed
secucam animation fixed
wallmount axis fixed

The whole package is now reduced to a third, from the original package 23Mb it is now down to only 7Mb.

>>> Download it here <<<

One slight problem remain for which I haven't got no idea on how to fix it right now so any help or clues will be pretty much appreciated.

Actually they are only 3 models that show the texture on certain maps but not on others...

- toca/milkcarton texture don't show on ac_werk (not really a problem since you hardly see this model).
- toca/stairs texture don't show in ac_ingress

but even more intriguing is in ac_depot, texture on same model (ladder) shows in CLA base but not in RVSF base.

I might have missed something but tbh I am a little confused about these 3 problems so if anyone can check these out for me and come up with a solution I'll buy him a drink.

The only thing I have noticed and that eventually could be the source of the problem is that some map cfg files have been tampered with, I mean some text has been removed/added.

[tempest]

but even more intriguing is in ac_depot, texture on same model (ladder) shows in CLA base but not in RVSF base.

Those are different models, so make sure all the ladder_* models work properly.

[Cleaner]

Right! The ladder problem is sorted, basically when you do repetitive actions sometimes your attention shifts away, it was simply a matter of a space in the cfg file.
../skins/ ladder.jpg instead of ../skins/ladder.jpg

Only 2 problems remain, so please carry on pointing out thing I might have overlooked.


Above download link updated.

[Dementium4ever]

Hm, the maps usually have this "Mapname.cfg.
Maybe there is the problem, with the textures?
I mean you can attach different textures to different models in the editor, and maybe that's why it's not working ;)

[Cleaner]

I don't think that's the case here since these 2 models already have the right fitting texture attached and all that has changed here is the mapmodels skins regrouped in a single folder, it wouldn't then matter if the texture is in the textures folder.

About the toca/milkcarton it shows up fine in ac_power (in the dumpster back of CLA base) but doesn't in ac_werk (on top of the shelves in the left passage way from CLA to RVSF base)

[Lantry]

The milkcarton model in ac_power uses a custom texture "./wotwot/skin/milkcarton.jpg", which is in the textures folder and specified using special texture argument for the mapmodel. This also means that the milkcarton is not working in the default map cfg either. I am not sure why it won't load the default texture, but I think it has to do with the model name specified in md3.cfg, as the path to the model lines up, the model loads, the path to the skin lines up, and the skin itself isn't corrupted or anything. I don't have blender installed but I am doing that now so I can take a look at it.

[Cleaner]

Thanks for helping out Lantry, I've never though of looking in the textures folder and tbh I don't get why it's been made like that, when I came up with the unique skin folder idea I have been advised to keep it in the mapmodels directory, adding to this that this file is pretty much useless since that texture is only slightly darker than the original one.

The main point of this idea -now that the mapmodels conversion is done- is to get rid of useless/redundant heavy image files, as a typical example all Toca's stairs models are using the same skin.


What I also really need to know now is if the devs are ready to approve this packaging method and in that case I will look further into sorting that ac_power "wotwot" packaging.


EDIT... Toca's stairs texture fixed, the only problem now remaining is that milkcarton skin not showing up in ac_werk.

[Cleaner]

Ok, I have moved house and had no internet for a while but this is now fixed and I am back.

I have in the meantime finished with that project so here is the final download link >>> mapmodels converted <<<

The only bit remaining is that milkcarton texture not working in ac_werk but that is cause by a fiddling of the map's .cfg file so i simply suggest to get rid of that mapmodel (you hardly see it anyway) for the next version.

Again I emphasise to the fact that the package is no only 7MB compared to the original mapmodels file at 23MB.

EDIT I had to post this here coz my other thread about a single file for the whole skins package is closed

[Snoosnoo]

That's such a saving, for a game that prides itself on being small file size. Perhaps this will open the possibility of more content for maps! <3 Good Job, Cleaner! Needless to say, I and everyone else should be impressed :P

[Cleaner]

Thanks Snoosnoo, it doesn't mean it is going to adopted though because modellers now gonna have to work a different way...

Thing is with this method within your 3D program you have to give your groups names (or once the model finished regroup all groups and name it as the mapmodel) and then in the md3.cfg tell to what group which image file is related to in in the 'skins' folder.

One thing to be careful to is avoid naming the image file with an existing one, just go in the skins folder to double check it out first.

It is basically very simple but as you know people over here hate changes XD

As packaging goes it is also easy...

packages/models/mapmodels/new item/new item.md3
/new item.cfg
packages/models/mapmodels/skins/new item.jpg

As explained in my other post with this method we can re-use existing mapmodels and modify they shapes (like crushed, torn, bumped) without having to add the heavy image file, we can also have new mapmodels using existing skins... Mapmodels are very light so this way we could add a hundred more in the official package.

[Snoosnoo]

I can understand this method not being adopted by current modellers, but I can't see the harm in modifying the current mapmodels folder to have these. It'd allow for more content, which to this point has been dismissed due to players disagreeing to increase the file size :)

WeNeedMoreModelzzz

[Dementium4ever]

First of all Cleaner, thank you.
Just as Snoosnoo said, this really carries the spirit of AC :)

I think this group'n'name process is acceptable, especially because it can be done in a few seconds even by beginners ;)

[Mr.Floppy]

Thanks Cleaner and sorry for the late reply. I'm going to have a look at it asap, which still may take a while.

[Cleaner]

@ Snoosnoo, when I meant not been adopted I was more referring to the devs part of it since for modellers it's only a simple matter of an extra 5 minutes job for it to work nice and easy, on the other hand if this process is accepted it will mean a whole lot of shake up in the documentations and also the way the auto-download is going to be handled using this process (for this last bit I am afraid I cannot provide any solutions since it is way out of my range of competences).

@ Dementium4ever it is indeed a piece of cake for any modeller but as explained above not everything is sorted yet.

@ Mr.Floppy, no worries in your own time mate, I am not by here to force this process in but although it's a great deal of improvement if the single 'skins' folder messes up with the auto-download gizmo's and cannot be resolved in a way or another at least the whole mapmodels conversion from .md2 to .md3 already saves quite some space.

At the end of the day, even though it took me quite some brainstorming time to fix this take whatever is of use... it's all yours, as previously said by fellow comrades AssaultCube has a spirit and I am one of them Dedicated Elite Soldier! Amen.

[Nightmare]

the mapmodels file alone takes up over half of AC's file size?

[Ronald_Reagan]

Nope, he is talking just about the mapmodels folder.

[Cleaner]

Indeed I am only talking about the mapmodels folder, that and the textures folder is what are taking most of the space in the game since the rest is all coding and scripting.

Converting the mapmodels to .md3 halved the size of that folder but with compiling all textures in a single folder and by doing so getting rid of redundant image files it got then reduced to less than a third of its original size.

Note that it could also apply to the playermodel and weapons but I'll leave this to a_slow_old_man or Dementium4ever to check out since I am a bit lost when it comes to animations.

[Dementium4ever]

Md2 animations should be easy to convert.
But you'd have to re-write some parts of the engine, as it only accepts .Md2 playermodels.
And this would have to be done for just ONE model. Isn't really worth it in my opinion.

For the weapons: I think 25% of the texture space could be reduced, as the world model always uses the same image as the normal and menu model.
This however could be a impact on the performance of the engine, as it would have to load 7 High-Resolution files, instead of one High-resolution file and 6 small.
I don't know if it's worth it.

But what we could really do, is using just one .jpg file for the world and menu model.
That could save about 35kb of space. Not much, but it would also give a slightly better performance.

[RandumKiwi]

You'll be pleased to know that almost all (only a few haven't for particular reasons) mapmodels are now converted to md3 format in the SVN.

Thanks for all the resources Cleaner.

[Felix-The-Ghost]

You'll be pleased to know that almost all (only a few haven't for particular reasons) mapmodels are now converted to md3 format in the SVN.

Thanks for all the resources Cleaner.

Yeah, I did a checkout when you were initially doing this and freaked out cause none of the mapmodels worked.

Now it's just the sub/ textures (brickwall and sand) I think. Just load some official maps up and read the errors.

[RandumKiwi]

You'll be pleased to know that almost all (only a few haven't for particular reasons) mapmodels are now converted to md3 format in the SVN.

Thanks for all the resources Cleaner.

Yeah, I did a checkout when you were initially doing this and freaked out cause none of the mapmodels worked.

Now it's just the sub/ textures (brickwall and sand) I think. Just load some official maps up and read the errors.

That's just cause I was lazy to fix them right this second.

[Cleaner]

@ Felix-The-Ghost, serious I don't know how to thank you for the many help you provided (not) towards this project.

Some bits and pieces weren't right at the beginning? Man! Have you got any pictures of you when you was first born?

[RandumKiwi]

Because I was lazy, I made this: http://sourceforge.net/p/actiongame/code...pconfig.sh

Now I have less reason to *not* update the map config files.