|
 |
Hello,
this e-mail is addressed to anyone, who belongs to the POVRAY-TEAM!
First of all, I would like to express my deep respect to this guys,
who wrote their famous and powerful POVRAY-program. I have never tried
any other raytracing-program, but I use POVRAY mainly to create
animations for some years now. I inspected a part of the source-code of
POVRAY 3.1g for WINDOWS95, which belongs to the "smooth_triangle"
objects.
There I found a BUG, because the normal vectors of the smooth_triangle
objects are not treated correctly during transformations which changes
the aspect ratios. Therefore this bug won't occur very often, but it
can be quite annoying in special situations. I wrote a scenefile,
which demonstrates this behaviour, and attached it to this e-mail
together with a suggestion for a source code patch. The last
attachment will only be included in the posting to 'povray.programming'.
To conclude, the BUG will
NOT occur in TRANSLATE-transformations,
NOT occur in ROTATE-transformations,
NOT occur in SCALE-transformations with equal scale factors,
ALWAYS occur in SCALE-transformations with different scale factors,
ALWAYS occur in shear transformations and so
MIGHT occur in general transformations.
The reason for this lies in the wrong treatment of the normal vectors
at the three edges of the smooth_triangle object. They are
NOT transformed in the special scale transformation subroutine and
WRONGLY transformed like points in the general transformation subroutine.
In the scene file you can see this BUG, if you are playing with the
flags "Triangle" and "Scaled". A "sphere {0,1}" object is compared to
a sphere, buildt completely from smooth_triangles. If they are scaled
You can see the difference.
Note, that I first believed to see another bug if the "Nu" and "Nv"
values, which compute the number of smooth_triangles in each of the
earth coordinates are too low. The construction will look edged, if
I use normal triangles, which is clearly quite normal. But the construction
will look really damaged, if I use smooth_triangles. And this occurs
at the parts of the sphere, whose normal vectors are perpendicular to the
camera ray. But I came to the conclusion, that this is a
general lack in objects, which have other RAW normal vectors than the
pure geometry would produce. At the damaged parts of the scene, the rays
are reflected through the surface and this cannot be catched like in the
case of disturbed normal vectors in the REFLECTION subroutine.
Maybe You find a way to solve this problem, but one can still live with it,
if the number of triangles in the problematic regions are increased.
With the best wishes for Your team and the development of POVRAY,
Michael Rose.
P.S.: The code of POVRAY is written in C, but the object orientated
formulation seems to be adopted from C++ (could be wrong :-)).
Why don't You change to C++? I don't think this would be a
speed problem, if You avoid some critical copy constructions.
Or do You think the language is still to buggy or to incompatible
on different platforms?
[Probably the amount of work to convert the program is also too big]
Post a reply to this message
Attachments:
Download 'test.pov.txt' (3 KB)
Download 'us-ascii' (29 KB)
|
|
|
|
Michael Rose <mic### [at] dlr de> writes:
> P.S.: The code of POVRAY is written in C, but the object orientated
> formulation seems to be adopted from C++ (could be wrong :-)).
> Why don't You change to C++? I don't think this would be a
> speed problem, if You avoid some critical copy constructions.
> Or do You think the language is still to buggy or to incompatible
> on different platforms?
I'm not a member of the POV-Team. However, I can provide you the following
information: It was mentioned in several postings and perhaps even in the
documentation of POV-Ray, that the next major release of POV-Ray, namely
4.0, will be a total rewrite in C++. (Apart from this, a version 3.5 is
planned that includes some of the fantastic patches.)
Thomas
--
http://thomas.willhalm.de/
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i
mQCNAzgBwGkAAAEEAKx6RGDGAhjwr2kEv7Z2oxx2SoYBpMWCN2M76HE0GLHRvvto
RMfuLp+ECPoyutG9DnrwpLGNKwntY10qsWNPZNHZ9obZOtQcZf+hYs+A/283l7Iv
EKtKsggRATbd44NECkkKLuWZzuklNaoSAN7SOnmG94ZpcjZTfIwTzXgp3F/9AAUR
tCRUaG9tYXMgV2lsbGhhbG0gPHRob21hc0B3aWxsaGFsbS5kZT4=
=UScf
-----END PGP PUBLIC KEY BLOCK-----
Post a reply to this message
|
|
|
|
On Tue, 26 Oct 1999 00:13:20 -0400, "Nathan Kopp" <Nat### [at] Koppcom> wrote:
>This does appear to be a bug. One work-around for it is to put your smooth
>triangles in a mesh object. I just tested it, and the mesh object does not
>contain this bug (further proof that this is a bug). I hope to incorporate
>your bugfix into UVPov. Thanks for finding this one.
Much obliged for checking this out, Nathan. Now posted to the bugreports
group.
--
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
Post a reply to this message
|
|
