I am working on a project with a very large geographical span.
This entails a huge height_model and a thousand or more objects.

The project is animated so that I travel through the space.

Display time is slow and I would like to speed things up substantially.

The bounding option does not appear to really help and I am interested to
explore the possibility of using the inside of a reduced radius sky_sphere
to lop off part of the scene.

I have tried to translate a simple sphere along with the camera position but
the time has not really improved enough to make a substantial difference.

Has anybody used this approach for bounding control and had any success?

Post a reply to this message

In article <38a9a1b2@news.povray.org>, "David Vincent-Jones" 
<geo### [at] galaxynetcom> wrote:

> I am working on a project with a very large geographical span.
> This entails a huge height_model and a thousand or more objects.
...
> The bounding option does not appear to really help

Have you tried bounding in a tree-like structure? Like, if you have a 
line of 8 objects, bound each half of it separately, and subdivide each 
half of it...ok, I am just really bad at explaining this. If you know 
something about programming, it is similar to a binary search tree.
If you do this, make sure you change the settings so POV doesn't ignore 
your bounded_by statements.


> and I am interested to explore the possibility of using the inside of 
> a reduced radius sky_sphere to lop off part of the scene.

A sky_sphere is not an object, it just acts like a background with a 
pigment that would fit on a unit-sized sphere. It would be useless as a 
bounding object, but from your description, you appear to be using a 
sphere object instead of sky_sphere.


> I have tried to translate a simple sphere along with the camera 
> position but the time has not really improved enough to make a 
> substantial difference.

Are you translating a bounding shape for all of your objects along with 
the camera? If so, you are not likely to get any increase in speed, in 
fact your render time will probably increase. Bounding works this way: 
if a ray hits the bounding shape defined by bounded_by, it is then 
tested for the bounded shape. There is no requirement that the 
bounded_by shape encloses the shape being bounded. If the bounded_by 
shape surrounds the camera, it will always be hit, so the calculations 
for the bounded shape will always be done.

If you are simply moving the sphere you are using as the sky along with 
the camera, so that most of the scene isn't visible...I don't know. That 
might work, but I am not certain how objects in front of other objects 
are handled, I never even looked at that part of the code.

What you might want to do is a kind of "level of detail". If an object 
is a certain distance from the camera, use a simpler model and faster 
textures, or eliminate it completely. An easy way to get the distance is 
vlength(ObjectDistance - CameraPosition).

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris

I had been using a sky_sphere for the backdrop..... It only occurred to me
that using the inside of a regular sphere could act as a backdrop as well as
limiting the visible scene elements and unwanted height_field. Unfortunately
I did not gain much in display time.

Bounded_By and Clipped_By both looked like good solutions but they appear to
be devised for individual elements rather than for the scene in general. Is
there a way to apply either of them to the overall view?

Yes, some kind of test based on vlength sounds interesting.... I will give
that a try.

Don't know about a tree like structure... I feel that might be more useful
with a pre-defined path; my journey needs to be quite random.

David

Chris Huff <chr### [at] yahoocom> wrote in message
news:chrishuff_99-A7F704.15432915022000@news.povray.org...
> In article <38a9a1b2@news.povray.org>, "David Vincent-Jones"
> <geo### [at] galaxynetcom> wrote:
>
> > I am working on a project with a very large geographical span.
> > This entails a huge height_model and a thousand or more objects.
> ...

Post a reply to this message

In article <38a9ee95@news.povray.org>, "David Vincent-Jones" 
<geo### [at] galaxynetcom> wrote:

> Don't know about a tree like structure... I feel that might be more 
> useful with a pre-defined path; my journey needs to be quite random.

By a tree structure I was talking about the path the program would take 
to find an intersection.

union {//x
   union {//xA
      union {//xAA
         bounded_by {...}
      }
      union {//xAB
         bounded_by {...}
      }
      bounded_by {...}
   }
   union {//xB
      union {//xBA
         bounded_by {...}
      }
      union {//xBB
         bounded_by {...}
      }
      bounded_by {...}
   }
   bounded_by {...}
}

