Raytracing shadows bug?

Add a cube, give it a material, put a light on the side (any kind that can cast a shadow), enable raytracing shadow and render: it takes only 00.05.00 seconds.
Add a plane under the cube to have the cube shadow, increase its size just a little to envelope the scene, give it a material, render: it take 01.00.00 seconds. And this is right.
Scale the plane bigger, very bigger, render and it takes the whole mesozoic era to render. Ok, this is of course because the raytracing has to task a huge distance.
But now, use the little first plane for the shadow, that is enable its material as “onlyshadow”, select “raytracing transparent”; put the huge plane on one other layer different from the light one, select “shadeless” so it is selfilluminating, enable layer in the light source so it doesn’t affect the huge plane, and render: it should take 01.00.00 to render, instead again it takes the whole mesozoic era.
Is this normal behaviour, or maybe it’s a bug?

Env

try disabling tracable?

I think this is rather a bug report than a question :slight_smile:

Can we have a .blend?

Possibly directly a bug report at www.blender.org?

Stefano

Ok, with a simple cube the difference is really little, so I used a more complex mesh.
This one render in 00.24 seconds:

http://www.enricovalenza.com/bug/raybug00.24.jpg

This one render in 01.31 seconds; there shouldn’t be any difference from the first one, because the scaled plane beneath the “onlyshadow” plane is on a layer non affected by the light and also it is in shadeless mode:

http://www.enricovalenza.com/bug/raybug01.31.jpg

Here is the blend:

http://www.enricovalenza.com/bug/rayshbug.blend

If someone else can comfirm it’s a bug, I’ll report it to blender.org.

Env

None?

Env

I think the low speed is also due to using RayTransp for the OnlyShadow plane. When I used ZTransp instead, it was as fast as using the small plane.

Might be a bug too, so posting in the tracker is not a bad idea.

Martin

If I understand you correctly, this is just a weakness of the octree method Blender currently uses. You can slightly improve the rendertime by increasing the octree resolution. It is a well known problem though, also known as the ‘teapot in a football stadium’ problem, look it up if you want the (technical) details.

theeth wrote:

I think the low speed is also due to using RayTransp for the OnlyShadow plane. When I used ZTransp instead, it was as fast as using the small plane.

Mm… I don’t know, the point is that the raytransparent onlyshadow plane has always the same size, only the shadowless plane beneath changes.

Might be a bug too, so posting in the tracker is not a bad idea.

Yes, I’ll do it.
eeshlo wrote:

If I understand you correctly, this is just a weakness of the octree method Blender currently uses. You can slightly improve the rendertime by increasing the octree resolution.

I know, but with a complex mesh the improvement is pratically nothing. :slight_smile:

It is a well known problem though, also known as the ‘teapot in a football stadium’ problem, look it up if you want the (technical) details.

Due to my awful cohemprension of english I cannot understand this, sorry. :expressionless:

Thanks. :slight_smile:

Env

Well, the point is that this is not a bug, just a weakness of blender’s octree method.
I’ll try to explain it as simply as possible. Raytracing means that blender has to do lots and lots of calculations, most important;y, intersection tests of rays with polygons.
It is possible to do this brute force, simply test every polygon if it is hit by a ray, but this will quickly get so slow the more polygons there are in the scene that you might need weeks, or even months to render more complex scenes. To optimize this, methods exist to subdivide the scene in parts that can be quickly tested for intersection so that not every polygon has to be tested, one of which is the ‘octree’ method that Blender uses.
A basic octree is created by starting with a cube around the scene and subdivide that cube in eight other cubes (exact cut through the midpoint). This subdivision is done several times until the cubes either contain a certain number of polygons or until the subdivision limit is reached.
This can work well, but it has some disadvantages.
The problem is that when the first cube around the scene is very large, the subdivision level might reach it’s limit before it has a chance to get to a detailed object it might contain, so that that object is entirely contained in a single cube. Which means that all of the polygons in that cube have to be tested for intersection every pixel…
And that is the cause of the slowdown you describe above.
So, as an example, say your scene would be something like a house with some rooms maybe, and one of the rooms would contain a very detailed object llike a statue or something like that. If you render that house from the outside, rendertimes might be ok, but when you try to render from the inside, like a closeup of the statue in the room, rendertimes suddenly might increase quite a bit because of this problem.
Better methods exist though. Yafray for instance creates a separate tree for every object, so doesn’t have this problem.

Well, I hope that makes it bit more clear…

Ah! Thanks eeshlo, yes, really more clear now.
So we can consider a kind of “bug” the fact that the shadowless plane, being on a layer not affected by the light and being shadowless, instead is take into consideration by the octree calculation (because it should not), isn’t it?

Env

The octree is probably not layer dependent and even if it doesn’t recieve shadow, it can still cast one. That’s why turning off both Shadow and Traceable brings the rendering time to a normal range.

Martin

Well, there is a solution though. By disabling ‘Traceable’, the object will not be included in the octree. That brings the rendertime down to ‘normal’. The problem is then that the transparent plane, since raytracing starts at the plane, cannot see the shadeless plane, so it stays black. The solution to that is to use ‘ZTransp’ instead of ‘RayTransp’ for the top plane. All this might exactly be what theeth already said several times above, sorry if I misunderstood that… :expressionless:

but all in all, still not a bug though.

Ok, many thanks theeth and eeshlo, I’ll try disabling “traceable” for the shadeless plane. :slight_smile:

P.S.: btw, an other possible solution could be of course to render first the “background” plane and then composit it.

Env