PDA

View Full Version : Rendering Times Using Radiosity Cache And Network Rendering



spigolo
08-28-2008, 09:32 AM
Hello,
i'm testing LW 9.5 in production..
I have studied the new radiosity setting and made some experiment to optimize time and quality.
Everything fine, but when I bake the radiosity using the cache options I have noticed that I get fliker free animations, but the time to render a single frame on the network is nearly the double then if I render it on a single machine without using the cache..
Is that normal? so the cache is just to avoid flikering but the way it's used makes frames calculation longer?

Exception
08-30-2008, 03:21 AM
Spigolo...

That's not supposed to happen. I've encountered cases like yours before and sometimes this seems to happen. We need more content to test for cases like this.

Ideally render time should not be affected by using the cache or not. With the animated cache, each frame will take as long as a non-cached render. With the static cache, each frame will take only as long as the normal-pass of a non-cached render, without the radiosity preprocessing.

If your scene is very complex, a lot of samples are generated and stored int he cache, which require re-rendering each frame (for animated cache), and re-applying each frame (for static cache). If there are a lot of samples, this may slow down rendering. If you bake many frames, you get more samples... A way to get around this is to use a larger frame step and try to find a good balance between sample points and frame steps. Also make sure your MPS settings are not very low.

For slow moving scenes I've used a cache frame step of 20 with success.

I know mark is looking into a way to make this process more efficient.

spigolo
08-30-2008, 06:42 AM
Except thanks for your reply..
What I have noticed is that render times on a single machine where I setup the scene are for example 4 minuts..
Let's say a yacht model around 100k poly with interp montecarlo etc. rendered at 1280*720.
When I bake the cache (10 frame step) everythig it's fine, then if I try to render both on the same machine or using butterflies I have noticed that the times nearly double..around 8 min..
What I have seen is that if I try to rerender a frame using the cache LW renders like he is rendering a standard Montecarlo (no iterpolated) and the rendering slices (the multi precessor tasks) advance in render regularly but much slower.
Also AS takes longer (this could be an impression)..
So to speed up I raised the AA passes and left away the As but anyhow render times are nearly the double on the render farm.
What I could say is that animation are fliker free, no radiosity problem.
i didn't understood if this is a price to pay to use radiosity in the render farm or I'm doing something wrong..

thanks for your help.

ps.
I'm out of the office now I can send you some content on monday..

Exception
08-31-2008, 06:18 PM
Hi Spigolo.
I don't quite understand your description.
It renders slower with LWSN than within Layout, is that what you're saying?
If so, are you sure LWSN can find the cache file properly? If not, it might be rerendering radiosity at render time.

Are you getting speed differences with one frame cached versus many frames cached? If so, it's the problem I described earlier: too many sample points are added.
If not... well... I don't really understand your message...

spigolo
09-01-2008, 12:42 AM
yes it's correct it renders slower..
I don't know if lightwave is loading the cache or not..
What I don't understain is:
If I bake the cache on a specific location (a shared drive mapped with an unic letter on the network so butterfly can access it..) then lightwave loads it automatically when I start to render the frames?
I don't see a load cache button anywhere, so I suppose that lightwave load the cache automatically if he sees that I have a cache baked.. and the same happens on the network, otherwise I'm doing something wrong..

thanks for your help...

phile
09-01-2008, 12:45 AM
Everything fine, but when I bake the radiosity using the cache options I have noticed that I get fliker free animations, but the time to render a single frame on the network is nearly the double then if I render it on a single machine without using the cache..

I'm seeing something very similar: render times double if you bake an animated cache and then render, rather than rendering direct using an unbaked animated cache.

Thread here: http://www.newtek.com/forums/showthread.php?t=87670

Phil

spigolo
09-01-2008, 01:02 AM
Thanks Phile!
I read the thread but it's the same situation I have..
I should say it's a bit frustating as I was very anxious to use the possibility to animate radiosity on the network..

What I can say is that when i examine the software in the rendering process after the cache baking what I see is that it renders like he is not interpolating, but as a standard montecarlo not interpolated..

hope jay roth or newtek may reply to this issue as this is one of the shiny key point of lightwave 9.5 and it's a pity to see it working like that..

spigolo
09-01-2008, 08:22 AM
..I'm thinking that maybe the problem depends from the location of the cache file..
Anyhow there are no specific indication in the documentation, so I assume that any location is good if it's accessible by the network.

Newtek where are you?

Exception
09-02-2008, 07:04 PM
It seems that sometimes the cach efile is saved with absolute file paths... so it can't be found with LWSN but can be found by the computer making it.

