Folks,

I have a special development version that needs exhaustive testing of
complex textures, so if you have a scene that uses wild combinations of
the following features (and you happen to be using Unix), it would be
greatly appreciated if you could give it a shot:

- patterned textures
- material_map
- layered textures
- overriding the texture of objects
- non-canonical syntax to define textures (e.g specifying `pigment`
directly on an object)
- any other texture-related stuff you can think of

The version in question can be found here:

  https://github.com/c-lipka/povray/tree/refactor/texture

(source code only at this time)

Also, I expect more follow-up versions to be coming, so I might ask you
to re-test with the same scenes later.

Post a reply to this message

On 10-8-2016 1:55, clipka wrote:
> Folks,
>
> I have a special development version that needs exhaustive testing of
> complex textures, so if you have a scene that uses wild combinations of
> the following features (and you happen to be using Unix), it would be
> greatly appreciated if you could give it a shot:
>

Only using Unix? No Windows?

-- 
Thomas

Post a reply to this message

Am 10.08.2016 um 08:47 schrieb Thomas de Groot:
> On 10-8-2016 1:55, clipka wrote:
>> Folks,
>>
>> I have a special development version that needs exhaustive testing of
>> complex textures, so if you have a scene that uses wild combinations of
>> the following features (and you happen to be using Unix), it would be
>> greatly appreciated if you could give it a shot:
>>
> 
> Only using Unix? No Windows?

If you're willing and able to build your own Windows binaries from the
sources, be my guest.

Post a reply to this message

On 10-8-2016 9:06, clipka wrote:
> Am 10.08.2016 um 08:47 schrieb Thomas de Groot:
>> On 10-8-2016 1:55, clipka wrote:
>>> Folks,
>>>
>>> I have a special development version that needs exhaustive testing of
>>> complex textures, so if you have a scene that uses wild combinations of
>>> the following features (and you happen to be using Unix), it would be
>>> greatly appreciated if you could give it a shot:
>>>
>>
>> Only using Unix? No Windows?
>
> If you're willing and able to build your own Windows binaries from the
> sources, be my guest.
>

That is far beyond my capacity and knowledge :-)

-- 
Thomas

Post a reply to this message

El 10/08/16 a las 01:55, clipka escribió:
> Folks,
>
> I have a special development version that needs exhaustive testing
> of complex textures, so if you have a scene that uses wild
> combinations of the following features (and you happen to be using
> Unix), it would be greatly appreciated if you could give it a shot:
>
> - patterned textures - material_map - layered textures - overriding
> the texture of objects - non-canonical syntax to define textures (e.g
> specifying `pigment` directly on an object) - any other
> texture-related stuff you can think of
>

   Ok, did compile fine. Testing without radiosity, results seem
identical to master on a first test: texture map using two layered
textures. What should we be looking at? Parse/render times? Differences
in output? Anything else?

--
jaime

Post a reply to this message

Am 10.08.2016 um 12:23 schrieb Jaime Vives Piqueres:

>   Ok, did compile fine. Testing without radiosity, results seem
> identical to master on a first test: texture map using two layered
> textures. What should we be looking at? Parse/render times? Differences
> in output? Anything else?

I'm mainly concerned about unexpected parse errors, crashes, or
differences in output.

(Absence of /expected/ parse errors would also be of concern, but would
obviously require dedicated test scenes.)

If you happen to notice anything suspicious about performance (parse
times, render times or memory consumption), of course I'd like to hear
about that as well, but I don't expect much of a difference there.

Post a reply to this message

El 10/08/16 a las 18:02, clipka escribió:
> I'm mainly concerned about unexpected parse errors, crashes, or
> differences in output.

   Seems all is fine: no errors or crashes, and always identical output.
I tried a bunch of old scenes of mine, mostly with layered textures,
texture maps and some material maps.

   Just out of curiosity... what was the reason for the refactoring?
Performance? Laying bed for future improvements/features?

--
jaime

Post a reply to this message

Am 10.08.2016 um 20:32 schrieb Jaime Vives Piqueres:
> El 10/08/16 a las 18:02, clipka escribió:
>> I'm mainly concerned about unexpected parse errors, crashes, or
>> differences in output.
> 
>   Seems all is fine: no errors or crashes, and always identical output.
> I tried a bunch of old scenes of mine, mostly with layered textures,
> texture maps and some material maps.
> 
>   Just out of curiosity... what was the reason for the refactoring?
> Performance? Laying bed for future improvements/features?

Something along the lines of the latter. The internal data structures
for textures are a Crappy Complicated Clusterfuck(TM), which I'm
currently untangling to get a clear picture of how it even works.

Post a reply to this message

Le 10/08/2016 à 21:58, clipka a écrit :
> Am 10.08.2016 um 20:32 schrieb Jaime Vives Piqueres:
>> El 10/08/16 a las 18:02, clipka escribió:
>>> I'm mainly concerned about unexpected parse errors, crashes, or
>>> differences in output.
>>
>>   Seems all is fine: no errors or crashes, and always identical output.
>> I tried a bunch of old scenes of mine, mostly with layered textures,
>> texture maps and some material maps.
>>
>>   Just out of curiosity... what was the reason for the refactoring?
>> Performance? Laying bed for future improvements/features?
>
> Something along the lines of the latter. The internal data structures
> for textures are a Crappy Complicated Clusterfuck(TM), which I'm
> currently untangling to get a clear picture of how it even works.
>

