On 23-9-2014 19:54, clipka wrote:
> Can you help me with identifying those textures?

Yes of course.

>
>
>> So the problem might be slightly different from what you were fearing.
>
> Well, what /was/ I "fearing" then? ;-)

Good point indeed :-)

>
> I have no doubt that the Prox Pattern macros are perfectly fine. I
> presume that they just happen to make use of a language construct that's
> broken, which may also be used in (and therefore affect) other materials.
>
> Say, do the vanished non-proxed objects perchance also make use of a
> texture_map?
>

I need to plunge into this and see how the textures are built and are 
affected. I'll be back.

Thomas

Post a reply to this message

On 23-9-2014 19:54, clipka wrote:
> I have no doubt that the Prox Pattern macros are perfectly fine. I
> presume that they just happen to make use of a language construct that's
> broken, which may also be used in (and therefore affect) other materials.
>
> Say, do the vanished non-proxed objects perchance also make use of a
> texture_map?
>

Right. This is what I found:

- The proximity pattern textures have the following build-up with 
pigment_pattern and a texture_map:
   texture {
     pigment_pattern {
       average
       pigment_map {
         #if( proximity_pattern_strength != 0 )
           [ proximity_pattern_strength*3 df3_pattern scale 1/texture_scale]
         #end
         #if( slope_pattern_strength != 0 )
           [ slope_pattern_strength*0.6 slope { y altitude <0,1,0> } 
color_map { [0 rgb 1] [1 rgb 0] } scale 140 * 1/texture_scale ]
         #end
         #if( noise_pattern_strength != 0 )
           [ noise_pattern_strength *0.4 bozo color_map { [0 rgb 0] [1 
rgb 1] } scale 4 * noise_scale ]
           [ noise_pattern_strength *0.3 bozo color_map { [0 rgb 0] [1 
rgb 1] } scale 1 * noise_scale]
           [ noise_pattern_strength *0.2 bozo color_map { [0 rgb 0] [1 
rgb 1] } scale 0.33 * noise_scale ]
           [ noise_pattern_strength *0.1 bozo color_map { [0 rgb 0] [1 
rgb 1] } scale 0.1 * noise_scale ]
         #end
       }
     }
     texture_map { map }
     scale texture_scale
   }

- Consequently, in my image, the fountain, the columns, the arcs, and 
the combined ridges, window sills, window arcs, are missing (part of) 
their shadows.

- As far as I can tell, all other elements have rendered correctly.

Thomas

Post a reply to this message

On 23-9-2014 10:22, Stephen wrote:
> I like this one very much.
>

I do too. Especially the subtle graininess left by the stochastic 
antialiasing is something I appreciate.

Thomas

Post a reply to this message

A pointillist version ;-)

I added a tiny transparency to the image_maps involved in the proximity 
patterns and that proved to be a good workaround. Thanks Christoph.

Tomorrow I shall render a better final version.

Thomas

Post a reply to this message

Attachments:
Download 'silentium.png' (1064 KB)

Preview of image 'silentium.png'

On 24/09/14 15:48, Thomas de Groot wrote:
> A pointillist version ;-)
> 
> I added a tiny transparency to the image_maps involved in the proximity
> patterns and that proved to be a good workaround. Thanks Christoph.
> 
> Tomorrow I shall render a better final version.
> 
> Thomas
> 

This I really like.

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children

Post a reply to this message

On 24/09/2014 16:01, Doctor John wrote:
> On 24/09/14 15:48, Thomas de Groot wrote:
>> A pointillist version ;-)
>>
>> I added a tiny transparency to the image_maps involved in the proximity
>> patterns and that proved to be a good workaround. Thanks Christoph.
>>
>> Tomorrow I shall render a better final version.
>>
>> Thomas
>>
>
> This I really like.
>

The graininess adds to the atmosphere.

@Clipka would it be feasible to add a feature to UberPov so that it 
takes a snapshot at different stages to see the progress of the render?
It is just a thought as an animation of the building of the picture 
might be interesting to see.


-- 

Regards
     Stephen

Post a reply to this message

Am 24.09.2014 17:34, schrieb Stephen:

> @Clipka would it be feasible to add a feature to UberPov so that it
> takes a snapshot at different stages to see the progress of the render?
> It is just a thought as an animation of the building of the picture
> might be interesting to see.

Such a feature is on my to-do list (has always been, actually), but I'm 
waiting for some other changes to happen in POV-Ray proper that will 
make it a whole lot easier.

Post a reply to this message

On 24/09/2014 16:49, clipka wrote:
> Am 24.09.2014 17:34, schrieb Stephen:
>
>> @Clipka would it be feasible to add a feature to UberPov so that it
>> takes a snapshot at different stages to see the progress of the render?
>> It is just a thought as an animation of the building of the picture
>> might be interesting to see.
>
> Such a feature is on my to-do list (has always been, actually), but I'm
> waiting for some other changes to happen in POV-Ray proper that will
> make it a whole lot easier.
>

Excellent!


-- 

Regards
     Stephen

Post a reply to this message

Am 24.09.2014 18:03, schrieb Stephen:
> On 24/09/2014 16:49, clipka wrote:
>> Am 24.09.2014 17:34, schrieb Stephen:
>>
>>> @Clipka would it be feasible to add a feature to UberPov so that it
>>> takes a snapshot at different stages to see the progress of the render?
>>> It is just a thought as an animation of the building of the picture
>>> might be interesting to see.
>>
>> Such a feature is on my to-do list (has always been, actually), but I'm
>> waiting for some other changes to happen in POV-Ray proper that will
>> make it a whole lot easier.
>
> Excellent!

Did I ever mention that whatever features MCPov has (*) is also on the 
to-do list for UberPOV? ;-)

(* uh, wait... MCPov is based on MegaPOV, isn't it? Well, I won't be 
able to add all /that/ to UberPOV... not in the one-man show UberPOV 
currently is.)

Post a reply to this message

On 24/09/2014 17:56, clipka wrote:
> Did I ever mention that whatever features MCPov has (*) is also on the
> to-do list for UberPOV? ;-)
>
No.

> (* uh, wait... MCPov is based on MegaPOV, isn't it? Well, I won't be
> able to add all /that/ to UberPOV... not in the one-man show UberPOV
> currently is.)

Do we change the name to UnterPov? ;-)
Or UnterMcPov Hoots!

I've never really used these unofficial versions as I need a modeller. 
And neither Moray nor Bishop3D supported them. You are making be 
re-evaluate that. Especially considering the way Blender is being developed.

-- 

Regards
     Stephen

Post a reply to this message