Check the .lws file with a scene editor and check if this is the case.
This kind of behavio ris not normal LWSN should behave exactly as Layout. If it doesn't, there's either a bug that hasn't been found yet( thi shas been tested thoroughly though) or it can't find the file due to an absolute path. I encountered that before.

spigolo
09-03-2008, 12:22 AM
Thanks I will check this..
I'm a bit desperate as I was pointing a lot on this feature.
I tried to export the scene using package scene to see if everything workfine but I still have the same problem.
With complex rendering times increase even of four times on the network rendering..

spigolo
09-03-2008, 02:50 AM
I drop my experiments with animated radiosity..and I will switch mmy efforts to Kray which is faster even if this will make things much more complicated as
I will have to start animation on every single machine..
I'm very deluded of the behaviour of the animated radiosity function..

Render times on network increases over any reasonable time..
Even if I experiment on a single machine when the software start to use the cache the render times becomes too long.

It's the typical Newtek style features lot's of promise and few results..

I hope they will fix this in the future..but future for Newtek means long long times..

Exception
09-03-2008, 04:30 AM
It's the typical Newtek style features lot's of promise and few results..


The animated cache works very well.
You have to learn how to use it. It has certain properties you need to understand. You also have to learn how to use Kray.

Animated radiosity is not available in Kray at all. Very few renderers offer something like this.

If you are getting severe slowdowns, it's probably just the path to the GI file. I's best o have it relative, and inside the content directory, which is where it defaults to. If that's too difficult a setting for you, sure, but don't start badmouthing Newtek for it. I've been trying to help you, and I kind of take this to reflect on me as well.

Exception
09-03-2008, 04:42 AM
You may also want to check this thread, and my response at the end.
http://www.newtek.com/forums/showthread.php?t=87670

Please also note in your original post you do not mention anything about using the ANIMATEd radiosity... that's not the same as the static one. This confused me, as this is not a likely thing to happen with the static cache. The animated cache works very differently.

spigolo
09-03-2008, 04:46 AM
Exception,
you have been very kind and I have nothing against you of course.
You are doing a lot also for the community..
But i'm not a novice in rendering since I do this from 1988 and if I'm missing some step the problem may lie also in the lack of documentation and example from newtek..(an old problem like always)
If you look at the what's new in 9.5 pdf file they even don't explain the various cache settings like automatic,never etc. etc.. just to explain how they care the documentation..

What i have done in this days is to setup a satisfing render with interpolated Montecarlo, bake the cache (animated or not), render the scene both on my network or on a single machine veryfing that the cache path has been saved correctly (both looking at the scene file as you have suggested, both verifing it on the render global panel) but the result is the same...ugly render times..

My network has disk mapped with unic names so I have just one Z drive for example or W: etc. etc.
I have also tried to package the scenes with the new package tool and use this scenes in the rendering but i have got the some problem.
The only attempt I haven't done yet is to save the cache on the root of my contend drive to see if there is more accessible..

anyhow as other people are having this kind of problems you have to agree with me that there must be some bugs on the management of the cache.

And Kray has an animated option that at least works for simple movements of objects as I have tested in the past for other productions.
The reason I wanted to move to LW to render this production was the possibility to use butterfly as it makes life easier..

maybe I have to wait LW 9.5.1?

Exception
09-03-2008, 05:22 AM
anyhow as other people are having this kind of problems you have to agree with me that there must be some bugs on the management of the cache.


Not that I know of. Have you read my response to that thread?
I also updated my guide with images and an animation to clarify the potential problem just now.

I can't look into your computer.. I don't know if it's your GI settings (could be it), your file locations (could be it), the scene content (could be it) or perhaps a bug, as that is possible, but highly unlikely. I tested the snot out of this thing. This means unless you are willing to share the scene, and be a bit more clear about the problem, I can't exactly tell you what the issue is.

Let's talk about 1 specific scene that you have trouble with. Don't mix in other scenes. One problem at a time. Please send me this scene. You can use the email listed on my website.

As far as Kray is concerned... I love Kray. But the animated radiosity... is just the interpolation of a bunch of solutions. It's really troublesome. You are almost guaranteed to lose more days worrying about that than LW's animated GI. That said, Kray is faster to render in the end, but you have less flexibility. Use the right tool for the job.

PhantomPhish
09-03-2008, 05:33 AM
It's the typical Newtek style features lot's of promise and few results..

I hope they will fix this in the future..but future for Newtek means long long times..

This isn't a fair comment.