If it can help, I modeled that back in 2005.

It is unlikely to have changed, but yes, it could be simplified (if you 
considers layering textures as a pattern, and you could also get ride of 
the texture at the storage level, the same way material is only a SDL 
container)

At that time I even considered a model for interior_texture for 
different pigment & finish according to the side, but it seems I missed 
a different normal per side.

Post a reply to this message

Attachments:
Download 'texture.png' (29 KB)

Preview of image 'texture.png'

Am 11.08.2016 um 07:48 schrieb Le_Forgeron:

>> Something along the lines of the latter. The internal data structures
>> for textures are a Crappy Complicated Clusterfuck(TM), which I'm
>> currently untangling to get a clear picture of how it even works.
> 
> If it can help, I modeled that back in 2005.
> 
> It is unlikely to have changed,

Not bad; and it does indeed still reflect the status quo -- though this
implies that it describes the picture at a very abstract level (which in
this case is a good thing), since I've already changed quite a lot of
details since 2005, especially in the pattern department ;)

Also, you clearly missed (or decided not to show separately) the
`material_map` mechanism. Which is effectively a patterned texture, but
for obscure reasons (probably plain legacy) uses its own data fields.

Well, it /used/ its own data fields, I should say :)


> but yes, it could be simplified (if you
> considers layering textures as a pattern, and you could also get ride of
> the texture at the storage level, the same way material is only a SDL
> container)

No, no -- that's not at all what I'm after. My goal is to make the
hierarchy more obvious, not eliminate it. Most notably, the box you
labelled `plain_texture` is now implemented as a dedicated
`TextureLayer` class.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Folks,
>
> I have a special development version that needs exhaustive testing of
> complex textures, so if you have a scene that uses wild combinations of
> the following features (and you happen to be using Unix), it would be
> greatly appreciated if you could give it a shot:
>
> - patterned textures
> - material_map
> - layered textures
> - overriding the texture of objects
> - non-canonical syntax to define textures (e.g specifying `pigment`
> directly on an object)
> - any other texture-related stuff you can think of
>
> The version in question can be found here:
>
>   https://github.com/c-lipka/povray/tree/refactor/texture
>
> (source code only at this time)
>
> Also, I expect more follow-up versions to be coming, so I might ask you
> to re-test with the same scenes later.

There is one test file I use for quick regression tests in the wiki:
http://wiki.blender.org/index.php/Dev:2.6/Py/Scripts/Render/POV-Ray#Test_files:

direct link to file :
https://wiki.blender.org/uploads/1/14/Regression_and_test_blendfiles.zip

it's in the TexturesTest folder once unzipped.
Using Blender Pov Exporter exports a complex setup with the "finish map"  trick
for specular map , uses an alpha, normal map and diffuse. But no material_map if
i remember correctly.

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Folks,
> >
> > I have a special development version that needs exhaustive testing of
> > complex textures, so if you have a scene that uses wild combinations of
> > the following features (and you happen to be using Unix), it would be
> > greatly appreciated if you could give it a shot:
> >
> > - patterned textures
> > - material_map
> > - layered textures
> > - overriding the texture of objects
> > - non-canonical syntax to define textures (e.g specifying `pigment`
> > directly on an object)
> > - any other texture-related stuff you can think of
> >
> > The version in question can be found here:
> >
> >   https://github.com/c-lipka/povray/tree/refactor/texture
> >
> > (source code only at this time)
> >
> > Also, I expect more follow-up versions to be coming, so I might ask you
> > to re-test with the same scenes later.
>
> There is one test file I use for quick regression tests in the wiki:
> http://wiki.blender.org/index.php/Dev:2.6/Py/Scripts/Render/POV-Ray#Test_files:
>
> direct link to file :
> https://wiki.blender.org/uploads/1/14/Regression_and_test_blendfiles.zip
>
> it's in the TexturesTest folder once unzipped.
> Using Blender Pov Exporter exports a complex setup with the "finish map"  trick
> for specular map , uses an alpha, normal map and diffuse. But no material_map if
> i remember correctly.

I forgot to mention that I'm on windows without a building setup.

Post a reply to this message

to clipka:
Over the weekend, I'll check.
My system allows nodes make the most insane texture

Post a reply to this message

"LanuHum" <Lan### [at] yandexru> wrote:
> to clipka:
> Over the weekend, I'll check.
> My system allows nodes make the most insane texture


Look BlendPov-alternative: screenshots

Post a reply to this message

Am 12.08.2016 um 17:30 schrieb LanuHum:
> "LanuHum" <Lan### [at] yandexru> wrote:
>> to clipka:
>> Over the weekend, I'll check.
>> My system allows nodes make the most insane texture
> 
> 
> Look BlendPov-alternative: screenshots

Thanks!
Did you compare the results of the development version with those of
POV-Ray 3.7.0?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Thanks!
> Did you compare the results of the development version with those of
> POV-Ray 3.7.0?

If you expect the time difference, then it does not exist.
Povray-3.7.0:
first test: 53 sec
second test: 49 sec

Povray-dev:
50 sec (screenshot)
second test: 52 sec

Post a reply to this message

Am 12.08.2016 um 18:30 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>>
>> Thanks!
>> Did you compare the results of the development version with those of
>> POV-Ray 3.7.0?
> 
> If you expect the time difference, then it does not exist.

