EZLight-II ( for Sycles II )

[FXDude]

Hi !

I wanted to release this before 2024, so technically, at least in my time zone we are a few minutes from midnight, so I'm good lol
( I literally finished the video edit a few minutes ago )

So here is "EZLight II" ...

EZLight-II.zip



... which is a second iteration of something I released a while back, ...
( viewtopic.php?p=62431&hilit=sycles#p62431 )
... but working with Sycles II while being MUCH faster.

Like EZLight, with EZLight-II you can just position the sun orientation
to have it's color/intensity AND the sky color/intensity self adjust accordingly, and includes a post processing tree.

Except that now you can take advantage of some of the new stuff, like improved denoising which got much more stable across frames,
and therefore allows to further decrease samples, thus can definitely shorten render-times,

But then "wobbling" artifacts can become noticeable in high frequency details, the lower the samples are set.

So the included FXTree, instead of mostly adressing interframe "splotches" noticeable in wide gradients in animation,
it now also stabilizes "edge wobbliness" artifacts in high frequency details that don't move too much,
WHILE enhancing detail using AO, and doing so without significantly lightening things in open space, or darkening things in corners.

And so overall do renders require considerably less samples ;
here using 256 samples, making for 3 to 6 minute renders,
relative to the 1024 samples in Vers.1 of EZLight,
which would take 10 to 15 minutes per frame before the "post-interframe-desplotching" process.

In other words, like most renderers, the more time passes, the more time it takes to clear-up remaining noise ,
and 256 samples is just about where even SEVERAL TIMES as much rendering time wouldn't make a huge difference
or we're supplying just enough samples for the post-process to yield what I personally considered to be "good-enough" frames .

Also BTW, most reported Cycles rendertimes for interior animations on the BlenderArtist Forum
is well above 30 minutes, in not more than an hour, but several Blender addons can also help with that.

Otherwise, particles are coming next !

Cheers, and of course
HAPPY NEW YEAR !!!!

[rray]

Happy new year to you and to all 🐽!

And what a nice surprise! Good to see new XSI stuff still coming out. Result looks fantastic, amazing how much information can be recovered from the raw data. Will check this out, I think I've opened the FX Tree window 2 or 3 times in my life so far.

Congrats btw on your 1111th post!

[matevil]

nice!

It's only on my side or link for download doesn't work?

[rray]

Looks like it works now (after edit)

[matevil]

Looks like it works now (after edit)

thanks

[rray]

Trying to add this to the resource section (totally missed adding EZLight I - sorry about that!!) but it looks like it might take a while getting the resources database to behave.

[FXDude]

nice!

It's only on my side or link for download doesn't work?

Hi sorry, I was rather sparsely at my computer after new-years,

And what a nice surprise! Good to see new XSI stuff still coming out. Result looks fantastic, amazing how much information can be recovered from the raw data.
Will check this out,
I think I've opened the FX Tree window 2 or 3 times in my life so far.

Congrats btw on your 1111th post!

Thanks for the comments !
( And for fixing the link ! )

Also, now the same link points to a yet newer version of the same scene, but with included preview settings
as the previous "PreviewSettings" pass, was actually using final render settings ...

.. and the final "RenderSettings" pass now has all necessary AOV's enabled,
because I would personally only output the main combined AOV, since Normal & Position passes etc.. would not change across my tests.
I also got rid of unused passes, an tidied things up more.
( you can re-download the .zip file if already downloaded, & you may want to save as presets, for later retrieval of "Preview" and "Render" settings )


... and a bit more about the included preview settings ;
apart that denoising can be great for final renders, it can also of course be great for previewing !

Or the denoiser can make "chunky" yet still quite excellent approximations of how things would look like in the end,
but even if given almost insignificant amount of samples to work with !
( which would look horrible in animation, but that's not the point here)

In the "non-sped-up" example below, using just 8 samples makes for mere 3 or 4 second long renders,
while producing quite representative results within that time,
and which can generally make the process of lighting & lookdev-ing become SUPER-FAST ... and not to mention ... SUPER-FUN !



Also, unlike the "RenderSettings" pass that uses the GPU with OpenDenoise,
the "PreviewSetting" pass uses the CPU with NvOptixDenoise.

Because even if the CPU samples the scene much less than the GPU given the same amount of time,
the CPU conversely updates the viewport much more frequently,
which was the priority in the case of live viewport previewing,

And it uses OptixDenoise, because denoising only takes one second out of the ~4 second renders , while being fine for previews,
relative to the "RenderSettings" pass using GPU with OpenDenoise, as it's seemingly slightly more stable across frames,
while taking a bit longer, but 3-4 seconds for denoising after 4 minute renders @ 256 samples is also fine.



________________________
Otherwise, no need to worry about having to deal-with, or manage the FXTree itself,
it was originally meant to need little or no adjustment to work with an "onRenderFrameEnd" script
sending commands to another XSI instance with the FXtree open, overwriting original frames ( or not ) as the render progressed.
( script not included because it's not not at-all made yet lol )

So in the scene, all the nodes in the tree are actually "collapsed" to the same spot,
making for a "simplified pseudo-compound",



And so for now, all the user needs to do, is pipe-in the corresponding AOV's, and set the output path.

You can untangle the nodes if you want to see it's guts,
or you can ask me for the tree to not have to untangle 50+ nodes, or if you'd like to reproduce it in Nuke, Natron or Fusion ...
( BTW, Natron eventually became 95% Nuke ! like they basically reproduced most of Nuke,
minus the 3d environment despite a handy "3dCard" transform node, and minus DeepImage support )

Otherwise ---> wow! t'was my 1111th post !?
( must be cosmic alignment lol )

Cheers !

[rray]

Very cool thanks for the detailed information, I'll use this as the FXTree initiation ritual

I've updated the resource site, let me know if I can add/should remove stuff I typed!

Thanks for the release of this!

[FXDude]

Very cool thanks for the detailed information, I'll use this as the FXTree initiation ritual

FxTree is awkward & "clunky" lol, but it's functional, and perhaps especially it's "built-in".

BTW, I mentionned various comp apps, ;;

... if you'd like to reproduce it in Nuke, Natron or Fusion ...

but post processing of XSI renders can also happen in Blender itself ...

... the following seems to go a step further, by using motion vectors to "warp" pixels to match surrounding frames before merging them ::

( using a much more elaborate city scene, but interior renders are always very good or "difficult" stress tests )

But otherwise, with motion vectors, then MotionBlur would also need to happen in post (?)

Because as far as I know, Cycles requires MotionBlur to be OFF to output motion vectors,
while although Blender's post-MB is also quite good or artifact free, for things like features in transparency and/or reflections, it remains 2.5d.

I've updated the resource site, let me know if I can add/should remove stuff I typed!

Thanks for the release of this!

No ... no .. thank you ! & the resource section entry/description seems great !

[FXDude]

.. seems to go a step further, by using motion vectors to "warp" pixels to match surrounding frames before merging them ::

( using a much more elaborate city scene, but interior renders are always very good or "difficult" stress tests )

the following suggests that it was me that went few steps further,
because it seems that "warping pixels" using motion vectors, isn't a "silver bullet", then still having to deal with "ghosting artifacts" around moving features,
and indeed involves having to do MotionBlur in post.

Here the author refers to the method in the previous city clip,
while proposing a "better solution" using a difference mask from depth which covers moving elements outlines, ...



So the "EZLight" post process goes a few steps further, as it also covers "ghosting artifacts" in moving texture and bump details
(using position, normals, and "Diffuse Color" channels )
..and apart from "enhancing detail" using AO, it is also universally applicable "worry free", or without adjustments.