Unfortunate that you couldn't get it to work, but the animated and static caches have been tested very thoroughly, and are amoung the most stable and complete features of 9.5 that deliver excellent results. Perhaps if you shared your scene we could help you find out what's going wrong?

spigolo
09-03-2008, 05:54 AM
I will try to send to exception the scene even if'its a bit rough too..

CROUTON213
09-09-2008, 06:05 PM
Hi, I don't mean to just jump into this long thread, but it stuck in my mind that perhaps when you render on the local system Lightwave is using all of your CPU cores to render 1 frame, but when network rendering it only uses a single core per frame, thus dividing your rendering speed.

Therefore you should setup 2 or 4 (or 8 or 16) render nodes or how ever many CPU cores you have your system to match the number of render nodes.

For example, I have a quad core CPU w/ 8GB on my local system. When network rendering with this local system and all the other systems in our studio, my local system has 4 render nodes, thus matching the number of cores...in this case a quad core CPU. So even though a single frame takes longer to render in a network rendering environment, I am rendering 4 frames at a time...

spigolo
09-10-2008, 07:59 AM
Butterfly should controll automatically the use of 4 threads for each quad.
So i suppose that the machine are using all the cpu.. anyhow I will make some test.

simpfendoerfer
09-10-2008, 07:30 PM
My experience too. I am rendering on just one machine.

[QUOTE=phile;743257]I'm seeing something very similar: render times double if you bake an animated cache and then render, rather than rendering direct using an unbaked animated cache.

Thread here: http://www.newtek.com/forums/showthread.php?t=87670

spigolo
09-11-2008, 11:22 AM
one thing that I have noticed is that if you have reflections active expecially on large surfaces times may become 3-4 times higher in a snap..

pixym
09-12-2008, 11:23 AM
That is really a BIG issue that needs to be fixed…

spigolo
09-12-2008, 11:36 AM
in this days I'm under a big production, and I'm testing lw 9.5 render and radiosity cache a lot..
One thing that I have realized is that if you have reflections radiosity time can grow of 3-5 times very easy.
After many optimization I succed in getting nearly decent render time for my production (15 min per frame with 1280*720 hd) and I..
what's wrong is that the 15 min per frame are 8 minutes if you render them on a single machine and not on the network..

anyhow suggestions:
1 avoid reflections as more as you can redure rays bounce to 4-6..
2 care for double side and rounded geometry
3 work on the radiosity parameter of every single objects to optimize

this are survival suggestion but there are issue that have to be fixed..soon!!

Newtek...? Jay..any help please..?

simpfendoerfer
09-12-2008, 12:17 PM
And avoid Photoreal Motion Blur and DOF

McLeft
12-24-2008, 01:45 AM
I have same issue. With cache turned off - render time ~6 min per frame, with cached GI render time can go up to 1.5 hours per frame (this is for 10 nodes renderfarm). I've been exploring this issue and found out that nodes constanly read/write something to network drive (quite heavy - non stop traffic in both directions). So my guess was that network is bottle neck, i assigned scene to one node and it helped. It was slower than with cache turned off but not so critical (+1-2 min per frame). But now i have scenes which express same behavior on ONE node. Render time rises from 5 min to 1 hour with cached GI. Say 1st frame 5 min... 20th frame 45 min... and so on. With cache turnd off render time is 5-6 min per frame for all frames.
I didn't find any solution yet. (exept moving back to 9.3).... With V-Ray precaching GI reduces render time but not with LW. Looks like serious bug for me.

UPD. Finally i had to re-save scenes to 9.2 version. LW9.3 render time is 4 min (where 2 min is GI calculation time), so pure frame render is ~2min!... comparing to 9.5's 6 min per frame with same settings (with GI cache off) and more than 60 min per frame on render farm with cached GI. Looks like one node with 9.3 will render at least 3 times faster than 10 nodes renderfarm with 9.5. Nice!

JonW
12-24-2008, 06:00 AM
Im doing 2000 frames @ 1280x720 with radiosity, Its tough!

Cached Radiosity.... I have noticed that if you stop part way through a sequence of frames & then restart, the radiosity changes. Which means that when you restart you will need to overlap enough frames & fade the sequence into each other.

Also if you are using say 2 computers & a 1000 frames, start the render in the middle + or - a bit allowing for the speed of each computer & the complexity within the sequence & render 1 computer up (first 501, last 1000, step +1 ) & the other computer down (first 500, last 0, step -1), but still overlap a few frames in the middle (at the start of each computer 491 & 510). You will get a better & shorter join.

