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

2014-11-13, 18:22:35
Reply #360

rrichie

  • Users
  • *
  • Posts: 1
    • View Profile
Hi,
is there possibility to convert material from Corona back to vray? I rendered something for client and he wants scene in vray.
Thanks.
Bye.

2014-11-13, 23:41:01
Reply #361

fellazb

  • Active Users
  • **
  • Posts: 281
    • View Profile
Nope, at least not with this convertor and I'haven't seen one that does your request I'm affraid.


2014-11-14, 11:17:53
Reply #362

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
Thas why i suggest making them a "selection set" just to to avoid the wirecolor changing. I ussually link some Revit files from time to time and its a pain to check by hand.
I'll see what I can do ;)

is there possibility to convert material from Corona back to vray? I rendered something for client and he wants scene in vray.
I'm not planning to do this, for several reasons. I guess you will have to wait until some other guy writes a converter for that.
Any sufficiently advanced bug is indistinguishable from a feature.

2014-11-23, 15:19:10
Reply #363

romullus

  • Global Moderator
  • Active Users
  • ****
  • Posts: 8779
  • Let's move this topic, shall we?
    • View Profile
    • My Models
Sorry if this already been ask, but is it possible to do such that converter would not leave old materials in slate view after conversion?
I'm not Corona Team member. Everything i say, is my personal opinion only.
My Models | My Videos | My Pictures

2014-12-03, 12:13:24
Reply #364

antanas

  • Active Users
  • **
  • Posts: 269
  • Hmm ...
    • View Profile
 Hi, yesterday, while working on some scene, I've noticed quite unexpected thing, someone might even call it a bug :)  - Well, while converting some materials in an already populated scene one selects  "Clamp bitmap blur to" function it changes/clamps that blur value not only on some other renderer's materials but on already present/converted/fine-tuned  corona materials too - that might lead to some quite unpredictable and nasty results. If it  was a normal script's behavior in previous versions too, I didn't notice it earlier as I mostly tend to convert materials in separate scenes prior to merging those models to a currently worked on one and just this time I did so in the scene and more importantly noticed those changes :)
 To be more specific max 2015,  corona daily 2014-10-19, converter 0.22. As expected from that function it only converts\clamps those values to a lower than existing one's so probably that's another reason I hadn't noticed it before.
Some sort of a request type thoughts :

 1. I think it would be a good idea to make some tickable option to skip corona's materials entirely but to have that ability if desired + it would be even better if you could bring back conversion modes to avoid such or similar converter/user behavior in the future to make it somewhat more foolproof and versatile so to say.
 2. What if those blur amount conversions could be made to work both ways (up and down I mean) - in conjunction with presumably brought back conversion modes it would be quite a welcome thing.

 3. What If it could change filter type during initial conversion or during material fine tuning - let's say if script could have some options for blur type conversion, like  :
 unchanged/original - default if no other options selected,
 force - to pyramidal,
 force to summed area
 force to none 
That imho would be quite welcome and the converter could become even better and more complete solution so one could say goodbye (for daily use at least) to some monstrous gui/interface scripts like the Modifier Modifier Zorb for example

 4. Plus if script could change blur values in Multitexture maps it would be quite welcome too - zorb can do that, yet in it's rather unwieldy manner

 5. Maybe those and similar functions that  you decide or people might want to implement in the future may require some sort of simple/advanced switch in the converters gui to hide away all those nuts and bolts until they are needed and those are needed quite often might I add-  it would be good to have those functions in one place.

 Hope I am not too greedy and those things are not too hard to implement and even more, not too unnecessary for everyone except me, yet then I found out that bug/unintended behavior it got me thinking of what could be improved further and so I decided to make this chaotic long-post :)

2014-12-03, 14:46:50
Reply #365

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
Sorry if this already been ask, but is it possible to do such that converter would not leave old materials in slate view after conversion?
Sorry, for the late answer, I missed that post =/
I'm not using slate, so this is a new bug to me. Scripting capabilities in slate are extremely limited (I hate it so much!), so I can't promise anything - but I'll have a look :)