No, I was refering to the render output: Are the resulting images the same?

If not, that would be bad news.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.08.2016 um 18:30 schrieb LanuHum:
> > clipka <ano### [at] anonymousorg> wrote:
> >>
> >> Thanks!
> >> Did you compare the results of the development version with those of
> >> POV-Ray 3.7.0?
> >
> > If you expect the time difference, then it does not exist.
>
> No, I was refering to the render output: Are the resulting images the same?
>
> If not, that would be bad news.

I posted a result for comparison.
In my opinion, there is no difference.

Post a reply to this message

On 08/09/2016 07:55 PM, clipka wrote:
> Folks,
>
> I have a special development version that needs exhaustive testing of
> complex textures, so if you have a scene that uses wild combinations of
> the following features (and you happen to be using Unix), it would be
> greatly appreciated if you could give it a shot:
>
> - patterned textures
> - material_map
> - layered textures
> - overriding the texture of objects
> - non-canonical syntax to define textures (e.g specifying `pigment`
> directly on an object)
> - any other texture-related stuff you can think of
>
> The version in question can be found here:
>
>   https://github.com/c-lipka/povray/tree/refactor/texture
>
> (source code only at this time)
>
> Also, I expect more follow-up versions to be coming, so I might ask you
> to re-test with the same scenes later.
>
A material mapped from Norbert Kern's collection and run against:

---
A - POV-Ray 3.7.0.unofficial

B - POV-Ray 3.7.1-alpha.8764097.unofficial (current 3.7.1)

C - POV-Ray 3.7.1-alpha.8738139.unofficial (refactor/texture)

Is showing differences in all three when run with radiosity. See the 
attached image where A, B and C shown left to right.

If run without radiosity A & C match well, but our current 3.7.1 is 
still different.

If run without radiosity and finish statements A, B & C match well, so 
something is different in finish {} with our current 3.7.1.

Unsure what might be expected and not. Where would you like to go from 
here?

Bill P.

Post a reply to this message

Attachments:
Download 'nk0065compare.png' (190 KB)

Preview of image 'nk0065compare.png'

On 08/31/2016 10:12 AM, William F Pokorny wrote:
> On 08/09/2016 07:55 PM, clipka wrote:
>
> Bill P.

Having looked at more results I have seen nothing which dies outright as 
yet. About a third run so far have little change across the three 
versions. The rest do and I'd say mostly in the shadows. There is I see 
a new shadow cache message out of the refactored code.

Another with somewhat significant differences is attached.

Bill P.

Post a reply to this message

Attachments:
Download 'nk0008compare.png' (244 KB)

Preview of image 'nk0008compare.png'

Am 31.08.2016 um 17:52 schrieb William F Pokorny:
> On 08/31/2016 10:12 AM, William F Pokorny wrote:
>> On 08/09/2016 07:55 PM, clipka wrote:
>>
>> Bill P.
> 
> Having looked at more results I have seen nothing which dies outright as
> yet. About a third run so far have little change across the three
> versions. The rest do and I'd say mostly in the shadows. There is I see
> a new shadow cache message out of the refactored code.

What do you mean by that last sentence? Do you mean there's a new
warning during compilation or some such?

Since shadow cache handling happens in `source/core/render/trace.cpp`,
I've had a cursory glance over the differences between the two branches,
but didn't notice anything obvious related to the shadow cache.

Can you name the exact location where you "see a new shadow cache
message", and what that message actually is?

Post a reply to this message

Am 31.08.2016 um 16:12 schrieb William F Pokorny:

> A - POV-Ray 3.7.0.unofficial
> 
> B - POV-Ray 3.7.1-alpha.8764097.unofficial (current 3.7.1)
> 
> C - POV-Ray 3.7.1-alpha.8738139.unofficial (refactor/texture)
> 
> Is showing differences in all three when run with radiosity. See the
> attached image where A, B and C shown left to right.
> 
> If run without radiosity A & C match well, but our current 3.7.1 is
> still different.
> 
> If run without radiosity and finish statements A, B & C match well, so
> something is different in finish {} with our current 3.7.1.
> 
> Unsure what might be expected and not. Where would you like to go from
> here?

Just to make sure -- you're saying that the version to be tested (the
refactor/texture one) matches good old 3.7.0, while the current version
that you used as reference shows differences?

My first instinct would be "duh! accidently fixed something along the
way!" But that might be misleading, as I might have instead accidently
removed a fix for something that was broken in 3.7.0.

The first thing I would like you to do is let me know the details of the
finish you were using. I presume this is not just an empty `finish{}`
block, right?

Post a reply to this message

On 08/31/2016 01:03 PM, clipka wrote:
> Am 31.08.2016 um 17:52 schrieb William F Pokorny:
>> On 08/31/2016 10:12 AM, William F Pokorny wrote:
>>> On 08/09/2016 07:55 PM, clipka wrote:
>>>
>>> Bill P.
>>
>> Having looked at more results I have seen nothing which dies outright as
>> yet. About a third run so far have little change across the three
>> versions. The rest do and I'd say mostly in the shadows. There is I see
>> a new shadow cache message out of the refactored code.
>
> What do you mean by that last sentence? Do you mean there's a new
> warning during compilation or some such?
>
> Since shadow cache handling happens in `source/core/render/trace.cpp`,
> I've had a cursory glance over the differences between the two branches,
> but didn't notice anything obvious related to the shadow cache.
>
> Can you name the exact location where you "see a new shadow cache
> message", and what that message actually is?
>

