Does anyone know if there is a way to speed up the standalone renderer?  I have an 8k x 8k image that will render within the interface in a few minutes.  I quadruple the size (16k x 16k) and attempt to render it using standalone (because it won't render with the UI running) which I expect to take approximately 4 times longer.  It's been running for 6hours so far and the console window is showing "Rendering... 55.43%" (it started at 50%). 

How can this be?  I have set the process priority to "High" and it didn't appear to make any difference.  As I mentioned, the 8k x 8k version takes less than 3 minutes to render.  I don't mind a few hours but this is crazy...

Pardon my NOOBness... I'm really excited about this program - it's just that I need to render 16k x 16k (or greater) images or it's not gonna work.  I can't fit any more RAM on this machine (without spending lots of $$$) - I have 12G

Quadrupling resolution doesn't multiply render times by 4, but by 8. Example: you render an image at 512x512= 262144 pixels in total, now re render at 1024x1024= 1048176 pixels.
So you see doubling resolution multiplies by 4 the number of pixels (each original pixel is split into 4 new pixels),and so quadrupling multiplies by ...64! changing priority doesn't have any impact indeed, unless you are using several apps at the same time. Then priority is taken into account.

First sentence in my 1st reply is wrong, you should read 64, not 8.

Quote - First sentence in my 1st reply is wrong, you should read 64, not 8.

Hi,

Thanks for the reply.

Hmm... I meant to say "increase my resolution by 4" - I thought that's what "quadruple" meant, i.e, quad=4+ruple :)...  If I've increased my pixel count by 4 why again wouldn't I expect my render time to increase by the same number - 4?  

If I didn't care about the projection matching I could rotate a 30degree (8k x 8k) camera; right once, up once, then left once in 30 degree increments to give me a 60degree by 60degree square comprised of 4 8k x 8k images.  The projection wouldn't match but the pixel size would be equivalent to 16k x 16k.  Since each 8k x 8k image took ~3min to render, my total render time would be ~12 minutes - yes? 

I don't know how long the 16k x 16k render I started last night has been going because I left it at work (it had been running for over 6 hours when I left).  Disappointing since a render 1/4th the size took ~3min. 

It appears to me that there are several (possible) issues.  1. Vue (with RenderUp), determines required system resources for a render based on the entire image size if it's done in the UI - this is despite the fact that you may be rendering a region/blowup.  This eliminates the possibility of rendering a 16k image with the internal render using my system.  2. The only possible way to do a 16k image is with the "External Renderer", which is designed to run in the background (makes sense) but there is no way to use the ExternalRenderer "at full speed" - it always runs assuming you want to use the machine at the same time.

I could be completely full of it on my "analysis so far"... that's wy I'm posting here :)...  I've only been using the program for a short time though - I'm still a NOOB, obviously.  My goal is actually to render at 32k x 32k  (I'm working on a 10' x 10' print project) and it would be great if I had a reasonably efficient way to do it without building a rendering farm and spending tons of money on software.  I don't mind waiting - I just need to quantify how Vue works.  Paula Sanders has been really helpful - she suggested I consider rending smaller sizes then scaling them up using GenuineFractals in pshop.  That will probably be my next test... Looking at the website; GenuineFractals looks like it does a pretty good job.  I'll probably try that next - it may be that 8k x 8k scaled up to 32k x 32k will be acceptable. 

I'm still figuring out how this thing works and I really appreciate the help. 

Quote - I quadruple the size (16k x 16k) and attempt to render it using standalone (because it won't render with the UI running) which I expect to take approximately 4 times longer.  It's been running for 6hours so far and the console window is showing "Rendering... 55.43%" (it started at 50%). 

Your assumption (4x time) is correct.
Your problem is that from a certain size your computer runs out of (physical) RAM and uses virtual memory from the page file.
Access to this memory is MUCH slower, because it resides on your disk drive.

Workarounds:

Best: more RAM :)

2nd best: go to render options and set the areas to render. I've never done this, but in theory (ahem) you should be able to split your render into smaller parts.

2nd best, part 2: use a local RenderCow and reduce the tile size enough to avoid the use of virtual memory. That's what I do when things become too slow.

3d best: place your page file on the fastest drive available.

Quote - > Quote - I quadruple the size (16k x 16k) and attempt to render it using standalone (because it won't render with the UI running) which I expect to take approximately 4 times longer.  It's been running for 6hours so far and the console window is showing "Rendering... 55.43%" (it started at 50%). 

Your assumption (4x time) is correct.
Your problem is that from a certain size your computer runs out of (physical) RAM and uses virtual memory from the page file.
Access to this memory is MUCH slower, because it resides on your disk drive.

Workarounds:

Best: more RAM :)

2nd best: go to render options and set the areas to render. I've never done this, but in theory (ahem) you should be able to split your render into smaller parts.

2nd best, part 2: use a local RenderCow and reduce the tile size enough to avoid the use of virtual memory. That's what I do when things become too slow.

3d best: place your page file on the fastest drive available.

Thanks CRowning...  Makes sense.  The test machine at work has RAID0 SSDs so I would hope memory swaps would be as speedy as possible.  Also, looking at perfMonitor, I don't see any page swaps - in fact, it looks like the renderer is "nibbling" properly - only using about a 4Gig pool of RAM (the work system has 12G of RAM).

I'm a total cheapskate - so far I'm using Pioneer with RenderUp so I don't have any rendercows available, AFAIK.  I'll check the Vue site again and see if I can add rendercows to my setup for a reasonable price...  I was really hoping to avoid buying the full version of Vue if I can help it - I know, I know... I get what I pay for, perhaps?

I've tried the region/blowup approach but it looks like Vue determines resource usage based on the total render size - not the sub-region.  Also, the numbers don't stick in the renderOptions UI when I go over 8k total - it's wierd... the region/blowup numbers seem to have a mind of their own.  It simply won't let me type in explicit dimensions when my total image size is over 8k x 8k (I think)... 

Nah!  do the math as I did in my first post: 512x512=262144 pixels in total, then 4096x4096(which is 4 times bigger, so quadruple)=16777216 pixels in total
Then divide those numbers and you get 64 times more polygons, so if a 512 render takes 3mn, a 4096 will take 196mn.

Quote - Nah!  do the math as I did in my first post: 512x512=262144 pixels in total, then 4096x4096(which is 4 times bigger, so quadruple)=16777216 pixels in total
Then divide those numbers and you get 64 times more polygons, so if a 512 render takes 3mn, a 4096 will take 196mn.

Hi bruno021,

AFAIK, Vue render times are largely based on total pixel count.

That said, you're math is correct, however, I'm trying to render 4 times the total pixel count, not 4 times the horizontal dimension multiplied by 4 times the vertical dimension.

Thanks for posting though... ANY ideas that help me reach my goal are much appreciated.**
**

Quote - Nah!  do the math as I did in my first post: 512x512=262144 pixels in total, then 4096x4096(which is 4 times bigger, so quadruple)=16777216 pixels in total
Then divide those numbers and you get 64 times more polygons, so if a 512 render takes 3mn, a 4096 will take 196mn.

512x4 = 4096?

Quote - 512x4 = 4096?

For large values of 4 yeah :biggrin:

You have me confused :)