Assume the ray will hit the union "xBB". It will first be tested against 
x, which has a bounding object containing all it's parts. Since the test 
succeeds, it will then be tested against xA and xB. Because it doesn't 
hit anything in xA, but does hit something in xB, it will continue to 
test xBA and xBB, and find it's intersection with xBB. It skips anything 
in XA completely.
With certain configurations of shapes and certain slow-calculating 
objects, this can be much faster than just going through all of the 
objects and testing for them, which is what happens if you just put all 
of the objects in the scene.

At least, this is how I understand it. I might be wrong...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

David Vincent-Jones wrote:
> 
> I am working on a project with a very large geographical span.
> This entails a huge height_model and a thousand or more objects.
> 
> The project is animated so that I travel through the space.
> 
> Display time is slow and I would like to speed things up substantially.
> 
> The bounding option does not appear to really help and I am interested to
> explore the possibility of using the inside of a reduced radius sky_sphere
> to lop off part of the scene.
> 
> I have tried to translate a simple sphere along with the camera position but
> the time has not really improved enough to make a substantial difference.

I think, that this cannot help, because if you want to cut off all
objects outside your sphere you must set clipped_by { your_sphere
inverse} to them
and ALL rays going from camera will intersect this sphere =>
=> no speedup from it, it makes no differences from scene without that
sphere,
even one more needless sphere is evaluated with each ray => I expect
small
slowdown from it. Forgot I something?

> 
> Has anybody used this approach for bounding control and had any success?

Post a reply to this message

Instead of bounding, try use #if directive and cut off
objects too distant from camera, something like:

#declare MaximumDistance= something

#declare CameraPos= <bla, bla, bla>

#macro dist(v1, v2)
  #local dx=v2.x-v1.x;
  #local dy=v2.y-v1.y;
  #local dz=v2.z-v1.z;
  ( sqrt(dx*dx + dy*dy +dz*dz) )
#end

...


#declare Building1=
object {
   ...
}
#declare Building1pos= <bla, bla, bla>

#if (dist(CameraPos, Building1Pos) < MaximumDistance)
   object { Building1 translate Building1pos }
#end

Maybe I make some mistake in syntax, but idea is clear, hopefully

Or you can enclose entire object definition in #if statement,
you will then improve parsing time too.

Disnel

E-Mail:   dis### [at] itamcascz
Homepage: http://www.itam.cas.cz/~disnel
ICQ:      20126042

Post a reply to this message

Or you can create your buildings in several levels of detail and
use them depending on distance from camera, like:

#declare CameraPos= ...

#declare HighLODDist= ...
#declare MiddleLODDist= ...
#declare LowLODDist= ...

#declare Build1HightLOD= ....

#declare Build1MiddleLOD= ...

#declare Build1LowLOD= ...

#macro dist (....

...
#end

#declare Build1Pos= somewhere
#local pdist=dist(Build1Pos, CameraPos)

#if (pdist < HighLODDist)
  object { Build1HighLOD translate Build1Pos }
#else
  #if (pdist < MiddleLODDist)
    object { Build1MiddleLOD translate Build1Pos }
  #else
    object { Build1LowLOD translate Build1Pos }
  #end
#end


Disnel

Post a reply to this message

In article <38AC138C.A5645660@linux.itam.cas.cz>, Disnel 
<Dis### [at] linuxitamcascz> wrote:

> #macro dist(v1, v2)
>   #local dx=v2.x-v1.x;
>   #local dy=v2.y-v1.y;
>   #local dz=v2.z-v1.z;
>   ( sqrt(dx*dx + dy*dy +dz*dz) )
> #end

This would be more clearly written as:
#macro dist(v1, v2)
   vlength(v1-v2)
#end

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38AC138C.A5645660@linux.itam.cas.cz>, Disnel
> <Dis### [at] linuxitamcascz> wrote:
> 
> > #macro dist(v1, v2)
> >   #local dx=v2.x-v1.x;
> >   #local dy=v2.y-v1.y;
> >   #local dz=v2.z-v1.z;
> >   ( sqrt(dx*dx + dy*dy +dz*dz) )
> > #end
> 
> This would be more clearly written as:
> #macro dist(v1, v2)
>    vlength(v1-v2)
> #end
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