In the re-factored code I see the new message just below the usual 
shadow ray test message as in:

Shadow Ray Tests:            345087   Succeeded:                 33718
Shadow Cache Hits:            31372

The 3.7.0 and current 3.7.1 has just:

Shadow Ray Tests:            422995   Succeeded:                 66614

and

Shadow Ray Tests:            410766   Succeeded:                 66001

respectively.

I've run a good bit more and I now wondering if some of the differences 
in shadows are not tangled in the normal handling. Really smooth 
results, as for example with Jaime's car paint materials, show no 
differences.

Bill P.

Post a reply to this message

On 08/31/2016 01:16 PM, clipka wrote:
> Am 31.08.2016 um 16:12 schrieb William F Pokorny:
>
>> A - POV-Ray 3.7.0.unofficial
>>
>> B - POV-Ray 3.7.1-alpha.8764097.unofficial (current 3.7.1)
>>
>> C - POV-Ray 3.7.1-alpha.8738139.unofficial (refactor/texture)
>>
>> Is showing differences in all three when run with radiosity. See the
>> attached image where A, B and C shown left to right.
>>
>> If run without radiosity A & C match well, but our current 3.7.1 is
>> still different.
>>
>> If run without radiosity and finish statements A, B & C match well, so
>> something is different in finish {} with our current 3.7.1.
>>
>> Unsure what might be expected and not. Where would you like to go from
>> here?
>
> Just to make sure -- you're saying that the version to be tested (the
> refactor/texture one) matches good old 3.7.0, while the current version
> that you used as reference shows differences?

Only with radiosity off does the re-factored code match 3.7.0 - 
otherwise none of the three match exactly.

>
> My first instinct would be "duh! accidently fixed something along the
> way!" But that might be misleading, as I might have instead accidently
> removed a fix for something that was broken in 3.7.0.
>
> The first thing I would like you to do is let me know the details of the
> finish you were using. I presume this is not just an empty `finish{}`
> block, right?
>

No it is not empty. I'll dig more to try and figure out which finish 
statement(s) cause the difference & report back.

For the moment I am still working through the collection of materials I 
have just see if they all work & what the differences are. Still the 
case I've hit nothing that dies outright.

I'm also not sure if the aim is to always exactly match 3.7.0? In the 
case of media for example, we know we don't match 3.7.0 to 3.7.1, but we 
are happier with the 3.7.1 result.

Bill P.

Post a reply to this message

Am 31.08.2016 um 21:07 schrieb William F Pokorny:
> On 08/31/2016 01:16 PM, clipka wrote:
>> Am 31.08.2016 um 16:12 schrieb William F Pokorny:
>>
>>> A - POV-Ray 3.7.0.unofficial
>>>
>>> B - POV-Ray 3.7.1-alpha.8764097.unofficial (current 3.7.1)
>>>
>>> C - POV-Ray 3.7.1-alpha.8738139.unofficial (refactor/texture)
>>>
>>> Is showing differences in all three when run with radiosity. See the
>>> attached image where A, B and C shown left to right.
>>>
>>> If run without radiosity A & C match well, but our current 3.7.1 is
>>> still different.
>>>
>>> If run without radiosity and finish statements A, B & C match well, so
>>> something is different in finish {} with our current 3.7.1.
>>>
>>> Unsure what might be expected and not. Where would you like to go from
>>> here?
>>
>> Just to make sure -- you're saying that the version to be tested (the
>> refactor/texture one) matches good old 3.7.0, while the current version
>> that you used as reference shows differences?
> 
> Only with radiosity off does the re-factored code match 3.7.0 -
> otherwise none of the three match exactly.

That is to be expected, unless you choose particularly high-quality
settings.

You can also increase the chances of identical results by using the
`+HR` command-line switch.

> I'm also not sure if the aim is to always exactly match 3.7.0? In the
> case of media for example, we know we don't match 3.7.0 to 3.7.1, but we
> are happier with the 3.7.1 result.

Yes, but there's a reason why we threw backward compatibility overboard
(to some degree) and changed the media code: The old implementation had
a bug, and computed demonstrably wrong results for low quality settings.
The implementation obviously failed to match the intention.

