![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |