3dsMax plugin allows us to easilly send to the gpu (octane render viewport) parts of the scene when used together with the layers panel on the 3dsmax application.
All you have to do is to assign objects to different layers and then hide/unhide layers before you hit the refresh button on the octane render viewport, this way you send portions of a huge scene that would fit to the gpu memory no matter what card do you use.
My questios are:
1) Is it possible to automate this procedure so that it would send to the layers sequentially to the renderer and save the pics with alpha channel for further comppositing?
2) On a multi-gpu installation, can you implement some way to send different layers to different gpus so that we can forward the output of the boards to a realtime compositor?
Best regards
Rendering big scenes, overcoming gpu limitations
Forum rules
Please post only in English in this subforum. For alternate language discussion please go here http://render.otoy.com/forum/viewforum.php?f=18
Please post only in English in this subforum. For alternate language discussion please go here http://render.otoy.com/forum/viewforum.php?f=18
1) It is possible. You just are first who want it. Let see, whether there are enough people who want it too.palhano wrote:3dsMax plugin allows us to easilly send to the gpu (octane render viewport) parts of the scene when used together with the layers panel on the 3dsmax application.
All you have to do is to assign objects to different layers and then hide/unhide layers before you hit the refresh button on the octane render viewport, this way you send portions of a huge scene that would fit to the gpu memory no matter what card do you use.
My questios are:
1) Is it possible to automate this procedure so that it would send to the layers sequentially to the renderer and save the pics with alpha channel for further comppositing?
2) On a multi-gpu installation, can you implement some way to send different layers to different gpus so that we can forward the output of the boards to a realtime compositor?
Best regards
2) It is not possible.
did I get the idea correctly - send parts of the scene that you can see to octane viewport and hide geometry you cannot see - that seems like a great idea for memory management!
3dmax, zbrush, UE
//Behance profile //BOONAR
//Octane render toolbox 3dsmax
//Behance profile //BOONAR
//Octane render toolbox 3dsmax
-
tehfailsafe
- Posts: 229
- Joined: Sun Nov 07, 2010 9:27 pm
This is a good idea, I've done it manually but never thought to do it automated.
But of course, instances first.
But of course, instances first.
windows 7 64 bit| GTX580 1.5Gb x2 | Intel 2600k @ 4.9 | 16gb ddr3 | 3ds max 2012
This would be great addition in a toolkit for very complex scenes =)
Not the priority, but overall that's really useful for heavy users!..
Not the priority, but overall that's really useful for heavy users!..
Appart from the fact that neither Refractive nor any other manufaturer has presented a way out of the gpu memory constrains and that this limitation keeps us from adopting a very nice renderer like Octane in a production enviroment, I tryed to find a way to deal with the problem right now using existing hardware and software.
I see people asking for instancing, but my experience with archictectural renderings that use a lot of trees, cars, buildings and so forth tels me that even if you do a lot of object instance and reference pretty soon you will have to limit the variety of the vegetation otherwise it will not fit the gpu memory no mather what you do. Them you will realise that your 4 brand new GTX boards and your 1200W power supply will be uselles.
See te links bellow for a 20 million poligons scene we rendered with CPU only. That scene would not fit on a 6GB Quadro 6000 board but I've got the feeling that if we split the scene like I said on the post and send parts of it automaticaly to the gpu it could be rendered faster on a couple of old 1.2GB GTX470 boards.
http://www.sgmi.com.br/demo3/masterplan01.jpg
http://www.sgmi.com.br/demo3/masterplan02.jpg
I see people asking for instancing, but my experience with archictectural renderings that use a lot of trees, cars, buildings and so forth tels me that even if you do a lot of object instance and reference pretty soon you will have to limit the variety of the vegetation otherwise it will not fit the gpu memory no mather what you do. Them you will realise that your 4 brand new GTX boards and your 1200W power supply will be uselles.
See te links bellow for a 20 million poligons scene we rendered with CPU only. That scene would not fit on a 6GB Quadro 6000 board but I've got the feeling that if we split the scene like I said on the post and send parts of it automaticaly to the gpu it could be rendered faster on a couple of old 1.2GB GTX470 boards.
http://www.sgmi.com.br/demo3/masterplan01.jpg
http://www.sgmi.com.br/demo3/masterplan02.jpg
-
Jaberwocky
- Posts: 976
- Joined: Tue Sep 07, 2010 3:03 pm
How about this as a way out of the problem.
Use a back face culling algorithm in Octane calculated from the camera position.All items in the scene that are not in view, or not affecting the rays are eliminated before the scene is sent by the CPU to the GPU.
That would in effect:
A) limit the amount of Polys to be rendered and speed up the rendering process no end.
B) limit the number of maps sent to the GPU thus keeping it below the Cuda limit , even of the whole scene had excess Maps.
Just an
Use a back face culling algorithm in Octane calculated from the camera position.All items in the scene that are not in view, or not affecting the rays are eliminated before the scene is sent by the CPU to the GPU.
That would in effect:
A) limit the amount of Polys to be rendered and speed up the rendering process no end.
B) limit the number of maps sent to the GPU thus keeping it below the Cuda limit , even of the whole scene had excess Maps.
Just an
CPU:-AMD 1055T 6 core, Motherboard:-Gigabyte 990FXA-UD3 AM3+, Gigabyte GTX 460-1GB, RAM:-8GB Kingston hyper X Genesis DDR3 1600Mhz D/Ch, Hard Disk:-500GB samsung F3 , OS:-Win7 64bit
It will not work properly.Jaberwocky wrote:How about this as a way out of the problem.
Use a back face culling algorithm in Octane calculated from the camera position.All items in the scene that are not in view, or not affecting the rays are eliminated before the scene is sent by the CPU to the GPU.
That would in effect:
A) limit the amount of Polys to be rendered and speed up the rendering process no end.
B) limit the number of maps sent to the GPU thus keeping it below the Cuda limit , even of the whole scene had excess Maps.
Just an
Even If we don't see some parts directly, we can see it indirectly (reflections, refractions, global illuminations, shadows and so on).