Am 01.09.2014 09:10, schrieb Thomas de Groot:
> On 31-8-2014 20:10, Alain wrote:

>>> I'm not sure why these are getting converted to a .dat attachment
>>> instead of an
>>> inline image...
>>>
>> No .DAT here.
>> Using Thunderbird.
>
> For some reason, .dat is added to the image when the post is addressed
> on the POV-Ray site, but not when addressed from Thunderbird. And only
> for these images by Bald Eagle. Strange.

It /might/ be because - surprise! - they're not PNG files at all; they 
have a .png extension, but really they're BMP files.

Post a reply to this message

On 01/09/14 11:59, clipka wrote:
> 
> It /might/ be because - surprise! - they're not PNG files at all; they
> have a .png extension, but really they're BMP files.
> 

Indeed they are:

john@aphrodite:~> file Bri### [at] ternpng
BrickPattern.png: PC bitmap, Windows 3.x format, 640 x 200 x 24

;-)

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 01/09/14 12:08, Doctor John wrote:
> On 01/09/14 11:59, clipka wrote:
>>
>> It /might/ be because - surprise! - they're not PNG files at all; they
>> have a .png extension, but really they're BMP files.
>>
> 
> Indeed they are:
> 
> john@aphrodite:~> file Bri### [at] ternpng
> BrickPattern.png: PC bitmap, Windows 3.x format, 640 x 200 x 24
> 
> ;-)
> 
> John
> 

Actually, I'm kicking myself for not noticing immediately. The size is a
big giveaway: 375 KB versus 65.1 KB.

A true PNG is attached to demonstrate the diffence.

BTW Bald Eagle, you need to change your ini file settings to generate
true PNG images

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

Attachments:
Download 'brickpattern(mod).png' (66 KB)

Preview of image 'brickpattern(mod).png'

> >> It /might/ be because - surprise! - they're not PNG files at all; they
> >> have a .png extension, but really they're BMP files.

Yay!  It's always so comforting when Windows deceives me with a superficially
_believable_ lie.  :\

It's not POV-Ray's fault, it windows saving a cropped image as png but with the
bmp file format - and then displaying a thumbnail in the directory.
I'll look for a better bare-bones graphics program to do simple tasks.  No need
to load in Paint.net or the Gimp just to do a quick crop-paste...

....

I would still like to know what's going on with the brick normal...
If you look at the dimensions of the "unbanded" cinder blocks in the foreground
and background, they're oriented properly with the wall along either axis.

Thanks, and sorry for the confusion.

Post a reply to this message

Am 01.09.2014 16:22, schrieb Bald Eagle:

> I would still like to know what's going on with the brick normal...
> If you look at the dimensions of the "unbanded" cinder blocks in the foreground
> and background, they're oriented properly with the wall along either axis.

Did you try translating the texture slightly perpendicular to the wall - 
into the room, as it were?

Post a reply to this message

>
>>>> It /might/ be because - surprise! - they're not PNG files at all; they
>>>> have a .png extension, but really they're BMP files.
>
> Yay!  It's always so comforting when Windows deceives me with a superficially
> _believable_ lie.  :\
>
> It's not POV-Ray's fault, it windows saving a cropped image as png but with the
> bmp file format - and then displaying a thumbnail in the directory.
> I'll look for a better bare-bones graphics program to do simple tasks.  No need
> to load in Paint.net or the Gimp just to do a quick crop-paste...
>
>

For that, you can try IrfanView.
It's a very nice media viewer that can be used to crop images, adjust 
contrast, brightness and gamma and apply several filters. Free and 
lightweight.
It can read and save images in most formats.

Post a reply to this message

> Did you try translating the texture slightly perpendicular to the wall -
> into the room, as it were?

No, I did not - though I should have thought of that.
I also tried scaling it along the x-axis, and that seemed to work too.

I'm still fighting with Pov-Ray about the syntax and heirarchical structure of
BRICK.   Right about now, I'm feeling as thick as one.   Cue Jethro Tull.

#declare White_Paint = material { texture {pigment {color White}  finish{diffuse
0.9 } normal {bumps scale <1, .1, .1>}} };

#declare White_Paint_T = texture {pigment {color White}  finish{diffuse 0.9 }
normal {bumps scale <1, .1, .1>} };

#declare White_Brick =  texture {brick texture {White_Paint_T}
     texture {White_Paint_T}
     brick_size <8, 8, 16>
     } ;

#declare White_Wall =  texture {White_Brick
    normal {brick brick_size <8, 8, 16> scale x*1.0625}
    finish {diffuse 0.9 phong 0.2}
    } ;

