Page 3 of 6 FirstFirst 12345 ... LastLast
Results 31 to 45 of 76

Thread: Rendering Times Using Radiosity Cache And Network Rendering

  1. #31
    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
    Attached Files Attached Files
    Last edited by McLeft; 01-20-2009 at 06:59 PM.

  2. #32
    I am home right now, so I will check that tomorrow.
    Thank for the scene btw.
    Eddy Marillat - PIXYM
    WS : MB ASUS X299-Pro/SE - i9 7980XE 2,6ghz 18C/36T - 32GB Ram- 2 GTX 1080 TI - Win 10 64
    GPU Net Rig : MB Biostar - Celeron 2,8 ghz 2C/2T - 8GB Ram - 2 RTX 2080 TI - Win 7 64

  3. #33
    President, 3D Product Division
    Join Date
    Jan 2005
    Location
    Orange County, CA
    Posts
    2,438
    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.
    Jay Roth
    NewTek
    www.lightwave3d.com
    http://twitter.com/jaymroth

    "Everything I write is forward looking -- specifications are subject to change without notice..."

  4. #34
    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.
    Last edited by McLeft; 01-20-2009 at 05:35 PM.

  5. #35
    NewTek Developer jameswillmott's Avatar
    Join Date
    Dec 2004
    Location
    Gold Coast
    Posts
    3,171
    GI Cache works beautifully in 9.6 as long as you are using it correctly, and it saves to a file, just like Vray.
    LightWave3D training, assets, news and discussion at www.liberty3d.com
    My opinions are my own and do not represent the opinions of any other entity, Liberty3D is not officially endorsed by NewTek.

  6. #36
    Quote Originally Posted by jameswillmott View Post
    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?
    Eddy Marillat - PIXYM
    WS : MB ASUS X299-Pro/SE - i9 7980XE 2,6ghz 18C/36T - 32GB Ram- 2 GTX 1080 TI - Win 10 64
    GPU Net Rig : MB Biostar - Celeron 2,8 ghz 2C/2T - 8GB Ram - 2 RTX 2080 TI - Win 7 64

  7. #37
    Registered User
    Join Date
    Feb 2006
    Location
    Placerville, CA USA
    Posts
    74
    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
    Last edited by grangerfx; 01-20-2009 at 06:37 PM.

  8. #38
    Registered User
    Join Date
    Feb 2006
    Location
    Placerville, CA USA
    Posts
    74
    Quote Originally Posted by pixym View Post
    Hi James, Just curious, do you test the McLeft scene here?
    I opened the scene. The Animation GI cache option is checked which explains why the scene is rendering slower after baking the cache.

    -Mark

  9. #39
    Thanks Mark for information about this scene.
    Eddy Marillat - PIXYM
    WS : MB ASUS X299-Pro/SE - i9 7980XE 2,6ghz 18C/36T - 32GB Ram- 2 GTX 1080 TI - Win 10 64
    GPU Net Rig : MB Biostar - Celeron 2,8 ghz 2C/2T - 8GB Ram - 2 RTX 2080 TI - Win 7 64

  10. #40
    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?

  11. #41
    NewTek Developer jameswillmott's Avatar
    Join Date
    Dec 2004
    Location
    Gold Coast
    Posts
    3,171
    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?
    LightWave3D training, assets, news and discussion at www.liberty3d.com
    My opinions are my own and do not represent the opinions of any other entity, Liberty3D is not officially endorsed by NewTek.

  12. #42
    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

  13. #43
    NewTek Developer jameswillmott's Avatar
    Join Date
    Dec 2004
    Location
    Gold Coast
    Posts
    3,171
    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.
    LightWave3D training, assets, news and discussion at www.liberty3d.com
    My opinions are my own and do not represent the opinions of any other entity, Liberty3D is not officially endorsed by NewTek.

  14. #44
    Registered User
    Join Date
    Dec 2004
    Location
    Texas
    Posts
    107
    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.

  15. #45
    Quote Originally Posted by jthompson3d View Post
    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.
    Eddy Marillat - PIXYM
    WS : MB ASUS X299-Pro/SE - i9 7980XE 2,6ghz 18C/36T - 32GB Ram- 2 GTX 1080 TI - Win 10 64
    GPU Net Rig : MB Biostar - Celeron 2,8 ghz 2C/2T - 8GB Ram - 2 RTX 2080 TI - Win 7 64

Page 3 of 6 FirstFirst 12345 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •