workflow map managment for high def print Add

[fraggle]

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.

[Dariusz Makowski (Dadal)]

32gb should be enough. What is it viz? U will run in to problems with RGB to CMYK covnersion.

[fraggle]

yes it is, interior design.

[Neilg]

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.

[grantwarwick]

You don't need to worry about any of that shit man.
Just better attention to detail is all.

[Morne]

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

[samuel_bubat]

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

[Neilg]

I use split scan lines on every single image I do.

[3LP]

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

[Neilg]

Why do you use split render guys?

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)

[Dariusz Makowski (Dadal)]

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....

[Neilg]

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.

[3LP]

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)

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

[fraggle]

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

[Neilg]

For the def, 600DPI is the client request, we can't go for lower def.

That's a print resolution, you don't have to render to that.