PDA

View Full Version : RenderQ vs LWSN on same machine



raw-m
02-03-2014, 10:58 AM
I've been using LWSN locally on the same computer (mac) for a while, rendering scenes with all it's 8 cores on the go. Haven't really used RenderQ before so decided to give it a go as theres little setting up. Is renderQ multithreaded, so using it to rendering a sequence one frame at a time is quicker than rendering 8 frames at a time using LWSN (which is obviously slower)?

Be gentle, I'm not that technically minded!

ernpchan
02-03-2014, 11:03 AM
I belieive RenderQ is just loading up scenes in Layout and then rendering that way. So it should be using the same resources as lwsn if it's on the same box.

Now if RenderQ requires more resources because you have the actual program up and not just the command-line...that I don't know.

Markc
02-03-2014, 11:57 AM
Have you tried SNUB launcher.
I find it very useful, as you don't need LightWave running (it uses LWSN).

raw-m
02-03-2014, 12:10 PM
Thanks all. Yes, I've used SNUB and it's very handy. Adding a list of files to RenderQ is very quick so was wondering what the performance difference was. Sounds like there might not be much in it...

JonW
02-03-2014, 12:23 PM
I believe render Q is for one computer, I have never tried it & I could be wrong. Have you tried Screamernet & a second second computer or are you simply using SN only on the one computer?

If you have only been using the one computer then it is worth getting another one rendering.

raw-m
02-03-2014, 02:20 PM
Can you clarify that last point, JonW? I generally work on one computer, using LWSN using 2-4 nodes in the background if I'm working on other stuff or render over lunch/night with more nodes. I'm a bit of a one-man-band so use what I have with me.

ernpchan
02-03-2014, 02:39 PM
RenderQ is in Layout. What it does is load up one scene after another to render them. It's just a more automated way of doing local F10s.

JonW
02-03-2014, 02:41 PM
From what you have said I think you seem to be using Screamernet only on the computer you are working on. One benefit of this is if one has a massive file & not a lot of RAM.

Also 2-4 nodes (on each computer) generally gets your computer rendering at 100% if you are rendering frames.

Are you using a second or third or more computers with Screamernet, so for instance a sequence of frames can be rendered on as many computers as you have?

raw-m
02-03-2014, 02:51 PM
Just using one computer. Generally, I like that I can load up to 8 nodes and send a list of scenes for them to chug away at (and it impresses the client seeing all the Terminal stuff scrolling away!). Which brings me to my question in getting renders done, is 1 RenderQ comparable 8 LWSN nodes over time? Does the power that goes into LWSN go into RenderQ? I guess the best way is to do a little test of 100 frames and see what happens!

JonW
02-03-2014, 03:17 PM
I have never used render Q so I can't really comment on it. You need to be careful starting up too many nodes on one computer. If you have a large scene & not enough RAM the computer will start using virtual RAM & renders will be slower.

If you have a second computer you really should be using it. It's a a pain to first set up SN with a second computer but once you have worked it out adding even more computers is easy. It is even more satisfying watching the frames fly in from all your computers.

raw-m
02-03-2014, 03:22 PM
Thanks JonW. On location using a RD MacBookP, 16gb and been really impressed how it's been performing. Will have to test the difference between using 4 and 8 cores on some scenes.

ernpchan
02-03-2014, 03:38 PM
is 1 RenderQ comparable 8 LWSN nodes over time?

I would think no...cuz RenderQ is just rendering the one scene one frame at a time. Whereas if you have 8 LWSN nodes, that would mean you've split up your scene over 8 nodes. So for example, if your shot was 80 frames long...RenderQ would be rendering frames 1-80 whereas your LWSN nodes would be rendering in 10 frame batches. So LWSN should be 8 times as fast because each node is only doing a small fraction of the whole job.

raw-m
02-03-2014, 03:44 PM
Thanks ernpchan, it sounds kind of obvious when you put it like that! But each render node seems to take a little longer to render the more nodes you have running. As ever, this is probably scene dependent but was wondering what that does to the average frame render over time.

ernpchan
02-03-2014, 03:53 PM
Thanks ernpchan, it sounds kind of obvious when you put it like that! But each render node seems to take a little longer to render the more nodes you have running.

Maybe cuz of increased network traffic? Sometimes instead of going with more nodes its better to go with less nodes but higher batch counts. Especially if it takes awhile for a scene to get loaded...no sense in clearing out a node so it can do the reload again. But yes, this is all dependent on what your scene is. It's a balancing act so to speak.

