PDA

View Full Version : Animated GI new look (flicker free)



artzgo
03-08-2015, 02:01 PM
HI,
check this video ... dwuklik.com/LW_GI.zip
https://www.youtube.com/watch?v=5YXlyip0Z8A
I did ti with an animated GI in the native renderer LW, render time about 2min/frame Full HD (1920x1080) on dual Xeon E5-2696 12core
No flicker, if you very look, you can felel the minimal flicker but at acceptable level

I cache GI with the Animation option but only for a few frames ... for a video above were frame: 1,50,90,130,170,215 and 250 ... Why? ...
In this mode LW placed only the samples for the 3D scene, if there are a lot render it takes a very long time, need to do so the information GI overlap but that was not too much of them.
After the cache GI Preprocess leave the automatic, lock the cache file in windows explorer (read only) and rendered by F9 Render Sequence plugins, you can rendered by F10 but rendering time is longer
setting for the scene 127355

Test the way!!!

Chrusion
03-08-2015, 05:23 PM
True. There is no issue using Animated GI cache sequence files (generated ONLY when frame step > 1) and rendering within LW Layout. It is only broken when using cache sequence files in LWSN. There is no issue rendering with LWSN when a single cache file (generated ONLY when frame step = 1) is used.

artzgo
03-10-2015, 12:47 PM
Next test, render time about 50sec/frame

https://www.youtube.com/watch?v=fYjkCRGEiUI

erikals
03-10-2015, 01:21 PM
interesting, would it be possible for you to share the scene?

just so we can have a quick look at the original?

note, this is 50sec/frame on a dual Xeon E5-2696 12core though, i won't be expecting that myself... http://erikalstad.com/backup/misc.php_files/smile.gif ...quad core here...

artzgo
03-10-2015, 02:48 PM
no problem, make sure to download

http://dwuklik.com/GI_TEST.zip

I noticed yet that more the Rays Per Evalution rendering speeds up, first flight (red progress bar) slower but another pass faster and AA are almost no anything to do

erikals
03-10-2015, 04:49 PM
thank you, as i suspected, Youtube compressed the heck out of that video file, the F9 render looks 5 times better http://erikalstad.com/backup/misc.php_files/smile.gif

seems LW won't read that locked file though, it forces and creates a .cache.temp temporary one instead...
i vaguely remember this issue when zipping and sharing a .cache file, but can't recall the solution... :

even changed the ContentDir at the very end inside the .lws file...

hm, any ideas anyone... ?

DAMAKERS
03-10-2015, 09:31 PM
hi erikals, right click the file, select properties and uncheck "read only" box :)

erikals
03-10-2015, 09:37 PM
thanks, yes, but if i do that the above trick doesn't work... \ : )

DAMAKERS
03-10-2015, 10:44 PM
Well, in that case, the only thing that comes to my mind is to assing the cache file with the same name into a desire folder and replace it with the locked file to see if it works.
I have not test that, but may work, is late here but can test it tomorrow

artzgo
03-11-2015, 02:11 AM
Well, in that case, the only thing that comes to my mind is to assing the cache file with the same name into a desire folder and replace it with the locked file to see if it works.


exactly !!!

Chrusion
03-11-2015, 07:01 AM
I'm getting confused here. What are you guys referring to re. cache file (singular) and moving to a different folder, etc.?

If you do a frame step > 1 and "Bake Radiosity Scene" you'll get cache sequence files (plural), eg. radiosity.cac.0, radiosity.cac.10, etc. So, what are you doing to bake the scene? Manually advancing the playback head on the timeline and "Bake Current Frame?" Why verse letting LW bake scene using frame step?

As far as I know, LW Layout renders flicker-free when the Preprocess mode is set to Never. No need to fiddle with setting the actual file(s) read-only bit, or whatever this "trick" you're referring to is. For me it's LWSN that's broken in this regard (cache sequence files).

Every4thPixel
03-11-2015, 07:41 AM
Ray precision 200? Why?

lardbros
03-11-2015, 08:14 AM
Glad someone else is investigating the LW GI caching. It's all a bit of a mess... especially as internally, LW is doing something different when it's set to frame caching steps of 2 more, compared to when it's set to 1. (Or this used to be the case anyway.)

Here is a snippet from Mark Granger (the guy who programmed all of this):
This is working exactly as intended. With a frame step of 1, you are using the original style animated radiosity cache. This was intended to allow you to move objects in the scene and have the samples stick to them. It works in some cases but most of the time it generates too many samples to be useful. We added multi-frame animated radiosity to provide an alternate method of allowing animation for scenes with interpolated radiosity. This bakes each frame as usual on each frame step. For the inbetween frames, it blends between the two radiosity solutions. This requires that it store twice as many samples but in practice it is a lot faster than the original animated radiosity. Rendering a frame between two cached frames uses interpolation which is why it is fast. If you render a frame outside of the frame range, the samples must be calculated so it is slower. The other choice for animated radiosity is to turn off interpolation and use adaptive sampling to smooth the noise. This can be quite slow but may actually be faster than the original (frame step of 1) animated radiosity and does not have any temporal issues (flashing or odd motion of the lighting).

