PDA

View Full Version : Animated GI Cache Flicker



Chrusion
08-15-2011, 08:51 PM
I'm using interp MC GI for the interior of a large, house-sized, air filtration unit illuminated by a single point light. I've baked the scene's radiosity to a cache with frame step 5, 250 rays, 10 Secondary, MinPS 1, MaxPS 10, 50% Multiplier, and 2 Indirect Bounces.

Rendering via Screamernet via BNR and am getting the dreaded radiosity flicker! Yes, all screamers are seeing/reading the cache on the shared network folder.

Isn't cached GI supposed to prevent/eliminate flicker?

See the attached 650KB high def QT clip (10 frames, so set QT to loop).

Do I need to up the primary rays to 500 and secondary to 20? Does that require rebaking/remaking the cache?

The odd thing is, with these exact same settings, there is no flicker when I rendered the exterior of this unit with a single sphere light and an LDR image mapped sky dome for fill. The view is much more distant, so maybe if there is flicker it's that much smaller, but still confused.
.

Chrusion
08-16-2011, 05:41 PM
It appears everyone is just as not-in-the-know as I am...Bummer, cuz 500 RPE and 20 SBR didn't decrease or eliminate the slight shimmering GI shading flicker.

Well, at least the HV particles look good, albeit crispy, even though they don't motion blur with the Volumetric AA setting off as I don't want to spend 3 weeks rendering them at 2 - 8 hrs/frame with Vol AA on.
.

jameswillmott
08-16-2011, 05:50 PM
It appears everyone is just as not-in-the-know as I am...Bummer, cuz 500 RPE and 20 SBR didn't decrease or eliminate the slight shimmering GI shading flicker.

Well, at least the HV particles look good, albeit crispy, even though they don't motion blur with the Volumetric AA setting off as I don't want to spend 3 weeks rendering them at 2 - 8 hrs/frame with Vol AA on.
.

The number of rays only affects the quality of the shading, it won't affect the flickering. If you try baking every single frame you might have more luck?

Sensei
08-16-2011, 06:07 PM
Did you Lock GI cache after baking.. ?

Chrusion
08-16-2011, 11:04 PM
This is being rendered with LWSN, which can't write to the cache, which is the same as being locked, so yes.

Now I've read that animated cache doesn't support or do well with deformations and moving lights. This part of the scene does have the front row of filter bags slightly deforming using Pole Effector and the light is moving, being parented to the camera. But even when the light and deformed bags are motionless, there's still GI shimmering/shading flicker (as seen in the sample clip in OP).

And then I've read where some are baking radiosity at 15, 20, and 25 frame steps without flicker. 5 should be plenty as the camera isn't moving that fast thru the unit and in this particular scene, it's rather stationary, just tilting up over 2 seconds.
.

Cageman
08-17-2011, 02:23 AM
And then I've read where some are baking radiosity at 15, 20, and 25 frame steps without flicker. 5 should be plenty as the camera isn't moving that fast thru the unit and in this particular scene, it's rather stationary, just tilting up over 2 seconds.
.

That's probably when using Final Gather though. For what you are doing, you need to change to Monte Carlo, Interpolation and make sure set the cache to Animation and bake every frame. Also, for the cache to be found by Screamernet, the cachefile needs to be in a folder called Radiosity, within the Content directory.

souzou
08-17-2011, 08:47 AM
Are you using LW 10.0? I thought I remember reading there were some problems with the radiosity cache in 10.0...

Chrusion
08-17-2011, 11:34 AM
you need to change to Monte Carlo, Interpolation and make sure set the cache to Animation and bake every frame.
That's what interp. MC GI meant in the first line of the OP, so already there.


for the cache to be found by Screamernet, the cachefile needs to be in a folder called Radiosity, within the Content directory.
Since BNR and thus LWSN are using UNC paths, the screamers say they are loading the cache from \\hostmachine\drive\projects\client\jobname\radios ity_cachename. No errors that it can't find it (does LWSN even report if it couldn't?). That is, the cache was saved in the root of the content dir containing the standard content dir subfolders... scenes, objects, and images. Are you saying that LWSN is ignoring this explicitly defined cache path in the scene file and instead looking for it in a non-existent radiosity folder? Why?

Re. frame step = 1... will rebake at this granularity and see if the flicker is eliminated.

Yes, using LW 10... dot one.

Thanks.
.

Sensei
08-17-2011, 11:49 AM
Try rendering on single machine. And check whether result will be looking exactly the same as from network rendering.

Cageman
08-17-2011, 01:34 PM
Are you saying that LWSN is ignoring this explicitly defined cache path in the scene file and instead looking for it in a non-existent radiosity folder? Why?

Yes. The easiest way to prooftest LWs GI-cache regarding Screamernet is to make a simple scene where you use cached Final Gather.

When screamernet renders, it should say something in the lines of:

Read radiosity cache:
X:\LightWave_Content\_Testscenes\Content_Folder\
Radiosity\xxx.cache.
Rendering frame 0, segment 1/1, pass 1/1

If the GI-cache path is incorrect, what should happen then is something like this:

Read radiosity cache:
X:\LightWave_Content\_Testscenes\Content_Folder\
Radiosity\xxx.cache.
Pre-Computing Global Illumination <--- This is not the correct wording, but when that happens, LWSN can not find the cachefile.
Rendering frame 0, segment 1/1, pass 1/1

Personally, I've had a much better experience with LW and mapped drives compared to UNC-paths.

Chrusion
08-17-2011, 04:33 PM
Yes. When screamernet renders, it should say something in the lines of:

Read radiosity cache:
X:\LightWave_Content\_Testscenes\Content_Folder\
Radiosity\xxx.cache.
Rendering frame 0, segment 1/1, pass 1/1

If the GI-cache path is incorrect, what should happen then is something like this:

Read radiosity cache:
X:\LightWave_Content\_Testscenes\Content_Folder\
Radiosity\xxx.cache.
Pre-Computing Global Illumination <--- This is not the correct wording, but when that happens, LWSN can not find the cachefile.
Rendering frame 0, segment 1/1, pass 1/1

Hmmm... So LWSN should NEVER say anything about "Computing preliminary radiosity solution" in conjunction with a valid cache? Bummer as that's what they're doing.

This is what's in the scene file... RadiosityCacheFilePath radiosity_augerBagClean.cache (no default 'radiosity' folder here... hmmm).

I am NOT using custom paths in LW config options, so maybe the culprit is the default radiosity folder named 'radiosity', even though all the fields are disabled/uneditable since the option is not enabled. So, I'll enable custom paths and set radiosity as blank and see if the above computing step is bypassed. If not, I'll move the new cache that's baking right now into a new 'radiosity' folder and see if that works.

Thanks again!

.

Chrusion
08-17-2011, 06:14 PM
I don't get it... LWSN always says "Computing preliminary radiosity solution...." no matter where the cache is. I even moved it out of the radiosity folder and LWSN didn't care... didn't say it could not read it.

So I followed Cageman's advice and changed everything over to a mapped drive ( R: ), reconfiged BNR to use the R: drive (which copies all LW files needed to a selected shared working directory (in my case R:\BNR) and rewrites all paths in all LW config files to this shared location), and still all screamers say "Computing preliminary radiosity solution...." All objects, images, particle PFX files, etc. are seen by all screamers just fine in the content dir. on the R: drive, so I can only assume the rad. cache file is too. But still getting shimmering shading.

.

dulo
08-18-2011, 03:18 AM
Had the same problem. Just edit the scene file with a Text editor and replace the cache file path with a normal windows notation. for me lightwave alway generated a path like t:bobo/bob/etc/...
make it
t:\bobo\bob\etc\ and it will work.
you can double check with processmonitor. It will tell you if your lwsn process was able to open the cache file. funny thing is that in the log file lwsn states it could open the file when in reallity it could not open the file.

good luck

Cageman
08-18-2011, 04:13 AM
When MC Animated Cache is working on screamernet, it should say something like this:

Read radiosity cache:
X:\LightWave_Content\_Testscenes\Content_Dir\
Radiosity\xxx.cache.
Recalculating radiosity samples....
Recalculating radiosity samples....
Rendering frame 0, segment 1/1, pass 1/1.

If you still see "Computing preliminary radiosity solution...." then you need to conform to the rules of Conent directories.

Chrusion
08-18-2011, 09:55 AM
I AM "conforming to the rules of Content directories"!!! It is R:\Projects\Astec\Baghouse with Objects, Scenes, Images, and Radiosity subfolders.

Have you noticed that LWSN is inconsistent re. paths? For loading scenes and setting content directory LWSN uses a \ as the path delimiter. When loading objects a / is used instead.

So, when the default content dir radiosity rule didn't work, I tried EVERY permutation of the path by hardcoding it into the ORIGINAL scene file per below and then in BNR reloading the original scene:

RadiosityCacheFilePath R:\Projects\Astec\Baghouse\Radiosity\AugerBagClean .cache
RadiosityCacheFilePath R:/Projects/Astec/Baghouse/Radiosity/AugerBagClean.cache
RadiosityCacheFilePath \Radiosity\AugerBagClean.cache
RadiosityCacheFilePath /Radiosity/AugerBagClean.cache
RadiosityCacheFilePath Radiosity\AugerBagClean.cache
RadiosityCacheFilePath Radiosity/AugerBagClean.cache
RadiosityCacheFilePath \AugerBagClean.cache
RadiosityCacheFilePath /AugerBagClean.cache
and just plain RadiosityCacheFilePath AugerBagClean.cache

I CONFIRMED that the BNR copy of the scene contained the above change (one at a time obviously) and for EVERY SINGLE ONE of these paths LWSN says "Read radiosity cache: R:\Projects\Astec\Baghouse\Radiosity\AugerBagClean .cache" followed by "Computing preliminary radiosity solution..."

