[JDHill]

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.

[numerobis]

a "render on network"-button would be nice!
would it be possible to implement some sort of a preset, where you can define a fixed output folder, if it's coop or not and set an automated naming of the mxi and mxs based on the image file name? So that it would start the render directly from Sketchup.

[JDHill]

Did you check this post: http://www.maxwellrender.com/forum/view ... 23#p330623

When you render to the network, you will see the job wizard -- afaik, that's just how it works, meaning, I don't think I have a way to bypass it. But I'll have to ask Juan -- maybe there are some hidden command line options.

[numerobis]

yes, i've seen this. Thanks! I'll try it!
It would be cool if the direct start could be managed.

[brodie_geers]

I agree that it would indeed be nice to be able to bypass having to go through the network dialog every time. Particularly since the dialog is to tall for my screen and doesn't have a scroll button, nor can the size be changed. I often end up having to hit enter and hope it works since I can't see the confirm/cancel buttons at the bottom.

BTW, JD, the network button seems to be working great Thanks again,

-Brodie

[Half Life]

I thought I was the only one with that problem -- reeeeaaaaalllllyyyy old monitor... like stone-age old.

Best,
Jason.

[brodie_geers]

I thought I was the only one with that problem -- reeeeaaaaalllllyyyy old monitor... like stone-age old.

Best,
Jason.

I've got 2 monitors, both pretty new. I think the problem is the aspect ratio. Mine are at 1440x900 so I think there's just not as much height as most people have. It was brought up awhile back. I'm hoping it will be fixed soon. In the meantime if I bring the dialog over to my second monitor (without the task bar along the bottom) and bring it up as high as I can, I can just barely see the tops of the buttons).

-Brodie

[Richard]

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.

[JDHill]

Thanks Richard, I have a clearer picture of what you want now. Still, this solution strikes me more as a hack -- I'd prefer to fix/implement things where they properly belong, and in this case, I do think that means that it should be addressed in maxwell.exe itself.

To that effect, I have put in a request that maxwell.exe would be able to automatically remember the state of your multilight sliders (when possible, but not failing when impossible) between rendering sessions without you needing to manually load emixer files.

[brodie_geers]

Environment-tab:
- Sun on/off unlinked to SketchUp. I would prefer a completely unlinked shadow-setting (or an option to link/unlink to application).

This was suggested by Stefan awhile ago. Just wanted to add a +1. I've had a lot of issues with the sun turning off on me which has lead to a number of wasted renderings.

-Brodie

[JDHill]

For me the real question is whether the linking should be optional or not -- I haven't answered that for myself yet, and so have not changed it, since making it optional requires both UI and logic changes. So let me know your opinion.

In the meantime, you should be able to de-link it permanently for yourself by going to plugins/maxwell/lib/observers/shadowinfoobserver.rb and commenting-out (i.e. adding a '#' in front of) lines 17-19, so they look like this:

Code: Select all

#              sun_enabled = shadow_info["DisplayShadows"]
#              Util.set_property(model, "environment", "environment.sun_enabled", sun_enabled)
#              Dispatcher.send_request("environment.sun_enabled", sun_enabled)

[brodie_geers]

Thanks. I really appreciate your little ruby hacks you've been dishing out to allow us to customize your plugin to our own whims and needs.

I think my problem with the linking is that it's not an all or nothing thing. Meaning, what I see in my viewport may or may not be what I get in my rendering and I'm never sure which it will be without checking the environment panel, eliminating any benefit of having the link.

I can't really test it since I already made the ruby tweak, but I think the problem I was running into was that I would turn on shadows and tweak the settings to get my sun where I wanted it. Once I've got that set, I'll turn them off and at some point I'll make sure that the sun is turned on in the env panel. But then I might turn the shadows on again, perhaps by going to a scene with them or or something like that and turn them off again but forget to go back to the env. panel again.

I think I'd probably want 2 options. One option where they're totally linked so that the env. panel always matchs up with the viewport (ie. if I enable sun in env. it enables it in SU). And another option where they're totally unlinked and one doesn't affect the other. I would probably mostly use that second option because I never want shadows on in SU (unless I'm specifically adjusting them) but I always want them on in Maxwell (as an arch-viz guy).

-Brodie

[JDHill]

All valid points. At first, they were simply linked, and it wasn't until I got into testing some more complex scenes that I really realized how much the shadows slow down SketchUp. So, my reasoning changed to: if you turn shadows on in SketchUp, I will assume that means you want to render them. That should be pretty obvious. The difficulty only comes when you turn them off: why are you doing it, for performance, or not? And of course there's no way of answering that question analytically.

So, I lean towards a simple replacement of the Sun toggle with a drop-down; similar to what you suggest, it would have on/off/linked choices.

[brodie_geers]

Yup, sounds perfect.

-Brodie

[numerobis]

yes, sounds good!

does the environment settings for maxwell can be saved separately for every scene?