On Wed, 23 Jan 2002 11:04:32 +0100, "Juergen Scharfy" <sch### [at] surfeuat>
wrote:
> That would be cool of course. I have first to get used to the file routine
> stuff (if any) in POV 3.1g. AFAIK there is a lot of support for this in 3.5
> beta but I don't want to download a new beta (which costs me almost an hour)
> every 2 or 3 weeks.

You can be interested in http://www.povray.org/ftp/pub/povray/MIRRORS.HTML

ABX

Post a reply to this message

> You can be interested in http://www.povray.org/ftp/pub/povray/MIRRORS.HTML

That's a list of mirror sites. The problem of the long download time is not
a slow server due to a wrong mirror. My problem is that I would have to
download 8MB through a 33kBit connection.
Or did I get you wrong?

best regards
SY

Post a reply to this message

On Wed, 23 Jan 2002 12:48:03 +0100, "Juergen Scharfy" <sch### [at] surfeuat>
wrote:
> > You can be interested in http://www.povray.org/ftp/pub/povray/MIRRORS.HTML
>
> That's a list of mirror sites. The problem of the long download time is not
> a slow server due to a wrong mirror. My problem is that I would have to
> download 8MB through a 33kBit connection.
> Or did I get you wrong?

No, you get me right. I didn't know reason of long download. If it is not your
case I hope at least it refreshed memory for others :-)

But I have another workaround for your long download. Install it once and later
download only second compiler version. It is little slower at work but only
1,1MB to download. You could download full package only when you find some bug
or read something important in
http://www.povray.org/binaries/windows/revision.txt 

ABX

Post a reply to this message

> But I have another workaround for your long download. Install it once and
later
> download only second compiler version. It is little slower at work but
only
> 1,1MB to download. You could download full package only when you find some
bug
> or read something important in

I see. Thanks for the tip!
Anyway, I just found out that I have all I need already in POV 3.1g so there
is no urgent need to download a new version.
I will implement file support although evaluating the functions isn't really
slow. The major advantage would be to share ferns via a definition file. The
slowest thing is creating the POV-objects since they allocate memory. This
has to be done anyway, no matter if the results are calculated or read from
file....

regards
SY

Post a reply to this message

Juergen Scharfy wrote:
> 
> [...]
> But what is the difference? If I make single objects, POV builds a bounding
> box around it at doesn't care about the object if the ray doesn't hit it.
> This check is done on a pretty high level. Any sub-processing is skipped for
> this object.
> If it is a single mesh with a lot of holes in it (between the leaves) it
> hits the bounding box all the time and has to analyse the mesh-triangles
> before it decides to do nothing. Is that really faster?

It is much faster unless you build a bounding box hierarchy yourself.  If
not, Povray always has to test against all the bounding boxes of several
thousand shapes which can be quite slow.  For a mesh it generates a very
efficient bounding structure (octree).  Apart from this the latter has
serious advantages if you want to render more than one fern

Transforming the vertices is not that much of a problem with
'vtransform()' but this is only available in megapov/Povray 3.5.

> That would be cool of course. I have first to get used to the file routine
> stuff (if any) in POV 3.1g. AFAIK there is a lot of support for this in 3.5
> beta but I don't want to download a new beta (which costs me almost an hour)
> every 2 or 3 weeks.

There is not much in Povray 3.5 to simplify this apart from some macros
like 'VStr()'.  You can find a good example how to do file writing in the
maketree include file.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Hi Christoph,

> It is much faster unless you build a bounding box hierarchy yourself.  If
> not, Povray always has to test against all the bounding boxes of several

I see. I will do some tests to get a comparison of these two methods. I
don't have a "feeling" how much the difference is in percent of total time.
This is very interesting. I let you know ASAP.

Thanks again,
regards
SY

Post a reply to this message

Hi there,

I just did some tests according to the comparison of a single, big mesh and
a structure of unions of small meshes.
The results are quite surprising.

I rendered a single wing with 40 leaves in 320x240 AA 0.3 in highest level
of detail (auto LOD settings turned off)
The picture was quite distorted since I removed any transformations beside a
single alterating horizontal shift of the leaves.

Single mesh variant:

85 objects (the stem was still included)
Parsing 1:20 (min:sec)
Tracing 1:04
Total 2:24

Complex unions:

11762 objects (full detail!)
Parsing 1:32 (only slight difference since code is unchanged there but some
more calculations)
Tracing 1:35 (slightly slower)
Total 3:07

As I could observe, in the union test (original code) tracing got faster to
the end. Obviously POV removed bounding boxes which coudn't be hit anymore
which  would subsequently reduce the number of boxes during tracing.
There were 138 times more objects (138837%)  in the second case but tracing
time increased only by 48%. 48% sounds a lot but the number of objects for a
complete fern (not only a wing) with auto LOD will have approx. 8000
objects!
I am shure that the single-mesh-solution has some advantages in case of a
complete fern since the bounding boxes are spread over the entire picture.

Anyway, the difference is (up to now) only 30 seconds. I decided to leave
the code as it is since I have to concentrate on the shape of the wings and
a macro assembling a whole fern. If parsing time gets more and more an issue
I can flip over to the single-mesh variant.
Thanks for your explanations,

best regards
SY

Post a reply to this message

> 
> [...]
> 
> Single mesh variant:
> 
> 85 objects (the stem was still included)

Make the stem part of the mesh, i'm sure the stem objects (cylinders i
suppose) take more time than the mesh.  

And as you mentioned the advantages will increase with more complex
geometry.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

> Make the stem part of the mesh, i'm sure the stem objects (cylinders i
> suppose) take more time than the mesh.

Cones to be exact since the stem gets thinner and thinner.
The stem itself (there was a part at the end where only stem cylinders were
visible and no more leaves) takes a second to trace. 99% of the time was
used for the leaves.
But I'm still working on POV 3.1g
regards
SY

Post a reply to this message

> 
> Cones to be exact since the stem gets thinner and thinner.
> The stem itself (there was a part at the end where only stem cylinders were
> visible and no more leaves) takes a second to trace. 99% of the time was
> used for the leaves.

It seems there is something going wrong there, but without the seeing the
code i can't say anything definite.  

> But I'm still working on POV 3.1g

The mesh code has not changed that much since then.

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message