Did you catch it? The path is ALWAYS the FULL path with backslashes no matter what is in the scene file, totally UNLIKE the loading of objects, which LWSN simply says "Loading Objects/objectname.lwo".

LWSN 10.1 appears to NOT be treating the path as RELATIVE to the content directory!! Am I wrong here?

@Dulo... explain this process monitor better. I'm unfamiliar with seeing what external files a process accesses from Windows Task Mgr Process tab.
.

Brazilian
08-18-2011, 04:43 PM
Actually 10.0 wasn't doing relative paths (see thread http://newtek.com/forums/showpost.php?p=1163095&postcount=5 ), however I've found it to be fixed in 10.1.

Chrusion
08-18-2011, 06:42 PM
Actually 10.0 wasn't doing relative paths, however I've found it to be fixed in 10.1.

Not here, even after a fresh reinstall of retail build 2161, fresh configs, a rescan of all plugin folders, and reconfiging/rebuilding BNR resources with all the new files for net rendering.

When the default "RadiosityCachFilePath Radiosity/AugerBagClean.cache" (forward slash) or "RadiosityCachFilePath Radiosity\AugerBagClean.cache" (back slash) is in the scene file, screamers will say, "Read Radiosity cache:" + Content Directory + \Radiosity\AugerBagClean.cache and compute prelim rad solution (notice path delim slash type is overwritten as back slashes even when forward slashes are used).

HOWEVER, when a forward or back slash is PREPENDED to the path in the scene file above, screamers will NOT include the Content dir. path and APPEAR to use relative paths when they say, "Read Radiosity cache: /Radiosity/AugBagClean.cache" or "\Radiosity\AugBagClean.cache" (notice slash type is retained), BUT they STILL compute prelim rad solution.

I REALLY need a solution to this as disabling the cache and going with straight non-interp MC makes for unacceptable render times of HOURS per frame instead of minutes, even with only 30 RPE.
.

Chrusion
08-18-2011, 11:22 PM
OK... I'm going to call it!

We're BOTH wrong! (Cageman and me that is.)

Test renders in LW reveal that with rad. cache ON, frame times are 4 min. with 3 - 5 seconds of "Computing preliminary radiosity solution" for each pass (4 pass dithered MB, so 8 total).

With rad. cache OFF, frame times are 7:20 with ~33 sec. of "Computing preliminary radiosity solution" for each pass.

Back in network render land, LWSN DOES NOT dispense with the "Computing prelim rad. solution," so with the cache in the default Radiosity folder, render times are identical to LW with the same 3-5 second "Computing prelim. rad. solution" before each pass.

SOOOOOO, the conclusion is we had a miscommunication re. the status msg in LWSN. The ONLY indication that the cache has been found and being read is the frame render time and per-pass, intra-frame "computing radiosity" times, NOT the elimination of "Computing prelim. rad. solution" msgs.

If the cache is valid, the per-pass computing time will be less than 5 seconds (your results may differ).

If the cache is not found, render and per-pass "computing prelim. rad. solution" msg times will be far longer as LWSN calculates a FULL rad. solution.

My apologies for not investigating more thoroughly sooner.

Now, with that said, and knowing that my previous render of this scene (350 frames) had frames times indicating the cache WAS being used (frame step = 1, 500 RPE, 20 SBR, 1x10 MPS, 2 IB, 50% multiplier), I am still perplexed as to why there is shimmering/slight GI shading flickering on large, open poly faces.

I KNOW object deformations are NOT supported by animated rad. cache, but does that mean the ENTIRE GI of the frame is affected by even one small object being slightly deformed OR is just the shading on the deformed object affected (causing only it to have flicker)?

.

Hieron
08-23-2011, 03:16 AM
Perhaps best to make a simpler test, only camera moving and no deformations. To start with. It should work as you tried all suggestions I had in mind already. (the wrong paths in LW scenefiles stumped me in 10.0 and beta too)

Also, make sure to check your lights. I noticed that low Q set Area Lights can mess up animated cache GI as well. As the Area Lights contribution is noisy (since it is at low Q) it influences the GI badly.

Normally this doesn't matter, since a low Q Area Light can be AA'ed just fine, but the noisy initial result gets applied to the GI -> animated splotches. This ofcourse is only true when using soft shadowing light types, but good to keep in mind I think. This is true for Layout as well, so if it splotches in subsequent Layout F9's it's easy to spot.

Animated GI cache can be really helpfull at times though..

ps: only now looked at your movie. No soft lights there. Hmm.. odd.

dulo
08-23-2011, 03:20 AM
The only reliable way to make screamer use the cache file was to edit the scene file with a text editor. But beware, after you opened the scene file with layout the wrong path will be written to file again. Now i have a small script ( awk, sed ) which automatically fixes the file path in the scene file.

good luck

Hieron
08-23-2011, 03:25 AM
Yeah, but is that bug still in 10.1? that'd suck.. I assume it's not the issue here though, seeing Chrusion tried to counter it specifically.

Cageman
08-23-2011, 04:09 AM
OK... I'm going to call it!

We're BOTH wrong! (Cageman and me that is.)

Back in network render land, LWSN DOES NOT dispense with the "Computing prelim rad. solution," so with the cache in the default Radiosity folder, render times are identical to LW with the same 3-5 second "Computing prelim. rad. solution" before each pass.

SOOOOOO, the conclusion is we had a miscommunication re. the status msg in LWSN. The ONLY indication that the cache has been found and being read is the frame render time and per-pass, intra-frame "computing radiosity" times, NOT the elimination of "Computing prelim. rad. solution" msgs.

Hmm... as I mentioned in my first post, the easiest way to test GI caching with LWSN is to use Final Gather. There is a very clear indication in LWSN log wether it sees and uses the cache or if it doesn't. So, the best way to figure things out is to first use Final Gather in order to establish a fact that LWSN sees the cache. Once that is established, switch back to MC.

EDIT:

If you still get flicker even though your content doesn't have any type of deformations, I guess you would have to send in a bugreport.

Chrusion
08-27-2011, 05:27 PM
easiest way to test GI caching with LWSN is to use Final Gather. There is a very clear indication in LWSN log wether it sees and uses the cache or if it doesn't... Once that is established, switch back to MC.
Since interp. FG doesn't support animated cache, I'm assuming you mean to just bake, say, frame 1 of the scene, save the cache, and see if LWSN renders the one frame with the appropriate log msg, yes?
.

Chrusion
08-28-2011, 03:07 PM
<swinging pocket watch in front of your faces>
Your eyes are getting heavy. You are totally relaxed. You will do anything I say... Forget everything that was said in this thread, because of this one ...

http://www.newtek.com/forums/showthread.php?t=121960

On the count of three you will awake refreshed and have no desire to laugh.

One, Two, Three.
.

Chrusion
02-01-2012, 08:27 PM
I'm resurrecting this thread because flicker GI has reared its ugly head again.

Take a look at the attached clip. I've been testing every permutation possible... again... to no avail. And since I'm the author of this thread, I'm NOT doing the same thing(s) as before. Here's my specs, which haven't varied much since I began rendering this project WITHOUT any flickering at all. It's just now popped up in this scene that I'm rerendering due to geometry and camera motion changes.

For the test clip below:

Interp MC
Use Trans. On (cuz the scene has parts of the unit dissolving in. The clip is after everything has been dissolved in 100%)
Use Grad. On (everything else off)
Int = 100%
IB = 2
RPE = 300
SBR = 10
AT = 30
MPS = 2 x 50
Mult = 100%

Cache = On
Anim = On
FS = 5
Cach path = content dir\Radiosity\Assembly.cache (on the local drive)

I've baked, cleared, rebaked, cleared, renamed, deleted, etc. the cache file 2 dozen times... nothing is giving me flicker-free results.

As you see in the clip NOTHING is moving... no objects, not the camera, not the light, etc. Per a previous post I even changed the light from soft-shadow sphere to plain distant.

I first noticed the flicker/popping after rendering the scene over my network and thought some of the LWSNs weren't seeing/reading the cache. But after clearing and rebaking GI and starting the render over again, I confirmed that ALL LWSNs were accessing the cache just fine per the LWSN shell msgs in the thread linked in the last post above.

So I tweaked RPE/MPS again, deleted and rebaked the cache, and network rerendered again, but nothing I've gone has fixed the flicker. I then tested by rendering locally using Layout (local drive D:, not a mapped drive or UNC paths for content dir, etc.) just to make sure the cache wasn't being accessed thru the network. Flicker still persists, so I rendered another umteenth time, this time WITHOUT a cache and this time the random popping splotches of darker shading was gone from the directly lit surfaces, replaced instead by less noticeable shimmering in the shadows, as one would expect to be the case.

I'm totally stumped. Any ideas OTHER than everything discussed previously in this thread?

.

Mr Rid
02-11-2012, 08:45 PM
Am dreading dealing with SN next. Occasionally I experiment with caching animated GI, and I read a lot of info about it but I always wind up with flicker, even on a single machine. I really prefer this to work for a project, and again am having no luck in 10.1 even in a simple Cornell Box setup. How the hell does anyone get flickerless, animated GI, on one machine even? What settings and steps?

Sensei
02-11-2012, 09:48 PM
Are you doing:
1. Render Globals > Global Illuminations > Preprocess to Always
2. Bake Radiosity Scene
3. Render Globals > Global Illuminations > Preprocess to Never
4. Use F10
??

geo_n
02-12-2012, 01:33 AM
Wasn't your remake of the Shining interior blood scene gi animation? No gi baking there? That makes it even cooler.

Chrusion
02-13-2012, 11:18 AM
Are you doing:
1. Render Globals > Global Illuminations > Preprocess to Always
2. Bake Radiosity Scene
3. Render Globals > Global Illuminations > Preprocess to Never
4. Use F10??
Yes, this is exactly what you need to do AND leave the Animated button 'on'.