And then we don't need macro, you are right.

Disnel

Post a reply to this message

Chris Huff wrote:
> 
> Have you tried bounding in a tree-like structure?

Any ideas how to construct such a tree structure in POV script?
Let's say I have a set of points, which I would like to sort into distance-based
subsets. How could I do this efficiently, i.e. without comparing every point to
every other point? An oct-tree? But how?

Margus

Post a reply to this message

In article <38AD605D.D9C23B5A@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Chris Huff wrote:
> > 
> > Have you tried bounding in a tree-like structure?
> 
> Any ideas how to construct such a tree structure in POV script?
> Let's say I have a set of points, which I would like to sort into 
> distance-based
> subsets. How could I do this efficiently, i.e. without comparing every 
> point to
> every other point? An oct-tree? But how?

A tree of unions is the eay I would do it:
union {
   union {
      union {
         union {}
         union {}
      }
      union {
         union {}
         union {}
      }
   }
   union {
      union {
         union {}
         union {}
      }
      union {
         union {}
         union {}
      }
   }
}

You might be able to make a macro which takes an array of objects as 
well as an array of their center positions and sorts them out into this 
tree structure. If you use MegaPOV, with min_extent and max_extent, the 
second array would be unnecessary.
But there are probably better ways to do this. It isn't my idea, there 
were some discussions in these newsgroups a while ago about it...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Yes, but construct such a tree I would still have to test all points against the
current one, no? I can't construct the tree at generation time, because
consequent points are not necessarily spatially close (I'm talking about an
actual case here).
Perhaps I could start recursively subdividing the points along a set of
planes... But then I would not end up with a constant number of points in a
subset. I would have constant-volume subsets. How could I achieve the former
goal?

Margus

Chris Huff wrote:
> 
> You might be able to make a macro which takes an array of objects as
> well as an array of their center positions and sorts them out into this
> tree structure. If you use MegaPOV, with min_extent and max_extent, the
> second array would be unnecessary.
> But there are probably better ways to do this. It isn't my idea, there
> were some discussions in these newsgroups a while ago about it...
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

Many thanks, good idea .... I will give it a try

Looking at the Histogram is also most revealing.
What I am seeing is that reducing distant objects is not the only criteria
in speeding up the display.

Much time is also spent with surfaces that are quite close to the camera
especially where the height_field passes under, or around, the camera.

David

Disnel <Dis### [at] linuxitamcascz> wrote in message
news:38AC138C.A5645660@linux.itam.cas.cz...
>
> Instead of bounding, try use #if directive and cut off
> objects too distant from camera, something like:
>
> #declare MaximumDistance= something
>
> #declare CameraPos= <bla, bla, bla>
>
> #macro dist(v1, v2)
>   #local dx=v2.x-v1.x;
>   #local dy=v2.y-v1.y;
>   #local dz=v2.z-v1.z;
>   ( sqrt(dx*dx + dy*dy +dz*dz) )
> #end
>
> ...
>
>
> #declare Building1=
> object {
>    ...
> }
> #declare Building1pos= <bla, bla, bla>
>
> #if (dist(CameraPos, Building1Pos) < MaximumDistance)
>    object { Building1 translate Building1pos }
> #end
>
> Maybe I make some mistake in syntax, but idea is clear, hopefully
>
> Or you can enclose entire object definition in #if statement,
> you will then improve parsing time too.
>
> Disnel
>
> E-Mail:   dis### [at] itamcascz
> Homepage: http://www.itam.cas.cz/~disnel
> ICQ:      20126042

Post a reply to this message

