If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
New! You can now log in to the forums with your chaos.com account as well as your forum account.
You can increase the Lens effects' Threshold value to diminish the effect, however, I'm not sure if the behavior in this particular scenario is correct. Could you send the scene via the contact form so we can take a look? Address it to me in the subject and post a link to this thread in the message.
You can increase the Lens effects' Threshold value to diminish the effect, however, I'm not sure if the behavior in this particular scenario is correct. Could you send the scene via the contact form so we can take a look? Address it to me in the subject and post a link to this thread in the message.
Hi, after spent a day with turning on and off objects in the scene, I have solved the problem.
It causes by a standard blend material on a 3d object, I switch the material to VRayBlendMtl, it works perfectly now.
If you've added another light between the renders, the values will restart. The recommended workflow is Render with LightMix > Make Adjustments > To Scene > Render.
If you've added another light between the renders, the values will restart. The recommended workflow is Render with LightMix > Make Adjustments > To Scene > Render.
What I do is save the lightmix, so that when I'm tweaking I can easily load in/out different setups.
In an ongoing project, a series of close-ups with very different settings for each, I do not want to send those
changes to the scene, as it results in me having many separate scenes.
So whilst it isn't the 'recommended' workflow it is in many circumstances the 'ideal' workflow and imo should be expanded to work more like this
and include other lighting types such as unique self illumination entries
In my example I have one 'mother' scene with 10 saved lightmixes, saving me an enormous amount of time, especially
when they return to make iterative changes.
Would it help if the LM created scene states for the changed entities when the changes were sent to the scene?
Those would then be able to be rendered with batch, while remaining a single scene file.
I think, using my example, that that would just create an extra step, so I would avoid that as it's actually it's pretty much fine as it is....just not what I'd advise to be the 'recommended' use.
Basically my opinion is to keep it as it is - with the ability to save mixes to use as in my example, or to send the changes to scene if one needs - and if possible
extend its functionality (the only thing currently I see as missing) to include entries for unique self illumination materials, if that is possible.
If not then cool, it's still a great boon to us all as it is
Eh, there is a logical loop i can't find the way out of:
If you *just* save the mixes, then you lose the connection with the scene in potentially irreparable ways (i.e. the saved mixes become useless.).
Consider this: white light, make an LM change so it's blue.
Save the LM mix to disk.
Save the LM changes to scene.
Now the saved mix is useless for that scene, as it'd apply a blue cast to a -now- blue light.
Analogous for multipliers: there's the very real chance to apply mixes twice (which isn't useless, but rather dangerous), as there is no correlation left between the saved mixes and the state of the contents of the scene.
In a one-user scenario, with a tidy, strictly controlled user, this is a minor issue.
Multi-user, bigger pipelines, or slightly more rushed work, this can become a nuisance quickly.
However, if the LM (optionally) saved scene states (ideally with some naming best practice, tied to the mixes saved on disk ) then one would know to always go back to the original scene state (the example light would then go back to the original multiplier and color), and *then* load a saved mix, or simply load the corresponding scene state to get results directly in rendering.
Getting the results into the scene *asap* is the suggested workflow because of noise levels: play just with the LM, and as you double a light's intensity, its noise contribution also doubles.
The *only* way to not get that is to use the adaptive sampler during a render of the light with doubled energy.
Notice this is a standard compositing tenant: I'd often render some scene one or two stops brighter to allow Compositors the post-exposure latitude without exceeding the necessary noise levels.
As for individual self-illum materials, i doubt that's practical due to their usual average count, often much bigger than that of lights.
However, you could get places with LPEs, as you can select specific materials and nodes' contributions, and composite that with the results of the rest of the LightMix.
I have a scene with a product with various coloured internal lighting. I have the main scene that I need both a main shot from, as well as multiple close up shots.
So, multiple camera views, each with a slightly different lighting setup and whatever other change to get the best shot.
For each camera view I tweak the lightmix and save that for each specific view.
In that way I can make scene-global changes, yet have a consistent and camera-specific lightmix for each view as I iterate based on feedback.
This is useful in all sorts of ways but mainly, again in this specific case, to adjust the light bleed onto other materials or additively colour the end shot, or to adjust the lens effects...all in a non-destructive way, as it's only a lightmix and not in the scene.
It has saved me from a total nightmare in this case, as they seem incapable of making up their minds.
I completely understand about the noise levels and have experienced that (I can't find the post right now but it's about my range rover scene where I was asking explicitly about that noise thing).
So I now know to avoid such extreme tweaks to the original lighting as it can royally fuck up my end result That was in the first days of using it however
Having it linked to scene states is a great addition for sure, as it would no doubt come in handy.
The self illuminated thing....yeah I thought that may be a big ask. In my mind they constitute 'lighting' but it's fine...I can compensate for that lack.
Thanks for the LPE pointer....will probably avoid that for the moment but good to know.
Yeah, it's as I "feared": the VFB2 is turning into a mini-nuke eheh.
We hear you, that case *is* common enough, but currently has the outlined pitfalls.
Not simple to work around of, given it's all live with a 3d scene it depends on, but then simple is generally boring. XD
....a sort of 'tactical nuke' really
Anyway, it wasn't my idea to create a renderer that everyone seems to like and want more from
Mission-creep is unavoidable. It's made my life wonderfully simpler, so, much applause...but get on and
make it even better you slackers!
What I do is save the lightmix, so that when I'm tweaking I can easily load in/out different setups.
In an ongoing project, a series of close-ups with very different settings for each, I do not want to send those
changes to the scene, as it results in me having many separate scenes.
So whilst it isn't the 'recommended' workflow it is in many circumstances the 'ideal' workflow and imo should be expanded to work more like this
and include other lighting types such as unique self illumination entries
In my example I have one 'mother' scene with 10 saved lightmixes, saving me an enormous amount of time, especially
when they return to make iterative changes.
Would it help if the LM created scene states for the changed entities when the changes were sent to the scene?
Those would then be able to be rendered with batch, while remaining a single scene file.
Do you mean use LM with scene state, haven't try it befoe, any tutorials?
Comment