There is no reason (or at least none that I'm currently aware of) to
think that there is a similar problem with the 3.7.0 finish
computations. One might debate whether the shading models chosen by the
original developers are a good choice (spoiler alert: I think they are
reasonably good, except for the "brilliance" parameter), but their
implementation seems to be correct. The implementation does seem to
match the intention.

Post a reply to this message

On 08/31/2016 03:53 PM, clipka wrote:
>> Only with radiosity off does the re-factored code match 3.7.0 -
>>otherwise none of the three match exactly.
 >
> That is to be expected, unless you choose particularly high-quality
> settings.
>
> You can also increase the chances of identical results by using the
> `+HR` command-line switch.
>

Sorry for my use of the word 'exactly.' Ignoring for the moment our 
current 3.7.1 code, I believe there is a systemic difference in 
radiosity results between 3.7.0 and the 3.7.1-re-factored texture code.

In the attached image the first row is the original NK0065, the second a 
very simple white texture. Both run with decent radiosity settings, on 
one thread and with +HR. The left result is 3.7.0, the middle the 
re-factored code and the right is the absolute difference between results.

The bottom or third row is the same NK0065 texture run twice with the 
re-factored code. The left image is with 4 threads and the right with 8 
threads to exaggerate the run to run radiosity noise I "think" you have 
in mind.

Not shown, but if I run the third row with one thread and +HR, I get no 
difference in result run to run.

Aside: To really see the difference images well the gamma might need to 
be tweaked as you view it.

Bill P.

Post a reply to this message

Attachments:
Download 'thinkraddiffsystemic.png' (443 KB)

Preview of image 'thinkraddiffsystemic.png'

Am 31.08.2016 um 23:48 schrieb William F Pokorny:
> On 08/31/2016 03:53 PM, clipka wrote:
>>> Only with radiosity off does the re-factored code match 3.7.0 -
>>> otherwise none of the three match exactly.
>>
>> That is to be expected, unless you choose particularly high-quality
>> settings.
>>
>> You can also increase the chances of identical results by using the
>> `+HR` command-line switch.
>>
> 
> Sorry for my use of the word 'exactly.' Ignoring for the moment our
> current 3.7.1 code, I believe there is a systemic difference in
> radiosity results between 3.7.0 and the 3.7.1-re-factored texture code.

I can't ignore our current 3.7.1 code in this context, because that's my
reference for whether the refactoring broke anything. It is the nature
of refactoring that it shouldn't change the behaviour of the program. (*)

The differences I'm really interested in are:

(1) Differences between the refactored code and its closest
non-refactored sibling (**), as they would indicate that I broke
something during refactoring; and

(2) Differences between 3.7.0 and any later version of the master
branch, as they may indicate that I broke something outside the
refactored branch.

Differences between the refactored code and 3.7.0 are of little
importance to me, except as an indicator that there must also be
differences in categories (1) or (2).

In case of (1), I know I need to fix the refactored branch; in case of
(2), I know I need to fix the main branch (and merge the fix into the
refactored branch); but in case of the third kind I'm left clueless.


(* I must confess though that I tend to mix in the occasional fix for
bugs I discover during refactoring, especially if the refactoring turns
out to be the bug's "natural enemy".)

(** Ideally that would be 3.7.1-alpha.8737949 aka commit 4d52c26, dated
2016-08-12, but the closest tagged version, 3.7.1-alpha.8737777, should
be good enough for any scenes that make no use of `no_image` and its
kin; 3.7.1-alpha.8764097, the version you're using for testing, is
actually non-ideal.)

Post a reply to this message

On 08/31/2016 11:03 PM, clipka wrote:
>>
>> Sorry for my use of the word 'exactly.' Ignoring for the moment our
>> current 3.7.1 code, I believe there is a systemic difference in
>> radiosity results between 3.7.0 and the 3.7.1-re-factored texture code.
>
> I can't ignore our current 3.7.1 code in this context, because that's my
> reference for whether the refactoring broke anything. It is the nature
> of refactoring that it shouldn't change the behaviour of the program. (*)
>
> The differences I'm really interested in are:
>
> (1) Differences between the refactored code and its closest
> non-refactored sibling (**), as they would indicate that I broke
> something during refactoring; and
>
> (2) Differences between 3.7.0 and any later version of the master
> branch, as they may indicate that I broke something outside the
> refactored branch.
>
> Differences between the refactored code and 3.7.0 are of little
> importance to me, except as an indicator that there must also be
> differences in categories (1) or (2).
>
> In case of (1), I know I need to fix the refactored branch; in case of
> (2), I know I need to fix the main branch (and merge the fix into the
> refactored branch); but in case of the third kind I'm left clueless.
>
>
> (* I must confess though that I tend to mix in the occasional fix for
> bugs I discover during refactoring, especially if the refactoring turns
> out to be the bug's "natural enemy".)
>
> (** Ideally that would be 3.7.1-alpha.8737949 aka commit 4d52c26, dated
> 2016-08-12, but the closest tagged version, 3.7.1-alpha.8737777, should
> be good enough for any scenes that make no use of `no_image` and its
> kin; 3.7.1-alpha.8764097, the version you're using for testing, is
> actually non-ideal.)
>

OK. The 3.7.0 -> 3.7.1 radiosity differences - and it turns out small 
shifts in shadow edges without radiosity that I didn't see until 
rendering larger images - are mostly (perhaps all?) attributable to:

c891131 - Fixed two mesh camera bugs and other camera flaws.

which itself introduced an AA/shift issue until:

3c07635 - Fix GitHub issue #63.

As such I think we should just ignore related differences as we 
certainly want those camera fixes.

------------
I've moved to 3.7.1-alpha.8737949 for the 3.7.1 baseline.

Let me see if I can run down the finish difference today.

Any idea yet why we are getting the new shadow cache message in the 
re-factored code and the largish differences in shadow ray counts?

I turned up other results differing quite a bit across versions, but 
I'll need to re-run those I guess with the new 3.7.1 baseline for starters.

Bill P.

Post a reply to this message

On 09/01/2016 08:53 AM, William F Pokorny wrote:
>
> OK. The 3.7.0 -> 3.7.1 radiosity differences - and it turns out small
> shifts in shadow edges without radiosity that I didn't see until
> rendering larger images - are mostly (perhaps all?) attributable to:
>
> c891131 - Fixed two mesh camera bugs and other camera flaws.
>
> which itself introduced an AA/shift issue until:
>
> 3c07635 - Fix GitHub issue #63.
>
> As such I think we should just ignore related differences as we
> certainly want those camera fixes.
>

Forget the shadow edges difference - these are isosurface artifacts 
introduced in between c891131 and 3c07635. Fixed in :

0889275 - Fix isosurface bug introduced with commit a10629b.

Bill P.

Post a reply to this message

On 09/01/2016 08:53 AM, William F Pokorny wrote:
> On 08/31/2016 11:03 PM, clipka wrote:
> ------------
> I've moved to 3.7.1-alpha.8737949 for the 3.7.1 baseline.
>
> Let me see if I can run down the finish difference today.
>

The finish difference seen between 3.7.1-alpha.8737949 and 
(refactor/texture) seems to be related to having a brilliance value > 1.0.

I think this probably the cause for a great many of the other 
differences I have seen. I'm going to hold off further testing until 
there is a fix for this in the (refactor/texture) branch.

Scene file is attached.

Bill P.

Post a reply to this message

Attachments:
Download 'nk0065__c.pov.txt' (5 KB)

Am 01.09.2016 um 14:53 schrieb William F Pokorny:

> Any idea yet why we are getting the new shadow cache message in the
> re-factored code and the largish differences in shadow ray counts?

Not yet; but maybe they are somehow related.

Post a reply to this message

On 09/01/2016 09:34 AM, William F Pokorny wrote:
> On 09/01/2016 08:53 AM, William F Pokorny wrote:
>> On 08/31/2016 11:03 PM, clipka wrote:
>> ------------
>> I've moved to 3.7.1-alpha.8737949 for the 3.7.1 baseline.
>>
>> Let me see if I can run down the finish difference today.
>>
>
> The finish difference seen between 3.7.1-alpha.8737949 and
> (refactor/texture) seems to be related to having a brilliance value > 1.0.
>
> I think this probably the cause for a great many of the other
> differences I have seen. I'm going to hold off further testing until
> there is a fix for this in the (refactor/texture) branch.
>
> Scene file is attached.
>
> Bill P.

FYI - I was able to track the change in brilliance > 1 behavior all the 
way back to commit :

54b283a - Improved finish features for more realism:

of July 23, 2014!

Good news is I believe refactor/texture has it right.

Bill P.

Post a reply to this message

Am 01.09.2016 um 16:46 schrieb William F Pokorny:

> FYI - I was able to track the change in brilliance > 1 behavior all the
> way back to commit :
> 
> 54b283a - Improved finish features for more realism:
> 
> of July 23, 2014!
> 
> Good news is I believe refactor/texture has it right.

That commit shouldn't have changed a thing for existing scenes; all the
added features should require extra keywords to enable: Radiosity
support for brilliance, for instance, should require `brilliance on` in
the radiosity block.


BTW, with all the updates you have sent, I notice that I'm losing track
of which differences in output you've noticed between our "cornerstone"
versions (official 3.7.0, feature/texture branch, and recent master
branch), what features you have found to be involved in those
differences, and what you have already managed to dig up about the exact
commit that changed the behaviour. If you could give me a summary, that
would be highly welcome.

(Sorry if I'm pestering you with this; I want you to know that your
research into this matter is very much appreciated.)

Post a reply to this message

On 09/01/2016 11:52 AM, clipka wrote:
> Am 01.09.2016 um 16:46 schrieb William F Pokorny:
>
>> FYI - I was able to track the change in brilliance > 1 behavior all the
>> way back to commit :
>>
>> 54b283a - Improved finish features for more realism:
>>
>> of July 23, 2014!
>>
>> Good news is I believe refactor/texture has it right.
>
> That commit shouldn't have changed a thing for existing scenes; all the
> added features should require extra keywords to enable: Radiosity
> support for brilliance, for instance, should require `brilliance on` in
> the radiosity block.
>
>
> BTW, with all the updates you have sent, I notice that I'm losing track
> of which differences in output you've noticed between our "cornerstone"
> versions (official 3.7.0, feature/texture branch, and recent master
> branch), what features you have found to be involved in those
> differences, and what you have already managed to dig up about the exact
> commit that changed the behaviour. If you could give me a summary, that
> would be highly welcome.
>
> (Sorry if I'm pestering you with this; I want you to know that your
> research into this matter is very much appreciated.)
>
In summary:

With radiosity on, there are smallish radiosity differences between 
3.7.0-stable and any 3.7.1 version on or after commit c891131. At the 
moment I think these are ignorable as the cost of that fix.

With radiosity off, finish statements with brilliance>1.0 are 
different/dimmer in 3.7.1 versions other than your latest 
3.7.1-alpha.8738139 (refactor/texture). This change in behavior happened 
with commit 54b283a as the commit prior (9b10411) matches 3.7.0-stable. 
The scene file elsewhere attached to this thread can be used to 
reproduce this result - though note you'll have to set the version to 
3.7 as both commits came before the change to 3.7.1.

I am running on on Ubuntu 16.04.

Bill

Post a reply to this message

Am 01.09.2016 um 18:28 schrieb William F Pokorny:

> In summary:
> 
> With radiosity on, there are smallish radiosity differences between
> 3.7.0-stable and any 3.7.1 version on or after commit c891131. At the
> moment I think these are ignorable as the cost of that fix.

Hm... they might be due to the fix affecting the positions of the
radiosity samples gathered during pretrace. But I'm not entirely
satisfied about this yet.

> With radiosity off, finish statements with brilliance>1.0 are
> different/dimmer in 3.7.1 versions other than your latest
> 3.7.1-alpha.8738139 (refactor/texture). This change in behavior happened
> with commit 54b283a as the commit prior (9b10411) matches 3.7.0-stable.
> The scene file elsewhere attached to this thread can be used to
> reproduce this result - though note you'll have to set the version to
> 3.7 as both commits came before the change to 3.7.1.

If that is so, then the conclusion I'd draw is that I probably messed up
something in 54b283a when introducing the advanced finish features, and
fixed it during texture refactoring without realizing and/or remembering it.

Post a reply to this message

On 09/01/2016 12:43 PM, clipka wrote:
> Am 01.09.2016 um 18:28 schrieb William F Pokorny:
>
>> In summary:
>>
>> With radiosity on, there are smallish radiosity differences between
>> 3.7.0-stable and any 3.7.1 version on or after commit c891131. At the
>> moment I think these are ignorable as the cost of that fix.
>
> Hm... they might be due to the fix affecting the positions of the
> radiosity samples gathered during pretrace. But I'm not entirely
> satisfied about this yet.
>

I am not myself sure it explains all of what I see with radiosity, but I 
believe that commit at least a partly the cause.

>> With radiosity off, finish statements with brilliance>1.0 are
>> different/dimmer in 3.7.1 versions other than your latest
>> 3.7.1-alpha.8738139 (refactor/texture). This change in behavior happened
>> with commit 54b283a as the commit prior (9b10411) matches 3.7.0-stable.
>> The scene file elsewhere attached to this thread can be used to
>> reproduce this result - though note you'll have to set the version to
>> 3.7 as both commits came before the change to 3.7.1.
>
> If that is so, then the conclusion I'd draw is that I probably messed up
> something in 54b283a when introducing the advanced finish features, and
> fixed it during texture refactoring without realizing and/or remembering it.
>

FYI. I've done some additional spot checking of cases where results were 
changing. With these, I turned off radiosity and edited materials so 
brillance was never more than 1.0. At least in the handful checked this 
way, 3.7.0 -> 3.7.1 -> refactor/texture results compare well.

Bill P.

Post a reply to this message

The texture refactoring has progressed some more; in addition to the
features mentioned earlier, testing would be welcome for:

- Finish properties: Nothing should have changed here.

- Smooth meshes and other objects that "fake" a smooth surface: The
handling of surface normals /has/ changed, and should be more
well-behaved; most notably I should have gotten rid of the
interior_texture-on-outside artifacts!

Again, a source code-only version can be found here:

    https://github.com/c-lipka/povray/tree/refactor/texture


Am 10.08.2016 um 01:55 schrieb clipka:
> Folks,
> 
> I have a special development version that needs exhaustive testing of
> complex textures, so if you have a scene that uses wild combinations of
> the following features (and you happen to be using Unix), it would be
> greatly appreciated if you could give it a shot:
> 
> - patterned textures
> - material_map
> - layered textures
> - overriding the texture of objects
> - non-canonical syntax to define textures (e.g specifying `pigment`
> directly on an object)
> - any other texture-related stuff you can think of
> 
> The version in question can be found here:
> 
>   https://github.com/c-lipka/povray/tree/refactor/texture
> 
> (source code only at this time)
> 
> Also, I expect more follow-up versions to be coming, so I might ask you
> to re-test with the same scenes later.
>

Post a reply to this message

On 09/05/2016 08:33 AM, clipka wrote:
> The texture refactoring has progressed some more; in addition to the
> features mentioned earlier, testing would be welcome for:
>
> - Finish properties: Nothing should have changed here.
>
> - Smooth meshes and other objects that "fake" a smooth surface: The
> handling of surface normals /has/ changed, and should be more
> well-behaved; most notably I should have gotten rid of the
> interior_texture-on-outside artifacts!
>
> Again, a source code-only version can be found here:
>
>     https://github.com/c-lipka/povray/tree/refactor/texture
>
>
> Am 10.08.2016 um 01:55 schrieb clipka:
>
The latest refactor/texture showing no differences on my non-mesh test 
cases in some spot checking to the previous version.

I also wanted to flesh out the brilliance & radiosity differences story.

Where A-F represents the following POV-Ray versions:

A -> povray 3.7.0 stable

B -> 167ed19. Commit prior to c891131 Fixed two mesh camera bugs and 
other camera flaws.

C -> 3c07635 Where the AA/shift of c891131 got fixed (but isosurface 
offset still there)

D -> 4d52c26 Fixed a bug causing radiosity to ignore refracted 
`no_image` objects.

E -> Previous refactor/texture. povray371Txtr_8738139

F -> Current refactor/texture.

So the rows in each attached image are comparing:

1) A to B
2) B to C
3) C to D
4) D to E
5) E to F
6) A to F

