Hello colleagues,
In creating renderings of a room and its lightshelves with a fore clipping plane it appears that the clipping plane is exposing the wall interior in such a way that it becomes rendered. Is this the way clipping planes operate?
If so, it suggests that the rendering is created after the clipping plane is applied and therefore doesn’t include objects that are between the viewpoint and the fore clipping plane.
This can be seen where the ceiling meets the wall and where the floor meets the wall in the perspective image. (-ab 2 -ad 1000 -av .368 .368 .368 -as 500 -ar 500 -aa .15 -dj .03)
The parallel view is also created with a clipping plane that seems to expose the wall interior, the scalloped isoline at the top of the image. (-ab 2 -ad 500 -av .37 .37 .37)
Images:
http://www.labergedaylight.com/pages/temp.html
Best regards,
Paul LaBerge
Paul,
In creating renderings of a room and its lightshelves with a fore
clipping plane it appears that the clipping plane is exposing the wall
interior in such a way that it becomes rendered. Is this the way
clipping planes operate?
Clipping planes do not introduce extra light where it should not be.
Assuming the model is air tight (which is not always the case for imported
CAD geometry), the inside of the wall the ceiling is visible due to the
ambient light. Setting -av to 0 0 0 should remedy this.
Axel
Axel,
Thanks much for the suggestion. I’d also thought of light leaks as the culprit so I overlapped the objects in formz to ensure there would be no light leaks before exporting as an obj file. I tried the -av 0 0 0 setting but am still getting rendered wall cavities.
settings were: rpict -vf scene-c1.vp -av 0 0 0 -ab 2 -ad 1000 -x 7000 -y 5000 rm.oct | pfilt -1 -x /2 -y /2 > scene-c1a.pic
The rendering is posted at:
http://www.labergedaylight.com/pages/temp.html
Thanks,
Paul
···
On Apr 7, 2005, at 10:34 AM, Axel Jacobs wrote:
Paul,
Clipping planes do not introduce extra light where it should not be.
Assuming the model is air tight (which is not always the case for imported
CAD geometry), the inside of the wall the ceiling is visible due to the
ambient light. Setting -av to 0 0 0 should remedy this.
Axel
Thanks much for the suggestion. I�d also thought of light leaks as the
culprit so I overlapped the objects in formz to ensure there would be
no light leaks before exporting as an obj file. I tried the -av 0 0 0
setting but am still getting rendered wall cavities.
settings were: rpict -vf scene-c1.vp -av 0 0 0 -ab 2 -ad 1000 -x 7000
-y 5000 rm.oct | pfilt -1 -x /2 -y /2 > scene-c1a.pic
I think the overlapping parts are exactly the problem. Radiance does some
interpolation between ambient samples. A new indirect sample is only
triggered if the new point is outside of the sphere of influence of all
previously computed ones. This is controlled by the -a* options. The
radius of those spheres is
r_min = max_scene_dimension * aa / ar
The light from the ambient sampling can spill over into areas that would
normally not receive indirect light. Could you post a blow-up image of the
bottom part of the left-hand wall? And see what fiddling with the -aa and
-ar options results in.
Axel
Hi,
In fact, it doesn't matter for the ambient calculation if polygons overlap or cut into each other, making the edge between them 'airtight'.
When reusing ambient values from the cache no 'quasi shadow testing' is done to ensure that nothing lies inbetween for the 'allowed' radius of this ambient value. Theoretically, this perhaps might be possible, but certainly at a very high computational cost.
So the solution is to set the ambient resolution -ar sufficiently high (and/or) -aa low. The size of the scene cube also plays a role as can be seen in the expression for rmin in Axels answer, so a big outside (e.g large ground polygon) increases the problem. (In the RwR book there is a section on this, and the use of a 'ground glow' is recommended to circumvent this problem.
If you want to model a huge outdoor part, it is better to use separate ambient caches for the 'outside' and the 'inside' part of your scene.
-cb
Hello,
We completed a second rendering with the settings below. It, as the other rendering, includes a ground polygon and ground glow. Prior to running the second interior rendering we did a quick outside view rendering to create an ambient cache. The difference we see between this and the first rendering is that the sky is blue.
Carsten; is this how you meant to “use separate ambient caches for the ‘outside’ and the ‘inside’ part of the scene”?
-ab 2
-av 0.37 0.37 0.37
-ad 5000
-as 500
-ar 500
-aa 0.15
-dj 0.03
Axel; details of the left side are posted.
http://www.labergedaylight.com/pages/temp.html
Thank you for your time. We are going to continue working on this rendering with your suggestions.
Paul
Hi Paul,
sorry, with that separate cache I was referring to a still somewhat experimental radzilla feature ('scene') which is not present in classic Radiance
sticking to classic Radiance, or in fact general, the key point to keep in mind is perhaps that the ambient cache is independent of the geometry. This means except for the surface normal present at creation, there is no other geometry info the ambient cache can use for deciding if it's 'allowed' to use a cached value or not. So it is vital to
use a correct -ar resolution value, otherwise the cache cannot adapt itself adequately (means closer spaced sample points) in regions with high variation of illumination.
(Maybe expressed a bit simplified, Greg pelase correct me if I'm wrong :-).
Taken this little amount of info known to the algorithm, the ambient cache in fact does quite a good job in sorting out things, and you see the effect of a higer -ar value in your rendering, the amount of spill light in the left wall is much lesser now.
Generally, I would not bother too much about this, as in fact the hollow
wall is an unphysical situation anyway. In reality, there's conrete inside. And a real, i.e. thick wall also means a greater distance between points outside and inside the room, and together with an adequate resolution value this makes it much easier then for the ambient algorithim to get things right, i.e. not use values from the outside for the inside.
-cb
Hello Carsten,
Thanks for the clarification and the extra explanations.
We'll be rendering more tests so we can learn to apply them more deftly.
Paul