OK, 'maters, I think the problem had everything to do with the number of objects dissolving in. Other scenes of this same object had one or two layers dissolving in but did NOT flicker after GI baking and Net rendering. But this assembly scene had 20 of the object's 21 layers initially set to 100% dissolve and 1 second dissolve ins throughout the course of 1000 frames.

With that in mind, I set them all to 99% dissolve so GI could "see" all the objects and rebaked, but that just drove the per-frame bake time thru the roof as it had to calc the multiple layers of transparency and if it did that, I imagined what would have happened to the render times... 8 hrs/frame, I bet. So, I scrapped that approach and decided to revised the scene to not use ANY dissolves, just moving object layers off-screen and moving them into position at their allotted times, then rebaking GI and net rendering. The result was NO FLICKER, even with a frame step of 10!!

There are GI splotches where one layer moves into near-touching proximity to another layer (eg. top covers moving down to rest on base frame), but I'm pretty sure that's just my very low RPE in order to get it to render faster... something the client won't notice, and gives it that dirty factor. BUT there isn't any flickering, shimmering, or popping like before!

Hope this helps others.
.

Hieron
02-25-2012, 07:12 PM
...How the hell does anyone get flickerless, animated GI, on one machine even? What settings and steps?

Did you intentially set the settings that low, to see if splotches are static?
Most of it makes no sense to me.. 10 bounces, no Color Space to RGB, very low RPE..

Especially a shot like this is very easy to get animated GI cache on since nothing moves in or out the shot. No animated GI is needed really even, this will render very fast without it with hardly a splotch showing.

Try this (done in LW11 btw):
102098

If all loads in well, you can set RPE to something insane like 10. Due to the correct cached GI, it will show static splotches. (see placed samples by turning on radiosity flags)

Load it back in again, and turn off all cache options. Renders fast imho and works fine too..

102099

Or perhaps I understood it wrong... Either way, I'm sure you've seen this but it is an absolutely must read:
http://www.except.nl/lightwave/RadiosityGuide96/index.htm

jasonwestmas
02-25-2012, 08:50 PM
Strange, My F10 render sequence won't render at all if GI Preprocess is set to Never or Locked after I baked the scene GI. This is LW11 trial.

Sensei
02-25-2012, 08:56 PM
F10 is deadlocking or it's finishing immediately?

check whether cache file is deletable after pressing F10 when it deadlocked..

jasonwestmas
02-25-2012, 09:06 PM
F10 just sits at 0% with black in the preview window. I deleted the old cache file and rebaking right now.

jasonwestmas
02-25-2012, 09:15 PM
Hmm, Same problem, not sure what I'm doing wrong but I don't recall having this issue the few times I baked GI in LW10.1


So others are having no issues with this in LW11?

Sensei
02-25-2012, 09:23 PM
So when F10 blocked, you can delete cache file no problem?

I was thinking that there is possible that something leaved exclusive access to file, and F10 is in loop waiting for releasing exclusive lock to file, therefor it blocks permanently. Just a theory.

jasonwestmas
02-25-2012, 09:41 PM
Hmph, it worked the third time. I guess I scared it into submission. ;)

Hieron
02-26-2012, 08:48 AM
So when F10 blocked, you can delete cache file no problem?

I was thinking that there is possible that something leaved exclusive access to file, and F10 is in loop waiting for releasing exclusive lock to file, therefor it blocks permanently. Just a theory.

Can something like that happen on lwsn too (exclusive access)?
Just yesterday I was trying to get a scene through BNR where there are 200 cells with clothfx-mdd on them. And they kept crashing.. unless I added nodes 1 by 1 so never one node was loading the same mdd or something.

Really odd and never seen it before..

Sensei
02-26-2012, 08:54 AM
Exclusive access to file is keep as long as application is running. So manually shutting down app in Task Manager should get ride off any exclusive locks.
Usually it's mode used while opening file for writing or appending data. So nobody will try to read it while it's not ready.
If application knows that something can append data to some file, programmers are making loops which try to open file, then sleep couple miliseconds, and repeating. If file will remain open, because application holding exclusive lock to file, will block for some reason, or due to bug, 2nd application in loop, will deadlock too.

Sensei
02-26-2012, 08:57 AM
Your issue might be related to network- 200 accesses to files * 100 computers in renderfarm for example, is 20,000 accesses to these file, which are on one physical disk..

Hieron
02-26-2012, 11:04 AM
Hmm in this case it is merely when 2 nodes start loading at the same time or so. Our farm is not that big sadly :)

Mr Rid
02-26-2012, 04:30 PM
... Either way, I'm sure you've seen this but it is an absolutely must read:
http://www.except.nl/lightwave/RadiosityGuide96/index.htm

Yeah, and I didnt see anywhere in that, or in the manual, or in any thread how to bake animated GI. They talk about what each button supposedly does (although the Always/Never/Sometimes thing is convoluted) but they dont explain 'here are the steps.'

Am in the middle of a tight deadline with dense scenes and dont have time to pin down the many bugs I am running into with GI bake and elsewhere.

One time the bake is flickerless, and the next its not, then every third bake crashes. There seems particular issues with reflections, and with amb occlusion surfaces (known).

Further ranting- I cant believe image sequence instancing/duplicating is STILL screwed and has never worked (really miss the reliable old school trick of changing the case of one letter in a image name, that LW no longer allows!). FBX is still screwed, as export out of LW10.1 is not loading in Max correctly, but LW96 export works(?). I need flares to work with VPR, and with photoreal blur. Sprites rendered over amb occ surface results in black object. VPR is a slew of glitches. Metadata view wont update when selecting different images (works in 9.6). Selection in old Scene Editor isnt updating. When is transparency ever going to work with volumetrics or fog (but found a couple of interesting workarounds)? Some intriguing bugs with a model created in LW4, one of which is it can only be affected by one light(?).

Hieron
02-28-2012, 07:32 AM
yikes, quite a bit of issues I cant help with.

Animated GI cache is quite straightforward to me though :/ It does need some experience and it is annoying when you move the camera around alot, specifically zooming in. Depends on the scene in use. If you can share a scene you struggle with, perhaps I can try and record what I would do to it? (and hopefully not make a fool out of myself :P)

Also, you can cache GI on a simpler version of the scene to circumvent certain issues or just speed it up. Like caching with reflections turned off to name but one thing. Then turn things all back again.

stiff paper
02-28-2012, 11:58 AM
Am in the middle of a tight deadline with dense scenes...

Unfortunately I have nothing to offer that'll help, except to say that I've never got it to work either. When I've had unsolvable problems I've mostly ended up surface baking the GI down to illumination maps wherever it's feasible (this is in 9.6) and then just hoped like hell that nobody spots the "burbling" when it isn't.

Personally, I don't think it works even for fly-throughs. Anywhere that's only illuminated by bounced light (i.e. no direct light) has always been problematic.

Worse, RebelHill posted some more of his experiments with animating radiosity renders in LW11 ( http://forums.newtek.com/showthread.php?t=126034 ) and although it's supposed to be much better in 11 it still looks like it's covered in burbling to me.

Can anybody out there please explain exactly what it is that VRay is doing that LW isn't that allows VRay to produce burbling-free animations?

RebelHill
02-28-2012, 03:11 PM
Vray doesnt prodice flicker free animation... it flickers like hell (unless u brute force it, which is the same in LW).

Vray gives stable, flicker free animation with camera motion ONLY... you cant move objects or lights... LW is no different here. Camera motion only is totally flicker free when used with cache.

GraphXs
02-28-2012, 08:10 PM
It is true that Vray does flicker. It however is mainly a fine noise and not splotchy. We have also used baking with Vray phonton mapping and it straight forward. What vray does better is having easy drop downs for picking gi settings. Low med high still or animation. We use it all the time for everything, animated characters, objects, cameras and it gives the results we want. I really hope LW takes a page from that from that. Vray is fast and easy to get results, its downfall is mixing Max functions, shaders,etc. A pita! If LW had a easier cleaner gi pipeline, easier network controller, with its already great shader pipe it would be kicking Vray in da @Zz!

stiff paper
03-10-2012, 04:07 PM
Okay, I'm going to try this one again. I know. Nag, nag, nag.

Blur Studio do their cinematics with V-Ray now. Here's an interview with a Blur person about the work they were doing when they were first starting to use V-Ray: http://www.chaosgroup.com/en/2/envyspot.html?i=10

They've done several fairly amzing cinematics since that interview, you can find them here, under work > cinematics: http://blur.com/ (You can usually find nice high res copies on YouTube too.) If I had to pick favorites it'd be Batman: Arkham City and Resident Evil: Raccoon City. But look at them. Just look. They're silky smooth. A zillion lights. A zillion characters. All kinds of stuff going on. And they're silky smooth. No burbles.

I can't do that in LW. I can't. But more than that, I pretty strongly suspect that it's actually completely impossible to do that with LW's GI.

So is it impossible? If not, I ask again: what's V-Ray doing that LW isn't? Because I'd really like to be able to throw in 20 lights and 10 characters in LW and not have any burbles.

RebelHill
03-10-2012, 04:33 PM
ofc its possible... question u gotta ask it, at least in blurs case... what were the render times?

edit, hows this fella? http://forums.newtek.com/showpost.php?p=1227730&postcount=24

Surrealist.
03-10-2012, 06:01 PM
Okay, I'm going to try this one again. I know. Nag, nag, nag.

Blur Studio do their cinematics with V-Ray now. Here's an interview with a Blur person about the work they were doing when they were first starting to use V-Ray: http://www.chaosgroup.com/en/2/envyspot.html?i=10

They've done several fairly amzing cinematics since that interview, you can find them here, under work > cinematics: http://blur.com/ (You can usually find nice high res copies on YouTube too.) If I had to pick favorites it'd be Batman: Arkham City and Resident Evil: Raccoon City. But look at them. Just look. They're silky smooth. A zillion lights. A zillion characters. All kinds of stuff going on. And they're silky smooth. No burbles.

I can't do that in LW. I can't. But more than that, I pretty strongly suspect that it's actually completely impossible to do that with LW's GI.

So is it impossible? If not, I ask again: what's V-Ray doing that LW isn't? Because I'd really like to be able to throw in 20 lights and 10 characters in LW and not have any burbles.


One of the things that Vray has is a Proxy object.

http://www.spot3d.com/vray/help/150SP1/vrayproxy_params.htm

What it does is take an object and save it to disc. It is loaded up in buckets as needed for the render. So therefore you can have a virtually unlimited amount of geometry in a scene and still render it.

The main thing I think that LightWave falls behind other render solutions is its ability to handle large amounts of geometry.

I am not an expert at what all LightWave GI can do. But I will say this. I think it can come close on a number of things. And the gotcha of Vray or any one you choose is render time.

This is the big trend these days. So not only do you have to shell out for the render package, you have to shell out for a render farm too. It seems the lid has come off as far as features are concerned and much less emphasis is put on the fact that it means getting the fastest machine(s) available. Sure that is nothing new. But this really is a more heightened hype these days over even 5 years ago. It is really about the sexy renders and not about the cost.

To get a good feel for this "trend" or revolution as it is called in this advertising article, have a read:

http://area.autodesk.com/renderingr

So basically it prices most of us out of getting anything useful out of these packages, in reality.

Your LightWave renders are as equally hindered by the amount of RAM and CPU speed. You will find that if you are willing to sacrifice the same things that the other packages ask you to sacrifice, in many situations you'd get as good or better performance out of LightWave GI.

Just turn Interpolated off.

Many packages have their various versions of fake GI by way of smoothing between sample points. In Lightwave it is the Interpolated option. This comes at a cost of quality against speed. It is a problematic solution that none of these packages (including LightWave) even claim is perfect. If you read the manuals and do tests it is clear. The bottom line is the best most reliable solution is to use brute force. No interpolation, no faking it. That is how the bulk of the real good looking stuff with lots of detail is done. The smooth between points solution looses detail. Might look OK in some situations, but for the real quality work, I don't think you can fake it.

jasonwestmas
03-10-2012, 07:08 PM
I'm no GI expert but I've seen Brute Force Monte Carlo solutions that are much faster than LW's non-interpolated MC. Or am I imagining things.

geo_n
03-10-2012, 08:07 PM
Try this (done in LW11 btw):
102098

If all loads in well, you can set RPE to something insane like 10. Due to the correct cached GI, it will show static splotches. (see placed samples by turning on radiosity flags)

Load it back in again, and turn off all cache options. Renders fast imho and works fine too..

102099



I rendered this and its flickering a lot on the room corners. Imho interiors with moving objects like this are better rendered separately if by any cach method. If its rendered together bruteforce is the only way for lw.

shrox
03-10-2012, 09:36 PM
...Just turn Interpolated off...

Thanks!

JonW
03-10-2012, 11:51 PM
This is a bit different approach. But still a lot quicker than Interpolated off.
LW11
I Baked every frame, it's quick enough, then Locked.

IB 2
RPE 300
SBR 50
AT 20
MinPS 1.0
MaxPS 20
M 100%

Camera
MinS 1
MaxS 3
Classic
Fixed
AS 0.1

Motion Blur
15 Passes

When the left box was at the top there was Interpolation noise in the corner of the back wall & ceiling with lower settings. Other than that you could cut back to say 10 - 12 passes. & RPE to 250.

It's 70 to 80 seconds per frame on my W5580. (25.6 GHz total)

JonW
03-11-2012, 12:31 AM
Cornell Box movie MB 15 passes with the above settings.

ivanze
03-11-2012, 01:33 AM
Looks nice. Thanks for the tips.

JonW
03-11-2012, 03:05 AM
IB 2
RPE 200
SBR 50
AT 20
MinPS 1.0
MaxPS 25
M 100%

Camera
MinS 1
MaxS 3
Classic
Fixed
AS 0.1

Motion Blur
11 Passes

About 40 seconds a frame.

JonW
03-11-2012, 03:29 AM
1 more!

IB 2
RPE 150
SBR 50
AT 20
MinPS 1.0
MaxPS 25
M 100%

Camera
MinS 1
MaxS 3
Classic
Fixed
AS 0.1

Motion Blur
9 Passes

About 25 seconds a frame.

stiff paper
03-11-2012, 03:36 AM
@RebelHill - "ofc its possible... question u gotta ask it, at least in blurs case... what were the render times?"

RH - Firstly, your latest test is a big improvement! That's a very nice result.

In the article I linked to, the Blur person said their frames were taking 1 to 2 hours. Now, I think that needs a pinch of salt to bring out the flavor, so let's say, for the sake of argument, that it was 4 hours per frame for the BG pass and 2 to 3 hours per character pass.

@JonW - "It's 70 to 80 seconds per frame..."

Unfortunately, though that's a nice render, it doesn't scale. If you try a scene that's a much bigger environment with 3 characters walking around and 14 lights in it the end result will be a mess.

@Surrealist. - "Just turn Interpolated off."

Ye-eeaaa-aahh... I was kind of expecting that was the answer. At the same time I was really hoping that it wasn't the answer.

Because... If I tried to render the BG pass for, say, the street set in Blur's Resident Evil cinematic, and I tried it with interpolated turned off, well... it wouldn't surprise me at all if that was 17 hours per frame. Don't get me wrong, I really like the image quality that can be coaxed out of LW's renderer. But it seems to me there are things that need improving before it'll compete with V-Ray for things other than stills and archvis.

Now, does anybody want to explain how it can be that fPrime was doing this kind of thing very well 8 years ago?

Surrealist.
03-11-2012, 03:41 AM
I'm no GI expert but I've seen Brute Force Monte Carlo solutions that are much faster than LW's non-interpolated MC. Or am I imagining things.

Where?

I have tried most of them.

Maxwell - perhaps 3 or more times slower. I ran out of patience waiting for something I could even use.

Vray - best contender. But if anything the speeds are comparable.

Cycles - same as Maxwell (keep in mind these two are not the same tech as Vray)

3Delight - actually under the same conditions test, is actually slower than Mental ray as I found out. By about 3X! But you'd have to really hunker down and do more comparative testing.

Sorry I was meaning to email you with an update. I actually found a serious artifact with 3Delight and no answer for I think about a month now. Sound familiar?

But anyway also 3delight also has an issue with volumetric lighting. It does not use the volume setting for lights in SI. You have to set up an environment fog. I think it can work in theory that way. Similar to how Vray does it, which basically works in Vray. But with my initial testing in Vray I could not get it to do anything usefull. I have to be honest, I had been testing to the point of exhaustion and I finally had to cut my losses and move on. It was taking so much of my time.

Arnold (what is available in Messiah) is pretty fast. But it does not work for animation in its current form. Brute force is about the same speed and quality as LightWave.

Actually of all of these solutions, given an interior space with lights coming in from the environment, LightWave is up there as being the most accurate from my tests. Maxwell seems more accurate but at 3-5 times slower?

Mental Ray is not actually as bad as some people think. But brute force is less accurate than LightWave. To get more accurate lighting you are forced to use lights and GI that is locked in to an interpolation mode. You can tweak it, but to get the same result as needed for animation you wind up kicking up the quality to the point you may as well use brute force.

And there is the thing. I have not used any of these packages for a long time. These are just initial testinig. But I can say this. That you have to test in animation and you have to really test in interior scenes.

For example that dancing baby in Final Render "flicker free" promo. Look at what they rendered. It is an evenly lit scene outside on a flat plane. Sorry but that is not a test. Not because it is relevant that they have a workable solution, but because there is nothing to bounce in the scene. Only the floor. You can get incredible speeds under these conditions. And you can do that in LightWave with a minimal render hit with non interpolated GI. I have done it. It is real fast.

Where all these packages break down as far as speed goes is when you put the character inside. It is commonly accepted that interiors are the most challenging for this reason. And the render times slow down to a crawl in these conditions.

If you can live with the quality of an Interpolated solution in these conditions, then fine.

I just think that you have to look at what it is that you want.

For me, I need good dramatic lighting solutions that work in interiors and I have not found anything that works for animation that is also fast. And nothing that is fast that actually looks pleasing to me or does not also loose lots of detail.

That is just my opinion. But I think it is true that there really is no silver bullet here, just like anything. I think money is better spent on hardware as things are going today.

JonW
03-11-2012, 05:05 AM
@JonW - "It's 70 to 80 seconds per frame..."

Unfortunately, though that's a nice render, it doesn't scale. If you try a scene that's a much bigger environment with 3 characters walking around and 14 lights in it the end result will be a mess.

Did this a few years ago. 640 x 400 averaged about 20 minutes a frame & all done within LW. I know a lot more now.

RebelHill
03-11-2012, 05:26 AM
Yeah see... 2 hours per frame... and on what u have to wonder. If thats 2 hours a frame on a dual 6core xeon box... then its a lot more on lesser systems.

And could u, given a nice powerful CPU, fancy shaders, characters, etc, get lovely renders out of LWs GI system given a couple hours per frame... I certainy think so. Again, check my test... 9 mins/frame and thats on my mid range box... shove that on the aforementioned Dxeon, and its more like 3mins per frame. Given 2 hours... I think u could get some real fancy looking stuff.

And Jason, yes... there are a couple brute force solutions that are quicker than LW, Vray being the main one I believe... but still, such renders are immensely slow.

Surrealist.
03-11-2012, 06:19 AM
From my testing with Vray and LightWave Vray is not really faster than LightWave under the same conditions. (exact scene exact lighting conditions) In fact, I think I'd have to go back and check, but I seem to rember LightWave was faster in fact and looked better. LightWave is actually more accurate in its interpretation of how much light is coming into the scene from windows than Vray.

Unfortunately my laptop died and I had to buy a newer faster one. Poor me. So I do not have SI installed anymore. When I get that back up and installed again, I can run some tests on my CPU.

Generally speaking I think there is a perception out there now. That there are all these other faster solutions than LightWave and Mental Ray. I am not so sure this is accurate. I have not found this to be true when testing.

What I have found is that the other solutions are claiming to be more accurate at the expense of time. It just sounds good in PR to say faster. But where the rubber hits the road, it is still basically the same math and basically limited to your hardware. There is no real silver bullet I have found yet. And I have not found one test that proved me wrong on that so far. I wish there was, believe me. I'd be all over it.

By the way I have forgotten what started this thread. But if we are talking about fly through and solid object animation I have not had any issues with this at all in LightWave. I had found that the caching system works quite well for this. And it is quite fast once you dial in the right settings.

Since then I have been doing testing on deformed characters. Another animal.

JonW
03-11-2012, 06:49 AM
Generally speaking I think there is a perception out there now. That there are all these other faster solutions than LightWave and Mental Ray. I am not so sure this is accurate. I have not found this to be true when testing.


Grass is always greener on the other side of the fence!

jasonwestmas
03-11-2012, 07:47 AM
haha, Surrealist, that's why we've got you to test this stuff for us. ;)