Showing the absolute difference mutiplied by 4x in the right most column.

For Story_Brill_Grtr1_wRad.jpg

1) A to B - The brilliance change of 54b283a.
2) B to C - The camera fixes of c891131.
3) C to D - Additional change some, not all in compensation of (2).
4) D to E - Mostly that refactor/texture code restored brilliance >1.
5) E to F - No change between last and current refactor/texture.
6) A to F - Surprise! With brilliace>1 quite a bit of radiosity difference.

For Story_Brill_Max1_wRad.jpg

1) A to B - Minor radiosity driven differences.
2) B to C - The camera fixes of c891131.
3) C to D - Additional change some, not all in compensation of (2).
4) D to E - No last refactor/texture to base 4d52c26
5) E to F - No change between last and current refactor/texture.
6) A to F - Believe mostly the result of c891131 & something between C & D.

For Story_Brill_Max1_NoRad.jpg

1) A to B - No difference.
2) B to C - Seeing the isosurface issue fixed with 0889275. (Yes affects 
Rad a little)
3) C to D - Seeing the isosurface issue fixed with 0889275.
4) D to E - No difference.
5) E to F - No difference between last and current refactor/text.
6) A to F - No difference.

I think most everything can be ignored except the surprise A-F 
radiosity results where the brilliance>1.0 is having a surprising effect 
on radiosity compared to 3.7.0 stable.

