2
$\begingroup$

I know there were tricks like cutting inside the volume object with another object with boolean modifier (this one I'd like to avoid) and another with putting the camera inside some sort of a bubble with inverted normals. The latter is the one I'd like to use, however I can't set it up properly. Does the "bubble" object need some specific material or is there something more I need to know? Or that doesn't work anymore?

Well, seems like there is a fix on the way, as pointed out: https://developer.blender.org/D794

Improve this question
$\endgroup$
  • $\begingroup$ Is this a volume with a surface BSDF, or is this a 2.7.0+ volumetric shader? $\endgroup$ – nanofarad Sep 13 '14 at 20:27
  • $\begingroup$ 2.7.0+ volumetric shader. $\endgroup$ – kilbee Sep 13 '14 at 20:39
  • 1
    $\begingroup$ A patch is in the works to do camera inside volume rendering. See this test render There is a link that leads to the patch if you want to build your own early test version. $\endgroup$ – sambler Sep 17 '14 at 11:57
  • $\begingroup$ Yes, I've seen the news today! So the issue is resolved thanks to the devs. $\endgroup$ – kilbee Sep 17 '14 at 17:25
  • $\begingroup$ What's wrong with the boolean modifier trick? $\endgroup$ – gandalf3♦ Sep 17 '14 at 20:19
4
$\begingroup$

Update

Camera in volume is now natively supported as of 2.73:

Cycles: Add support for cameras inside volume

Basically the title says it all, volume stack initialization now is aware that camera might be inside of the volume. This gives quite noticeable render time regressions in cases camera is in the volume (didn't measure them yet) because this requires quite a few of ray-casting per camera ray in order to check which objects we're inside. Not quite sure if this might be optimized.

But the good thing is that we can do quite a good job on detecting whether camera is outside of any of the volumes and in this case there should be no time penalty at all (apart from some extra checks during the sync state).

For now we're only doing rather simple AABB checks between the viewplane and volume objects. This could give some false-positives, but this should be good starting point.

Need to mention panoramic cameras here, for them it's only check for whether there are volumes in the scene, which would lead to speed regressions even if the camera is outside of the volumes. Would need to figure out proper check for such cameras.

There are still quite a few of TODOs in the code, but the patch is good enough to start playing around with it checking whether there are some obvious mistakes somewhere.

Currently the feature is only available in the Experimental feature sey, need to solve some of the TODOs and look into making things faster before considering the feature is ready for the official feature set. This would still likely happen in current release cycle.

As user sambler pointed out, fix is on the way.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.