I'll do my own testing one of these days. I may have to go outside of lightwave for certain kinds of FX renders but I do think LW is fast enough for a lot of subject matter.

jasonwestmas
03-11-2012, 08:23 AM
Since then I have been doing testing on deformed characters. Another animal.

mmyeah, that is actually the subject matter I will be testing for when the 2013 products hit the road. That, and animated displacements on top of bones deformations with good lighting conditions that include quite a lot of reflections (blurred of course), lots of lights and possibly GI but I think that would just put my render time over the top, not sure I could afford that amount of time for rendering, I'd never get anything done. So obviously it's about balance.

geo_n
03-11-2012, 08:49 AM
I'm no GI expert but I've seen Brute Force Monte Carlo solutions that are much faster than LW's non-interpolated MC. Or am I imagining things.

No you're not imagining things. I can show you in vray with lots of animated characters and it renders lightning fast. For enclosed spaces vray has a wonderful trick for non splotchy gi animation, animation prepass cache. You won't need monte carlo for vray because the cache works even on animated characters.
These projects we did are not tests but real projects and time is money and the faster and easier a renderer is to setup, the more money for our bosses :thumbsup:
Studios would not be switching from lw,mray to vray if there's no reason to do it.

stiff paper
03-11-2012, 11:01 AM
Ah... thanks for that geo_n.

What V-Ray has that LightWave doesn't:
http://www.mintviz.com/blog/flicker-free-animation-using-vray/

Hopefully, the LW dev team are already all over this.

geo_n
03-11-2012, 11:36 AM
Ah... thanks for that geo_n.

What V-Ray has that LightWave doesn't:
http://www.mintviz.com/blog/flicker-free-animation-using-vray/

Hopefully, the LW dev team are already all over this.

Its been around for a few years and studios know about it. The people who usually have problems with gi animation are doing tests with no support from more experienced users. My collegues went thru lw render, brazil render, finalrender, mray before they switched to vray. If there's something better they won't hesitate to switch.
First thing in lw that needs fixing is when you hit F9 gi renders it should be 98-99% identical each time like fprime renders. The ray doesn't seem accurate for lw renderer.
In vray or fprime when you hit render the image is identical with no baking. Animation does not even need baking or mblur cheats like lw.

jasonwestmas
03-11-2012, 11:39 AM
Its been around for a few years and studios know about it. The people who usually have problems with gi animation are doing tests with no support from more experienced users. My collegues went thru lw render, brazil render, finalrender, mray before they switched to vray. If there's something better they won't hesitate to switch.


Sound like cool friends tbh. Very open-minded I hope. I like this approach because the project then becomes the focus, not the brand name.

Surrealist.
03-11-2012, 01:04 PM
haha, Surrealist, that's why we've got you to test this stuff for us. ;)

I'll do my own testing one of these days. I may have to go outside of lightwave for certain kinds of FX renders but I do think LW is fast enough for a lot of subject matter.


lol

Yeah I am such a willing martyr. But seriously I don't mind sharing what I find. I try to keep an open mind always. But also, I am testing for something specific and that might not work for someone else. But under these specific requirements, this is what I have found in my comparisons. Individual results may vary. :hey:

Surrealist.
03-11-2012, 01:23 PM
No you're not imagining things. I can show you in vray with lots of animated characters and it renders lightning fast. For enclosed spaces vray has a wonderful trick for non splotchy gi animation, animation prepass cache. You won't need monte carlo for vray because the cache works even on animated characters.
These projects we did are not tests but real projects and time is money and the faster and easier a renderer is to setup, the more money for our bosses :thumbsup:
Studios would not be switching from lw,mray to vray if there's no reason to do it.

Well the thing is, it depends on the scene. In information you are giving here is very general. I don't have any doubts about what you say.

All I am saying is you can not make blanket statements without qualification.

There are pros and cons for going for that look. And in some situations it is acceptable. To me, I find it not so. And with the qualification of "using brute force" which to me looks better and works better in my situation, LightWave is not far behind actually.

As for animated characters with cache, I think clearly LightWave falls way behind. I was actually shocked to find out it did not work.

So it just depends on what you are referring to. In that case I can amend what I have said to be sure it is not misunderstood as to my qualification.

jasonwestmas
03-11-2012, 01:38 PM
Yes, thanks for your honesty and specificity Surrealist. I'll be sharing my progress and observations as well. Maybe not about GI, but I'll try it out. But most definitely using reflection as a lighting condition and displacement stuff, which I'm quite fond of.

geo_n
03-11-2012, 09:22 PM
Well the thing is, it depends on the scene. In information you are giving here is very general. I don't have any doubts about what you say.


Yep it depends on the scene. And the scenes that would make sense to test are not simple scenes. Put some multiple elements with animated gi, soft shadows, blurry reflections, clean AA settings.

Pm for you.:D

JonW
03-11-2012, 11:34 PM
There are pros and cons for going for that look. And in some situations it is acceptable. To me, I find it not so. And with the qualification of "using brute force" which to me looks better and works better in my situation, LightWave is not far behind actually.

"using brute force"

I have just tried out a few "using brute force" renders, haven't really bothered before. But I have to agree that there is something nice with the renders which is a bit lacking with Interpolated.

Surrealist.
03-12-2012, 04:42 AM
Yep it depends on the scene. And the scenes that would make sense to test are not simple scenes. Put some multiple elements with animated gi, soft shadows, blurry reflections, clean AA settings.

Pm for you.:D

Will answer in more detail here rather than the PM. Thanks for sharing the "not for public" link.

I fully understand the limitations of LightWave in that scenario. In that scenario Vray wins out. No doubt.

The problem is, once you get past an open environment where you have characters primarily outdoors, everything changes as far as render times.

The testing I have been doing is very specific. And for that testing Vray is not faster. And is also less accurate. I don't know why. But I find that Maxwell and LightWave both natively treat the interior scenes more correctly without tweaking than other things I have tried.

This is not to try and say LightWave is as capable... bla bla.. I don't care about that. Just in my testing with what I need, Vray is not faster nor as accurate. That is all.

And I do think it addresses this broader perception which I think is not something you can not generalize. Because I think you could walk into a rendering scenario - as I have - and assume other solutions are better and then find out - as I have - that they are not.

Surrealist.
03-12-2012, 04:43 AM
"using brute force"

I have just tried out a few "using brute force" renders, haven't really bothered before. But I have to agree that there is something nice with the renders which is a bit lacking with Interpolated.


Exactly. And I suppose it is a personal thing. And also a professional consideration given the project needs. This is why we have choices. :)

geo_n
03-12-2012, 05:28 AM
The testing I have been doing is very specific. And for that testing Vray is not faster. And is also less accurate.

Yes please do more tests. Atleast you will gain first hand knowledge of actual speed from renderer to renderer. You must consider to add blurry reflection, soft shadows, good AA. Avoid noise, splotches and flicker in real projects with multiple elements not simple scenes and render them as fast as possible. If you find a solution for good images that render in the one minute mark per frame, I'll be very interested since I use lw at home.

Surrealist.
03-12-2012, 09:51 AM
Yes please do more tests. Atleast you will gain first hand knowledge of actual speed from renderer to renderer. You must consider to add blurry reflection, soft shadows, good AA. Avoid noise, splotches and flicker in real projects with multiple elements not simple scenes and render them as fast as possible. If you find a solution for good images that render in the one minute mark per frame, I'll be very interested since I use lw at home.

lol. perhaps we have a misunderstanding. I am not doing tests for other people. The tests I am doing are completely adequate for a real project. Mine. If that works for you, great. I don't think many people will be interested though.

But if I am sure as things progress, I'll have some things to show and I don't mind sharing. But I'll warn you now, it likely won't be what you are looking for.

But for anyone looking to emulate a certain look that this can only give, that is Brute force. All I am saying is that for this case, LightWave is not far behind. And the renders are long. As they are in other packages.

The only solution in this case is to buy more CPU. And if you want Vray buy that also and more CPUS as well as the host program for Vray.

jasonwestmas
03-12-2012, 10:18 AM
lol. perhaps we have a misunderstanding. I am not doing tests for other people. The tests I am doing are completely adequate for a real project. Mine. If that works for you, great. I don't think many people will be interested though.