I'm off to try this latest refactor/texture with additional scenes - 
especially some with meshes.

Bill P.

Post a reply to this message

Attachments:
Download 'story_brill_grtr1_wrad.jpg' (167 KB) Download 'story_brill_max1_norad.jpg' (135 KB) Download 'story_brill_max1_wrad.jpg' (141 KB)

Preview of image 'story_brill_grtr1_wrad.jpg'

Preview of image 'story_brill_max1_norad.jpg'

Preview of image 'story_brill_max1_wrad.jpg'

On 09/06/2016 06:33 AM, William F Pokorny wrote:
>
> I'm off to try this latest refactor/texture with additional scenes -
> especially some with meshes.
>
> Bill P.
>
Ah, looks like something changed in this last release to better align 
the metallic keyword behavior with 3.7.0-stable - good! I'd not before 
picked up this difference.

Bill P.

Post a reply to this message

Attachments:
Download 'storynk0226_brill_max1_norad.jpg' (105 KB)

Preview of image 'storynk0226_brill_max1_norad.jpg'

On 09/06/2016 06:33 AM, William F Pokorny wrote:
>
> I'm off to try this latest refactor/texture with additional scenes -
> especially some with meshes.
>
> Bill P.
>
>

Found a case where some shadows changed with the last refactor/texture 
and stayed the same with this last version. Experimented quite a bit and 
unable to find a normal or finish option which triggers it though able 
to change the signature in the shadows some.

Files attached. (Differences at 8x absolute value to better see them) 
Maybe this is a case which will let us run down the differences in 
shadow rays & shadow cache numbers...

FYI - I'd argue differences small enough to ignore in this material, but 
does appear to be a change due the texture refactoring.

Bill P.

Post a reply to this message

Attachments:
Download 'nk0278__e.pov.txt' (5 KB) Download 'storynk0278_brill_max1_norad.jpg' (229 KB)

Preview of image 'storynk0278_brill_max1_norad.jpg'

On 09/06/2016 06:33 AM, William F Pokorny wrote:
>
> I'm off to try this latest refactor/texture with additional scenes -
> especially some with meshes.
>
> Bill P.
>
>

To the Good.

Found another material (NK0304) which with the latest refactor/texture 
is now aligned with 3.7.0-stable results where "specular 0.01 roughness 
0.25" coupled with "brilliance 0.85" had been giving slightly different 
results.

Bill P.

Post a reply to this message

On 09/06/2016 06:33 AM, William F Pokorny wrote:
>
> I'm off to try this latest refactor/texture with additional scenes -
> especially some with meshes.
>
> Bill P.
>
A reminder for others doing texture testing.

The documentation warns turbulence modifiers not wrapped in a warp{} 
blocks might not run in SDL apparent order or even the same order as 
other modifiers over time. I've run down a set of my own texture testing 
differences to this cause.

A source code change after 3.7.0-stable and sometime before (B - 
167ed19) causes 'some' materials I've picked up over time to appear 
differently where turbulence is not specified in a warp {} block.

In other words, code such as:

pigment {
    wood turbulence 0.135 omega 0.65 lambda 3
    color_map {...}
    rotate <0,90,0>
    scale <1,0.2,0.2>
    rotate <0,0.5,10>
}

Needs to be written as something like:

pigment {
    wood
    color_map {...}
    warp { turbulence 0.135 omega 0.65 lambda 3 }
    rotate <0,90,0>
    scale <1,0.2,0.2>
    rotate <0,0.5,10>
}

If one wants such textures to appear exactly the same in 3.7.1 as 3.7.0.

Bill P.

Post a reply to this message

On 09/06/2016 06:33 AM, William F Pokorny wrote:
>
> I'm off to try this latest refactor/texture with additional scenes -
> especially some with meshes.
>
> Bill P.
>

Attached is a modified case eliminating previously seen differences 
leaving a difference where we have only specular highlights defined for 
the surface. There is some slight difference in the shadows A (3.7.0) 
->B (167ed19) which persists in all later versions.

Bill P.

Post a reply to this message

Attachments:
Download 'nk0314__f.pov.txt' (4 KB) Download 'storynk0314_norad.jpg' (124 KB)

Preview of image 'storynk0314_norad.jpg'