If you are using 4 computers, run in pairs, each pair up & down, & then you have one main join in the middle & 2 small joins.

Cache Radiosity is good but you do have to fight it.

I am doing my images on a, 5335 V8 12gb, 940 12gb (OC 3.68ghz), 920 12gb (OC 3.15ghz), 5450 V8 16gb. The scene while rendering according to WTM is about 9gb on the 4 bangers & 10gb on the V8s. The 4 boxes are spitting out 9 frames an hour..... Bugger!

14m polys, FG Cached, AA11, IB 6, RPE 256 & 16, AT 6, 4, 100, RRL 5, Area lights 4, & 9/10 of the plants radiosity turned off.

JonW
12-24-2008, 06:26 AM
Typo: AT is 46 degrees

McLeft
01-20-2009, 03:12 PM
Another scene. Render time: 6:30 (cache is off), 14:50 (prechached GI)
Does anyone ever had such issue?

pixym
01-20-2009, 03:14 PM
I have just test a scene that shows this exact same issue with 9.6.

pixym
01-20-2009, 03:36 PM
Sorry, but after checking:
Render time: 9:48 (cache is off), 10:41 (prechached GI)
Less than 10% speed lost

McLeft
01-20-2009, 04:46 PM
There is a simple scene to demonstrate this issue.

1. Open scene
2. Go to Global Illum tab under Render Globals, click Reset Cache File Path button.
3. Click Bake Radiosity Scene button. (Will take less than 2 min)
4. When done, render, say frame 10. (In my case it 2:32)
5. Go to Global Illum tab again and uncheck Cache button.
6. Render frame 10 again. (in my case i get 1:18)

about 95% slower for such simple scene... So far GI in LW9.5 is near to useless for animation, because LW9.3 renders much faster.

UPDATE: Tested this scene with LW9.6
Precached GI: 1:09
GI cache off : 0:36
Looks like nothing was changed in this department

pixym
01-20-2009, 04:59 PM
I am home right now, so I will check that tomorrow.
Thank for the scene btw.

jayroth
01-20-2009, 05:00 PM
First of all, you should be using 9.6, as that is now the current version. There have been many improvements in 9.6 in this area.

Second, understand what the caches are for; there are two, one for stills or camera-only motion, and one where there can be changes anywhere.

The still image cache will likely resort in very quick render times after the cache has been calculated. This cache is only appropriate to use where there is camera motion only.

The animation cache can resort in longer render times than using brute force GI on your animation. The benefit of using the animation cache is to have a flicker-free result when rendering (provided you have properly set up the cache). Brute force GI, regardless of the method, will always result in flickering animation.

Due to the nature of the animation cache, render times will often be longer, due to the fact that new sampling regions are uncovered throughout a sequence; those samples need to be performed, weighted, managed, etc.

Once you understand when to use the tools, as well as how to use them, you will be happier with the results that you are getting.

McLeft
01-20-2009, 05:29 PM
I know what cache is for. Im using LW since version 5.5 and unfortunately i know how to use tools and it doen't make me happier :) But this way we are moving discussion away from a problem.
Let me tell you how this feature works in VRay.
VRay saves GI solution to .vrmap file and once it's done you get MUCH faster render times across render farm. Just few real life numbers:
frame render time with GI: 6-7 minutes
frame render time with GI from file: 2 minutes.
(Note not 12-14 min but just 2 minutes)
And it doesn't matter was GI solution interpolated across frames for animation or not (for camera only movement) you get same time.
Indeed, if you saved GI solution to file you dont have to recalculte it. It means that render time should be shorten by GI calculation time and there's no any sane reason for a way longer render times. And LW9.3 does it exactly this way (shorter render time with cache) exept a fact it doesn't save cache to file but keeps it in RAM.

jameswillmott
01-20-2009, 06:16 PM
GI Cache works beautifully in 9.6 as long as you are using it correctly, and it saves to a file, just like Vray.

pixym
01-20-2009, 06:19 PM
GI Cache works beautifully in 9.6 as long as you are using it correctly, and it saves to a file, just like Vray.
Hi James, Just curious, do you test the McLeft scene here (http://www.newtek.com/forums/showpost.php?p=810324&postcount=31)?

grangerfx
01-20-2009, 06:25 PM
I am going to have to echo what Jay said. It is worth reading the manual about the new features before suggesting that they are not working correctly.

The animated radiosity cache is a new feature. It has a completely different purpose than the static radiosity cache (which is still fully supported and works better than ever in 9.6).

The purpose of the animated radiosity cache is to eliminate or at least greatly reduce flickering of radiosity in animations. This comes at the cost of a significant increase in render times compared to the animations rendered with the static cache. Radiosity has become such an important rendering feature that we decided to do some R&D and solve its biggest limitation which is flickering in animations when more than just the camera is moving.

The animated radiosity cache algorithm was invented by NewTek (Yes, new technology from NewTek.) It works differently than the way other programs animate radiosity (there are plusses and minuses to each of the algorithms). You therefor cannot compare the animated radiosity cache in Lightwave to the static cache pr the animated caches in other products.

Because the animated radiosity cache is a new feature and is still somewhat experimental. This means that over time we hope to improve it and make it more efficient. For example, one obvious enhancement would be to merge the static and animated caches into a single cache. That way if most of your scene is static while only a few objects are moving, the rendering times could be greatly reduced.

The animated cache does have one major advantage over the static cache: The baking process goes a lot faster. Even though each individual frame takes longer to render, the total time to render an animation, including the baking, may be less when rendering it with a network of computers.

-Mark Granger

grangerfx
01-20-2009, 06:28 PM
Hi James, Just curious, do you test the McLeft scene here (http://www.newtek.com/forums/showpost.php?p=810324&postcount=31)?

I opened the scene. The Animation GI cache option is checked which explains why the scene is rendering slower after baking the cache.

-Mark

pixym
01-20-2009, 06:30 PM
Thanks Mark for information about this scene.

McLeft
01-20-2009, 07:44 PM
This is SAMPLE scene to demonstrate an issue. Actual scenes i have to work with require "Animation" to be ON.
But look at LW95 render times with "Animation" OFF:
Precached: 1:36
Recalculated: 1:16
Difference is not so dramatic but still cached GI takes more(!) time to calculate.
This is simple test scene but i have real life scenes (with animation turned OFF) where render time goes up to 1 hour while w/o cache it's just 6min.

Look at how LW93 does it. If GI calculation time is 3 min and a rest of frame takes 5 min to render which is equal to 8 min per frame total. If you turn cache ON you will get 5 min + few second for additional GI for consequent frames. So you get faster render time, but on one node only.

Do i look insane saying this?

I tested this scene with LW96 and render time is about a same for cache on/off despite a fact that it DOESN'T have to recalculate GI. Looks like something was done to "new invention", but not enough still :)

I don't understand such "inventions". It's like i would invent alternative fuel which would reduce engine power and mpg. Probably i would have to sell it really cheap to make people buy it.

So sanity check: It is not a Problem but New Feature and New Invention by Newtek? And we should stop this discussion? :)

jameswillmott
01-20-2009, 08:21 PM
My times for that scene are: ( With the Animation check OFF, because only the camera moves )

Cache Off
18 seconds GI + 35 seconds rendering

and

Cache On (18 seconds to build cache)
40 seconds rendering


That's for just a single frame. I tried caching the entire animation as well and got basically identical results.

This seems to be what you'd expect, what's the problem?

McLeft
01-20-2009, 09:21 PM
This seems to be what you'd expect, what's the problem?
You probably using LW9.6. With Animation off you get OK render times there.
Just try to leave it ON. If you want i can make one of boxes moving :)

jameswillmott
01-20-2009, 10:11 PM
In your scene, only the camera is moving, therefore Animation checkbox should be off... as Mark said, the Animation check doesn't make GI much faster but it prevents flickering.

jthompson3d
01-21-2009, 08:00 PM
One question I have for you that i found and over looked is are you using screamerner or BNR (Butterfly net render) to manage your network? In layout you might have your threads set to 4, 8, 10, 12 threads or somthing were in most network rendering programs they don't have this ability only to use 1,2,4 threads. I had to find that out the hard way.

As far as using the radosity cache, we have been doing it on our projects for clients for about two months and havn't had a problem until at first when we had to figure this all out. There isn't enough documentation on this and how it exactly works. I have also found out your cache file CAN NOT have any spaces or weird things like that in the name or it wont get pikced up, if you make your cache file 1 name or use underscores it picks it up fine, just some small bugs I have found in the past.

Don't know if any of this helps. :thumbsup:

pixym
01-22-2009, 03:54 AM
One question I have for you that i found and over looked is are you using screamerner or BNR (Butterfly net render) to manage your network? In layout you might have your threads set to 4, 8, 10, 12 threads or somthing were in most network rendering programs they don't have this ability only to use 1,2,4 threads. I had to find that out the hard way.
If multithread is set to automatic, lwsn set # of thread = # of core of the host computer. Hope this helps.
BTW: I use screamernet.

