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