Daily builds version 2

[Benny]

Biggest advantage is all those models and scenes that have accumulated over the years, and to be able to use them without having to convert first.

[Monkeybrother]

Biggest advantage is all those models and scenes that have accumulated over the years, and to be able to use them without having to convert first.

I agree. VRay material compatibility is a very good thing. At work we still have hundreds of objects we've bought but just haven't had the time and energy to convert. Also, the converter is far from perfect, foliage on converted trees often looked really bad for example, and often the reflection properties are way off.

[romullus]

I don't think it will be much better with native Vray materials support. If model looks bad after converter (especially foliage), then it's most likely because of original material's setup and not because converter does a bad job. It's very unlikely, that native Vray materials support would fix those issues.

[Monkeybrother]

I don't think it will be much better with native Vray materials support. If model looks bad after converter (especially foliage), then it's most likely because of original material's setup and not because converter does a bad job. It's very unlikely, that native Vray materials support would fix those issues.

Well, the materials look good in VRay and I just assumed that materials would look exactly like in VRay when Corona can read those materials? Wasn't one of the "selling points" of the merger that the teams can exchange code? If it's just an approximation and no better than the converter, I'm disappointed.

[ihabkal]

latest build hidden objects in the viewport are still being rendered.

[sprayer]

materials look good in VRay and I just assumed that materials would look exactly like in VRay

they looks better because vray fake render and corona not, i am doubt what wrong material will be looks better with support vray material. For example many people seting up  in vray for foliage ior 999 and dark gray reflection. You still will need to check materials so it's usless


can you check this scene in latest build? https://forum.corona-renderer.com/index.php?topic=6883.msg122496#msg122496

[Monkeybrother]

materials look good in VRay and I just assumed that materials would look exactly like in VRay

they looks better because vray fake render and corona not, i am doubt what wrong material will be looks better with support vray material. For example many people seting up  in vray for foliage ior 999 and dark gray reflection. You still will need to check materials so it's usless

I know that. I assumed that the whole point was that VRay materials would look like they do in VRay, no matter if they're built "correctly", what's the point otherwise? If I can't load an object with VRay materials and use it as is, why have that feature at all?

[Ondra]

Hi,
I see some negative reaction to us adding vray compatibility, so I will try to address some of the issues raised:

First, this is not us changing plans or secretly sneaking in "evil" features - we were very upfront about this right from the beginning, as it is very logical thing to do: https://corona-renderer.com/blog/new-horizons-plans-for-2017-and-beyond/.

As for advantages this has over the convertor: while we like the convertor and it works well, there are few limitations we aim to overcome:

• We managed to get the support working (without some very specific features like object include/exclude) even without vray installed
• Speed of work, UI improvements - no need to run the script every time new asset is imported, no more "unsupported material" warning. Ideally, we would like that assets that are "vray compatible" be automatically also "corona compatible", to make shopping/browsing assets easier.
• While the support is not perfect and never can be (the rendered images can differ if some features unsupported in one renderer are used), it is non-destructive - meaning the assets are preserved as they were, unsupported features are not rendered, but also not destroyed - so the assets can be still used in vray, or can render better once the feature support is addded. There is no need to store 2 versions of well-made assets.

We intend to preserve the convertor to support other render engines, and to offer permanent conversion of vray->corona assets.


I understand that this feature is not useful for all, but please, put way the tinfoil hats. Volumetrics, skin, hair, ... are features also not used by all, yet people do not complain when we spend (way more) time on them.

[Nejc Kilar]

I definitely don't get the semi-negative feedback with regards to V-Ray compatibility. There are so many assets out there that are made with V-Ray that it just makes sense to do it.

Obviously a converter can't get you there 100% unless its a really simple material but just having the ability to drag & drop it in the scene to see if it looks alright and then having the "non-destructive" ability to recreate the shader side by side... I don't know, to me it just cuts a few steps along the way and makes things easier.

I guess its one of those things that some people will like and some people won't... Like Advanced Volumetrics support maybe? (I'm definitely excited about those too)

[NicolasC]

Hi,
I see some negative reaction to us adding vray compatibility, so I will try to address some of the issues raised:

First, this is not us changing plans or secretly sneaking in "evil" features - we were very upfront about this right from the beginning, as it is very logical thing to do: https://corona-renderer.com/blog/new-horizons-plans-for-2017-and-beyond/.

As for advantages this has over the convertor: while we like the convertor and it works well, there are few limitations we aim to overcome:

• We managed to get the support working (without some very specific features like object include/exclude) even without vray installed
• Speed of work, UI improvements - no need to run the script every time new asset is imported, no more "unsupported material" warning. Ideally, we would like that assets that are "vray compatible" be automatically also "corona compatible", to make shopping/browsing assets easier.
• While the support is not perfect and never can be (the rendered images can differ if some features unsupported in one renderer are used), it is non-destructive - meaning the assets are preserved as they were, unsupported features are not rendered, but also not destroyed - so the assets can be still used in vray, or can render better once the feature support is addded. There is no need to store 2 versions of well-made assets.

We intend to preserve the convertor to support other render engines, and to offer permanent conversion of vray->corona assets.


