File Size

[DMS Pete]

Hi

I am a fairly new Vray user, but am finding the file sizes to be very large. After modelling something up in Rhino it is about, say, 5MB, but then when I apply materials and set my scene I am finding my files jump to about 300MB+. I usually save new copies each day, so I can go back to old versions, so at 300MB each it is becoming quite onerous. I think it has something to do with the meshing. Are these file sizes reasonable, or do I have some settings wrong somewhere?

I have tried using the export vray proxy which has worked well for final renderings, bringing the final render file back down to about 6MB, but this stops me making changes to the geometry and is a bit restrictive.

Any advice would be appreciated.

Thanks

Pete

[Micha_cg]

Use "save small" and the Rhino scene is saved without render meshes. Next opening need longer for new creating the render meshes. Also the command "purge" could be interesting for you. I use it to delete unused blocks from imported geometry.

[DMS Pete]

Thanks Micha. I tried both of of your suggestions. The save small dropped about 20MB from a 350MB file, so it helped, but didn't see the sort of drop I was hoping for. I also tried the purging but it didn't have any noticable effect, as there seemed to be no unused blocks. I'll have to research some more, as maybe it is a geometry thing. One of the files that is very large uses some T-spline surfaces, so maybe they are making everything large.

Thanks for your suggestions.

[Mindmuck]

Hello! Same here!

Applying materials to geometry increases file size were massive in some cases - 1.05 didn't behave in this way and it's really annoying.
"Save small" doesn't help in this case, it just reduces the "real" model size (without vRay involved) a bit.
This really seems to be a bug within vRay that generates, stores and duplicates (?) big masses of data somewhere.
It seems that especially if you have many small objects (which really aren't complex or big in file size!), the file size becomes insanely high.

For example: Last time, I made a landscape model for an information graphic. Because of the abstract character of all objects, there really wasn't much geometry to handle, the scene was about 35 MB as I remember - some "box"-houses, a number of electric towers, wind energy plants, streets... everything very low-detail.
...until I made some materials and applied them.

Rhino file size increased from 35 MB up to 600 MB! Just with 10-12 simple materials..

By removing materials step by step, I discovered the following behaviour:
- the more complex a material is (number of layers etc.), the bigger file size becomes. Materials with reflection layers increase more than those with just a diffuse layer, using bitmap textures increases more than just using colors etc.
- removing all materials brings back the initial file size of 35 MB - without changing anything in geometry
- much bigger models with hundreds of megabytes of geometry (e.g. hi poly car models) don't "grow" that much in file size when applying materials - but only if they don't have many single small objects. Big, merged complex parts = O.K., thousands of little things (even mesh objects with only 2 polygons!) = not O.K.


For this project, I managed it by converting many things to blocks, so file sizes stayed pretty small at the end.
But this workaround is not suitable in other situations - e.g. more technical designs with high detail and small parts that are not similarn to another - and in Rhino 4 / VfR1.05 there were never problems like this.

Any advice? I'm surprised that nobody noticed that strange behaviour yet..

[Micha_cg]

So we talk about v1.5? I thought 1.05.

I don't know why it's so quiet around the 1.5 release. At the current state of the plugin frequent updates are very needed for a production use.

[DMS Pete]

Thanks for the input Mindmuck. I am also using 1.5 with Rhino 5 beta (64-bit). I've done some tests on one of my models I'm having trouble with, and it appears in line with what you are saying. I have an outboard engine which is made up of about 3000 small surfaces. I originally had it as the material "Black Glossiness Floor" as downloaded from the materials section of this website. The material has a reflection layer, but no refraction of maps applied. Looks like it should be pretty simple. When the outboard is coloured in this material I have a total file size of about 350MB. When I change the material to a basic black plastic material, my file size drops to 38MB or 27MB is using SaveSmall.

Another file I have has a similar problem. I've done some tests and there a few blocks with multiple surfaces also in that one. The file was 330MB to start with. Some of the block items were coloured in a Grey Diffuse colour. It was again a simple material, with a basic reflection layer and no maps applied. I created a new basic default material and converted all these items to that material. It dropped the file size from 330MB to 150MB. The other items that had block items with multiple surfaces had the material "aluminium_matte", downloaded from this site. Again, it has a reflection layer, but it is pretty basic with no maps. Converting these objects to my new default material dropped the file size to 80MB. I tested all of my other materials and they all had some effect, but nothing too bad. Removing all other materials dfropped the final file size to 70MB or 50MB with SaveSmall.

These large file sizes are very problematic for me, as I use automatic on-line backup for my files and the 300MB+ files are taking forever to upload and blocking up my system. As with Mindmuck, I never had any issues like this with 1.05. Any suggestions or fixes Chaos Group?

Thanks

[renee81]

well,all the materials that are available for download from here,were made with the previous version of vray 1.05,and they are translated to 1.5 when you use them in 1.5.
I am pretty sure the problem come from that situation.
Even my own material that I have created in the previous version show the same problem.So better recreate the material in 1.5

[Micha_cg]

Even my own material that I have created in the previous version show the same problem.So better recreate the material in 1.5

I hope only a workaround, not a real solution, since after 5 years 1.05 many materials are used. A bug report and a fix would be great.

[DMS Pete]

Thanks Renee,

I've checked all of the materials that were causing the problems, recreated them in V1.5 and it has fixed the problem. Still a workaround though and makes all the 1.05 materials useless. I haven't done it before but I will try to report a bug and get it fixed.

Thanks for all the help.

Pete

[Micha_cg]

Here a quote from the developing team:

As for issue 2, I have not yet come up with the best way to approach it. Part of the problem is that Rhino is odd about how it makes and stores materials. You can have 1000 of copies of the same material depending on how you apply your materials. This is why I generally tell users to use our material editor to apply materials where possible, as we ensure we only apply 1 material to all objects selected, whereas Rhino, in some cases, will assign a separate copy to each item in the selection. Since we are now using XML, and also embed a preview image in that xml, our materials are much larger than their old binary counterparts.

So for now I tell users to try using our material editor for applications as much as possible. In the future I will probably have to revert to storing binary information, which is part of why I started experimenting with serializing to binary in our asset table a week or so ago. Just going to binary won't be enough, however, since the embedded preview adds 25-30KB anyway. Switching to binary can give us about 30% reduction, switching to binary without the image can take us further. I have not been actively working on this, though it has been in the back of my mind.

Unfortunately, the best way to eliminate size would just be to make the materials hold a url and reference a separate table. However, this would greatly complicate things when users choose to copy and paste between scenes ( which they seem to do according to old bug reports ). If our material isn't on the ON_Material when its copied, it wont' be brought to the new scene.

So there isn't a fool-proof fix that will make everyone happy yet, but I will continue looking into it.

[Mindmuck]

Here a quote from the developing team:

Thanks a lot - this seems to be a workaround. I'll try it as soon as possible...

Thanks Renee,
I've checked all of the materials that were causing the problems, recreated them in V1.5 and it has fixed the problem.

Unfortunately, in my case this didn't help. Due to some other issues with old 1.05 materials (that didn't appear in material editor after copy+paste, or were rendered in a wrong way) I've built every material "from scratch" in VfR1.5 and still had the file size increase.
But as I always used Rhino's object properties tab to select materials until now - maybe using the material editor for applying materials will help