Hieron
01-22-2009, 07:32 AM
You probably using LW9.6. With Animation off you get OK render times there.
Just try to leave it ON. If you want i can make one of boxes moving :)


Did you read the mandatory radiosity guide by Tom (Except.nl)?

He describes *exactly* what you are experiencing, gives a perfect solution and shows that this behaviour is 100% as intended.

There is a damn good reason for the render to take longer and if you'd read up on it (using LW since 5.5 is not much use here, this is all new) then it would be alot clearer.

It works fine, you just can't render a single frame correctly, slam the "anim cache" button, bake the scene and expect it to be done. You need to tweak that for a sec before it is perfect. And the new 9.6 has great radiosity flags to help you.

As I said, all in Tom's guide... all there.


Hmm, his guide is up, http://www.except.nl/lightwave/RadiosityGuide96/index.htm but not with a direct link from his site yet..

Castius
01-22-2009, 09:20 AM
Hieron it's probable a good idea to not get so angry. 8)

Castius
01-22-2009, 10:11 AM
Hieron I did take your input and did a render to see the sample points.

You can clearly see that with animated cached on there is a lot more samples. Once you see that is should be easy to see why animated(Non Flicker) would take longer. So if you take exception advice you will need to modifier your radosity setting. In order to match your previous render speed sometimes.

Uncached 7:30 seconds
cached 10:10 seconds.

Hieron
01-22-2009, 01:15 PM
Didn't mean to be angry though.. but wasn't really happy with:

*had a HUGE list of nags, complaints, wrong claims and odd references to perfect Vray here but meh, nvm*


This urge of shouting "it sucks!" and meanwhile completely ignoring all the perfect explanations got to me I guess :) I'll try to ignore it better next time.. tough though.
The cache is a great addition.




Perhaps Proton can make Exceptions guide into a video, for extra clarity. Seriously though.. the new system is cool enough to warrant it.. :)

Castius
01-22-2009, 01:28 PM
:agree:

adamredwoods
01-22-2009, 06:19 PM
As I said, all in Tom's guide... all there.


Hmm, his guide is up, http://www.except.nl/lightwave/RadiosityGuide96/index.htm but not with a direct link from his site yet..

This is nice info. How did he learn all this? Is this in the Lightwave manual?

....and someone make sure the LightWiki has this link. (EDIT: it is, but i dont think its updated)

Hieron
01-23-2009, 06:11 AM
Well, he posted this updated guide on the beta forums, so I hope it is fine I spill the beans here.

Not entirely sure how he figured out all those details, checked the radiosity flags etc even before they were a nice option in Layout itself. I think he is a smart driven person and needed the info for a job and was kind enough to write it down too.

It is a great resource, and could use a sticky here, or even sit snuggly side by side the video links on the LW main site. Or become a video itself (even though I like the guide type of thing and inherent better image quality)

ow and he has a donation link up if you liked it. To me the info is very valuable as it helped me directly with projects and would have been a hassle to figure out myself, so I did. But that is up to everyone to decide, which is nice.

geo_n
01-26-2009, 12:14 AM
My old 9.3.1 scenes are finally faster in terms of quality. You can now get better quality renders with almost the same render time as 9.3.1. Not necessarily faster but better quality.
But why is lw renderer still so slow with blurry reflections? Same scene takes 3 times to render than kray or vray. I put 10-30 blur on some surface and the scene takes a render hit immensely. I'm just spoiled with kray and vray I guess.

Exception
01-26-2009, 09:00 AM
Thanks for plugging the guide, Hieron, and thanks for the donation :)

I'm glad you find it useful.

Regarding the animated GI and the speed, as I was reading this thread that it's a typical behaviour and it's reasonably easy to solve in 99% of the cases. The guide explains well enough how this works so no need to go into it here.

I will probably sooner rather than later make video tutorials regarding all this material, as well as the AA engine. I'm working on a large video / magazine tutorial now for 3D world on a related topic which is taking up my spare time. After this I can make some, which likely will not be free like the guide. Very few people donate, and it takes a tremendous amount of time figuring all this stuff out, writing it down and making content.
That said, I enjoy doing it.

GraphXs
02-16-2009, 09:47 PM
A big thanks for the guide, and looking forward to your video tutorials! Any idea when ya going to come out with them. Also in what 3D world will your write up be in? Is it about LW GI? I wonder if Core will have some new GI stuff.

GraphXs
02-16-2009, 09:52 PM
Oh, and while I'm on this thread, is it easy to set-up screamernet? I have never done it before? I will check the docs but if anyone can give me some tips or a easy step by step that would be welcome.:thumbsup::thumbsup:

