Scene Very large after Conversion from Corona to Vray

[philip kelly]

Good Morning.
I have this on two projects.
It may be a Proxy issue, but after a 300mb corona file is converted to a Vray file, the size can be up to 1gb.
Has anybody else had this.
Also slower render times than if the project was built natively in Vray from the start. I have done it both way, conversion and built from scratch and the clean Vray file is so smooth and easy to handle.
I use Max convert Pro to convert.

Anybody else come across this...may be my approach is wrong.

Thank you for your time.

phil

[^Lele^]

It's for the author of the converter to answer.
If the converter imports the proxies as max meshes, f.e., this would happen.
However it's just one of the many possibilities for file size increase.

[philip kelly]

I agree 100% with your comment, thanks you . It just slows down the process. Funny when you switch to one piece of software, you do everything to make it work.

[^Lele^]

I agree 100% with your comment, thanks you . It just slows down the process. Funny when you switch to one piece of software, you do everything to make it work.

I hear you, and also think i know the position of the author of the script: conversion is never exact, it's often a compromise, and very often it's ugly (f.e. you need many nodes to make exact material conversions from Corona if the materials use levels, a control we lack.).
As You found out yourself, rebuilding from (near) scratch is often the best bet: the more complex the scene, the more time the checking and fixing and backtracking will take, all the more so if one's affectionate to a particular look.

[Vizioen]

It might be a long shot here, but is there any future in mutual compatibility between corona and vray in terms of materials and maps? Or at least creating same 'features' in both so a conversion is easier?

[^Lele^]

It might be a long shot here, but is there any future in mutual compatibility between corona and vray in terms of materials and maps? Or at least creating same 'features' in both so a conversion is easier?

Some compatibility enhancements are in the works, indeed, but there will be a sharp-ish limit to conversion capabilities, regardless.
There are practical, and theoretical limitations to any conversion, and this specifically.

Corona philosophically is a software meant to be converted to, not from.
The team quite rightly likes their freedom to do as they please, change what and when they like, and as such they are not as interested into third party compatibility as us, for example.
Price to pay for the kind of flexibility they afford the user.

In general, translation is imperfect, and in any form, not just 3d.
Theoretically, the only perfect translation is a logical identity (i.e. when the two terms are identical for meaning), any other form is lossy in one way or the other.
It's not by chance that there exists the locution "Lost in Translation"...

Stuff like USD and MtlX bring a host of promise, but are still quite far from general production readiness, both in standard and for breadth of implementation.
This though would only be working for the two engines as a form of minimum common denominator of features, surely it wouldn't magically make any Corona shader work with V-Ray.

[3DZver]

Although, as Lele rightly pointed out, converting materials can affect file sizes, I don't think this is the main reason.
For example, I created an empty scene with one box, to which I assigned V-Ray, Standard and Corona materials and saved to different files.
In the screenshot below you can see how the file size differs depending on what material is assigned to the box:



It seems to me that the question why scenes with V-Ray materials weigh so much more than scenes with Corona materials can only be answered by V-Ray developers

[philip kelly]

Interesting thank you.

[^Lele^]

Although, as Lele rightly pointed out, converting materials can affect file sizes, I don't think this is the main reason.
For example, I created an empty scene with one box, to which I assigned V-Ray, Standard and Corona materials and saved to different files.
In the screenshot below you can see how the file size differs depending on what material is assigned to the box:



It seems to me that the question why scenes with V-Ray materials weigh so much more than scenes with Corona materials can only be answered by V-Ray developers

In your example, the difference is about 10%, which is wholly acceptable.
The OP mentions file sizes that are three times and a bit bigger.
If you prefer, we can surely check the client scenes out in your stead, and find out what happened, but i am fairly sure it's down to conversion *options*, not to inherent structural differences.

[^Lele^]

Further on material sizes:
I tested creating 1000 cubes and assigning them no materials, scanline standard, corona legacy, corona physical and vraymtl, then saving uncompressed max files.
The max file sizes are attached.

We're talking 3kb per material for the corona Legacy, and 6kb per material for V-Ray: nowhere near the kind of differences the OP talks about.

Now, as a counter example, if the converter endeavoured to convert the level parameter in corona materials, and chose specific map types to do so, or it de-instanced bitmaps to apply gammas, etc., then yes, the file size may well baloon out of proportions.

[3DZver]

Further on material sizes:
I tested creating 1000 cubes and assigning them no materials, scanline standard, corona legacy, corona physical and vraymtl, then saving uncompressed max files.
The max file sizes are attached.

We're talking 3kb per material for the corona Legacy, and 6kb per material for V-Ray: nowhere near the kind of differences the OP talks about.

Now, as a counter example, if the converter endeavoured to convert the level parameter in corona materials, and chose specific map types to do so, or it de-instanced bitmaps to apply gammas, etc., then yes, the file size may well baloon out of proportions.

It looks like you didn't quite understand what I wrote.
I'm not arguing with you, but just adding)
As I wrote above - converting materials can affect the size of the final scene file, but in addition to this, the file size is also affected by the structure of the original materials that are used in the scene. And sometimes this can be a significant reason for the difference in file sizes.
Our examples are very simplified, and do not forget that scenes can contain a much larger number of different objects with unique (non-instance) materials. By the way, in your example, the difference between vrayMat and corLMat files is actually 3mb, which is not 10% but almost 40%, and as the number of unique materials in the scene increases, the difference in file size will increase exponentially.

Here is my example with 10000 unique boxes. I assigned unique materials to each of these boxes (10,000 materials in total). You can see that the difference is at least 22 mb (between VrayMtl and CoronaPhysicalMtl), and 29 mb (between VRayMtl and CoronaLegacy):



As for the proxies (that OP mentioned), the difference will already be 50%:

[^Lele^]

My shaders were all unique, as well.
I'm not sure how you're doing the maths: the base boxes size needs to be subtracted before doing the comparison.
And once done we're talking of exactly the same numbers: 30Mb to 49Mb: minute fractions for 10000 unique shaders (size difference is the scope of the V-Ray shader, and the Qt UI).
A triplication of the file size is *not* coming from shaders inherent class size, i'd bet my house on it.

The difference in proxy sizes, as well, are minute for those kind of counts, and it's obvious why the v-ray proxy is bigger (Alembic support, absent in corona.).
Still by far not nearly enough for the OP description.

Besides, the user does mention that without conversion, the rebuilt scene is fine and runs well.

The user wants to know for sure: should we provide him support in your stead, then?