 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi!
I know this will be a wired description (and sorry for the headline),
but I try:
Render an animation of this one:
about 50 (or 100) frames (AA) height:3 width:20
///start
default { finish {ambient 1}}
/// +w20 +h3
#local F = function(x,y,z) {1-min(abs(z),1)}
box {-1,1
pigment {
function {F(x,y,z)}
color_map {
[0.0 color rgb 0]
[1.0 color green 1]
}
scale .4
}
rotate y*90
}
camera {
location <0,1,0>
orthographic
right <1,0,0>*2
up <0,1,0>*2
look_at 0
translate x*sin(clock*2*pi)
}
///end
(it was written to make a vertical "copper" - this kind of
assemblertrick: moving a colored bar in the background in textmode -
but vertical)
Make the renderwindow fullscreen and look at the lowest of the three
pixel while realtime-rendering: The first half of the animation they
are as bright as the ones above, the other half they are somewhat 50%
dimmed.
I don't know what it's comming from lowering up and right in the
camera reduces but doesn't solve the problem.
It was working with beta 8 - something has to be changed.
amd 1.4GHz Win98
thank you for looking into this!
Kalle
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it KalleK who wrote:
>Make the renderwindow fullscreen and look at the lowest of the three
>pixel while realtime-rendering: The first half of the animation they
>are as bright as the ones above, the other half they are somewhat 50%
>dimmed.
When I make it full screen, I just get a white panel and the text
"StretchDIBits () failed ! (Windows Error)". This seems to happen when w
is less than 38 and h is less than 9.
POV 3.5b8, Win 98se, Celeron II 850, 128 Mb
I observe no dimming on the images that are produced when I look at them
later.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> When I make it full screen, I just get a white panel and the text
> "StretchDIBits () failed ! (Windows Error)". This seems to happen when w
> is less than 38 and h is less than 9.
hmm. For that matter you may use +w38 +h9 - I can still see the lowest row of
pixels very good and dimmed...
> POV 3.5b8, Win 98se, Celeron II 850, 128 Mb
do you meant really beta 8? Am I too early with beta9 - having downloaded it
without an official announcement in this group? I'm soory then. But maybe it
was just a typo...
> I observe no dimming on the images that are produced when I look at them
> later.
Now, I have to search for another one to confirm this
(but its you, keeping the buglist...)
using msvc compile I got the same behaviour: the lowest row is dimmed for the
second half of the animation...
cukk
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: the lowest pixel getting dimmed
Date: 22 Dec 2001 05:02:13
Message: <3c245a25@news.povray.org>
|
|
|
| |
| |
|
|
In article <3c24583c$1@news.povray.org> , "KalleK" <kal### [at] gmx de> wrote:
> using msvc compile I got the same behaviour: the lowest row is dimmed for the
> second half of the animation...
What does it look like in the _output_ image on disk?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams <mik### [at] nospamplease> wrote:
: POV 3.5b8, Win 98se, Celeron II 850, 128 Mb
How did you manage getting beta8 to work after the expiration period?
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> How did you manage getting beta8 to work after
> the expiration period?
Is this some kind of trick question?
Setting back the clock is relly not that hard...
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What does it look like in the _output_ image on disk?
I posted an example in p.b-t.b.
I tested a bit more: If you turn off AA or enlarge the box by "scale 10"
there are no dimmed pixel anymore.
Maybe it's something about the "picture a half pixel off"-"bug" or has to do
with it beeing fixed (but there's nothing about a change with that or AA in
revision.txt). (It's strange that it appears only in the second half.) I'm
not really sure anymore if it's a bug.
But it changed from beta 8 to beta 9.
cukk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I posted an example in p.b-t.b.
> I tested a bit more: If you turn off AA or enlarge the box by "scale 10"
> there are no dimmed pixel anymore.
> Maybe it's something about the "picture a half pixel off"-"bug" or has to
do
> with it beeing fixed (but there's nothing about a change with that or AA
in
> revision.txt). (It's strange that it appears only in the second half.)
Your problem sounds very much like a case of the half-pixel camera bug. That
bug has not been fixed in beta 9. As for it only being visible in the second
half, the AA threshold is playing tricks on you. If you use either +am2 or
+a0.0, the bug is visible through the whole animation.
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Your problem sounds very much like a case of the half-pixel camera bug.
That
> bug has not been fixed in beta 9. As for it only being visible in the
second
> half, the AA threshold is playing tricks on you. If you use either +am2 or
> +a0.0, the bug is visible through the whole animation.
Could be. The only strange thing is, it wasn't there in beta 8 (at least not
in my case - using the same code with beta 8 produced no dimmed pixels for
me.)
cukk
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: the lowest pixel getting dimmed
Date: 22 Dec 2001 11:03:40
Message: <3c24aedc@news.povray.org>
|
|
|
| |
| |
|
|
In article <3c24a085$1@news.povray.org> , "Anders K."
<and### [at] prostard2gcom> wrote:
> Your problem sounds very much like a case of the half-pixel camera bug. That
> bug has not been fixed in beta 9.
It hasn't been a problem for 15 years, so I would say it isn't a bug but
standard behavior of POV-Ray. Thus, changing it is a feature request...
> As for it only being visible in the second
> half, the AA threshold is playing tricks on you. If you use either +am2 or
> +a0.0, the bug is visible through the whole animation.
I think so, too. Adjusting either the box size of the camera position will
make it look as expected.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Your problem sounds very much like a case of the half-pixel camera bug.
That
> > bug has not been fixed in beta 9.
>
> It hasn't been a problem for 15 years, so I would say it isn't a bug but
> standard behavior of POV-Ray. Thus, changing it is a feature request...
Ok. I will adjust my scene.
Just want to add: Concerning that behavior something changed from beta 8 to
beta 9, because I had no dimmed pixel with beta 8. If that is ok. If not,
there is something unexpected.
Thank you for explaining my problem and for POVRay!
cukk
(shutting up now)
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: the lowest pixel getting dimmed
Date: 23 Dec 2001 06:06:53
Message: <3c25bacd@news.povray.org>
|
|
|
| |
| |
|
|
In article <3c25b545@news.povray.org> , "KalleK" <kal### [at] gmxde> wrote:
> Just want to add: Concerning that behavior something changed from beta 8 to
> beta 9, because I had no dimmed pixel with beta 8. If that is ok. If not,
> there is something unexpected.
This is expected because now the transparency (for the alpha channel) it
taking into account when doing anti-aliasing.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" wrote:
> It hasn't been a problem for 15 years, so I would
> say it isn't a bug but standard behavior of POV-Ray.
It has been a problem for many, but maybe not big enough a problem for
anyone to make a patch to fix it.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This is expected because now the transparency (for the alpha channel) it
> taking into account when doing anti-aliasing.
OK. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > It hasn't been a problem for 15 years, so I would
> > say it isn't a bug but standard behavior of POV-Ray.
I disagree. By definition, the camera is supposed to be centered on the
look_at point, but it isn't. For most scenes, the half pixel doesn't matter
very much, but for things which require to-the-pixel accuracy, the current
behavior is *very* annoying. And a lot more scenes require this accuracy
than one would think at first glance. For an example, look no further than
Insert > Scene Templates > Orthographic Scene.
> It has been a problem for many, but maybe not big enough a problem for
> anyone to make a patch to fix it.
I actually described how to fix it for 3.1g. See my earlier thread, "Camera
is off by half a pixel".
Anders
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: the lowest pixel getting dimmed
Date: 28 Dec 2001 12:29:31
Message: <3c2cabfb@news.povray.org>
|
|
|
| |
| |
|
|
In article <3c2bdf75$1@news.povray.org> , "Anders K."
<and### [at] prostard2gcom> wrote:
> I disagree. By definition, the camera is supposed to be centered on the
> look_at point, but it isn't. For most scenes, the half pixel doesn't matter
> very much, but for things which require to-the-pixel accuracy, the current
If you want it centered, one very simple solution is to add one pixel to the
width and height of the image.
> behavior is *very* annoying. And a lot more scenes require this accuracy
> than one would think at first glance. For an example, look no further than
> Insert > Scene Templates > Orthographic Scene.
I think orthographic camera scenes are the only place where this may matter
in a very few scenes. Of course, the above solution will still work fine.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If you want it centered, one very simple solution is to add one pixel to
the
> width and height of the image.
What if I don't want to add one pixel to the width and height of the image?
For example, one of my POV-Ray projects is creating a set of tiles for a 2D
game. There are hundreds of tiles, and they are rendered by a single file as
an animation. I don't want to have to go in manually with an image editor to
remove one row and column from every single image. Moving the camera works,
but then I need to change the amount I move it by every time I change the
size of the images, and I'm making two sizes of tiles (32x32 and 48x48).
> I think orthographic camera scenes are the only place where this may
matter
> in a very few scenes. Of course, the above solution will still work fine.
That doesn't change the fact that the current behavior is simply incorrect,
and it is very easy to fix. I know you're probably worried about backwards
compatibility, but as you pointed out, it only makes a big difference on a
few scenes, and even on those scenes it would be much better to have the
camera in the right place anyway.
Anders
--
light_source{6#macro A(B)#declare C=mod(E B);#declare E=(E-C)/B;C#end
#macro B(E)#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)cylinder
{0(C=<1 2>).2translate<D+C*A(2)A(4)#else intersection{torus{1 .2}box{
-y 2}rotate<-1 0C+1>*90translate<D+1A(2)*2+1#end-2 13>finish{specular
1}pigment{red 1}}#end#end#end#local D=-8;1}B(445000298)B(519053970)B(
483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anders K." wrote:
> What if I don't want to add one pixel to the width
> and height of the image?
Yes, it's not always a useful solution.
Besides, it actually skews the aspect ratio slightly! ;)
> Moving the camera works, but then I need to change the
> amount I move it by every time I change the size of the
> images, and I'm making two sizes of tiles (32x32 and 48x48).
I've had the exact same problem every time I create logos, icons, cursors,
web graphics etc. It's rather annoying.
And I don't always use orthographic camera for that by the way.
> That doesn't change the fact that the current behavior
> is simply incorrect, and it is very easy to fix. I know
> you're probably worried about backwards compatibility,
> but as you pointed out, it only makes a big difference
> on a few scenes, and even on those scenes it would be
> much better to have the camera in the right place anyway.
I agree.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 28 Dec 2001 15:02:26 -0500, Anders K. wrote:
> an animation. I don't want to have to go in manually with an image editor to
> remove one row and column from every single image. Moving the camera works,
For this was netpbm created.
--
#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" <ron### [at] povrayorg> wrote:
> For this was netpbm created.
Even if this worked, you shouldn't have to work around incorrect behavior.
However, adding one row and column doesn't even work: it scales everything
by <(w+1)/w, (h+1)/h>. And for camera types other than orthographic, moving
the camera doesn't work either, since objects closer to the camera would get
shifted more than objects farther away. Rotating the camera would skew the
whole image unpredictably. So there is no satisfactory workaround.
Anders
--
light_source{6#macro A(B)#declare C=mod(E B);#declare E=(E-C)/B;C#end
#macro B(E)#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)cylinder
{0(C=<1 2>).2translate<D+C*A(2)A(4)#else intersection{torus{1 .2}box{
-y 2}rotate<-1 0C+1>*90translate<D+1A(2)*2+1#end-2 13>finish{specular
1}pigment{red 1}}#end#end#end#local D=-8;1}B(445000298)B(519053970)B(
483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: the lowest pixel getting dimmed
Date: 29 Dec 2001 12:29:50
Message: <3c2dfd8e@news.povray.org>
|
|
|
| |
| |
|
|
In article <3c2de5e0$1@news.povray.org> , "Anders K."
<and### [at] prostard2gcom> wrote:
> However, adding one row and column doesn't even work: it scales everything
> by <(w+1)/w, (h+1)/h>. And for camera types other than orthographic, moving
> the camera doesn't work either, since objects closer to the camera would get
> shifted more than objects farther away. Rotating the camera would skew the
> whole image unpredictably. So there is no satisfactory workaround.
Actually, a quick look at the code suggests that your observation may not be
correct (but I never really cared about this part of the code before)...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > However, adding one row and column doesn't even work: it scales
everything
> > by <(w+1)/w, (h+1)/h>. And for camera types other than orthographic,
moving
> > the camera doesn't work either, since objects closer to the camera would
get
> > shifted more than objects farther away. Rotating the camera would skew
the
> > whole image unpredictably. So there is no satisfactory workaround.
>
> Actually, a quick look at the code suggests that your observation may not
be
> correct [...]...
How so?
Anders
--
light_source{6#macro A(B)#declare C=mod(E B);#declare E=(E-C)/B;C#end
#macro B(E)#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)cylinder
{0(C=<1 2>).2translate<D+C*A(2)A(4)#else intersection{torus{1 .2}box{
-y 2}rotate<-1 0C+1>*90translate<D+1A(2)*2+1#end-2 13>finish{specular
1}pigment{red 1}}#end#end#end#local D=-8;1}B(445000298)B(519053970)B(
483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