JonW
02-16-2009, 11:52 PM
Best to post in SN section, but here are some notes,

Use Matt’s PDF first then the video. I have re set up SN up for 9.6. & it works fine. Im using 4 computers.
It is best to print off the PDF, read it very closely & very slowly & take your time & follow it to the letter, read every page.
Once you have got your main computer set up including one node & also a second node running. Any extra nodes are copy & paste to each computer & you only have to change a few numbers.
best to do the set-up if your in the mood & can think clearly.
____________________________________

@echo OFF
echo "Lightwave ScreamerNet Node 2 initialisation ..."
cd "c:\LightWave\Programs\"
lwsn -2 -c"\\J5450\screamernet\config_sn" -d\\J5450\screamernet\ -q "\\J5450\screamernet\screamer_command\job2" "\\J5450\screamernet\screamer_command\ack2"

___________________________________

Node 2 for my computer with the correct paths.
The “-q” stops most of the text, but its best to add this once you are up and running.
Make sure you copy your plug-in folder to each computer as well.
All_your_files_must_not_have_gaps_in_their_names.

GraphXs
02-17-2009, 03:58 PM
Thanks for the info!

Exception
02-17-2009, 06:11 PM
I'm not sure when I'll make them. Or in what way.
The guide covers everything, basically, I guess Ill make some videos of specific cases.

erikals
04-26-2009, 12:29 PM
what i think is a bit confusing is that in the Siggraph 08 video the Animated Radiosity Cache was demonstrated as if it was a tremendous time saver...

http://www.newtek.com/lightwave/sigvideos.php
click on "List" in upper right corner... and choose, "Animated Radiosity Cashing"

...it seems a bit misleading (?)
...or maybe i just never noticed the flicker problem as i had to use very HQ settings for the radiosity (?)

jayroth
04-26-2009, 03:09 PM
there are two caches; one where only the camera moves (the static cache), and one where anything can move (the animated cache). The static cache is significantly faster to render, though limited to camera motion. The animated cache can be slower, if many things are in motion. The goal of the animated cache is to have a flicker-free solution. We are looking into ways to speed up the animated cache for LightWave CORE.

Mr Rid
04-26-2009, 04:30 PM
what i think is a bit confusing is that in the Siggraph 08 video the Animated Radiosity Cache was demonstrated as if it was a tremendous time saver...

Exactly! The speaker specifically presents animated caching as a way to save render time but never actually does a before and after time comparison.

That promo was the first (misleading) thing I saw regarding caching that made me look into it and found that flicker could be controlled but that render times only increased with animated cache. So be it. BTW, I also found that reflective surfaces may flicker worse with animated cache. But I normally dont ever have a problem with GI flicker since I always use classic camera with plenty of moblur passes to squelch it.

erikals
04-26-2009, 04:54 PM
yep,
see Jay mentioned they are looking into improving it in Core,...
i hope they make it work, cause it does have a great potential.
as of now though, it's somewhat limited.

dwburman
04-27-2009, 01:14 PM
I think Jerrod meant that getting flicker-free animation with radiosity is faster with the animated cache than with cranking your radiosity quality settings so high that you have no flicker.

erikals
04-27-2009, 02:22 PM
I think Jerrod meant that getting flicker-free animation with radiosity is faster with the animated cache than with cranking your radiosity quality settings so high that you have no flicker.

myeah...,that was the conclusion i came to as well...

GraphXs
04-27-2009, 05:17 PM
What still is confusing to me about (AC) is the fact that the radiosity or rendering of the final frame is really slow, and shoud be faster because it doesn't need to do the radiosity caculation anymore. I thought the AC looks at the frames before and after when caculating and the GI to make sure the bounces match then do the final beauty pass. I've been using V-Ray(Max) as of late, and it has GI baking, but it's not needed, it' GI has a simple drop down to select Med(Animation) or High(Animation). Sure it has some really minor flicker, that isn't that noticable, it does a clean fast job and it's easy to set-up. In LW it just seems that using AC doesn't save on anything. Upping the quality of the Radiosity in LW seems faster then using the AC. Maybe newtek can create some easy presets for the GI to work well with animation.

I loved the Sigg demo of the AC and showed it off to V-Ray users, then I tried it with an animation.....so slow.....when doing the beauty pass. :devil:

toby
05-02-2009, 10:53 AM
What still is confusing to me about (AC) is the fact that the radiosity or rendering of the final frame is really slow, and shoud be faster because it doesn't need to do the radiosity caculation anymore.
It does have to calculate some radiosity, for motion blur and anti-aliasing, because they've tried to make it "idiot-proof", so it's impossible to turn off recalculation completely.