In article <38AD84F1.CF309BF6@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Yes, but construct such a tree I would still have to test all points 
> against the current one, no? I can't construct the tree at generation 
> time, because consequent points are not necessarily spatially close 
> (I'm talking about an actual case here).
> Perhaps I could start recursively subdividing the points along a set 
> of planes... But then I would not end up with a constant number of 
> points in a subset. I would have constant-volume subsets. How could I 
> achieve the former goal?

I am not sure what you mean here...could you clarify?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

On Tue, 15 Feb 2000 15:43:29 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>> The bounding option does not appear to really help
>
>Have you tried bounding in a tree-like structure? Like, if you have a 
>line of 8 objects, bound each half of it separately, and subdivide each 
>half of it...ok, I am just really bad at explaining this. If you know 
>something about programming, it is similar to a binary search tree.
>If you do this, make sure you change the settings so POV doesn't ignore 
>your bounded_by statements.

An oct-tree is built recursively by splitting each bounding box in
eight smaller parts, right? How are the three splitting planes
determined? Is the midpoint of the bounding box used or is an adaptive
median approach used? The latter would yield a much more efficient
bounding scheme but the overhead in parse time would almost surely
render any benefits in render time unsibstantial. If this is
implemented in a POV script generating external program, such as
PlantStudio or TreeDesigner or a particle system this should not be
much of a problem.


Peter Popov
pet### [at] tagpovrayorg
ICQ: 15002700

Post a reply to this message

On Fri, 18 Feb 2000 19:44:17 +0200, Margus Ramst <mar### [at] peakeduee>
wrote:

>Yes, but construct such a tree I would still have to test all points against the
>current one, no? I can't construct the tree at generation time, because
>consequent points are not necessarily spatially close (I'm talking about an
>actual case here).

Try this approach. Let's assume it's points we're working with though
things won't change much for objects:

1. Find the smallest box that encloses all points
2. Put all x-coords in an array and sort it. Do this for y and z as
well.
3. Get the middle point of each array (x,y and z) and form a vector
4. Divide the initial bounding box into eight bounding boxes using the
vector from point 3
5. Recursively repeat the procedure for each child of the parent
bounding box until a recursion limit is reached or no further
subdivision is pointless

Each parent will bound its children. Only the leafs of the oct-tree
will bound actual objects.

Does this make any sense to anyone?


Peter Popov
pet### [at] tagpovrayorg
ICQ: 15002700

Post a reply to this message

Chris Huff wrote:
> 
> I am not sure what you mean here...could you clarify?
> 

Basically, what Peter suggests sound like it...
When I have some time I'll check it out and see.

Margus

Post a reply to this message

Interesting. Approximately what I had in mind. Perhaps weighed averaging
might give a more uniform distribution though... Did I just reinvent an
oct-tree? ;)
I'll have to check if this actually works.
Thanks.

Margus

Post a reply to this message

In article <On+tOPJBpDTW19hVUhYU9Bh3Vtgf@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> An oct-tree is built recursively by splitting each bounding box in
> eight smaller parts, right? How are the three splitting planes
> determined? Is the midpoint of the bounding box used or is an adaptive
> median approach used?

I wouldn't know, I know very little about bounding structures. I only 
know what the most basic form of an oct-tree is.


> The latter would yield a much more efficient bounding scheme but the 
> overhead in parse time would almost surely render any benefits in 
> render time unsibstantial. If this is implemented in a POV script 
> generating external program, such as PlantStudio or TreeDesigner or a 
> particle system this should not be much of a problem.

Is this a disguised hint for a feature in my particle simulator? :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

On Sat, 19 Feb 2000 00:06:51 +0200, Margus Ramst <mar### [at] peakeduee>
wrote:

>Interesting. Approximately what I had in mind. Perhaps weighed averaging
>might give a more uniform distribution though... 

The median approach is used in color reduction (Adaptive Palette for
PhotoShop users). It is considered the best non-empirical algorithm
for the purpose. It might prove the best in bounding as well.

>Did I just reinvent an oct-tree? ;)

I have no idea, I myself have never seen one :)

>I'll have to check if this actually works.
>Thanks.

Keep us posted.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On Fri, 18 Feb 2000 17:30:36 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>Is this a disguised hint for a feature in my particle simulator? :-)

These kids are just getting smarter every day :-)


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message