Hi again.
I've changed the scripts which build my model. I had a hierarchical structure of nested octrees (instances), which were not really good. I had used this structure as I wanted to "bundle" geometry into some more cubic-like clusters. In fact, I did the opposite as I later "invented" the use of ximage to repeat objects - the result was that the octree contained not this "cube-like" block, but all the instances of this block - and thus this octree was not cube-like any more.
Now I use instances only on a lower level, for small objects, and use xform everywhere else. The errors are gone, as there are fewer overlappings of octrees now.
CU and thanks a lot, Lars.
It's a shame we'll never know what caused this problem, whether it was the model or a bug....
···
From: Lars O. Grobe <[email protected]>
Date: April 18, 2005 5:26:28 AM PDT
Hi again.
I've changed the scripts which build my model. I had a hierarchical structure of nested octrees (instances), which were not really good. I had used this structure as I wanted to "bundle" geometry into some more cubic-like clusters. In fact, I did the opposite as I later "invented" the use of ximage to repeat objects - the result was that the octree contained not this "cube-like" block, but all the instances of this block - and thus this octree was not cube-like any more.
Now I use instances only on a lower level, for small objects, and use xform everywhere else. The errors are gone, as there are fewer overlappings of octrees now.
CU and thanks a lot, Lars.
Gregory J. Ward wrote:
It's a shame we'll never know what caused this problem, whether it was the model or a bug....
Hi Greg & Lars,
just guessing form afar, I think it is (was..) not a bug but a simple instance overlapping problem. If several instances overlap, each one will be traversed for a ray hit, and the one which actually 'wins' in the end is determined by the way they're inserted into the object set for this octree subcube, and not e.g by the distance of the ray hit to the view point.
(PS one reason for me joining into that discussion and risking a statement is to check if my understanding of the meachinism is correct...)
-cb
Carsten is correct in the case of actual overlapping geometry, but overlapping instances are not a problem per se, though they do tend to make oconv take a lot longer and use a lot more memory resolving them.
If two or more instances overlap, Radiance traces rays in each instance, and returns the geometry that intersects first (in the case of multiple intersections). If two bits of geometry are coincident, the one that gets returned is decided randomly, usually as a result of floating point roundoff errors. The same is true when geometry is not contained in instances.
-Greg
···
From: Carsten Bauer <[email protected]>
Date: April 19, 2005 1:56:34 AM PDT
Gregory J. Ward wrote:
It's a shame we'll never know what caused this problem, whether it was the model or a bug....
Hi Greg & Lars,
just guessing form afar, I think it is (was..) not a bug but a simple instance overlapping problem. If several instances overlap, each one will be traversed for a ray hit, and the one which actually 'wins' in the end is determined by the way they're inserted into the object set for this octree subcube, and not e.g by the distance of the ray hit to the view point.
(PS one reason for me joining into that discussion and risking a statement is to check if my understanding of the meachinism is correct...)
-cb