But if I am sure as things progress, I'll have some things to show and I don't mind sharing. But I'll warn you now, it likely won't be what you are looking for.

But for anyone looking to emulate a certain look that this can only give, that is Brute force. All I am saying is that for this case, LightWave is not far behind. And the renders are long. As they are in other packages.

The only solution in this case is to buy more CPU. And if you want Vray buy that also and more CPUS as well as the host program for Vray.

If it's a more stylized piece with GI, I'm sure we'll understand and perhaps even enjoy it. =) Every scene is unique afterall.

Surrealist.
03-12-2012, 11:27 AM
Yeah. Thanks. I am sure if something is done nicely, that it is appreciated for whatever it is. I only hope I can accomplish what I see in my head. If people like it also all the better.

But I think the point I am making is that something like this does not come cheap.

http://area.autodesk.com/showcase/movies/the_witcher_2_intro

I can't imagine how you would accomplish this with interpolated of any sort and even if you could, do it at anything less than an hour or more per frame.

My path of research led me away from LightWave and as you know, to try out Arnold in Messiah, from there, 3Dlight, a short stint with a few other things and then Vray.

At some point along the way, I had to accept that the look I wanted was only going to be achieved using some form of brute force. So I began just exploring with that in mind. It was after this that I stopped and realized, I had never given LightWave GI non- interpolated a chance. Because, just like I am sure anyone who has tried, I had come to the conclusion - too long. Forget it. Not even a possibility to consider.

But here I was already planning to go this route, purchase software and hardware to crank out the images I wanted to see. It was only after all of this that I recently came back to LightWave and put it through the paces against things like Vray, 3Delight and so on in this capacity.

So this is what I mean by it won't be what most people are looking for. I'm sure that most people are like I was a few months ago. Longer than 1-5 minutes per frame? - forget it.

But I have been learning the hard way that good stuff does not come cheap. Just a matter of finding the right balance for what you want and can afford.

Anyways, still a work in progress. We'll see what comes out here in the near future.

RebelHill
03-12-2012, 11:56 AM
Ahh... those lovely folks over at Platige...

But y'know... who's to say its ALL gi? And even if so... its all outdoors, so how many bounces do u reli need?

To achieve a similar look in an acceptable time frame is probs doable (in whatever app btw)... but its gonna be a mix of separating things out into layers and passes, using GI where its appropriate, regular lighting, or global light rigs where its not. Some interpolated, some brute force.

Set all that up in just one scene, one pass, and hit render... unlikely I think.

Surrealist.
03-12-2012, 12:03 PM
True. they don't do it like that.

And true. It is outdoors which knocks it down 4x at least.

But still you add up all of those passes all of that rendering composting and you have long render times. Plus there is a ton of detail in the clothes alone.

That is an expensive hit. No way around it.

jasonwestmas
03-12-2012, 12:40 PM
Indeed that cinematic trailer does look really really expensive, just to render the polycounts in layers.

What about vertex based GI? That might render faster with polycounts that high.

JonW
03-12-2012, 03:23 PM
Very detailed trailer, they obviously put in the extra effort here so it looks as good as possible.

It's like anything, if you want & or need quality one just has to have the right tools & it's going to be expensive. More computers or top model camera with prime lenses for example. One may get away with less but it sure does make life easier if you have all the resources you wish for. Unfortunately we will all need to make shortcuts with the tools we have or don't have & hope we can get away with it.

geo_n
03-12-2012, 07:23 PM
lol. perhaps we have a misunderstanding. I am not doing tests for other people. The tests I am doing are completely adequate for a real project. Mine. If that works for you, great. I don't think many people will be interested though.

But if I am sure as things progress, I'll have some things to show and I don't mind sharing. But I'll warn you now, it likely won't be what you are looking for.

But for anyone looking to emulate a certain look that this can only give, that is Brute force. All I am saying is that for this case, LightWave is not far behind. And the renders are long. As they are in other packages.

The only solution in this case is to buy more CPU. And if you want Vray buy that also and more CPUS as well as the host program for Vray.

Like I said do more tests. Share them or not atleast you'll have firsthand knowledge and can be objective with how the two renderers compare. :thumbsup:

Surrealist.
03-13-2012, 12:21 AM
Like I said do more tests. Share them or not atleast you'll have firsthand knowledge and can be objective with how the two renderers compare. :thumbsup:

Right Absolutely. That is what I have been doing for the last 3 to 4 months now. Damn! Where does the time go?

Anyways I have to move on. I am not testing for a living. :D

But there will be a few more tests I am sure down the road here. Nothing too heavy because I have pretty much all of it taped for now. For the most part everything points to LightWave for this particular project. Can't believe I am saying that. But that is what I have found with my own tests according to the criteria I am looking at.

I think I was more eluding to something like a WIP and if it is interesting to people, I am happy to share. Just not 100 percent sure that many will want to use it in their own projects. And that is more or less what I have been referring to.

We'll see though. Keeping an open mind and moving forward. But I do have to know when it is time to quit on certain aspects and for rendering that is about it for now.

To sum it up just sharing my thoughts on the direct comparison of brute force to brute force in other packages. Not Brute force to interpolation etc.

geo_n
03-14-2012, 03:44 AM
But I think the point I am making is that something like this does not come cheap.

http://area.autodesk.com/showcase/movies/the_witcher_2_intro



That was rendered in vray.
Now one has to wonder why didn't they use mray or any other renderer for the final output and instead opted to use vray. I'm sure the render is not that long, but not as fast as 46 sec. :D
But I agree, one must be realistic in what can be achieved with the given resources. The cg I showed was done with less than 5 people and two compositors. Doing it solo, maybe a year. Doing the witcher 2 intro, 4 years.
But it really helps to have a super fast renderer like vray :thumbsup:

Btw try to investigate on animation prepass for vray. This eliminates the need for bruteforce in most cases.

Surrealist.
03-14-2012, 02:22 PM
Right. I am aware that was Vray.

That was part of my point.

And I agree. It does not take much imagination to see why LightWave would not be used for that.

As for me. It is coming down to the other tools really in LightWave, not so much the rendering. It has always been a strong point. I still think it is, on a budget.

Certainly the rendering needs improvement. But I think the other tools really need to come up to speed. That may sway my decision more than rendering at this point.

JonW
03-14-2012, 04:09 PM
But I agree, one must be realistic in what can be achieved with the given resources. The cg I showed was done with less than 5 people and two compositors. Doing it solo, maybe a year. Doing the witcher 2 intro, 4 years.
But it really helps to have a super fast renderer like vray

I agree one needs to be realistic. If you have moving things, reflections & transparency, let alone all the other stuff. You need as many computers as you can get or time. Or both!

Attached, this sequence of 2000 frames took 2 weeks on a E5450, 940, 920 & E5335. I was actually pretty impressed, doors & windows opening, pool & fountain water moving, all done in LW.

One just cannot expect it to be done in a day on 1 computer which it probably a year or 2 old.

geo_n
03-14-2012, 08:45 PM
Right. I am aware that was Vray.

That was part of my point.

I thought your point was lw was not far behind in rendering with bruteforce, etc.
Maybe I missed the point. In anycase the renderer in lw 11 did get a lot better with unified sampling but not nearly as close to vray speed, in our case anyway, especially with blurred reflection, softshadows, multiple hi poly characters, clean AA. With animation prepass its even faster.


I agree one needs to be realistic. If you have moving things, reflections & transparency, let alone all the other stuff. You need as many computers as you can get or time. Or both!


I didn't know it before I worked on a studio. I just dreamed of doing stuff like Final Fantasy before but when I finally started work on our studio on similar projects I realized it takes a team of dedicated pros several weeks to do it. With limited rendering resources of less than 10 pc's its important to manage time. And the best possible tools helps a lot not spending 15 hours a day in front of a pc :D

Surrealist.
03-14-2012, 10:53 PM
I thought your point was lw was not far behind in rendering with bruteforce, etc.
Maybe I missed the point. In anycase the renderer in lw 11 did get a lot better with unified sampling but not nearly as close to vray speed, in our case anyway, especially with blurred reflection, softshadows, multiple hi poly characters, clean AA. With animation prepass its even faster.

Well you not are using brute force as I understand it. You are using cache. So yes. With my tests. LightWave is not far behind on Brute force method. Just that alone.

I am not even trying to make this a comparison thread. I am just stating this simple fact. With Vray set to Brute Force as the rendering option, it is very close in speed to LightWave with Interpolated off. This is on a direct comparison on the same scene. As direct as can be with the different quality settings.

To make sure we are on the same page. Here is the documentation I go on when calling something brute force in Vray for Softimage:



Exact vs approximate methods


Exact (unbiased or brute-force) methods.

Advantages:

Produce very accurate results.
The only artifact these methods produce is noise.
Renderers using exact methods typically have only few controls for specifying image quality.
Typically require very little additional memory.

Disadvantages:

Unbiased methods are not adaptive and so are extremely slow for a noiseless image.
Some effects cannot be computed at all by an exact method (for example, caustics from a point light seen through a perfect mirror).
It may be difficult to impose a quality requirement on these methods.
Exact methods typically operate directly on the final image; the GI solution cannot be saved and re-used in any way.

Examples:

Path tracing (brute-force GI in some rendereres).
Bi-directional path tracing.
Metropolis light transport.

Approximate (biased) methods:

Advantages:

Adaptive, so typically those are a lot faster than exact methods.
Can compute some effects that are impossible for an exact method (e.g. caustics from a point light seen through a perfect mirror).
Quality requirements may be set and the solution can be refined until those requirements are met.
For some approximate methods, the GI solution can be saved and re-used.

Disadvantages:

Results may not be entirely accurate (e.g. may be blurry) although typically the error can be made as small as necessary.
Artifacts are possible (e.g. light leaks under thin walls etc).
More settings for quality control.
Some approximate methods may require (a lot of) additional memory.

Examples:

Photon mapping.
Irradiance caching.
Radiosity.
Light cache in VRay.

Hybrid methods: exact methods used for some effects, approximate methods for others.

Advantages:

Combine both speed and quality.

Disadvantages:

May be more complicated to set up.

Examples:

Final gathering with Min/Max radius 0/0 + photon mapping in mental ray.
QMC GI + photon mapping or light cache in VRay.
Light tracer with Min/Max rate 0/0 + radiosity in 3dsmax.
Some methods can be asymptotically unbiased - that is, they start with some bias initially, but it is gradually decreased as the calculation progresses.

II: Gathering vs shooting methods

Shooting methods

These start from the lights and distribute light energy throughout the scene. Note that shooting methods can be either exact or approximate.

Advantages:

Can easily simulate some specific light effects like caustics.

Disadvantages:

They don't take into consideration the camera view; thus they might spend a lot of time for parts of the scene that are not visible or do not contribute to the image (e.g. caustics that are not visible - they must still be computed).
Produce more precise solutions for portions of the scene that are close to lights; regions that are far from light sources may be computed with insufficient precision.
Cannot simulate efficiently all kinds of light effects e.g. object lights and environment lights (skylight); non-physical light sources are difficult to simulate.

Examples:

photon mapping (approximate).
particle tracing (approximate).
light tracing (exact).
some radiosity methods (approximate).

Gathering methods

These start from the camera and/or the scene geometry. Note that gathering methods can be either exact or approximate.

Advantages:

They work based on which parts of the scene we are interested in; therefore, they can be more efficient than shooting methods.
Can produce a very precise solution for all visible parts of the image.
Can simulate various light effects (object and environment lights), non-physical lights.

Disadvantages:

Some light effects (caustics from point lights or small area lights) are difficult or impossible to simulate.

Examples

path tracing (exact)
irradiance caching (final gathering in mental ray), (approximate).
some radiosity methods (approximate).

Hybrid methods

These combine shooting and gathering; again, hybrid methods can be either exact or approximate.

Advantages:

Can simulate nearly all kinds of light effects

Disadvantages:

May be difficult to implement and/or set up.

Examples:

final gathering + photon mapping in mental ray (approximate).
irradiance map/qmc GI + photon map in VRay (approximate).
bi-directional path tracing and metropolis light transport (exact).
some radiosity methods (approximate).

III: Approximate methods: view-dependent vs view-independent solutions

Some approximate methods allow the caching of the GI solution. The cache can be either view-dependent or view-independent.
Shooting methods

Advantages:

Shooting methods typically produce a view-independent solution.

Disadvantages:

The solution is typically of low quality (blurry and lacking details). Detailed solution requires a lot of time and/or memory.
Adaptive solutions are difficult to produce.
Regions that are far from light sources may be computed with insufficient accuracy.

Examples:

photon mapping
some radiosity methods

Gathering methods

Gathering methods and some hybrid methods allow for both view-dependent and view-independent solutions.
View-dependent solutions

Advantages:

Only the relevant parts of the scene are taken into consideration (no time is wasted on regions that are not visible).
Can work with any kind of geometry (i.e. no restriction on geometry type).
Can produce very high-quality results (keeping all the fine details).
In some methods, view-dependent portions of the solution can be cached as well (glossy reflections, refractions etc).
Require less memory than a view-independent solution.

Disadvantages:

Requires updating for different camera positions; still, in some implementations portions of the solution may be re-used.

Examples:

Irradiance caching (in VRay, mental ray, finalRender, Brazil r/s, 3dsmax's light tracer).

View-independent solutions

Advantages:

Solution needs to be computed only once.

Disadvantages:

All of the scene geometry must be considered, even though some of it may never be visible.
The type of geometry in the scene is usually restricted to trianglular or quadrangular meshes (no procedural or infinite geometry allowed).
Detailed solutions require lots of memory.
Only the diffuse portion of the solution can be cached; view-dependent portions (glossy reflections) must still be computed.

Examples:

Some radiosity methods.

Hybrid methods

Different combinations of view-dependent and view-independent techniques can be combined.

Examples:

photon mapping and irradiance caching in VRay.
photon mapping and final gathering in mental ray.
radiosity and light tracer in 3dsmax.

GI methods supported by VRay

VRay supports a number of different methods for solving the GI equation - exact, approximate, shooting and gathering. Some methods are more suitable for some specific types of scenes.
Exact methods

VRay supports two exact methods for calculating the rendering equation: QMC GI and progressive path tracing. The difference between the two is that QMC GI works with traditional image construction algorithms (bucket rendering) and is adaptive, whereas path tracing refines the whole image at once and does not perform any adaptation.

Approximate methods

All other methods used VRay (irradiance map, light cache, photon map) are approximate methods.

Shooting methods

The photon map is the only shooting method in VRay. Caustics can also be computed with photon mapping, in combination with a gathering method.

Gathering methods

All other methods in VRay (QMC GI, irradiance map, light cache) are gathering methods.

Hybrid methods

VRay can use different GI engines for primary and secondary bounces, which allows you to combine exact and approximate, shooting and gathering algorithms, depending on what is your goal. Some of the possible combinations are demonstrated on the GI examples page.


So now that we are on the same page. By definition if you are using any kind of cache, you are NOT using brute force. That is if I understand these docs and the features I have been using in Softimage. If you have some other docs that prove me wrong lets see it.

Exact methods typically operate directly on the final image; the GI solution cannot be saved and re-used in any way.

And when you do in Vray:

Unbiased methods are not adaptive and so are extremely slow for a noiseless image.

As is true in LightWave. It is NOT faster in Vray or Maxwel or Cycles or Octane or any other brute force method.

That is entirely my only point here.

Vray is astounding in every respect. But just on this point alone it is NOT faster. That is all there is to it. And Vray is not alone. It is no big deal that is just the way that it is.

As for other aspects like geometry and so on, LightWave is behind.

And this:

Results may not be entirely accurate (e.g. may be blurry) although typically the error can be made as small as necessary.
Artifacts are possible (e.g. light leaks under thin walls etc).
More settings for quality control.
Some approximate methods may require (a lot of) additional memory.

Is why it is very unlikely that they used adaptive in that trailer I gave the example of. That was my point. Given the way that Vray is designed to be used, they probably used a combination of methods. But specifically for the high detail and that ice geometry, it was brute force all the way on those passes. I would be willing to bet on it.

So, now back to LightWave. Some people don't have a choice. For a Lightwaver, perhaps, this is an option one has not thought of. I think a lot of people don't even consider Lightwave GI with interpolated off, yet dream of having Mawell or some other solution that is just as slow as LightWave in this method.

I personally think Vray is awesome. If you have Softimage or Maya or it is a great solution. I like the way it looks, its controls, its top of the line world class features and so on. It supports Ptex I believe and also Vray proxi is awesome.

But this thread was not about that. Just a comment or two I made about brute force based on direct speed comparisons.

geo_n
03-15-2012, 01:57 AM
With my tests. LightWave is not far behind on Brute force method. Just that alone.

As is true in LightWave. It is NOT faster in Vray or Maxwel or Cycles or Octane or any other brute force method.

That is entirely my only point here.



Very nice list of methods. Thanks for the summary.
The majority of lwvers think that fprime montecarlo is faster than the montecarlo in lw. They're both bruteforce method but one is clearly faster than the other. Its been tried and tested for years in real world projects. That alone clearly means fprime brute force method IS faster than lightwave. In lw 9.6 up to current version people are still using interp mc and cheating with mblur,AS. Few using plain lw mc which the simplest scene takes half an hour to render. I really don't know anyone using plain mc in lw. I know a lot using fprime and lw 8.5 up to now. After all these years fprime still kicks lw mc. :D If only fprime had buffers and easier lwf.
Its not hard to think that it is faster in vray which is being developed at a faster pace. Fwiw better cg than that witch 2 made by companies like Blur studios takes one hour in vray to render ALL passes. I doubt they use bruteforce all the time because its the lazy way to work, and speaking from experience we don't use vray brutefoce all the time either. But who knows.

Surrealist.
03-15-2012, 02:25 AM
Yeah. True points. Nothing more to contribute there.

jasonwestmas
03-15-2012, 08:41 AM
oh yeah Fprime GI smokes! It just doesn't have pixel effects and volumetric lighting, which is why I don't use it. The G2 gamma and color corrector works alright with Fprime but while technically it is possible to composite F10 renders in, it's kind of a drag to get the settings just right.

Surrealist.
03-15-2012, 10:24 AM
Which is the inherent problem with all 3P render solutions. I think Mental ray is the only fully integrated 3P render solution. Every other render engine that I know of - even Vray - has limitations on what it supports and how. Yet they all love to claim... full support of all features. Bogus. Some of the features are taken over by the render engine (meaning you have to use Vray lights for some things etc.) which is good and bad. Some features simply don't work at all. Maxwell for instance as far as I understand has no support for LightWave volume lights. Vray support for SI Volume lights is nil too as is 3Delight. Both solutions require another method and more complex set up. In the Case of Vray this could be considered a good thing. But in SI current version I could not get the settings to do anything useful. But this is an early release and I also may likely missing something. It is probably a better more advanced way to do it. But it is not as easy to do.

Trade offs I suppose. I wonder if Fprime would be as fast if it were required to calculate things that it does not support, which leads me to suspect the design of it as being something intended to cut corners rather than be a true alternate solution. So it is it is more like a tease. Which is why I think I never used it.

jasonwestmas
03-15-2012, 10:45 AM
Which is the inherent problem with all 3P render solutions. I think Mental ray is the only fully integrated 3P render solution. Every other render engine that I know of - even Vray - has limitations on what it supports and how. Yet they all love to claim... full support of all features. Bogus. Some of the features are taken over by the render engine (meaning you have to use Vray lights for some things etc.) which is good and bad. Some features simply don't work at all. Maxwell for instance as far as I understand has no support for LightWave volume lights. Vray support for SI Volume lights is nil too as is 3Delight. Both solutions require another method and more complex set up. In the Case of Vray this could be considered a good thing. But in SI current version I could not get the settings to do anything useful. But this is an early release and I also may likely missing something. It is probably a better more advanced way to do it. But it is not as easy to do.

Trade offs I suppose. I wonder if Fprime would be as fast if it were required to calculate things that it does not support, which leads me to suspect the design of it as being something intended to cut corners rather than be a true alternate solution. So it is it is more like a tease. Which is why I think I never used it.

Yeah I can see why you may feel that way about Fprime, the nodal shading never looked as good as an F10 anyway, imo.

Well at least there are trade offs for volumetrics and pixel filters in vray and 3delight. Fprime has no trade offs for volumetrics and pixel filters, it just doesn't have the capability available to us.

Unless there is some trick in Lightwave for faking volumetrics I'm not aware of.

geo_n
03-15-2012, 10:46 AM
oh yeah Fprime GI smokes! It just doesn't have pixel effects and volumetric lighting, which is why I don't use it. The G2 gamma and color corrector works alright with Fprime but while technically it is possible to composite F10 renders in, it's kind of a drag to get the settings just right.

Yes it does smoke and give vray a run for their money. Its really too bad its not been updated to support the current stuff. But if anyone is doing work solely in lw 9.6 and below, its the renderer to use. Hassle free and even just plain raytracing on it is fast and gets those sharp details.
Just don't bother with lwf and buffers and you're all right. People have been doing good cg without them anway for the past decade. But its just that extra oomph. control and consistency with these lwf, buffers, etc.

jasonwestmas
03-15-2012, 10:53 AM
Yes it does smoke and give vray a run for their money. Its really too bad its not been updated to support the current stuff. But if anyone is doing work solely in lw 9.6 and below, its the renderer to use. Hassle free and even just plain raytracing on it is fast and gets those sharp details.
Just don't bother with lwf and buffers and you're all right. People have been doing good cg without them anway for the past decade. But its just that extra oomph. control and consistency with these lwf, buffers, etc.

Oh yeah, if I needed something done really quickly, I would dig out 9.6 and Fprime in a heart beat. Which is why I really do hope that Worley keeps expanding on his code some how.

geo_n
03-15-2012, 11:00 AM
I think Mental ray is the only fully integrated 3P render solution. Every other render engine that I know of - even Vray - has limitations on what it supports and how.

From what I know 2 years ago mray didn't support a lot of stuff in 3dmax and vray was more integrated in that platform. We couldn't even use some standard materials for 3dmax to show up in mray. Vray is ok with standard material and lights but you lose the speed up from vray lights and materials.
A simple discussion of mray
http://www.linkedin.com/groups/What-are-biggest-issues-you-1893352.S.68571212

I'm guessing maya and xsi version are a generation behind 3dmax vray.

jasonwestmas
03-15-2012, 11:39 AM
From what I know 2 years ago mray didn't support a lot of stuff in 3dmax and vray was more integrated in that platform. We couldn't even use some standard materials for 3dmax to show up in mray. Vray is ok with standard material and lights but you lose the speed up from vray lights and materials.
A simple discussion of mray
http://www.linkedin.com/groups/What-are-biggest-issues-you-1893352.S.68571212

I'm guessing maya and xsi version are a generation behind 3dmax vray.

Super interesting link, thanks. :thumbsup:

Surrealist.
03-15-2012, 12:20 PM
From what I know 2 years ago mray didn't support a lot of stuff in 3dmax and vray was more integrated in that platform. We couldn't even use some standard materials for 3dmax to show up in mray. Vray is ok with standard material and lights but you lose the speed up from vray lights and materials.
A simple discussion of mray
http://www.linkedin.com/groups/What-are-biggest-issues-you-1893352.S.68571212

I'm guessing maya and xsi version are a generation behind 3dmax vray.


Yeah that is interesting. Come to think of it I have heard it said that XSI has the best integration of Mray. Not sure about Maya. But in XSI it is virtually transparent.

Chernoby
02-07-2015, 11:38 AM
Also, you can cache GI on a simpler version of the scene to circumvent certain issues or just speed it up. Like caching with reflections turned off to name but one thing. Then turn things all back again.

So glad to have read this. It is awesome advice.

artzgo
02-25-2015, 11:18 AM
Recently a lot of time spent on testing the animated GI in LW.
The conclusions are that good performance is difficult to achieve and often impossible.

I did a test in Kray and there everything goes smoothly, nice results with simple settings.

Here my tests in Kray:
https://www.youtube.com/watch?v=fHBVyag3ldI
https://www.youtube.com/watch?v=zjo4AOMhzmY

greetings

jasonwestmas
02-26-2015, 12:14 PM
yeah interriors are expensive to render realistically. Glad Kray works out. Or is kray missing something else that made you look back at Lightwave?

artzgo
02-26-2015, 01:06 PM
no VPR and fur is still not connected

jasonwestmas
02-26-2015, 02:45 PM
no VPR and fur is still not connected

I would take speed and dependability over VPR any day. Fur/grass I can understand but only if I didn't have instancing and I didn't have to animate the fur/grass.

Chrusion
03-06-2015, 08:25 PM
Recently a lot of time spent on testing the animated GI in LW.
The conclusions are that good performance is difficult to achieve and often impossible.
Do explain. What do you mean "impossible" to achieve good performance? Is this render time/frame vs. visual quality? Or are you referring to GI flicker using baked cache with frame step greater than 1?

I'm having major issues getting LWSN 11.6.x to interpolate between cached frames due to the fact that NT changed caching from a single file pre-LW 11.6 to cache sequence files every frame step. LWSN reads the frame step numbered files just fine, but inbetween frames (in which cache files don't exist) force the render engine to calculate a new GI solution, ignoring any of the previous or future cached data. This, of course, results in GI flicker as if the scene wasn't even baked to begin with. LW 11.0, with it's single cache file, renders in LWSN without any "reading" or intra-frame interpolation problems, resulting in flicker-free GI, even at low RPE and SBR.