Well, while converting some materials in an already populated scene one selects  "Clamp bitmap blur to" function it changes/clamps that blur value not only on some other renderer's materials but on already present/converted/fine-tuned  corona materials too
hmm.. yes, it's a "known" bug. Originally it was meant to be a temporary tool for having a workaround for bitmap blur which was kinda broken in old Corona builds. I never really expected people were still using it after it got fixed :D . So, yes it is always clamping all blurs (it's a very simple implementation) and I'm tempted to remove it completely. The converter should convert materials and maps and not do all sorts of other very specific things ("Make 1 tool, but make it good" philosophy ;) ).

1. I think it would be a good idea to make some tickable option to skip corona's materials entirely but to have that ability if desired + it would be even better if you could bring back conversion modes to avoid such or similar converter/user behavior in the future to make it somewhat more foolproof and versatile so to say.
Currently I do not have any plans to re-implement conversion modes. These never worked the way a lot of people seem to have thought, and the problem about whether or not to break instancing between selected and non-selected objects still remains, even If I'd plan to redo those modes in a better way. I see that there are use-cases where you'd like to have this functionality (where there are no instances to break) but I don't see a clever way right now to implement it without confusing lots of users which are then using it, don't know what they do and report bugs about shitty conversion results (that happened quite often and was the reason why I decided to deactivate them) ;)

2. What if those blur amount conversions could be made to work both ways (up and down I mean) - in conjunction with presumably brought back conversion modes it would be quite a welcome thing.
 3. What If it could change filter type during initial conversion or during material fine tuning - let's say if script could have some options for blur type conversion, like  :
 unchanged/original - default if no other options selected,
 force - to pyramidal,
 force to summed area
 force to none 
That imho would be quite welcome and the converter could become even better and more complete solution so one could say goodbye (for daily use at least) to some monstrous gui/interface scripts like the Modifier Modifier Zorb for example
 4. Plus if script could change blur values in Multitexture maps it would be quite welcome too - zorb can do that, yet in it's rather unwieldy manner
Well, that's exactly the problem, scripts like the zorb tools are a bit clunky but can do a huge amount of things. If I implement a "little" version for just clamping blur or some other mass change functionality it's always very very limited and can only do exactly what I had in mind people would want. You are now requesting new features which (if I implemented these) would make my tools a little bit more useful for some people but are basically still very limited and are just more complicated to implement and generate more bugs (as I'm just adding more stuff on top but the underlaying framework was never written to be that flexible, so I have to do ugly workarounds) . As written above, make 1 tool but make it good.

5. Maybe those and similar functions that  you decide or people might want to implement in the future may require some sort of simple/advanced switch in the converters gui to hide away all those nuts and bolts until they are needed and those are needed quite often might I add-  it would be good to have those functions in one place.
Yes, that's what I'm currently thinking about - adding a completely separate toolset for all sorts of "little things" I don't want to implement in the converter but have proven to be useful for some people. Normally that's stuff I'm doing with one or two lines of code for myself while working.

Hope I am not too greedy and those things are not too hard to implement and even more, not too unnecessary for everyone except me, yet then I found out that bug/unintended behavior it got me thinking of what could be improved further and so I decided to make this chaotic long-post :)
No, you are very welcome to make suggestions and I really appreciate every feedback! It's all of your feedback that made this converter so successful :) Most of the time the problem with feature requests is not that I wouldn't want to implement it but that I'm not sure how to do it in a really good way. Some developers just throw in everything people "may" want to have one day or another and what comes out it a totally messed up interface like Vray3 now has. I prefer to make everything as simple as possible, ideally a 1-click solution without any pitfalls (pretty much how corona is meant to be). I could add lots of fine-tuning settings and stuff that is helpful in very specific cases but that would also mean less users are able to use the converter right away. In the end it's all a matter of balance between features and usability.
« Last Edit: 2014-12-03, 14:53:42 by DeadClown »
Any sufficiently advanced bug is indistinguishable from a feature.

2014-12-03, 15:53:18
Reply #366

antanas

  • Active Users
  • **
  • Posts: 269
  • Hmm ...
    • View Profile
