Author Topic: Corona Material/Lights Converter (legacy)  (Read 1088663 times)

2014-08-20, 11:32:32
Reply #300

naeq

  • Active Users
  • **
  • Posts: 17
  • Corona lover
    • View Profile
    • Portfolio

2014-09-18, 13:58:05
Reply #301

moadr

  • Active Users
  • **
  • Posts: 58
    • View Profile
    • Vermeer by Stableworks
I have searched for it in the forums, but couldn't find a report about it, so I just let you know my remarks :)

First and foremost I would like to say a big thanks to you for this amazing script. It works really well and as most of our resources are in vray format, it would be impossible to do the everyday work without it. So thank you! :)

What I recognized is, when you convert materials, somehow it can't convert the bump value properly, as it was setup before in vray. Most of the time I get values like: 0,333 / 0,666 / 1,66, etc. With all the other maps in the materials it converts to the proper value, but with the bump it doesn't work correctly. In my understanding this doesn't seems like as a big problem, maybe just a minor thing that is not working the right way, but can make a big mess.

Can you have a look at it please? :)

Thanks!

All the best,
Adrian
Adrian Moorsel

Vermeer by Stableworks   |   https://stableworks.tech

2014-09-18, 14:20:30
Reply #302

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
I'm glad you find it helpful :)

What I recognized is, when you convert materials, somehow it can't convert the bump value properly, as it was setup before in vray. Most of the time I get values like: 0,333 / 0,666 / 1,66, etc. With all the other maps in the materials it converts to the proper value, but with the bump it doesn't work correctly.

It's one of those decisions I had to make when I was thinking about the "most useful" and "least harmful" method to convert bump ;) .
The converter divides the bump value which is set in Vray by 30.0. That means, if you're converting a default VrayMtl it will convert to a "default" CoronaMtl, at least concerning bump values.
On the one hand (personally) I think 1.0 is (always!) too much bump in a CoronaMtl (30 is too much for vray mtls too, most of the time), on the other hand, you never know what users did set for bump and how careful they were. If I convert my own Vray mtls - which are using around 5.0 to 10.0 bump value - it comes out a little too weak, but for other people, which are using bump values of 50.0 or more it is still way too much for corona and looks aweful.
Any sufficiently advanced bug is indistinguishable from a feature.

2014-09-24, 02:00:37
Reply #303

snakebox

  • Active Users
  • **
  • Posts: 493
    • View Profile
    • Snakebox Media
Any updates on the limiting the IOR values when converting vray materials?  The 999.99 causes a lot of issues.  Thanks

2014-09-24, 07:14:55
Reply #304

borisquezadaa

  • Active Users
  • **
  • Posts: 614
    • View Profile
Hi snakebox!...
A workaround for now... a small pretty clever script called SlateConnector.
http://www.scriptspot.com/3ds-max/scripts/slate-connector

It can batch edit Corona materials on the Slate editor... pretty handy. You can just select a bunch of materials and add a IOR slider to all of them at once, check it... worth a try.

(Waiting for a IOR checkbox "Apply a Defalut IOR of ---enter magic number here-- for materials whitout it"... cause EVERYTHING HAS FRESNEL!!!!... XD).
What i do with Corona My Corona post of random stuff rendering
WARNING: English.dll still loading...

2014-09-24, 10:39:22
Reply #305

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
Any updates on the limiting the IOR values when converting vray materials?  The 999.99 causes a lot of issues.  Thanks

It will be included in the next version (which will be released when there's more stuff to be implemented).
Until then you can use this code snippet to clamp IOR values:
Code: [Select]
for mtl in (getclassinstances CoronaMtl) do( if mtl.fresnelIor > 25.0 do mtl.fresnelIor = 25.0 )
or set all mtls which have an ior of 999.0 to some arbitrary value
Code: [Select]
for mtl in (getclassinstances CoronaMtl) do( if mtl.fresnelIor == 999.0 do mtl.fresnelIor = 25.0 )
Any sufficiently advanced bug is indistinguishable from a feature.

2014-09-24, 15:59:44
Reply #306

davius

  • Active Users
  • **
  • Posts: 36
    • View Profile
Hey DeadClown! Thanks for your tips on ScriptSpot! I will try to make my head around your code since I'm no Maxscript expert by no means (guess it shows on the script body :P ) and my main concern was making the script "work" at first.

Currently, the new version (0.3a, still unreleased) changed the way you select and change your materials selection. As of now, the script isn't "fool proof" and the properties and methods of the SME are pretty limited. One serious limitation is that you can't change the properties or assign nodes using SME commands (basically all you can get is the node's name and position on Slate) - you need to first select the material and it's done using an array that collects all classinstances of CoronaMtl type and compares the names of those materials to the names of the nodes selected on the SME. As you know, you CAN have materials with the SAME name on Slate (but not on Max's scene) and this alone is a possible "bug".

If AD exposed more methods and commands to the SME, maybe it would make the script even faster and more direct.

Cheers! And thanks a bunch!

2014-09-24, 18:59:47
Reply #307

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
Hey DeadClown! Thanks for your tips on ScriptSpot! I will try to make my head around your code since I'm no Maxscript expert by no means (guess it shows on the script body :P ) and my main concern was making the script "work" at first.

You're welcome ;)
No worries, as long as it does the job and you constantly improve your scripting capabilities you're on the right track :)

I had a look at the SME interfaces. Holy ****!. I never liked Slate, now I know why! =/
I might try testing all scenematerial instances with the "<Interface>GetNodeByRef <maxObject>ref " method and see if their selected property is true.. but... seriously Autodesk? That is really stupid.


P.S. we should continue our conversion elsewhere, not necessarily in this thread ;)
« Last Edit: 2014-09-24, 19:03:38 by DeadClown »
Any sufficiently advanced bug is indistinguishable from a feature.

2014-09-25, 04:17:52
Reply #308

davius

  • Active Users
  • **
  • Posts: 36
    • View Profile
Just sent you a PM, DeadClown. Let us be friends :)

2014-10-10, 17:45:57
Reply #309

nehale

  • Active Users
  • **
  • Posts: 283
    • View Profile
I was wondering, would it be possible to make this script work the other way around? as in convert corona materials to vray?
I had a girlfriend once.....her name was Vray

2014-10-10, 18:03:43
Reply #310

Stan_But

  • Active Users
  • **
  • Posts: 526
    • View Profile
    • https://www.behance.net/archdizs
I was wondering, would it be possible to make this script work the other way around? as in convert corona materials to vray?

No. It is the way to come back to hell))