But there is something more seriously wrong going on. It shouldn't take 10 times longer when the bulk of the calculation has been done. Vray has been doing it for years now, and it's never taken a speed-hit for animation with GI. It frequently needs no cache anyway.

I'm doing some tests with something even more weird, seems that using a baked cache that was baked at 25% Multiplier scale, but then rendered with it at 50% renders considerably faster and looks better. But it's too early to tell if it really works, I'll let y'all know. Or give it try along with me.

toby
05-05-2009, 09:35 PM
Ok my first test came out great. The radiosity cache was baked with the Multiplier at 25%, then rendered with it set to 50%, it rendered MUCH faster ( 4 min. 50 sec. compared to 7 min. 50 sec; but without aa the difference is only about 10%), looked noticeably better than a 25% render and still no flicker.

geo_n
05-06-2009, 07:46 AM
What still is confusing to me about (AC) is the fact that the radiosity or rendering of the final frame is really slow, and shoud be faster because it doesn't need to do the radiosity caculation anymore. I thought the AC looks at the frames before and after when caculating and the GI to make sure the bounces match then do the final beauty pass. I've been using V-Ray(Max) as of late, and it has GI baking, but it's not needed, it' GI has a simple drop down to select Med(Animation) or High(Animation). Sure it has some really minor flicker, that isn't that noticable, it does a clean fast job and it's easy to set-up. In LW it just seems that using AC doesn't save on anything. Upping the quality of the Radiosity in LW seems faster then using the AC. Maybe newtek can create some easy presets for the GI to work well with animation.

I loved the Sigg demo of the AC and showed it off to V-Ray users, then I tried it with an animation.....so slow.....when doing the beauty pass. :devil:

Is it slow even in GI calculation? The only thing slow for me is the AA and upping the blurry reflection. The GI calc seems to be just as fast as vray Irr/lightcache and faster than brute force quasi/lightcache on my machine. But to finish the pass with best AA and blurry refl, lw is slower.
I dont use animated cache. I think faking gi is the better way, up to now the veterans still use it.

erikals
05-06-2009, 12:29 PM
Is it slow even in GI calculation? The only thing slow for me is the AA and upping the blurry reflection. The GI calc seems to be just as fast as vray Irr/lightcache and faster than brute force quasi/lightcache on my machine. But to finish the pass with best AA and blurry refl, lw is slower.
I dont use animated cache. I think faking gi is the better way, up to now the veterans still use it.

well, yes and no,... one can't always make a good fake.
it really depends on the scene.

erikals
05-06-2009, 12:30 PM
Ok my first test came out great. The radiosity cache was baked with the Multiplier at 25%, then rendered with it set to 50%, it rendered MUCH faster ( 4 min. 50 sec. compared to 7 min. 50 sec; but without aa the difference is only about 10%), looked noticeably better than a 25% render and still no flicker.

Hm,... interesting,...
so the AA is cached somehow?

toby
05-06-2009, 01:55 PM
Hm,... interesting,...
so the AA is cached somehow?
?
what makes you say that?

erikals
05-06-2009, 03:37 PM
from the way i understood it, in the test,..

ARC using AA was 50% faster
ARC not using AA was only 10% faster

so i thought it had to be some kind of cache that saved AA calculation time, or something like that..

toby
05-06-2009, 05:26 PM
I don't think aa is something you can cache, it's more like, it forces some GI recalculation, so you really notice the difference with this fluke method I found.

I tested it with a different scene and it still worked very well. One thing I noticed is that baking the radiosity *completely* ignores the RPE. At 10,000 it baked just as fast as with 10 and looked the same.

GraphXs
05-10-2009, 10:40 PM
Toby, was your test using AC? Do you do AC for all frames in the test or skip a few? It would be nice to see some setups that work for AC that look great and not crazy on the render times.

Newtek can ya add some type of Save GI settings that could be loaded? I suppose this could be done already using the .LWS file. However, it would be neat to be able to save out a GI setting and just load it. How about it, maybe in 9.6.1. Or are their any plugin writers that can mae some script? :D

toby
05-11-2009, 01:04 AM
Yes the test was specifically for animated cache, but no I didn't try it with skipped frames. Skipped frames aren't useful for anything but architectural walk-thrus, but I suppose it could work just as well.

Come to think of it, the cache for the whole scene bakes faster than a single frame can render - is there really any need to skip frames?