I've tried breaking things up, declaring an explicit TEXTURE, and the problem
I'm having is that POV shoots back  "line 116: Parse Error: No matching } in
'texture', finish found instead"
<whine>
But Pov-Raaaaaaay, normal and finish are _part of a texture definition_.  :(
</whine>

How do I get the brick and mortar to have a PAINT texture, and the WALL have an
overall BRICK normal?   I've searched around for an explanation or better yet a
working example, but haven't come up with much.

Post a reply to this message

Am 02.09.2014 00:46, schrieb Bald Eagle:

> I'm still fighting with Pov-Ray about the syntax and heirarchical structure of
> BRICK.   Right about now, I'm feeling as thick as one.   Cue Jethro Tull.
>
> #declare White_Paint = material { texture {pigment {color White}  finish{diffuse
> 0.9 } normal {bumps scale <1, .1, .1>}} };
>
> #declare White_Paint_T = texture {pigment {color White}  finish{diffuse 0.9 }
> normal {bumps scale <1, .1, .1>} };
>
> #declare White_Brick =  texture {brick texture {White_Paint_T}
>       texture {White_Paint_T}
>       brick_size <8, 8, 16>
>       } ;

Why are you doing this? Doesn't make much sense having both the bricks 
and the mortar use the same texture, does it?

> #declare White_Wall =  texture {White_Brick
>      normal {brick brick_size <8, 8, 16> scale x*1.0625}
>      finish {diffuse 0.9 phong 0.2}
>      } ;
>
> I've tried breaking things up, declaring an explicit TEXTURE, and the problem
> I'm having is that POV shoots back  "line 116: Parse Error: No matching } in
> 'texture', finish found instead"

I get "normal found instead", but I also get the point.

I've never come across this before, but apparently (and knowing the 
interna of texture handling it does make sense to me) you can't override 
normal, texture or finish of a multi-component texture (i.e. one 
composed of multiple textures).

> <whine>
> But Pov-Raaaaaaay, normal and finish are _part of a texture definition_.  :(
> </whine>
>
> How do I get the brick and mortar to have a PAINT texture, and the WALL have an
> overall BRICK normal?   I've searched around for an explanation or better yet a
> working example, but haven't come up with much.

You need to make the brick normal part of each individual sub-texture; 
it'll require an average normal_map to mix it with the normal 
perturbation you're already using.

Post a reply to this message

> Why are you doing this? Doesn't make much sense having both the bricks
> and the mortar use the same texture, does it?

Well, it does.
From:
http://news.povray.org/web.53ff71d6848b38545e7df57c0%40news.povray.org

"I'm simply trying to model a cinder block wall that has been painted a fairly
uniform color."

> I get "normal found instead", but I also get the point.
>
> I've never come across this before,

Well, I break things.  And they you should find one thing that you do well, and
stick with that.  Also, everyone has a superpower.  This is mine.

> but apparently (and knowing the
> internal of texture handling it does make sense to me) you can't override
> normal, texture or finish of a multi-component texture (i.e. one
> composed of multiple textures).

I suspected something like that, but couldn't be sure.

> You need to make the brick normal part of each individual sub-texture;
> it'll require an average normal_map to mix it with the normal
> perturbation you're already using.

Well, I tried about 20 - 30 different things, and at long last I got something
that looks fairly passable in both the block and the mortar, at almost any angle
and with a simple point light source.

#declare White_Brick =  texture {pigment {brick
pigment {rgb <202/255, 198/255, 173/255>}
pigment {rgb <202/255, 198/255, 173/255>}
brick_size <8, 8, 16>}
} ;

#declare White_Wall =  material {texture {White_Brick
normal {brick
normal {bumps scale <0.2, 0.5, .1> rotate x*5 rotate z*5}
normal {bumps scale <.05, 0.5, .1>}  brick_size <8, 8, 16>}
finish {diffuse 0.9 phong 0.2}
}
} ;

I'll likely dabble with that at some point to add a touch more yellow, and
possible a slightly varied granite pigment map, but it was the normal that was
driving me crazy.

Hopefully this helps someone in the future.

If anyone has any clever improvements to jazz this up a bit, I'd love to hear
them.

Post a reply to this message

Attachments:
Download 'wall_test_best.png' (226 KB)

Preview of image 'wall_test_best.png'

Am 02.09.2014 05:18, schrieb Bald Eagle:
>
>> Why are you doing this? Doesn't make much sense having both the bricks
>> and the mortar use the same texture, does it?
>
> Well, it does.
> From:
> http://news.povray.org/web.53ff71d6848b38545e7df57c0%40news.povray.org
>
> "I'm simply trying to model a cinder block wall that has been painted a fairly
> uniform color."

But you don't need the brick pattern for that. You only need it in the 
normals.

> #declare White_Brick =  texture {pigment {brick
> pigment {rgb <202/255, 198/255, 173/255>}
> pigment {rgb <202/255, 198/255, 173/255>}
> brick_size <8, 8, 16>}
> } ;

Simply make this:

     #declare White_Brick =  texture {
       pigment {rgb <202/255, 198/255, 173/255>}
     } ;

Post a reply to this message