Well, it's hard to argue, your points are justified indeed - simplicity of process is the result's best friend :)
 Still, I think some sort of function to exclude already present corona materials from conversion (if that is possible) would be quite welcome as without it, in some cases, conversion can lead to some if not nasty but surely unpredictable results. Or as you wrote above, you can remove that mischief causing function completely, yet not before you make some additional toolset of "little things" which you mentioned - you can even add your diffuse level/albedo value auto-changer there :) 

2014-12-03, 16:17:57
Reply #367

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
Well, it's hard to argue, your points are justified indeed - simplicity of process is the result's best friend :)
 Still, I think some sort of function to exclude already present corona materials from conversion (if that is possible) would be quite welcome as without it, in some cases, conversion can lead to some if not nasty but surely unpredictable results.
Well, currently only this blur clamping thing should be a problem, everything else should work fine - no matter how often you run it. Only the blur thing is running as a separate loop after the whole conversion took place, that's the reason why it's clamping everthing everytime. Not nice but exactly what happens if you "quickly add something on top temporarily" :D
I will try to make the toolset stuff as soon as I can spare some time for the converter again (I'm still waiting for the new daily builds where I have to change some other important things first)

Or as you wrote above, you can remove that mischief causing function completely, yet not before you make some additional toolset of "little things" which you mentioned - you can even add your diffuse level/albedo value auto-changer there :)
Over my dead body! :D This albedo thing will never be a part of it (for pretty much all (and more) the reasons mentioned in the post before ;)
Any sufficiently advanced bug is indistinguishable from a feature.

2014-12-07, 20:43:11
Reply #368

xt13r

  • Active Users
  • **
  • Posts: 157
  • Viva la Corona!
    • View Profile
    • my portfolio
Hello. Seems like with the latest builds script don't want to work properly. It shows mistake.
http://i57.tinypic.com/1zd11ro.jpg

2014-12-07, 22:56:44
Reply #369

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
Yep, multiple maxscript parameter names have changed and I have to fix those first. I'll make a "daily-builds" converter version soon.
Any sufficiently advanced bug is indistinguishable from a feature.

2014-12-08, 06:31:26
Reply #370

snakebox

  • Active Users
  • **
  • Posts: 493
    • View Profile
    • Snakebox Media
Yep, multiple maxscript parameter names have changed and I have to fix those first. I'll make a "daily-builds" converter version soon.

Awesome! appreciate it! Hoping to see it very soon :D  oh please oh please?

2014-12-08, 15:48:48
Reply #371

racoonart

  • Active Users
  • **
  • Posts: 1446
    • View Profile
    • racoon-artworks
FOLLOWING SCRIPT IS ONLY WORKING WITH DAILY BUILDS!
Script is attached to this post.
Since there has been quite a change in the maxscript properties I'd be very happy if it got tested sooner than later.
I'm also doing a bit of performance debugging. If some of you could copy&paste some of the stat infos that are printed in the maxscript listener it would be helpful :) It looks like this:
Quote
INFO: Converting scene materials...
INFO: Converting Material Editor materials...
INFO: Conversion took 0.767 seconds
INFO: 73 Iterations through Material classes
INFO: 0 Material instances have been converted
INFO: Replace unsupported maps...
INFO: UpdateFix took 0.373 seconds to complete

changelog:
*v0.23_dailyBuilds
  • updated maxscript properties to new naming scheme
  • added selection set for objects which had autodesk materials
  • added tool for switching BSDF models
  • if renderer assignment for material editor is not locked, "switch renderer" function will also change material editor renderer

No solution for the bitmap blur thing yet, sorry.
[Edit] Little stats update in a new scriptfile
« Last Edit: 2014-12-08, 16:13:12 by DeadClown »
Any sufficiently advanced bug is indistinguishable from a feature.

2014-12-08, 15:54:15
Reply #372

snakebox

  • Active Users
  • **
  • Posts: 493
    • View Profile
    • Snakebox Media
Thank you so much for doing this so quickly!  Hero!

2014-12-08, 17:02:35
Reply #373

Dom74

  • Active Users
  • **
  • Posts: 95
    • View Profile

2014-12-08, 17:55:29
Reply #374

xt13r

  • Active Users
  • **
  • Posts: 157
  • Viva la Corona!
    • View Profile
    • my portfolio
so cool! thank you very much! You are the best, DeadClown!