Danner
02-03-2014, 04:42 PM
RenderQ is intended for rendering many quick scenes (or passes) on one machine, screamernet is quite the opposite, it's made for rendering a heavy scene over many computers. RenderQ can schedule all your scenes to render your radiosity cache before the actual render, that is will speed up your renders quite a bit if you have the "frame step" set to something like 10 or 15. (quite common for us Arch-viz guys that use a slow moving camera) For screamernet you need to render the cache manually before starting the actual render if you want to take advantage of the interpolation. RenderQ loads the scene into memory only once so no network traffic or HD trashing going on.

Another area where screamernet is slower than RenderQ or regular F10 is on shadow maps. Each time a job is sent to a node it calculates the shadow maps from scratch even if the shadow map cache button is on. (Amletto screamernet controller lets you send batches of frames, instead of one by one, and I beleive they do share shadowmap cache info.)

spherical
02-03-2014, 05:09 PM
I would think no...cuz RenderQ is just rendering the one scene one frame at a time. Whereas if you have 8 LWSN nodes, that would mean you've split up your scene over 8 nodes. So for example, if your shot was 80 frames long...RenderQ would be rendering frames 1-80 whereas your LWSN nodes would be rendering in 10 frame batches. So LWSN should be 8 times as fast because each node is only doing a small fraction of the whole job.

OK, I've read this thread and some of the responses a number of times and my logic chip is overheating. I'm reading that this is being done all on one box. Unless you are on a box that doesn't have a multi-thread CPU, and therefore need to use LWSN to send jobs to other cores, Layout uses all cores by default, splitting up the frame into 8 sections and, when a core completes a section, retasking cores--thereby splitting up that section again until the frame is completed.

Pixels are pixels. In a given frame, there are a finite number of pixels to be calculated and rendered. For all intents and purposes, using 8 cores to render one frame, or using one core each to render 8 frames will be darn close to each other in completion time of 8 frames total. Caching of GI and such will have impacts but we'll leave that out of the calculation for now.

IOW, sending "10 frame batches" to a core is not that core running through the assigned pixels 10 frames all at the same time; it's still one frame at a time, but that core has no other cores to retask to uncompleted sections. It goes through the frame from top to bottom and then starts the next in line.

That said, my CPU has 6 physical cores and two threads per core so 12 "cores" available. Depending upon how the targeting is done, one physical core can split a frame in two and retask a thread that completes its section; but it will only be working on the one frame in that mode.

Or... I've completely misunderstood the situation.

If you want to limit how many CPU cycles are being used, so that you can do other tasks while rendering, take Layout off Threads = Automatic and limit it to only using X number of threads and/or set Layout's CPU priority.

ernpchan
02-03-2014, 05:22 PM
OK, I've read this thread and some of the responses a number of times and my logic chip is overheating. I'm reading that this is being done all on one box. Unless you are on a box that doesn't have a multi-thread CPU, and therefore need to use LWSN to send jobs to other cores, Layout uses all cores by default, splitting up the frame into 8 sections and, when a core completes a section, retasking cores--thereby splitting up that section again until the frame is completed.

Pixels are pixels. In a given frame, there are a finite number of pixels to be calculated and rendered. For all intents and purposes, using 8 cores to render one frame, or using one core each to render 8 frames will be darn close to each other in completion time of 8 frames total. Caching of GI and such will have impacts but we'll leave that out of the calculation for now.

IOW, sending "10 frame batches" to a core is not that core running through the assigned pixels 10 frames all at the same time; it's still one frame at a time, but that core has no other cores to retask to uncompleted sections. It goes through the frame from top to bottom and then starts the next in line.

If you want to limit how many CPU cycles are being used, so that you can do other tasks while rendering, take Layout off Threads = Automatic and limit it to only using X number of threads and/or set Layout's CPU priority.

When I say 10 frame batches, I'm referring to a render launch where one node is rendering 10 frames. But yes, that one node could have multiple cpus.

JonW
02-03-2014, 07:10 PM
Thanks JonW. On location using a RD MacBookP, 16gb and been really impressed how it's been performing. Will have to test the difference between using 4 and 8 cores on some scenes.

When you have some spare time, don't do it while you have work as you need a clear mind to solve problems, try to get Screamernet up & running for a second computer. It really is worth the effort.

You can even use the shift camera & render 2 frames, half a frame on each computer.