Alain wrote:
> It looks like it can be prety usefull. I'll play with that one.

The edge map is probably the most useful feature :)

Post a reply to this message

"stbenge" <UN### [at] hotmailcom> schreef in bericht 
news:4b283e59@news.povray.org...
>
> I really need to make a small functioning example to provide along with a 
> bug report.

I may be talking nonsense here, but those same features are often also 
created by WM or GeoControl. I don't remember them from Leveller, but it has 
been a while since I last used that app. Do you think they have the same 
origin? Are they the same kind of bug?

In GeoControl I can correct manually with a brush, but in hf's from WM I 
just cut off a thin slice around from it by using an intersection in POV. 
Not very elegant as a solution but it works.

Thomas

Post a reply to this message

Where was this years ago??!!  You've created some real magic here. It must be
the coffee--drink lots more, so you can come up with more cool ideas!

I'm really looking forward to trying this out (and looking over your code, to
glean some ideas from 'the Master.')

Ken

Post a reply to this message

stbenge escreveu:

>> High!
> 
> Not yet! Maybe my second cup of coffee will do the trick ;)

bwahaha.  Always wanted to do some fun with that... :D

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Thomas de Groot wrote:
> "stbenge" <UN### [at] hotmailcom> schreef in bericht 
> news:4b283e59@news.povray.org...
>> I really need to make a small functioning example to provide along with a 
>> bug report.
> 
> I may be talking nonsense here, but those same features are often also 
> created by WM or GeoControl. I don't remember them from Leveller, but it has 
> been a while since I last used that app. Do you think they have the same 
> origin? Are they the same kind of bug?

I doubt they are the same bug.

Check this out:

height_field{
  png"mountains.png"
  ...
}

It works just fine, always has.

Compare it to this:

height_field{
  function 513, 513{
   pigment{
    image_map{
     png"mountains.png"
     interpolate 2 once
    }
   }
  }
  ...
}

This is when edge artifacts show up. The dimensions are correct. The 
problem happens regardless of image_map attributes such as interpolation 
and repetition.

I would say it's a height_field issue, but I know it's not. I have 
encountered this same problem when using image_maps at other times, like 
for my luminous bloom code.

> In GeoControl I can correct manually with a brush, but in hf's from WM I 
> just cut off a thin slice around from it by using an intersection in POV. 
> Not very elegant as a solution but it works.

Whatever works :)

Post a reply to this message

Kenneth wrote:
> Where was this years ago??!!  You've created some real magic here. It must be
> the coffee--drink lots more, so you can come up with more cool ideas!

Drink more coffee? Okay :)

> I'm really looking forward to trying this out (and looking over your code, to
> glean some ideas from 'the Master.')

Whatever you do, have fun!

Post a reply to this message

"stbenge" <UN### [at] hotmailcom> schreef in bericht 
news:4b2931c8@news.povray.org...
> Check this out:
>
> height_field{
>  png"mountains.png"
>  ...
> }
>
> It works just fine, always has.
>
> Compare it to this:
>
> height_field{
>  function 513, 513{
>   pigment{
>    image_map{
>     png"mountains.png"
>     interpolate 2 once
>    }
>   }
>  }
>  ...
> }
>
> This is when edge artifacts show up. The dimensions are correct. The 
> problem happens regardless of image_map attributes such as interpolation 
> and repetition.
>
> I would say it's a height_field issue, but I know it's not. I have 
> encountered this same problem when using image_maps at other times, like 
> for my luminous bloom code.

Ah, right. I see your point. One way or another I have never noticed this 
difference. Strange indeed. Thanks for drawing my attention to it.

Thomas

Post a reply to this message

stbenge <UN### [at] hotmailcom> wrote:

> I doubt they are the same bug.
>
> Check this out:
>
> height_field{
>   png"mountains.png"
>   ...
> }
>
> It works just fine, always has.
>
> Compare it to this:
>
> height_field{
>   function 513, 513{
>    pigment{
>     image_map{
>      png"mountains.png"
>      interpolate 2 once
>     }
>    }
>   }
>   ...
> }

Yeah, there are some strange goings-on in HFs made from functions.  I think I've
noticed the edge artifacts you mentioned.  But there's also the odd fact that
the applied pattern (or image_map) ends up being flipped upside down(?) like a
mirror-image, AND that the 'origin point' of the pattern/image is out of place.
The usual origin that we all know and love is at <0,0,0>; with a HF function,
the 'origin' is mysteriously at <0,0,1>, and the applied pattern/image
scales out from there. I've come up with simple workarounds to these particular
situations--but, along with the edge artifacts, it's apparent that HF functions
are not working correctly. I suppose, though, that re-engineering the
problematic code (whatever it is!) would cause lots of backward-compatibility
problems with previously-made scenes.

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> ...But there's also the odd fact that
> the applied pattern (or image_map) ends up being flipped upside down(?) like a
> mirror-image, AND that the 'origin point' of the pattern/image is out of
> place...

BY 'image_map,' what I meant to say was "an image_map used as [or used as part
of] the HF function"--not an image_map *texture* applied to the HF afterward
(which is applied as it should be.) Sorry if that confused anyone.

Ken

Post a reply to this message

Kenneth wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
>> ...But there's also the odd fact that
>> the applied pattern (or image_map) ends up being flipped upside down(?) like a
>> mirror-image, AND that the 'origin point' of the pattern/image is out of
>> place...
> 
> BY 'image_map,' what I meant to say was "an image_map used as [or used as part
> of] the HF function"--not an image_map *texture* applied to the HF afterward
> (which is applied as it should be.) Sorry if that confused anyone.

It didn't confuse me, Kenneth :) It's an annoying problem, but easy 
enough to work around. It probably should be fixed, but you're right 
when saying that by doing so, many older scenes will be broken.

Post a reply to this message