I understand that this feature is not useful for all, but please, put way the tinfoil hats. Volumetrics, skin, hair, ... are features also not used by all, yet people do not complain when we spend (way more) time on them.

Hello Ondra :)

Thank you for your explanations, understood. While I now see how it can be useful, I'm still surprised to see it's such a priority compared to other stuff ;)

[Bormax]

Hi

About Corona native thing...

Selection frame is not visible wile IR (docked or in VFB) is active. DB 2018-08-03, Max 2014

[Fluss]

Hi,
I see some negative reaction to us adding vray compatibility, so I will try to address some of the issues raised:

First, this is not us changing plans or secretly sneaking in "evil" features - we were very upfront about this right from the beginning, as it is very logical thing to do: https://corona-renderer.com/blog/new-horizons-plans-for-2017-and-beyond/.

As for advantages this has over the convertor: while we like the convertor and it works well, there are few limitations we aim to overcome:

• We managed to get the support working (without some very specific features like object include/exclude) even without vray installed
• Speed of work, UI improvements - no need to run the script every time new asset is imported, no more "unsupported material" warning. Ideally, we would like that assets that are "vray compatible" be automatically also "corona compatible", to make shopping/browsing assets easier.
• While the support is not perfect and never can be (the rendered images can differ if some features unsupported in one renderer are used), it is non-destructive - meaning the assets are preserved as they were, unsupported features are not rendered, but also not destroyed - so the assets can be still used in vray, or can render better once the feature support is addded. There is no need to store 2 versions of well-made assets.

We intend to preserve the convertor to support other render engines, and to offer permanent conversion of vray->corona assets.


I understand that this feature is not useful for all, but please, put way the tinfoil hats. Volumetrics, skin, hair, ... are features also not used by all, yet people do not complain when we spend (way more) time on them.

I totally get your point here Ondra. Different people = different needs etc etc... As far as I'm concerned, I was not especially negative, just a bit disappointed.. Some long terms bugs/feature, that I consider crucial are still in the pipe, version after version and that's kinda frustrating. That's all. Most of us do not intend to be agressive/offending, we're just trying to push for these features/fix to be addressed and don't fall in the abyss. That said, Corona is getting better and better and even if I don't consider that feature a must have compared to some others, that's still a great step forward and it will for sure be beneficial to my workflow. So keep up the good work :)

[scionik]

OK...
but for daily work I need this feature "Multimap - randomization by mesh elements" much more than vray light or mtls support

[lupaz]

Hi,
I see some negative reaction to us adding vray compatibility, so I will try to address some of the issues raised:

I wouldn't call it negative reaction. I'd call it curiosity.
At least in my case it was a way of asking why the development in that area.

I understand that this feature is not useful for all, but please, put way the tinfoil hats. Volumetrics, skin, hair, ... are features also not used by all, yet people do not complain when we spend (way more) time on them.

Making vray and corona 100% compatible sounds like a daunting task to me...
Especially when I'd die to have certain other capabilities with Corona that I find much more important to NOT look in other directions (GPU rendering or speed).

[fraine7]

Hi,
I see some negative reaction to us adding vray compatibility, so I will try to address some of the issues raised:

First, this is not us changing plans or secretly sneaking in "evil" features - we were very upfront about this right from the beginning, as it is very logical thing to do: https://corona-renderer.com/blog/new-horizons-plans-for-2017-and-beyond/.

As for advantages this has over the convertor: while we like the convertor and it works well, there are few limitations we aim to overcome:

• We managed to get the support working (without some very specific features like object include/exclude) even without vray installed
• Speed of work, UI improvements - no need to run the script every time new asset is imported, no more "unsupported material" warning. Ideally, we would like that assets that are "vray compatible" be automatically also "corona compatible", to make shopping/browsing assets easier.
• While the support is not perfect and never can be (the rendered images can differ if some features unsupported in one renderer are used), it is non-destructive - meaning the assets are preserved as they were, unsupported features are not rendered, but also not destroyed - so the assets can be still used in vray, or can render better once the feature support is addded. There is no need to store 2 versions of well-made assets.

We intend to preserve the convertor to support other render engines, and to offer permanent conversion of vray->corona assets.


I understand that this feature is not useful for all, but please, put way the tinfoil hats. Volumetrics, skin, hair, ... are features also not used by all, yet people do not complain when we spend (way more) time on them.

I totally get your point here Ondra. Different people = different needs etc etc... As far as I'm concerned, I was not especially negative, just a bit disappointed.. Some long terms bugs/feature, that I consider crucial are still in the pipe, version after version and that's kinda frustrating. That's all. Most of us do not intend to be agressive/offending, we're just trying to push for these features/fix to be addressed and don't fall in the abyss. That said, Corona is getting better and better and even if I don't consider that feature a must have compared to some others, that's still a great step forward and it will for sure be beneficial to my workflow. So keep up the good work :)

I'm definitely with Fluss on this one. Our negativity (if you wish to call it that) is not with vray compatibility as such, it's because all of the other requests/features/fixes etc. will be placed on the backburner whilst this happens. The ability for me to render a Vray plane light is certainly not going to improve my work or my life - however, a working Lightlister (remember that?) would be of huge benefit. I love Corona and I have not once thought of Vray since switching so I will reserve a slight annoyance that it continues to slow me down even when I don't use it.