JDHill wrote:does have a downfall if an additional emitter material is added
But I don't see the problem with that. If I've understood you correctly, you are basically asking for an extra 'multilight power' slider in the plugin's emitter UI. In which case, you are just ending up with two sliders for the same thing: the total power of the emitter. Nevermind that we already do basically have two -- watts & efficacy. So, there would be three, and you would not know what the multilight slider should be set to until after you had already rendered once...and by then, its multilight value would already be contained in the proposed .ml file.
Or have I missed the idea completely?
Keeping in mind too that this is all academic: I really have no way to pre-set the position of your multilight sliders from the plugin.
JD the issue with adding an emitter comes about even in MXCL - if the emixer file was saved with 5 emitters it wont load of a 6th is added.
I do understand your suggestion that there are already two sliders- given yes! though what I'm suggesting is a third that adds a multiplier by percentage rather than one having to do the math and then obviously most often run out of efficiency value where that material covers large emitter numbers.
I'm actually not suggesting this then sets the multilight sliders later, just that after a first test one can set their emitters at the ML and test under the same lighting levels.
The whole aim is to over come the pain in bum issue that is current when testing (and this is where most is to be gained every time in the process) - I just consider the time taken with the workflow listed below that HAS to be undertaken with every subsequent test.
Current workflow:
1. export with ML enabled
2. adjust ML sliders
3. save emixer file
4. stop test when convinced
5. return to SU make any tweaks
6. export next test with ML enabled
7. Load emixer file
8. stop test when convinced etc!
No with this WF some issues occur, in each test ML needs to be enabled and emixer file loaded, if one doesn't get this done quickly one has to await update to see propoer consistant result. Obviously this can be overcome updating the efficiency values for the emitter material but it may not achieve the limits permitted by a high level ML value (ie in the 1000's). In fact this aspect of reloading the emixer each time drives me bloody CRAZY! Partyicularly if interupted and I don't get the file loaded quickly - it also slows the process and loads the system using ML, correct?
The other issue IF at point 5 I add an emitter material to the scene the emixer is no longer relative and cant be utilised and I'm f*#^ed! adjust and try to get it right again.
My suggested workflow:
1. export with ML enabled
2. adjust ML sliders
3. stop test when convinced
4. return to SU make any tweaks to model and set emitter material exponent to match ML value,
5. export next test with ML disabled
6. stop test when convinced etc!
Now the beauty here is that I'm not needing to each test export with ML enabled and I don't need each time to load the emixer file which as stated in the case an additional emitter material is added to the scene it wont load anyway then I need to attempt as close as possible to achieve the same levels.
But the biggest one I can continue working, being interupted etc and soon as I flick to MXCL I can see the correct result instantly without touching and tweaking.
Certainly when I hit my final render I will enable multilight so as to fine tune lighting but the point is not during testing to get the exact result but one of consistancy so results can be measured and to cut workflow, app switching and a faster WF all round!
It will also mean that once i export my final the lighting is tweaked slightly from 100% not one slider at 10000% and another at 5%!
I'm not sure how others work with emitter materials but for me I use ML completely to adjust light power and count very little on the emitter material settings - in fact for all materials I set the colour in SU and rely on the default power values then tweak away in ML, I'm then suggesting this as an alternative to WF. Again at least if the option is there we aren't forced into a WF that is counter productive on testing quickly.
Certainly reading the values from the emixer or MXS file would suffice as long as it doesn't create the same shitty issue that comes with the current failure to load an emixer when a material is added.