Chrusion
03-11-2015, 08:56 AM
The way preliminary radiosity samples are calculated in full when generating cache sequence files has at least one bug... if an object encloses the scene (eg. reflection sphere, etc.) and is set to "Unseen by Radiosity," then the resulting render will flash slightly lighter or darker on each frame step frame. LW never did this using the "old," single cache file method prior to 11.6.

And, again, screamernet (LWSN) is broken when using cache sequence files... it appears it doesn't load both previous/next frame step cache files and interpolate between them for in between frames. IOW LWSN calculates all new samples every frame as though you didn't even bake the scene's GI cache (ie.. GI flicker/shimmer).

Chrusion
03-11-2015, 09:15 AM
Mark Granger wrote:
[single file cache] was intended to allow you to move objects in the scene and have the samples stick to them. It works in some cases but most of the time it generates too many samples to be useful.
I've always minimized this tendency by setting Min. Pixel Spacing to 5 or 6 instead of 2 or 3, which generates less samples at poly intersections and corners, etc. This method worked well, so not sure why it was "fixed/changed" to the cache sequence file method. The single file method established a base/foundation set of samples on the first frame and subsequent frame steps simply added new samples as new geometry came in to camera view. Existing samples from the previous frame step became the base for the next frame step.

I think the flaw of the single file cache method prior to 11.6 (which allowed frame steps) was a progressive increase in frame render times for long duration scenes of greater than 1,000 frames due to the build up of samples, even though the camera or objects had moved significantly "out of range" of the initial batch of samples.

jasonwestmas
03-11-2015, 09:45 AM
not bad but that video shows a very noticeable "heatwave" kind of look to the stairs.

erikals
03-11-2015, 09:51 AM
as far as loading a shared .cache file, i'm kind of stuck... not sure why...
my findings when loading a shared .zip file...


http://youtu.be/8-HTuOn1JaM

sorry for long video...

maybe this also is related to the screamernet problem, not sure...

Chrusion
03-11-2015, 11:22 AM
@3:00 the most likely reason it's recalc'ing is because Preprocess is set to Automatic and the cache file is set to read only... meaning, LW can't open the file for writing any additional samples it finds that aren't already in the cache. Automatic is just that, LW automatically selects whether to ALWAYS refine the existing solution in the cahce by adding new samples or NEVER do so based on what going on in the scene.

Also, it's best practice, if not mandatory, to create the missing "radiosity' folder in your content dir. as specified as the DEFAULT in your LW prefs Path tab @ 2:32. Your LWS will then properly read "RadiosityCacheFilePath radiosity/GI.cache" after selecting that location in the GI render globals panel.

Strange settings @6:54!! 60% Multiplier? You know what that does, right? It simply scales the pixel shading "map" by the percentage entered. Thus 60% of your 1920 x 1080 render dimension = 1152 x 648, which is then scaled up to fit the frame. Yes, scaling it down saves a bit of calc time, but it also introduces shading artifacts (flicker/shimmer?) due scaling up a smaller shading map to the original frame dimensions. Just go with 100% for animations in order to preserve the pixel-for-pixel sampling and adjust RPE, SBR, MPS, etc. to achieve faster calc times.

Also, 0.3 for Min. Pixel Spacing? Why? No wonder the renders are taking so long. That's really no different than brute force, non-interp MC. Set that puppy back to 3. The idea here is to space out the samples and let the interp mode of MC do the smooth shading of pixels in between samples at high-density locations like 90 deg corners, etc... not put samples on every pixel! 300 Max Pixel Spacing is probably OK for 1080 HD. That value needs to scale with the frame pixel dimension. I use 100 for 720 HD.

@7:10 GI.cache.temp makes perfect sense, because you've prevented LW from writing to the GI.cache file by setting the read-only bit, and it wants to write to it because Preprocess is set to Automatic and LW wants to refine the existing solution by adding more samples. It can't write to the file, so it creates this temp file.

@8:00 Overwrite does NOT delete and replace, as you discovered! This is just a standard Win OS dialog, not LW generated. So, YES, click OK! This then allows LW to open and write to the file. Again, per above, create a 'radiosity' folder first, move the cache file into it, THEN set the path to 'radiosity' and DO NOT set the cache file read-only bit. INSTEAD, set Preprocess mode to LOCKED. This tells LW to NEVER refine the GI solution and not add more samples to the existing cache... just use the cache as is.

erikals
03-11-2015, 05:14 PM
@3:00 - yes, i think the reason is that for some reason it works if it's done on one machine,
but not when sharing it. yes, probably right, automatic forces a new .temp file...

@2:32 - yes, could be a good idea making that radiosity folder

@6:54 - i don't think 60% Multiplier is that bad, as you state, it will save some rendertime,
guess it depends on the camera movement and scene how low one should make it...

0.3 for Min. Pixel Spacing? i wouldn't usually recommend setting the pixel spacing to higher than 1.0...
That's really no different than brute force, non-interp MC - Brute force non-interpolated MC takes waaay longer, i cannot agree there. i read some guys had some nice results setting it to lower than 1.0 can't find that post though.
but really, Brute force non-interpolated MC can't be compared, i'm doing a test render now of Brute, and its at least 20 times slower, with noise...

@7:10 GI.cache.temp makes perfect sense - yep, thanks for the clarification, looks to be right http://erikalstad.com/backup/misc.php_files/smile.gif

@8:00 thanks, that seems to fix it, not sure how i missed that one, been a long time since i used locked in LightWave (2010) might be the reason...

thank you for the feedback, finally nailed it thanks to your help... http://erikalstad.com/backup/misc.php_files/king.gif http://erikalstad.com/backup/misc.php_files/smile.gif

Chrusion
03-11-2015, 09:01 PM
@2:32 - yes, could be a good idea making that radiosity folder"Could" sounds optional. I'd say you would be better off using the content dir structure (folder names) as defined in the Path Prefs.


@6:54 - i don't think 60% Multiplier is that bad, as you state, it will save some rendertime, guess it depends on the camera movement and scene how low one should make it...If anything I'd reduce by factors divisible by 2... so 50% or (heaven forbid) 25%, because you'll get a cleaner, power of 2 mathematical result.


0.3 for Min. Pixel Spacing? i wouldn't usually recommend setting the pixel spacing to higher than 1.0...Why? 1 pixel is the closest any sample will be from another, yes, but the locations of where those will be placed will be very rare (only in the most "tight" geometrical places). For the rest of the frame, the samples will "fan" out to a distance of your Max spacing, in this case 300 pixels apart. And this is where the majority of samples will find themselves. So, what difference does it make, except in both pre-calc and render times, to space the far fewer samples at a min distance of 3 pixels vs. 1, when the vast majority of samples will be 5, 21, 62, 129, 273, et. al. pixels apart?


"That's really no different than brute force, non-interp MC" - Brute force non-interpolated MC takes waaay longer, i cannot agree there.Non-interp MC is WAAAY slower because EVERY FREAKIN' pixel is sampled! What I intended to infer here is that setting MPS = 0.3 is guaranteeing that far more pixels than necessary WILL BE 1 pixel apart. The purpose of interpolated MC is to significantly reduce the number of samples so that NOT every pixel is a sample and then let the interpolated shading engine fill in the gaps between samples.


but really, Brute force non-interpolated MC can't be compared, i'm doing a test render now of Brute, and its at least 20 times slower, with noise...Of course, because your firing the number of RPE rays for every pixel in the image as well as multiplying that by the SBR value. So, heck yeah, there's bazillions of rays being fired and of course it's going to be slower. Oh, and then multiply that by the number pixels selected by the AA threshold value, multiplied by the Max AA Samples.


finally nailed it thanks to your help... YAY! Your welcome.

erikals
03-11-2015, 11:43 PM
If anything I'd reduce by factors divisible by 2... so 50% or (heaven forbid) 25%, because you'll get a cleaner, power of 2 mathematical result.
usually i'd agree, but i'm not so sure the power of 2 applies in this case. so no big deal imo.

So, what difference does it make, except in both pre-calc and render times, to space the far fewer samples at a min distance of 3 pixels vs. 1, when the vast majority of samples will be 5, 21, 62, 129, 273, et. al. pixels apart?
there is quite a difference (imo, but each to its own), as the thin lines in the render will get more noise the higher the minpixelspacing is...

The purpose of interpolated MC is to significantly reduce the number of samples so that NOT every pixel is a sample and then let the interpolated shading engine fill in the gaps between samples.
yes, but my second answer applies here as well.

so, maybe we basically agree, sorry to make you misunderstand...

Chrusion
03-12-2015, 10:34 AM
As I predicted... baking GI cache at frame step = 1 (single cache file) is a time washout compared to baking every 10th frame (cache sequence files).

I just rebaked the beginning 565 frames of an outdoor (Texture Environment HDR illuminated) scene at frame step 1 with all ray trace options Off. It took around 25 minutes and is rendering flicker free over the network.
The same scene was baked at frame step 10 with ray traced options on (shadows, reflections, AO - all required due to the way baking in this mode works. Meaning, if turned off, each frame step frame would render slightly lighter or darker than the in between frames. Why? No idea. It's just bitten me in the butt a few times until I tracked down why.). It took around 28 minutes, but, per the reason(s) discussed above, renders with GI flicker/shimmer over the network.

Too bad that we can't bake to a single cache file with frame step greater than 1. It would get us BACK to even greater time savings that we had prior to 11.6. Albeit it would only be a few to a couple dozen minutes and be just a drop in the bucket of time compared to the actual total render time of the animation, it still seems like a good idea to bring this option back in LW 2015.x.

erikals
03-12-2015, 12:51 PM
i haven't had the time to look at it, but this technique from Gerardo surely looks interesting >
http://forums.newtek.com/showthread.php?146003-Gerardo-Estrada-DPont-Denoiser

Before >
http://forums.newtek.com/attachment.php?attachmentid=127447&d=1426180915

After >
http://forums.newtek.com/attachment.php?attachmentid=127450&d=1426181014