[renee81]

[/QUOTE] maybe using the material editor for applying materials will help [/QUOTE]

this is the way I do it always ,I don't know if it helps....

[Micha_cg]

I opened my current project file from R4 1.05 at R5 64 1.5 and saved it - the size jumps from 380MB to 750MB. So, it seem to be that not the workflow helps to avoid the file increase.

[Helldoor]

Hi there,

I have been experiencing the same problem recently:


. After constructing everything for an exterior scene, my model was suddenly huge - 1.5 gb. you can take a look at the attached pic - it's not a very complicated scene, although there is some displacement and lights...
. At this point, the render time for a 800x600 image was about 58 mins, taking all of my 16 gb RAM!!! Bigger images were not really possible to be rendered...
. First, I tried removing all the 2d data and simplifying the model (converting '3d' glass to '2d', deleting all the surfaces, that are not seen in the scene or being reflected) - that reduced the whole size to about 1.4 gb - so it didn't help much. The problem was elsewhere.
. The render time for a 800x600 image went to about 55 mins, still using all of the RAM...
. After that, I removed all the textures, thinking, that I have a corrupted texture somewhere, snuck in with an imported furniture model or something.. The file size dropped drastically to 180 mb!
. Render time for a 800x600 pic - about 1 minute (check settings attached). The RAM stayed low.
. At that point I knew, it was a texture problem. I began importing new (existing .mtl) textures to the scene, using the material editor (as I always do).
. I saved my scene, after importing and applying each texture. It was crazy, as I saw, that after applying the concrete thexture to the tower in the scene (check TOWER pic), the scene size grew from 250 mb to about 700 mb!
. The concrete texture has a reflection map, using a filter, but is non of a big one... The concrete texture image (also the filter image) is about 150 kb of size...
. After retexturing the whole scene, the model size grew up again to 1.3 gb. As if Rhino/Vray was saving and embedding all the applyed textures in the model...
. The render time of a 800x600 scene dropped to 21 mins, but images, bigger than 1024x.. are not really possible, because of the immence RAM usage.
. Damn.


Did you come with any solution in the meantime?


Greetz
teo

[DMS Pete]

Hi Teo,

I'm a very occasional user, so don't know if I ever found a sold reason. But if I remember correctly, the issue was related to materials that were created in earlier versions and then transferred over to RT. Some of these caused huge file sizes, whereas if a whole new material was created from scratch with the same maps,, etc it would be fine. I'm not 100% that this is the answer, but I think it is along those lines. I recently took some of the materials of the Chaos Group site and didn't have size issues, so maybe they were updated to suit RT?