Timeline for How Does Blender Camera Culling Operate Internally?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 30 at 22:34 | comment | added | Andrew | @Nathan and @ MarkusvonBroady My original inquiry is targeted on reducing the memory load resulting from applying a subdivision modifier ahead of the ocean modifier, for improved realism in closeup renders. The two modifiers are applied to a plane mesh object (animated to rise and fall) that covers the entire scene at high tide, and about 20% at low tide. I'd like to vary my camera location/orientation at random, for random tide levels. I was hoping that culling could be used to reduce memory pressure. Answers so far seem to indicate "no". Suggestions? Is it time to post a new question? | |
| Jun 30 at 21:22 | comment | added | Markus von Broady | In my defense: it was very hot today where I live :D I just thought you're explaining camera clip settings by involving the camera frustum. But you were just explaining clipping not clip min/max, now I get that, thanks for eli5 :D | |
| Jun 30 at 21:16 | comment | added | Nathan | @MarkusvonBroady Uhh, maybe I'm not getting you, but that's exactly where the concept of the camera frustum comes from. Does your left cube show up in your render? No, it gets clipped by the camera frustum. There are two "eyes" in your screenshot, with different frustums: your viewport is showing you geometry that has been clipped to one frustum (the bounds of which are your viewport bounds) while your camera will show you geometry that has been clipped to another frustum. A different way of saying this: your viewport has a wider FoV than your explicit camera does. | |
| Jun 30 at 20:17 | comment | added | Markus von Broady | as for 1), I meant your 2nd paragraph, clipping, not culling. | |
| Jun 30 at 19:56 | comment | added | Nathan | @MarkusvonBroady 1) There's two different kinds of camera culling in the simplify settings, distance and frustum. The frustum might not literally be the frustum (it might ignore aspect, it might ignore clip planes.) 2) Dunno. I suppose it's possible that it gets ignored for purposes of distance calculation. But I think the general takeaway here is, culling is going to speed BVH + rendering, but not modifier stuff (the animation/deformation/transformation cost, generally CPU, vs the rendering cost, generally GPU.) If you test, let us know! | |
| Jun 30 at 17:52 | comment | added | Markus von Broady | 1. I don't think camera clipping has anything to do with camera frustum: you can prove it easily by moving something beyond camera frustum - it's still visible as long as it's at the right distance: i.imgur.com/87DqlCZ.png 2. Last paragraph: what about GPU subdivision? | |
| Jun 29 at 0:33 | comment | added | Nathan | @Andrew No, you can't use swap in lieu of GPU ram-- you can't even use system ram in lieu of GPU ram. If you can't fit what you need in GPU, the render fails. This is assuming GPU or GPU + CPU rendering. CPU-only rendering should be able to use swap. But CPU rendering is already slow, and using swap would make it intolerable. | |
| Jun 28 at 21:43 | comment | added | Andrew | Thanks Nathan, for running this to ground. All makes sense. I ran a few more tests inspired by your revised answer, to confirm your insights. Also switched from GPU to CPU rendering when the GPU ran out of memory and, as expected, the render proceeded without complaint. Does that suggest to you that CPU rendering can take advantage of swap space, while the GPU render can't? | |
| Jun 28 at 14:16 | history | edited | Nathan | CC BY-SA 4.0 |
added 6 characters in body
|
| Jun 28 at 14:07 | comment | added | Nathan | @Andrew Okay. See the edited answer then. | |
| Jun 28 at 14:07 | history | edited | Nathan | CC BY-SA 4.0 |
deleted 566 characters in body
|
| Jun 28 at 12:14 | comment | added | Andrew | I'm referring to the Camera Cull option in the Simplify panel of the Render tab. Combined with the Use Camera Culling option under Culling in the Visibility panel in the Object tab. As I understand it, while objects, faces, and edges behind the camera are not drawn, they influence and are therefore considered during renders (e.g., shadows, reflections, light bounces, etc). I was hoping that these options would eliminate objects and portions of objects from memory before the render ray tracing algorithms are applied. Thank you for your feedback Nathan | |
| Jun 27 at 2:32 | comment | added | Nathan | @Andrew I think you need to be more specific about exactly what you mean by "applying camera culling." The kind of culling I'm talking about, inspired by some of the things you said, is not optional. We can control the parameters of it, but there's no sense in doing no culling. For example, we'd be drawing faces that existed behind the camera; and for faces outside of FoV, where would we draw them, since we can't draw them to the monitor? | |
| Jun 27 at 0:47 | comment | added | Andrew | Thanks Nathan. Most helpful. It sounds like applying camera culling to large dense meshes is a sound approach. It's easy enough to disable if it proves to be inefficient from a rendering time perspective, and/or as the cost of memory declines. And I can always opt to reduce the level of subdivision. I wish that there was a simple/robust way to apply adaptive subdivision to the ocean modifier | |
| Jun 26 at 23:42 | history | answered | Nathan | CC BY-SA 4.0 |
