Howdy povers!

I seem to be having a wee bit o' difficulty in making a nice
heightfield. I have read the docs and tried a bunch of things
(hf_gray_16, tga and png formats etc...) but no matter what I try, I
cannot make a smooth height field.

I use an orthographic scene file with an agate pattern to generate the
required hf image (1024 x 768 aa 0.3), then in another scene use the
smooth command and I get a stepped effect.

Does any on have any suggestions as to what would make a good hf? Would
an isosurface (shudder.....) be better?

-thanks

paul (a three year pov user, and still a new user!! argh!!  :-)

Post a reply to this message

> I seem to be having a wee bit o' difficulty in making a nice
> heightfield.

You are talking about isosurfaces - are you using 3.5 beta ? Perhaps there is
everything ok with your method but something wrong with beta. IIRC there were
some reports in bugreports about heighfield but I can't find it now. Show
sources and/or image within apropriate group - perhaps somebody help.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

> 
> > I seem to be having a wee bit o' difficulty in making a nice
> > heightfield.
> 
> You are talking about isosurfaces - are you using 3.5 beta ? Perhaps there is
> everything ok with your method but something wrong with beta. IIRC there were
> some reports in bugreports about heighfield but I can't find it now. Show
> sources and/or image within apropriate group - perhaps somebody help.
> 

There is nothing wrong with image maps in isosurfaces specifically, but
there are general problems with isosurfaces.  

Concerning heightfields: It's a known bug in current 3.5 beta that png
output with 'hf_gray_16 on' is broken, apart from that i see nothing
preventing you from creating a smooth heightfileld, if you post a sample
(in p.b.i.) to show what's wrong i can say more.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On Wed, 05 Dec 2001 17:20:22 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> There is nothing wrong with image maps in isosurfaces specifically, but
> there are general problems with isosurfaces.  

Misunderstand - I used 'isosurfaces' to conclude he is using 3.5 but I talked
about heighfields. :-)

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

On Wed, 05 Dec 2001 17:20:22 +0100, Christoph Hormann wrote:
> Concerning heightfields: It's a known bug in current 3.5 beta that png
> output with 'hf_gray_16 on' is broken, apart from that i see nothing

Interesting.  And here I thought it was the 16-bit PNG input that was
broken. :)

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

Ron Parker wrote:
> 
> Interesting.  And here I thought it was the 16-bit PNG input that was
> broken. :)
> 

I think we had this discussion before, it's the output, if not, all other
programs that read or write those files must be wrong...

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On Wed, 05 Dec 2001 21:19:58 +0100, Christoph Hormann wrote:
> 
> 
> Ron Parker wrote:
>> 
>> Interesting.  And here I thought it was the 16-bit PNG input that was
>> broken. :)
>> 
> 
> I think we had this discussion before, it's the output, if not, all other
> programs that read or write those files must be wrong...

I have yet to see anyone claim that anything but Photoshop has problems
with those file.  pngtopnm certainly deals with them correctly, and if
anything could be expected to implement 16-bit PNGs correctly, I'd think 
that would be it.  Do you have examples of other programs that are supposed
to be able to read 16-bit PNGs that have a problem?

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

Ron Parker wrote:
> 
> I have yet to see anyone claim that anything but Photoshop has problems
> with those file.  pngtopnm certainly deals with them correctly, and if
> anything could be expected to implement 16-bit PNGs correctly, I'd think
> that would be it.  Do you have examples of other programs that are supposed
> to be able to read 16-bit PNGs that have a problem?

Apart from all past Povray versions, all paint programs i tested that can
read 16 bit png as 8 bit read the wrong byte and gforge/hf-lab generated
files are the other way round too.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On Wed, 05 Dec 2001 22:30:42 +0100, Christoph Hormann wrote:
> 
> 
> Ron Parker wrote:
>> 
>> I have yet to see anyone claim that anything but Photoshop has problems
>> with those file.  pngtopnm certainly deals with them correctly, and if
>> anything could be expected to implement 16-bit PNGs correctly, I'd think
>> that would be it.  Do you have examples of other programs that are supposed
>> to be able to read 16-bit PNGs that have a problem?
> 
> Apart from all past Povray versions, all paint programs i tested that can
> read 16 bit png as 8 bit read the wrong byte and gforge/hf-lab generated
> files are the other way round too.  

Past povray versions had a known bug.

Has anyone tested POVWin's 16-bit PNG output on a Mac?  I seem to remember
that we did that when this first came up and it worked okay, leading me to
believe that it's all those windows apps that are broken.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

Ron Parker wrote:
> 
> Past povray versions had a known bug.
> 

In this case it's of course reasonable to presume that programs like
gforge took the wrong format from Povray.  

> Has anyone tested POVWin's 16-bit PNG output on a Mac?  I seem to remember
> that we did that when this first came up and it worked okay, leading me to
> believe that it's all those windows apps that are broken.
> 

I just tested with xv and gimp BTW, the both behave just like the Windows
programs.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message