Currently I am fighting with lighting artefacts within a smoke simulation, when the lightsource is within the volume and especially also within a transparent object within this volume. (Note this question is about the old Blender Internal engine, not Cycles).

Basically I can show the problems with a simple demo setup:

  • A ground plane which receives shadows from transparent objects;
  • A container (cube) with a volume material, here a simple, constant density;
  • A small cube which is transparent so the light can pass out. This small cube is located within the container;
  • A simple point light within the small cube and thus also within the container and the voumetric material.

This will give you a situation like the following:

Lightsource within transparent cube within volume material

Note the following problems:

  • The floor within the volume is way brighter than outside, as if the volume material has a semi-transparent bounding;
  • The volume material does not interact properly with the light source (without encasing the light within the small transparent box, it would show up as lit);
  • The volume also does not cast proper shadows onto the surrounding plane.

Is this a known problem (with Blender Internal)? Is there anything I can configure differently to make it work?

I could not find any option to make the volume material receive transparent shadows; on regular solid shading material, there is such an option ("Receive Transparent" in the shadow pane).

This problem is especially anoying with the smoke simulation, since there the adaptive domain object takes on the role of the volume container, thus creating a dancing bright patch on the ground as soon as some light source moves into the smoke domain.

The only workaround I see right now would be to use light groups and basically clone several copies of the light source...


1 Answer 1


After a lot of experimentation, my gut feeling says this might be a "bug" or shortcoming of BlenderInternal...

This being said, I'd like to share a workaround (sometimes you're in the unfortunate situation that you just can not switch to the Cycles engine, but have to pull matters trough with BlenderInternal):

  • the problems arise when other objects with transparent material do intersect with the volumetric material.
  • thus a partial workaround is to forego such intersections.

In the example shown, we can use the boolean modifier to cut away precisely the intersecting parts. Plus in addition we must take care to avoid fringe artifacts

  1. add a boolean modifier to the cube with the volumetric material. Choose the ground plane as the other object, and switch to set difference operation. For this to work, in the case of the plane (which has no volume), we also need so switch to the "carve" solver (default ist "bmesh").

  2. next we need to apply the modifier. The cube is now cut such as not to overlap below the ground plane anymore. To avoid problems with ray intersection solving, we should move up the cube by 1 blender unit.

  3. Then add again a boolean modifier to the cube with the volumetric material; just this time we'll cut out the space taken by the small light cube. Use again the set difference operation.

  4. next again apply the modifire. Then select the small light cube (which is still there, now sitting within the hole of the volumetric cube). Again to avoid problems with inferior/exterior tests, we should scale the light cube down by a tiny amount, so it is always clear it does not intersect with the volumetric material.

And voila, now it renders as expected: workaround from volumetric material intersecting with transparent material

In practice, it can be quite tedious and maybe impossible to adapt this workaround for the case of a smoke simulation. So bottom line, this is a problem and if anyone knows a better solution.....

  • $\begingroup$ Blender Internal did have a lot of shortcomings and is now completely obsolete and no longer available in recent versions of Blender. You should mark this answer as the ‘accepted’ answer as I’d be very surprised if there was any further activity here. $\endgroup$ Jun 3 at 21:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .