Hello,
for the first time, we need to accomplish a render for a printed add (A3/600DPI).
So, we are wondering about all the trap we need to avoid, i.e. using high def texture, aliasing… All the little thing that probably have to be taken into account while going “print” vs “screen”.
We may need to increase our RAM as well to deal with the texture, especially for close up view (32Gb at the moment)
Thank for your advice.
32gb should be enough. What is it viz? U will run in to problems with RGB to CMYK covnersion.
yes it is, interior design.
Just render at 5k (even 3 may do) wide & spend more time in photoshop zoomed in to 200% checking everything/fixing issues. and do it all on a calibrated monitor.
Making sure you assets hold up is something you’re going to have to do during tests - dont wait until the final image to do a full res test. switch off gi/turn on default lighting and do a quick full res test to check AA & map resolution.
You don’t need to worry about any of that shit man.
Just better attention to detail is all.
A3 at 600dpi? Is this the size the printers are asking you? That seems excessively huge for no apparent reason.
I agree with cubiclegangster - go for something between 3k and 5k.
Your 32gb ram is fine
So in case you really want to render it at full resolution in 600dpi in would be roughly 10000x7000k px. This shouldn´t be a problem in max/vray. We just finished a project
for a wall of 38x7m where the final resolution was 60kx11k px.
1. To safe rendertime. use irradiance map/lc and make sure if you use vray lights store with irradiance map is on. With such large resolutions you don´r really need things
to be samples down to a single pixel (what a brute force, progressive path tracing or vray lights without "store with irr. map would do). You can turn the irradiance map
down to something like -8,-4. But if rendertime isn´t the problem just skip that and use whatever looks best for you.
2. Be extremely carefull with displacement. May work well in the previews but can explode you rendertimes ones you go full resolution.
3. Regarding textures. Keep in mind after all it´s just printed on A3, means it´s not larger than your monitor. So you don´t really need any special highres textures
for that. (unless you plan to watch it with a magnifier later 
)
4. In case you run into any problems with rendertimes or memory. Just split it up. Make a crop rendering and stitch the parts together in ps later. that´s how
we did the wall rendering. Backburner even has an option for that “split scan lines” but i haven´t used it for ages and don´t know how reliable it is or if it supports
vray.
5. Make sure you only render the elements you really need.
6. In case you plan to use backburner don´t use the Vray frame buffer ! When saving out such large images backburner sometimes crashes the job. Probabely
because it doesn´t recognize the Vray Frame Buffer as part of max and “thinks” something went wrong. (adjusting the backburner timeouts dows not prevent this).
7. Don´t worry to much about the colors. Of course a calibrated monitor is always good. But if i´s s going to be printed professional you or your customer needs to make
a proof anyway. colors highly depend on the paper and printer used.
8. If everything goes wrong, just render it smaller and blow it up with photoshop later. A rendering is that sharp that noone will recognize it later
I use split scan lines on every single image I do.
Why do you use split render guys?
We often do High ress images (10kx6k) and we have 32 Gb of ram, but the actual render scene use up to 29Gb.
So in theory there is “only” 3Gb left for the image, for a render of 512*256 it’s enough, but for high ress, it blow the ram off (full ress raw VrayVFB use up to 29Gb as well 29+29=58Gb :()
So we are just exporting to *.vrimg without using the render to memory.
This ensure that you render use only the needed ram for the image for each bucket.
So, what ever size your’re doing, it will never use more than ram needed for the actual render buckets.
We spawn those images with the show preview to make sure everything goes well, work like a charm.
You just need to export the VRimg to exr or what ever after, but that’s easy (few way and scripts exist to ease that process).
You don’t need to think about ram anymore, you don’t need to think of the elements anymore, you don’t need to think of the stitching anymore, you don’t need to think of the precalculated IR/LC anymore, you don’t need to worry about anything actually
This technique is soooo much easier… I tend to use the BB strip render like 6 years ago, I quickly changed my mind and went for the easy solution
Stan
If I send 40-50 strips to our network that take 20 minutes each, the machines of people who are out for lunch can pick up and chip away it as they like. If someone has something urgent to get done, they can take half the machines off my rendering and we’ll share the farm. It’s incredibly flexible.
Coming in to something that went wrong and being able to request the farm urgently to get a new full res render out in under 2 hours is pretty nice too. Again, provides more flexibility. Even if something hasnt gone wrong, being able to get a 10+ hour render done while i’m out for lunch is amazing. With DR I have to lock those machines down & stop other people from using them, log in to each, turn off the backburner server - and when it finishes, go through and add them back to bb. And even then, the vast majority of the time only half the machines will actually bother to start rendering the job.
Plus if you precalc the IR there are a number of tricks you can do to make it much faster, so even when I render on a single machine i pre-calc. (like doing it with glossy effects off or even reflections turned off entirely)
you need to have reflections enabled as it affect gi strength and physics. Other way is incorrectly as far as I remember…
It’s a pretty minor difference. If your room has very reflective walls and floors then sometimes it gets a little brighter.
I’m not in the business of being accurate. if it looks good, it is good.
We use Refamo to manage the farm, 50 computer, 1 click and boom, all the BB server starts/stops, the DR starts/stops, RT, WOL, etc. No need to log-in into each individual machine.
We often need to render thing urgently, and this is the trick I use : I send all my render with the low thread priority on, by default. If someone need to render something else, they just uncheck the low thread priority and send the render off. If I’m sending backburner animations, they can spawn at the same time. This means that 2 max will run on the same machine, and the cpu will prioritize the “normal thread” (the urgent spawner job) and once the render is done, the cpu will jump back on mine. It’s like if we “paused” my job, so nothing is lost.
We are managing the farm like that for a long time now, and it’s awesome to be able to use the farm whenever you want and having low thread stuff rendering in the background. That way, cpu is red 99% of the time…
The two downsides are :
1) You need to manage 32Go of ram across both jobs, usually it’s not too hard to achieve.
2) if you want to spawn 2 jobs at the same time, it’s currently hard the manage the farm to jump from one render to another. The current workaround is to kill max and they will jump on the second render, but it’s not true at 100%, most of the time it does. And that’s why we are waiting for years now that Chaos group release a tool allowing to manage hot swapping nodes…
But mate, if strip render works perfectly in your pipeline, then that’s the way to do it for you 
I didn’t meant to be rude, sorry if I looked that way
Stan
thanks for all the advice.
For the def, 600DPI is the client request, we can’t go for lower def.
Will let you know if it went fine.
Thanks
That’s a print resolution, you don’t have to render to that.
Do you mean that print is not the same than screen resolution?
A render to 600Dpi/A3 in max = 9921x7015 pixel
The question may sounds stupid, but we are not in print field at all.
Retina displays (where the pixels are smaller than the human eye can make out) are about 330 ppi. (at a3 that’s 5.4k across) that’s on a phone you hold close to your face - the mac retina displays at standard monitor distance are only about 220 (which gives a resolution of 3.5k across for a3)
dpi is a print term - it’s how many dots make up an area. you can go up to 1200 and it will still make the image look better because it contributes a lot to how vibrant the colors look and how nice the blacks are, but as far as feeding it cg goes you dont need to give it anything rendered higher than 300dpi which has been scaled up in photoshop to the equivalent it’s printing at.
Render at 5k, do all you post work & photoshop, totally finish the image (sending them the 1200px wide ones to proof or whatever you do) and then when it comes to deliver for print, save out a 5k final image & scale it up to whatever resolution they need.
You could even get away with 3k wide and a good image scaling software.
e: dots per inch is just the printer doing it’s thing, you can ignore that & any client who needs that resolution. just render to 3k wide if it’s a4, 5k if it’s a3, and if it’s bigger and banner sized - still just 5k, because people will be looking at it from further away. Once you’re completley finished with the image, scale it up to whatever dpi the client is asking for so they dont get confused and try and argue with you about it. hopefully you’ll be sending these straight to the printer so the client wont zoom in to 200% and ask why it’s blurry at fullscreen (despite that being a 1mm area on the print)
You could even get away with 3k wide and a good image scaling software.
Thanks a lot,
What do you mean by good image scaling software. Is Photoshop not good at doing it?
The built in ones aren’t. If you go from a 2k image to a 4k image in one jump for example, photoshop is making up a huge amount of data on it’s own - since the new image is twice as big horizontally and vertically, it means that photoshop is making up 75% of the picture. There are other plugins and programs that do what’s called “stair interpolation” which means that rather than taking one big jump, they do multiple resizes of the image in maybe 10% increments each time until they reach the final size. It means that each time they’re using more of the original data when making new pixels, so it’s more accurate.