2014-10-10, 18:44:48
Reply #311

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
No. It is the way to come back to hell))

That's one of the problems :D

The other thing is that it's not always easy to reverse the process. There's some kind of information loss involved, so in most cases it would work fine (basic parameters) but others may just be lost during the process (it's obviously also happening from vray or mr to Corona).
But maybe the most important reason NOT to do it is that it would cost me a lot of time - time where I do not really see much benefit investing it. It may help a handful of people to compare the two renderers but it wouldn't be as much used as the converter now.
Any sufficiently advanced bug is indistinguishable from a feature.

2014-10-17, 16:08:20
Reply #312

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
New version is up

changelog:
*v0.21
  • added tooltips for all controls
  • added VrayMtl self-illumination conversion
  • builds starting 2014-09-30 (daily builds, Corona 1.0,..): VrayNormalMap and Normal_Bump are now converted in a way that they should not need manual gamma fixing. Depends if it was used correctly in Vray/Mr/fR/..
  • added an option to clamp the default 999 Vray Fresnel IOR (happends if fresnel is turned off) to a lower value
Any sufficiently advanced bug is indistinguishable from a feature.

2014-10-18, 00:24:40
Reply #313

Juraj

  • Active Users
  • **
  • Posts: 4743
    • View Profile
    • studio website
I'm glad you find it helpful :)

What I recognized is, when you convert materials, somehow it can't convert the bump value properly, as it was setup before in vray. Most of the time I get values like: 0,333 / 0,666 / 1,66, etc. With all the other maps in the materials it converts to the proper value, but with the bump it doesn't work correctly.

It's one of those decisions I had to make when I was thinking about the "most useful" and "least harmful" method to convert bump ;) .
The converter divides the bump value which is set in Vray by 30.0. That means, if you're converting a default VrayMtl it will convert to a "default" CoronaMtl, at least concerning bump values.
On the one hand (personally) I think 1.0 is (always!) too much bump in a CoronaMtl (30 is too much for vray mtls too, most of the time), on the other hand, you never know what users did set for bump and how careful they were. If I convert my own Vray mtls - which are using around 5.0 to 10.0 bump value - it comes out a little too weak, but for other people, which are using bump values of 50.0 or more it is still way too much for corona and looks aweful.

I noticed the same I wondered what was the reason. I think 30 is too low number, it seems like two different values are being compared, default Vray (30, but it's really just random number), and maximum Corona (1.0). I think that perhaps it should be the same value to same value (1.0=100) so divide by 100 instead.
I don't think it got the bump value right in either case I always have to lower it. At average, I find Corona more "sensitive" (in way that bump artifacts/general noisy ugliness) appears sooner, so I use way lower values than I do in Vray. But at lowest, I would divide by 100, not 30.

The way it is always creates incorrect stuff with maps that are 1=100 for reason, like normal map. After conversion, it ends up being 3.333, 330perc. stronger than it should be.

Maybe there should be a field/option to choose what is the division number (optional).

I agree that 30 for bump (not normal, edge or other maps which are supposed to be "full" ) can be too much in Vray, but it's equal to 0.3 in Corona, not 1. The same ugliness starts at 0.3, not 1.

Please follow my new Instagram for latest projects, tips&tricks, short video tutorials and free models
Behance  Probably best updated portfolio of my work
lysfaere.com Please check the new stuff!

2014-10-18, 14:35:09
Reply #314

Chakib

  • Active Users
  • **
  • Posts: 787
  • Corona Omnomnomer !
    • View Profile
Thanks for the new update, also i would like to see a  conversion button for CoronaNormatex instead of simple Normal map in the scene to avoid the alert message.