 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello POV-Team!
So, here comes feedback on povray-3.6.
It is a list not sorted in any way...
Some aspects of this message clearly show that POVRay (I mean the quality
of the program) could benefit from publication of the sources prior to
releasing the binaries. But I know that there are prople around here which
do not want to hear that...
------
More than a year ago, on Sunday 09 February 2003 22:08:27, I posted
to this group:
>/* NK phmap */
>/* this function checks if 'object' is equal to 'parent' or is a child
>static int IsObjectInCSG(OBJECT *Object, OBJECT *parent)
>{
>
>
>}
Shortly later, Thorsten Froehlich wrote back:
>Wolfgang Wieser wrote:
>> What about applying this trivial patch?
>> I think there is no need to continue the for() loop once
>> we set found=true.
>
>Yes, it has been noted. It will be included sometime in the future.
One year later looking at the code, nothing has changed...
(Thorsten will probably answer that "sometime in the future" does not
necessarily mean version 3.6. Oh, well...)
-------
Some patch against the following warning...
Warning: The maximum gradient found was 0.000, but max_gradient of the
isosurface was set to 0.000. The isosurface may contain holes!
Adjust max_gradient to get a proper rendering of the isosurface.
...was not included, too.
(I proposed replacing %.3f -> %.3g at that time = 21 May 2003 20:45:07)
------
No patch against the parametric object trouble (crash and getting black)
reported by me (20 Jun 2003 21:49:03) was introduced (these bugs are
sill present and stating in the docu that no bugs are known is incorrect).
It's really strange: THIS patch made it into the code (fpmetric.cpp):
598c588,591
< Assign_BBox_Vect(Param->BBox.Lower_Left,
Param->container.box.corner1);
---
> // [ABX 20.01.2004] Low_Left introduced to hide BCC 5.5 bug
> BBOX_VECT& Low_Left = Param->BBox.Lower_Left;
>
> Assign_BBox_Vect(Low_Left, Param->container.box.corner1);
<polemic>A patch against a bug in a compiler (BCC) nobody is
using...</polemic>
However, around line 420 in fpmetric.cpp,
/* 1 copy */
if ((SectorNum[i] *= 2) >= Max_intNumber)
SectorNum[i] = Max_intNumber;
SectorNum[i + 1] = SectorNum[i];
SectorNum[i]++;
POVRay still happily accesses SectorNum[i + 1] outside array boundaries.
(On my box using my posted test scene, POVRay will, however, _not_ crash
because it happens that the overwritten regions of memory are non-lethal.)
Furthermore, the parametric object test case will still render a completely
black object. Somebody proposed a patch against that and I have the code
here. I'll come to this issue in a later posting.
------
I suggest to apply the following patch in pattern.cpp which was also
already proposed by me earlier. This will bring the return value into the
legal range 0..1 while not changing the results (the 0.25 phase is absorbed
by changing the sign of the y argument of atan2()):
static DBL radial_pattern (VECTOR EPoint)
{
register DBL value;
if ((fabs(EPoint[X])<0.001) && (fabs(EPoint[Z])<0.001))
{
value = 0.25;
}
else
{
- value = 0.25 + (atan2(EPoint[X],EPoint[Z]) + M_PI) / TWO_M_PI;
+ value = (atan2(EPoint[Z],-EPoint[X]) + M_PI) / TWO_M_PI;
}
return(value);
}
------
The render status line should be patched to append some whitespace at the
end of the line. Otherwise, shorter lines will contain the end of the
message of the previous longer line resulting in something like:
0:01:03 Rendering line 449 of 480 at 4x4
...when we're actually at 1x1 pixels.
------
Closig the window while rendering will now work but the rendering is not
stopped in this case. This is okay for "-X" traces but when using
command line option "+X", closing the window should IMO abort the render
just as pressing "q" in the window.
The following patch for xwin.cpp will change that:
if (theEvent.xclient.message_type == WM_PROTOCOLS &&
theEvent.xclient.data.l[0] == WM_DELETE_WINDOW)
{
- // [NC] abortRender = true;
+ if(opts.Options & EXITENABLE) abortRender = true;
refresh = false;
BTW, Thanks to Nicolas Calimet for including my other fixes (key and
event handling).
------
Finite objects: 4
Infinite objects: 0
Light sources: 1
Total: 5
Hmm... I must admit that I do not at all understand the "Total" line.
Why does it make sense to add apples and bananas?
------
Okay, I think this was enough feedback for now.
I hope I can finally write some _positive_ feedback when looking
at the image IO code.
Regards,
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
> Hello POV-Team!
>
> So, here comes feedback on povray-3.6.
> It is a list not sorted in any way...
I won't comment on the individual things you write but you should be
aware that:
- the beta version Nicolas provided it not yet the final source release.
It is *only* meant for testing the build system, not for doing
anything else. We especially do not want unofficial versions based on
this beta code to be created (which would of course be illegal but not
everyone cares).
- you have been visiting these newsgroups long enough to know the
correct proceedings of a bug report. Still i can only find a single bug
report from you in povray.bugreports.
- there has been a several month long beta phase for POV-Ray 3.6 and i
don't remember any report from you in povray.beta-test. The only
explanation i have for this is that you want to demonstrate the
necessity to release the source code to get useful feedback...
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Closig the window while rendering will now work but the rendering is not
> stopped in this case. This is okay for "-X" traces but when using
> command line option "+X", closing the window should IMO abort the render
> just as pressing "q" in the window.
No, this is intended behavior, as I wanted to allow one to close
the display window without necessarily stop the rendering itself -- similar
to what you can do with e.g. WinPOV. The idea is that you can still close
the display after starting a long render, in the hope it will speed it up.
(ideally I should add support for re-opening the display window while or
after rendering).
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> - the beta version Nicolas provided it not yet the final source release.
> It is *only* meant for testing the build system, not for doing
> anything else. We especially do not want unofficial versions based on
> this beta code to be created (which would of course be illegal but not
> everyone cares).
>
I do not intend to create unofficial binaries for distribution. I primarily
downloaded to test the build system because I felt that it was my duty
to do so. Then, I had a look at the docu and stumbled over the change log
at the same level as the html/ directory.
There, I saw that it did not mention several bugs which I reported, so I
felt that it was high time to have a look and tell people.
> - you have been visiting these newsgroups long enough to know the
> correct proceedings of a bug report. Still i can only find a single bug
> report from you in povray.bugreports.
>
If I post a patch against a bug in povray.programming and some member
of the POV team comments on it, then this must be enough. (Especially
if I am told that "it has been noted".)
If the POV team fails to include patches proposed this way, I do not
feel guilty for that.
Especially note that in most cases I am not providing a "bug report"
but actually a "bug fix". And I am just writing such one for the parametric
objet code (when reporting it, I was unable to fix the out-of-bounds
condition).
> - there has been a several month long beta phase for POV-Ray 3.6 and i
> don't remember any report from you in povray.beta-test. The only
> explanation i have for this is that you want to demonstrate the
> necessity to release the source code to get useful feedback...
>
Okay, so then please tell me how I could check if the "break;" in
the search loop was included from using the binary? How could I have done
so for the parametric object (the bug is still there but povray does no
longer crash becasue the overwritten memory is non-lethal)? How can
I tell from testing the binary that the radial pattern patch was included
(I do not have a test case for this since it is not really something which
shows up as image disortion but will make the function conform to the
allowed return value range stated in the code)?
Please tell me!
And trust me: I actually wanted to look at the code and see that everything
with the patches went fine. Because the other issues I had on my lists (see
my home page!) were actually fixed in the pre-release binaries:
There was the torus numerics patch where I provided a test scene:
Correctly fixed in prerelease so no reason for a bug report.
Then the various X11 fixes proposed by me: All were included in the
prerelease binaries, so no reason for a bug report, too.
Okay, and the other things I mentioned are no _real_ bugs:
The window close is a feature (as pointed out by N.C.), the rendering
status line is just eye candy [I actually thought this was mentioned by
somebody else in the beta testing stage] and the last one is a question
of me (eye-candy subject) and not a bug.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet wrote:
> No, this is intended behavior, as I wanted to allow one to close
> the display window without necessarily stop the rendering itself --
> similar
> to what you can do with e.g. WinPOV. The idea is that you can still close
> the display after starting a long render, in the hope it will speed it up.
> (ideally I should add support for re-opening the display window while or
> after rendering).
>
Okay, I can see your point and I actually share that opinion for normal
renders. Because often, for a final trace, it is enough to see that the
+EP4 mosaic preview looks correct and then one can close the window.
But I still think that when using +X (allow trace interruption), pressing
"q" and closing the window should abort the render. But if other people
are of different opinion, I can live with that (my private version will be
patched...)
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
>
>>- you have been visiting these newsgroups long enough to know the
>>correct proceedings of a bug report. Still i can only find a single bug
>>report from you in povray.bugreports.
>>
>
> If I post a patch against a bug in povray.programming and some member
> of the POV team comments on it, then this must be enough. (Especially
> if I am told that "it has been noted".)
>
> If the POV team fails to include patches proposed this way, I do not
> feel guilty for that.
>
> Especially note that in most cases I am not providing a "bug report"
> but actually a "bug fix".
My advise in hopefully clear words: if you observe a problem using
POV-Ray you should point this out in one of these newsgroups, if
possible illustrated with reproducible examples. If you think you have
a solution for the problem you should of course include it as well (not
as a patch but as an explanation what you think should be changed).
After others had the opportunity to comment you should post this to
.bugreports. And even if you think all this is completely unnecessary
and have no idea why anyone would make it that complicated it would
still be a good idea to follow this.
>
>>- there has been a several month long beta phase for POV-Ray 3.6 and i
>>don't remember any report from you in povray.beta-test. The only
>>explanation i have for this is that you want to demonstrate the
>>necessity to release the source code to get useful feedback...
>>
>
> Okay, so then please tell me how I could check if the "break;" in
> the search loop was included from using the binary?
To make it perfectly clear your analysis of the source code is
absolutely irrelevant here. The beta test phase is about finding
problems in the use of the program. If you now find a 'problem' in the
source that does not manifest itself in form of a problem for the user
of the program it is completely unnecessary to change it. The only
problem you as it seems correctly pointed out is the parametric object
one. I don't want to speculate why others have not worked on this but
the fact that the parametric object is classified experimental gives it
relatively low priority in general. The other things you write about in
this thread you could have perfectly observed and reported during beta
phase (and even if they are only 'cosmetic' things it would still have
been good to point them out).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>> If the POV team fails to include patches proposed this way, I do not
>> feel guilty for that.
>>
>> Especially note that in most cases I am not providing a "bug report"
>> but actually a "bug fix".
>
> My advise in hopefully clear words:
>
I like clear words :)
> if you observe a problem using
> POV-Ray you should point this out in one of these newsgroups, if
> possible illustrated with reproducible examples.
>
I did that.
> If you think you have
> a solution for the problem you should of course include it as well
>
In case I have a solution, I include it as well...
> (not
> as a patch but as an explanation what you think should be changed).
>
...by explaining what should be changed in the code. This is what I
mean when calling it "patch": Some lines of code context and some
text which make it clear to the reader what I propose to be changed.
It it the easiest way and the only one which makes sure that we're
all talking about the same thing.
> After others had the opportunity to comment you should post this to
> .bugreports.
> And even if you think all this is completely unnecessary
> and have no idea why anyone would make it that complicated it would
> still be a good idea to follow this.
>
(1) I _did_ post something about the parametric object to bugreports.
(2) I do not see it as my task to run after people in a way which seems
ridiculous to me. It makes the impression that the POV team is not
actually interested in improving the code and that it is my task
to bring a patch into their code. Well, up to now, I was not this
opinion but...
>> Okay, so then please tell me how I could check if the "break;" in
>> the search loop was included from using the binary?
>
> To make it perfectly clear your analysis of the source code is
> absolutely irrelevant here. The beta test phase is about finding
> problems in the use of the program. If you now find a 'problem' in the
> source that does not manifest itself in form of a problem for the user
> of the program it is completely unnecessary to change it.
>
So it is better to adjust eve candy than to improve the algorithms to
run faster. I hope some time in future, the POV team will have changed
their opinion concerning "quality of code".
> The only
> problem you as it seems correctly pointed out is the parametric object
> one. I don't want to speculate why others have not worked on this but
> the fact that the parametric object is classified experimental gives it
> relatively low priority in general.
>
I think I have a solution here which completely removes the problem.
Somebody with more clue about the code (does such one exist BTW?)
should comment on it and I will post it here this night.
> The other things you write about in
> this thread you could have perfectly observed and reported during beta
> phase (and even if they are only 'cosmetic' things it would still have
> been good to point them out).
>
Let's see:
- IsObjectInCSG():
cannot be detected without looking at the code
- parametric. Okay, we agreed.
- radial_pattern():
cannot be detected without looking at the code (or at least I would
not know how)
- isosurface warning:
This warning was caused by a scene written by me which rendered
Schroedinger equation solutions. To render this scene, a patched version
of POVRay (with orbit function built-in) was necessary. Hence, I could not
test for this one during beta test and relied on Thorsten who sait
something like "I'll see if I can come up with a solution" (non-literal).
- render status line
I thought this was already known.
- Total:..
This is not a bug. I am just wondering...
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40e6e581@news.povray.org> , Wolfgang Wieser <wwi### [at] gmx de>
wrote:
>> To make it perfectly clear your analysis of the source code is
>> absolutely irrelevant here. The beta test phase is about finding
>> problems in the use of the program. If you now find a 'problem' in the
>> source that does not manifest itself in form of a problem for the user
>> of the program it is completely unnecessary to change it.
>
> So it is better to adjust eve candy than to improve the algorithms to
> run faster. I hope some time in future, the POV team will have changed
> their opinion concerning "quality of code".
I don't think if I would provide you with some insight showing how
ridiculous this statement of yours is would serve anybody as you obviously
don't care about that, but rather insist on just complaining. I shall nope
however, that that is the best way to get ignored completely...
*plonk*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wolfgang Wieser wrote:
>>
>>To make it perfectly clear your analysis of the source code is
>>absolutely irrelevant here. The beta test phase is about finding
>>problems in the use of the program. If you now find a 'problem' in the
>>source that does not manifest itself in form of a problem for the user
>>of the program it is completely unnecessary to change it.
>
> So it is better to adjust eve candy than to improve the algorithms to
> run faster. I hope some time in future, the POV team will have changed
> their opinion concerning "quality of code".
What exactly didn't you understand about the purpose of the beta
testing? Your reply absolutely ignores what i wrote and even worse, you
are trying to imply things i have never said.
I would strongly suggest you revise your attitude before continuing, if
you think you can do things so much better you are free to publish your
own patched version (after the source release of course).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>>>
>>>To make it perfectly clear your analysis of the source code is
>>>absolutely irrelevant here. The beta test phase is about finding
>>>problems in the use of the program. If you now find a 'problem' in the
>>>source that does not manifest itself in form of a problem for the user
>>>of the program it is completely unnecessary to change it.
>>
>> So it is better to adjust eve candy than to improve the algorithms to
>> run faster. I hope some time in future, the POV team will have changed
>> their opinion concerning "quality of code".
>
> What exactly didn't you understand about the purpose of the beta
> testing? Your reply absolutely ignores what i wrote and even worse, you
> are trying to imply things i have never said.
>
So, then please tell me exactly why.
All the "bugs" I reported in the initial posting with the exception of the
eye-candy "status line" could not be detected by me in beta-testing phase.
And what are the things I am "trying to imply" although you "never said"
them?
> I would strongly suggest you revise your attitude before continuing, if
> you think you can do things so much better you are free to publish your
> own patched version (after the source release of course).
>
I will not publish a patched version.
However, I will provide patches to make the official version better.
But that is nothing new; I've been doing so since 3.5 was out.
Wolfgang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
