 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmx de>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 22:57:53 +0100, Christoph Hormann wrote:
>
>
> 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.
The goal is to test on a big-endian machine, so that test is inconclusive.
--
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 just tested with xv and gimp BTW, the both behave just like the Windows
> > programs.
>
> The goal is to test on a big-endian machine, so that test is inconclusive.
>
All right, just wanted to mention it.
BTW, how about:
http://www.libpng.org/pub/png/pngsuite.html
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 5 Dec 2001 16:32:16 -0500, Ron Parker wrote:
> 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.
Never mind. I found it... color 16bpp images are okay, gray ones are
broken. 9-15 bpp are probably broken, too, but in a different way.
It'll be fixed in the next beta.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
never mind, I fixed it, I was actually making the hf image at a lower
resolution than I had thought.... doh....!
"Paul D. Jones" wrote:
> 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
|
|
| |
| |
|
|
|
|
| |
