 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scenes/objects/bezier.pov
8< snip >8
bicubic_patch { type 1 flatness 0.1 u_steps 8 v_steps 8
8< snip >8
I don't see a bicubic_patch 8[
Any confirmations?
--
Thorsten aka ThH
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Messed up. Second try ...
Am 04.03.2016 um 16:11 schrieb ThH:
> scenes/objects/bezier.pov
>
> 8< snip >8
> bicubic_patch { type 1 flatness 0.1 u_steps 8 v_steps 8
> 8< snip >8
>
> I don't see a bicubic_patch 8[
>
> Any confirmations?
>
> --
> Thorsten aka ThH
...any bicubic _patch...
Only the background is visible in the rendered image.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/04/2016 10:42 AM, ThH wrote:
> Messed up. Second try ...
>
> Am 04.03.2016 um 16:11 schrieb ThH:
>> scenes/objects/bezier.pov
>>
>> 8< snip >8
>> bicubic_patch { type 1 flatness 0.1 u_steps 8 v_steps 8
>> 8< snip >8
>>
>> I don't see a bicubic_patch 8[
>>
>> Any confirmations?
>>
>> --
>> Thorsten aka ThH
>
> ...any bicubic _patch...
>
> Only the background is visible in the rendered image.
Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
Ubuntu 14.04.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.03.2016 um 17:22 schrieb William F Pokorny:
> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
> 3.7.0-stable.
Thanks for your confirmation Bill :))
> Ubuntu 14.04.
Debian "Jessie" here ;) Used Ubuntu for a long time before changing to
Debian last december.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.03.2016 um 17:22 schrieb William F Pokorny:
> On 03/04/2016 10:42 AM, ThH wrote:
...
>> Am 04.03.2016 um 16:11 schrieb ThH:
>>> scenes/objects/bezier.pov
...
>>> I don't see a bicubic_patch 8[
>>>
>>> Any confirmations?
...
> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
> 3.7.0-stable.
>
> Ubuntu 14.04.
Want to take a guess what I see with the Windows version?
.
.
.
.
.
.
(Spoiler alert!)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Hey, it's an issue reported by ThH. _Of course_ it works perfectly fine
on Windows >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 04/03/2016 17:22, William F Pokorny a écrit :
> On 03/04/2016 10:42 AM, ThH wrote:
>> Messed up. Second try ...
>>
>> Am 04.03.2016 um 16:11 schrieb ThH:
>>> scenes/objects/bezier.pov
>>>
>>> 8< snip >8
>>> bicubic_patch { type 1 flatness 0.1 u_steps 8 v_steps 8
>>> 8< snip >8
>>>
>>> I don't see a bicubic_patch 8[
>>>
>>> Any confirmations?
>>>
>>> --
>>> Thorsten aka ThH
>>
>> ...any bicubic _patch...
>>
>> Only the background is visible in the rendered image.
>
> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
>
Testing 3.7.1-alpha.8503825.unofficial, the object is there, same as with stable
version.
(but with gcc and intel compiler, but not clang, my own master branch does have a
small problem of two squares on the patch that are gone, but that's another story)
Ubuntu 15.10
> Ubuntu 14.04.
>
> Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.03.2016 um 19:01 schrieb Le_Forgeron:
> Le 04/03/2016 17:22, William F Pokorny a écrit :
...
>> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
>
> Testing 3.7.1-alpha.8503825.unofficial, the object is there, same as with stable
version.
While I did my own testing with 3.7.1-alpha.8503825 as well, I'd be
quite surprised if any of the changes since alpha.8499454 had fixed it.
They appear to be as unrelated as I could possibly imagine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.03.2016 um 18:59 schrieb clipka:
> Hey, it's an issue reported by ThH. _Of course_ it works perfectly fine
> on Windows >_<
Haha :D
No reason for me to change the OS ;))
Just hoping it's your natural interest to get it fixed for Linux users :))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03/04/2016 01:22 PM, clipka wrote:
> Am 04.03.2016 um 19:01 schrieb Le_Forgeron:
>> Le 04/03/2016 17:22, William F Pokorny a écrit :
> ...
>>> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
>>
>> Testing 3.7.1-alpha.8503825.unofficial, the object is there, same as with stable
version.
>
> While I did my own testing with 3.7.1-alpha.8503825 as well, I'd be
> quite surprised if any of the changes since alpha.8499454 had fixed it.
> They appear to be as unrelated as I could possibly imagine.
>
Think you are correct. I just pulled and compiled 3.7.1-alpha.8503825 on
seeing Jérôme at a newer version, but still nothing (no ray patch
intersections are found). So maybe a 14.04 vs 15.1 difference ?
My compiler is g++ 4.8.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 04/03/2016 19:41, William F Pokorny a écrit :
> On 03/04/2016 01:22 PM, clipka wrote:
>> Am 04.03.2016 um 19:01 schrieb Le_Forgeron:
>>> Le 04/03/2016 17:22, William F Pokorny a écrit :
>> ...
>>>> Same here. The patch disappears in 3.7.1-alpha.8499454 while it works in
3.7.0-stable.
>>>
>>> Testing 3.7.1-alpha.8503825.unofficial, the object is there, same as with stable
version.
>>
>> While I did my own testing with 3.7.1-alpha.8503825 as well, I'd be
>> quite surprised if any of the changes since alpha.8499454 had fixed it.
>> They appear to be as unrelated as I could possibly imagine.
>>
> Think you are correct. I just pulled and compiled 3.7.1-alpha.8503825 on seeing
Jérôme at a newer version, but still nothing (no ray patch intersections are found).
So maybe a 14.04 vs 15.1 difference ?
>
> My compiler is g++ 4.8.
>
Nope, even with a produced "right" picture, valgrind reports a definitive problem of
uninitialised data.
Just ignore the syscall param write, the interesting parts seem to be in bezier.cpp
I presume even windows get the same problem if you have some auditing tools on it.
And using the same valgrind on the stable version: no such issue.
It's new, it's fresh, it's hidden and unreliable, due to the memory content.
Post a reply to this message
Attachments:
Download 'memcheck2.txt' (48 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.03.2016 um 19:25 schrieb ThH:
> Am 04.03.2016 um 18:59 schrieb clipka:
>
>> Hey, it's an issue reported by ThH. _Of course_ it works perfectly fine
>> on Windows >_<
>
> Haha :D
>
> No reason for me to change the OS ;))
>
> Just hoping it's your natural interest to get it fixed for Linux users :))
It is. But alas! ...
Well, you probably know the drill: Toy around and try to figure out
/some/ useful information.
@Jerome: Care to do some "binary search" again to narrow down the
offending version?
(Let me guess: It's that range of commits again that refuses to compile
on Linux, right?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.03.2016 um 19:51 schrieb Le_Forgeron:
> Le 04/03/2016 19:41, William F Pokorny a écrit :
> Nope, even with a produced "right" picture, valgrind reports a definitive problem of
uninitialised data.
If valgrind was right, that would certainly explain the problems.
Unfortunately it's mistaken.
Valgrind's report indicates that Bezier_Node_Struct::Radius_Squared is
not (or not always) initialized properly when
BicubicPatch::bezier_tree_walker() is called.
But if that is the case, then adding
Node->Radius_Squared = -1;
to BicubicPatch::create_new_bezier_node() and adding
POV_ASSERT(Node->Radius_Squared >= 0);
to the beginning of BicubicPatch::bezier_tree_walker() should force the
code to bomb.
It doesn't. Valgrind must be seeing ghosts.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.03.2016 um 08:54 schrieb clipka:
> Well, you probably know the drill: Toy around and try to figure out
> /some/ useful information.
SIR YESSSS SIR... Just had some other things to do... SIR !
8< snip >8
//bicubic_patch { type 1 flatness 0.1 u_steps 8 v_steps 8
bicubic_patch { type 0 flatness 0.1 u_steps 8 v_steps 8
8< snip >8
Line 1: no_image effect ;)
Line 2: 8D
SIR!
Time for breakfast here...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.03.2016 um 10:11 schrieb ThH:
> Am 05.03.2016 um 08:54 schrieb clipka:
>
>> Well, you probably know the drill: Toy around and try to figure out
>> /some/ useful information.
>
> SIR YESSSS SIR... Just had some other things to do... SIR !
SOLDIER, I don't remember having ordered you to do OTHER THINGS!
> 8< snip >8
> //bicubic_patch { type 1 flatness 0.1 u_steps 8 v_steps 8
> bicubic_patch { type 0 flatness 0.1 u_steps 8 v_steps 8
> 8< snip >8
>
> Line 1: no_image effect ;)
>
> Line 2: 8D
Does that mean "it works"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.03.2016 um 10:19 schrieb clipka:
> SOLDIER, I don't remember having ordered you to do OTHER THINGS!
Sir soldier used it's brain SIR !
>> Line 2: 8D
>
> Does that mean "it works"?
Yes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/03/2016 09:14, clipka a écrit :
> Am 04.03.2016 um 19:51 schrieb Le_Forgeron:
>> Le 04/03/2016 19:41, William F Pokorny a écrit :
>
>> Nope, even with a produced "right" picture, valgrind reports a definitive problem
of uninitialised data.
>
> If valgrind was right, that would certainly explain the problems.
> Unfortunately it's mistaken.
>
> Valgrind's report indicates that Bezier_Node_Struct::Radius_Squared is
> not (or not always) initialized properly when
> BicubicPatch::bezier_tree_walker() is called.
>
> But if that is the case, then adding
>
> Node->Radius_Squared = -1;
>
> to BicubicPatch::create_new_bezier_node() and adding
>
> POV_ASSERT(Node->Radius_Squared >= 0);
>
> to the beginning of BicubicPatch::bezier_tree_walker() should force the
> code to bomb.
>
> It doesn't. Valgrind must be seeing ghosts.
>
I do not say that the Radius_Squared is not initialized...
but adding
memset(Node, 0, sizeof(BEZIER_NODE));
in create_new_bezier_node does remove the issue with valgrind.
Now, remember that we are using -O3 as default level of optimisation,
which means the execution can be reported on line X while the compiler
is actually performing some operations of line X-1 or X+1.
And we are dealing with an hybride code: the declaration of Bezier_Node_Struct is a
100% C++ thing,
with an implicit constructor that would call Véctor3d constructor for Center,
yet create_new_bezier_node is a C thing, calling a memory allocator and casting the
type.
The other members of Bezier_Node_Struct are still C thing, so they are not
initialised.
Nevertheless, for Center, the code that computes it has been "optimised".
Instead of using a temporary variable, initialised to 0 (xc, yc, zc), to add the
various contributions
and then copying the result in Center at the end, the function now add directly the
various contributions
to Center. But what if... you start with *garbage* in Center ? Garbage in, Garbage
out.
(it's in bezier_bounding_sphere() )
And to finish it (give me a hammer, that's the last nail on the coffin):
If I replace the memset over the whole structure with just (in addition to Data_Ptr =
NULL):
Node->Center = Vector3d();
valgrind become as happy as with the full initialisation.
Even a bigger hammer: if I use memset with a value of 0xFF (instead of 0), I get a
100% background image.
Reliably.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> wrote:
> Even a bigger hammer: if I use memset with a value of 0xFF (instead of 0), I get a
100% background image.
> Reliably.
That did the trick.
Found the culprit and about to submit a fix any moment now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ThH <no.spam@address> wrote:
> I don't see a bicubic_patch 8[
Please test the newest master.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/03/2016 17:37, clipka a écrit :
> ThH <no.spam@address> wrote:
>> I don't see a bicubic_patch 8[
>
> Please test the newest master.
>
POV-Ray 3.7.1-alpha.8508492.unofficial seems ok, at least for valgrind (but I was only
getting small artefacts, randomly)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Good to be back on news.povray.org:119 !
Am 05.03.2016 um 17:37 schrieb clipka:
> Please test the newest master.
Bezier is fine now. Thanks clipka :))
--
Thorsten aka ThH
povray --V
POV-Ray 3.7.1-alpha.8508492.unofficial
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.03.2016 um 09:18 schrieb Le_Forgeron:
> Le 05/03/2016 17:37, clipka a écrit :
>> ThH <no.spam@address> wrote:
>>> I don't see a bicubic_patch 8[
>>
>> Please test the newest master.
>
> POV-Ray 3.7.1-alpha.8508492.unofficial seems ok, at least for valgrind (but I was
only getting small artefacts, randomly)
Does it also affect the Leak Summary?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.03.2016 um 09:20 schrieb ThH:
> Bezier is fine now. Thanks clipka :))
bezier.pov shows some artefacts.
flatness seems to have some influence on this. Lower flatness, less/no
artefacts.
Just to let you know ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 06/03/2016 09:25, clipka a écrit :
> Am 06.03.2016 um 09:18 schrieb Le_Forgeron:
>> Le 05/03/2016 17:37, clipka a écrit :
>>> ThH <no.spam@address> wrote:
>>>> I don't see a bicubic_patch 8[
>>>
>>> Please test the newest master.
>>
>> POV-Ray 3.7.1-alpha.8508492.unofficial seems ok, at least for valgrind (but I was
only getting small artefacts, randomly)
>
> Does it also affect the Leak Summary?
>
If you want more details about the leak, attached file was done with:
valgrind --log-file=memcheckpovray2.txt --track-origins=yes --leak-check=full dmpovray
bezier.pov
Post a reply to this message
Attachments:
Download 'memcheckpovray2.txt' (24 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.03.2016 um 09:32 schrieb ThH:
> bezier.pov shows some artefacts.
>
> flatness seems to have some influence on this. Lower flatness, less/no
> artefacts.
Thin lines?
They're normal, and the flatness parameter is indeed the setting to
counteract them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 06/03/2016 09:42, Le_Forgeron a écrit :
> Le 06/03/2016 09:25, clipka a écrit :
>> Am 06.03.2016 um 09:18 schrieb Le_Forgeron:
>>> Le 05/03/2016 17:37, clipka a écrit :
>>>> ThH <no.spam@address> wrote:
>>>>> I don't see a bicubic_patch 8[
>>>>
>>>> Please test the newest master.
>>>
>>> POV-Ray 3.7.1-alpha.8508492.unofficial seems ok, at least for valgrind (but I was
only getting small artefacts, randomly)
>>
>> Does it also affect the Leak Summary?
>>
> If you want more details about the leak, attached file was done with:
>
> valgrind --log-file=memcheckpovray2.txt --track-origins=yes --leak-check=full
dmpovray bezier.pov
>
And to compare with the stable head, another attached file.
It was less leaking before :-)
Post a reply to this message
Attachments:
Download 'memcheckpovray.txt' (6 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.03.2016 um 09:46 schrieb clipka:
> Thin lines?
Yes.
> They're normal, and the flatness parameter is indeed the setting to
> counteract them.
Looked up the docs. That's why I tried this ;)
To be honest... I've never used bicubic_patch before.
For me the image is fine :)
The 'rest' is yours.
Only citing valgrind here: Go fix your program! ;))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
