I've just spent about an hour analysing photographs of Ely Cathedral.

You know what? Whoever designed that thing knew a crapload of stuff 
about geometry!

There are regular polygon prisms, cylinders and torii, circles, arcs, 
recursively nested epicycloids, curves and spirals, points and spires, 
shapes nested within shapes nested within shapes... The level of detail 
is astonishing. Every single individual archway has at least a dozen 
ribs to it. Every column has multiple pillars, and where column meets 
arch, there are disks and trapiziods and flowery scrolls. There are 
bicylindric vaults everywhere, some of them with hexagonal recursive 
ribbing, the ribs multi-loped and the crossings capped by guilt-painted 
flower buds. Even the gaps in the choir screen contain holes within 
holes, windows within windows, arches capped by spires surrounded in 
spires capped with smaller spires, beadwork everywhere...

I was going to try to moddel some of this stuff in POV-Ray, but I don't 
know - how much RAM does it take to describe 25 arches when each one is 
made up of four-dozen torii segments? How many CSG operations is that? 
The number of intersection tests per ray would be absurd...

My head hurts.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

4ac47899$1@news.povray.org...
> I was going to try to moddel some of this stuff in POV-Ray, but I don't 
> know - how much RAM does it take to describe 25 arches when each one is 
> made up of four-dozen torii segments? How many CSG operations is that? The 
> number of intersection tests per ray would be absurd...
>
> My head hurts.

I see what you mean :-)
http://www.stanford.edu/~dorris/photos/ely2.htm

Marc

Post a reply to this message

Orchid XP v8 schrieb:
> I was going to try to moddel some of this stuff in POV-Ray, but I don't 
> know - how much RAM does it take to describe 25 arches when each one is 
> made up of four-dozen torii segments? How many CSG operations is that? 
> The number of intersection tests per ray would be absurd...

It's not as bad as you may expect. For instance, that (currently) 
30,000-primitives train of mine is still in the low hundreds-of-kB range.

Render times are quite moderate, too. Just avoid differences and 
intersections with too many members, and then there will be cake.

Post a reply to this message

On 10/1/2009 10:22 AM, clipka wrote:

> Render times are quite moderate, too. Just avoid differences and
> intersections with too many members, and then there will be cake.

Speaking of ...

If there any feasible fix for the difference/intersection ray/object 
intersection performance problem? (I mean, aside from altering the scene 
file...)
-- 
~Mike

Post a reply to this message

Le 01/10/2009 18:48, Mike Raiford nous fit lire :
> On 10/1/2009 10:22 AM, clipka wrote:
> 
>> Render times are quite moderate, too. Just avoid differences and
>> intersections with too many members, and then there will be cake.
> 
> Speaking of ...
> 
> If there any feasible fix for the difference/intersection ray/object
> intersection performance problem? (I mean, aside from altering the scene
> file...)

the "problem"b (as far as I know) is only due to the bounding box
computation. If you can get a better bounding box, you would save a lot
from real object computation.

Now, If you think you have a solution, try it on that:

intersection of sphere at <0,0,-10>, radius 10.3
with sphere at <0,0,10>, radius 10.3

the bounding box of each sphere is a box of 20.6 side.
the bounding box of the intersection is 20.6 x 20.6 x ~40
(that's a volume!)
But the real object is a very very small lens near the origin.

Each time a ray hit the bounding box, there is a real computation for
the object (and that could be lengthy).

So, if you can pre-compute a better bounding box, your issue is nearly
solved. (as long as you did not remove manual bounding in the option line)
(Don't dream to much, no automatic solution (yet ? make a name, find
it!) would be possible)

(and to make thing worst, you can replace the sphere with more complex
shapes... good luck)

Post a reply to this message

Le_Forgeron schrieb:

>> If there any feasible fix for the difference/intersection ray/object
>> intersection performance problem? (I mean, aside from altering the scene
>> file...)
> 
> the "problem"b (as far as I know) is only due to the bounding box
> computation. If you can get a better bounding box, you would save a lot
> from real object computation.

No the problem is actually a much different one (see below).

> intersection of sphere at <0,0,-10>, radius 10.3
> with sphere at <0,0,10>, radius 10.3
> 
> the bounding box of each sphere is a box of 20.6 side.
> the bounding box of the intersection is 20.6 x 20.6 x ~40
> (that's a volume!)

If you actually try this, you'll find that POV-Ray will come up with a 
bounding box from <-10.3,-10.3,-0.30> to <-10.3,-10.3,-0.30>.

Intersection bounding boxes are computed by intersecting the individual 
boxes, not adding them.


The /real/ problem typically manifests as the "many-holes problem": 
Picture a 20x20 units slab, with 1 unit diameter holes drilled at 
distances of 2 units, cut out using cylinders and the "difference" 
statement. That's 10x10 = 100 holes. Internally, the construct is 
represented as an intersection of a box and inverse cylinders.

Now, whenever the construct is tested for an intersection, this involves 
  two steps:

(1) Compute /potential/ intersections with the compound object, by 
finding intersections with the primitives.

(2) Test which of the potential intersections is contained in /all/ 
other members.

Step 1 is not much of a big deal, as POV-Ray uses a quite smart bounding 
hierarchy there.

Step 2, however, breaks your neck - not because each test would be 
difficult; actually, POV-Ray can (and does) make use of bounding boxes 
here, too (if the point is outside the inverted cylinder's bounding box, 
it is definitely outside the cylinder and therefore inside its inverse, 
and further testing is only required when inside the bounding box). But 
when having to perform the test for 100 members, it's still bad enough.

What's missing there is probably some bounding hierarchy in CSG 
intersection objects. Or, alternatively, a completely different approach 
at intersection-type CSG objects that gets away without inside-tests, 
instead making use of intersection tests only (checking the order in 
which the light ray enters and leaves the members).

Post a reply to this message