So, please elaborate on your tests of anim GI in 11.6.x and/or 2015... flicker? or no?

Chrusion
03-06-2015, 09:53 PM
Wow! Something VERY interesting just happened!

I decided to just go for broke and set frame step to 1 in 11.6.3 and amazingly, LW baked the scene SUPER FAST, just like 11.0! IOW, it was using the previous frame's samples as the base for the next frame. OK... didn't see that coming. I was totally expecting LW to crank on each frame from scratch like it does when frame step is greater than 1.

The next surprise came when I started up LWSN and seen that good ol' friendly status msg "Recalculating radiosity samples... Recalculating radiosity samples..."!!! Again, this is what 11.0 did before the change to cache sequence files in 11.6.

And finally, what floored me is that I was expecting to see 150 cache files for this 150 frame cornell box anim test. But what did my eyes see, instead? Yep, a SINGLE cache file far SMALLER in size than the total of the 15 cache sequence files when I baked the scene at a frame step of 10!!! The single cache file at frame step 1 = 3.1 MB, while the average size of the cache sequence files was 2 MB (times 15 = 30 MB). Cool!

So far, after only 10 frames rendered (single LWSN node at under 2 min/frame) the result is free of GI flicker, even though I turned all ray trace options Off, except shadows, in order to speed up GI baking that I was expecting to take 40 seconds/frame. Instead, it took 2 sec/frame! I thought the lack of ray traced shading would influence the preliminary GI baking calcs and cause flicker when those rays were turned back on, but apparently it doesn't!

Overall this makes me VERY happy! Even though my future GI bakes of complex production scenes will be every frame, I just might see a decrease in total scene bake time vs the render time of doing every 10th frame at the longer "from scratch" preliminary calc time. But, if the total bake time is longer doing it every frame, well, it'll be something I can live with knowing there won't be any flicker. Soooo, if and when NT fixes the broken GI cache sequence file issue in LWSN (works fine using Layout to render), this compromise will have to do.

Good night.

artzgo
03-08-2015, 06:46 AM
Wow! Something VERY interesting just happened!

So far, after only 10 frames rendered (single LWSN node at under 2 min/frame) the result is free of GI flicker, even though I turned all ray trace options Off, except shadows, in order to speed up GI baking that I was expecting to take 40 seconds/frame. Instead, it took 2 sec/frame! I thought the lack of ray traced shading would influence the preliminary GI baking calcs and cause flicker when those rays were turned back on, but apparently it doesn't!


Good night.

You can upload an example ?


I mean the scene flicker-free ... in animation where moves, camera, lights and objects ...
It's difficult to do in LW

We can certainly do it in parts .... render background with static GI, then render moving objects and submitted Postproduction

Generally the animated GI with cache as for example 10/frame works fairly well if the camera and objects in the scene is moving slowly ... then mixing frame is good ... but the shadows are also blending often does not look good

Need a method that mixes GI so as not to be seen flickering but also properly credited shadows.

I hope LW3DG, do it right ... we are in 2015 and there are still problems with this :)
But recently I came up with the idea ... I have yet to test it ... after a while I put you to info on the forum

Chrusion
03-08-2015, 05:11 PM
The scene doesn't matter. Use whatever you want. Indoor. Outdoor. Cornell Box. Whatever. Then do an animated GI bake at frame step 1 (turn all ray trace options off to speed baking). Turn ray trace options back on and save the scene. Send to your LWSN render farm. You'll have flicker free GI with camera, light, instances, HV, and object motion.

This frame step, GI cache sequence file LWSN bug has been submitted under Case LWB-1407.