Archive: My new presets no more fit into 100 kb


23rd October 2006 04:15 UTC

My new presets no more fit into 100 kb
My new presets no more fit into 100 kb.
That's it. My latest presets contain big gmegabuf models /images/animated pictures/video, so no of them can be posted here. "shell" weights 1560 kb.


23rd October 2006 12:13 UTC

dude wtf.. no presets need to be that big :eek:


23rd October 2006 13:00 UTC

then get some webspace


23rd October 2006 16:10 UTC

How big?!
Man, surly they arn't that big when zipped up.


23rd October 2006 16:21 UTC

Obviously none of you have used my Global Variable Manager .ape for loading bitmaps/models.

Due to the cheapness of my implementation the filesizes are typically somewhere between "stupidly big" and "unreasonably huge".

I made a much more elaborate model conversion tool than Model2GVM in the past (which I have since butchered and wrecked) which generated some models with lots of lighting info so that I could make models that looked more realistic. If i remember correctly the highest detail level models that I used became @80Mb as .gvm files. Nice, eh?


24th October 2006 16:18 UTC

Umm.... loading times....

My models for GVM arn't that big, although I have wrote a (crap ish) 3D modeler to make them in. :)


24th October 2006 20:20 UTC

i don't know about gvm files, but 7-zip has an awesome compression ratio for avs and bmp files. i remember shrinking my 80mb avs dir to 9mb with it (rar had 12mb). in the worst case you could still post a yousendit (or any clone) link.


27th October 2006 10:03 UTC

Originally posted by QOALsoft
How big?!
Man, surly they arn't that big when zipped up.
Zip encodes "shell" to 180 kb with normal compression.

Originally posted by QOALsoft
I have wrote a (crap ish) 3D modeler
I have written a modeller too. I had a problem with GVM Tools 0.5 beta Model2GVM, so i needed a tool that could at least offset GVMs and perhaps add new models. "Shell" and "Shell plus" are partly made with that modeller.

27th October 2006 10:25 UTC

7-zip ftw, but iirc not supported on the forums as an upload? if its 180kb as a 'normal' zip it might be under 100kb as a 'best' rar.

The main reason for the enormous size is the bad format.
1.) it stores a model as lines of evallib code, so instead of one vertex with all information filling say (3*3*4 +3*4 +3*4*4 + vertices + normal + 4 material properties) 96 bytes per triangle as would be expected in a binary format we have that each COMPONENT consumes at least the length of assign(gmegabuf(x),x.x); = 24 bytes in reality this will vary for component but this means that a triangle with the same properties as the '96-byte in binary' format will take up 3*24+24+4*24 = 192 bytes. This means nothing for dictionary compression however since all the "assign(gmegabuf(" are ideal for these methods.

2.) Model2GVM and other tools havent been using the 'index method' where each vertex/normal/colour value is stored once in a unique list and "pointers" are stored per vertex etc. Since 3d models are usually closed this means that any one coordinate is used at least twice for vertices on different triangles. Since symmetry is often present in a model too some vertex components will be recycled even more heavily. This is the main difference between .gvm and something like .obj/.3ds, there is no reason why it can't be done in .gvm too but it would be questionable whether the end result file would be smaller since assign(gmegabuf(... is quite lengthy on its own, all the extra copies of that will most likely outweigh the benefits of making a unique list and using references in the first place.

I'm curious why you are writing modellers too... why not use something which someone has already made? e.g 3d studio max (if you like vertical learning curves) or SketchUp (if you like to make models). That is why I made the Model2GVM tool in the first place. :)


27th October 2006 10:33 UTC

"Normal" rar compresses it into 135 kb.
"Best" rar compresses it into 111 kb. Rar posts are not allowed also.

Still too big. And nothing about expanding "Shell".
Reducing it by deletion of some triangles,...*

And why it is so big: it was partly made with some tool other than my tool. I could add 3d primitives like Sphere/Cylinder, and using Cylinder for the floor of "Shell" enviromnent caused it to store 2 cylinder caps, one of which could not be deleted (cause there, vertex couldn't be deleted at all). Also the Shell. It was made from 2 spheres, and it could be 2 times smaller if they were Hemispheres, with less vertex.

"Shell plus" is bigger than "Shell".
*edit: that would cause Shell's quality to go down, with black segments etc. Deletion of the 2nd cap in "Shell plus" causes black segments too.

Other history with Rockets stage 3. There are some .bmp images, their amount in best case must be bigger than in Rockets stage 2, in worst case... I can post it with one/certain placeholder images, with normal zip compression and not quite a big size. And webplace for full patch.


31st October 2006 14:13 UTC

Earthquaker: rar has been postable for a couple of years now.

Also I was wrong about 7-zip files. 7z is allowed to be posted here now too.

Valid file extensions: gif jpg png txt zip rar bmp jpeg wsz wal m maki nsi nsh 7z xml

31st October 2006 15:21 UTC

Thanks Jheriko.
Alth I wanted not to use rar for main presets, but this allows me not to make additional posts for less important data.


1st November 2006 10:37 UTC

You can of course make a spanned rar/zip/7z to submit something across multiple posts, don't know if its frowned upon by the mods though... the filesize limit is probably there for some practical reason, after all.

I think I've done it at least once before... no one seemed to be bothered.