If you double the size, you get four times the pixel count. If you quadruple the size you get 16 times the pixel count.

10 x 10= 100
20 x 20= 400
40 x 40= 1,600

Doubling the size of anything be it pixels or poly's gives you four times what you start with. It also increases render times exponentially.

An 8,000 x 8,000 render is really geting up there and you can expect long renders.

Render times depend on many factors not just size. You should really read all the info you can find on render quality and render times. If you want high quality with an 8,000 x 8,000 render you can expect very long render times. Clouds, radiosity, anti-aliasing, reflections, transparency, sub-surface scattering, displacement and many other things increase render times greatly along with quality. When you increase the size you are also increasing the poly count of the procedurals.

There are good posts of hints and tips on render times at cornucopia, here and other places.

A photo-realistic render with cloud layer, radiosity, transparency (water) reflections and all the bells and whistles including displacement materials and sss materials can take days at that size.

Quote - You have me confused :)

If you double the size, you get four times the pixel count. If you quadruple the size you get 16 times the pixel count.

10 x 10= 100
20 x 20= 400
40 x 40= 1,600

Doubling the size of anything be it pixels or poly's gives you four times what you start with. It also increases render times exponentially.

An 8,000 x 8,000 render is really geting up there and you can expect long renders.

Render times depend on many factors not just size. You should really read all the info you can find on render quality and render times. If you want high quality with an 8,000 x 8,000 render you can expect very long render times. Clouds, radiosity, anti-aliasing, reflections, transparency, sub-surface scattering, displacement and many other things increase render times greatly along with quality. When you increase the size you are also increasing the poly count of the procedurals.

There are good posts of hints and tips on render times at cornucopia, here and other places.

A photo-realistic render with cloud layer, radiosity, transparency (water) reflections and all the bells and whistles including displacement materials and sss materials can take days at that size.

Thanks blaineak,

The thing I'm trying to wrap my mind around is how an 8k x 8k render takes less than 3 minutes using "render to screen" on a very beefy machine.  The same file at 16k x 16k took 14 hours on the same machine using the standalone renderer - same settings other than resolution (rendering 16k x 16k to screen in the UI gives me the "resources exceeded warning"). 

Thanks for the suggestions... I'm making progress at least :)... 

Hmmm....512x4=2048, sorry! Got a little carried away! So it's 16 times more polygons, not 64!

Quote - > Quote - 512x4 = 4096?

For large values of 4 yeah :biggrin:

Oh, come on, kids, enough already, lol!