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