 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
