 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c434a59@news.povray.org> , Warp <war### [at] tag povrayorg> wrote:
> On the other hand, why would you want to use a #version older than 3.5
> for the camera?
Actually, the version setting that is active at render time will influence
the behavior. Just putting the #version 3.1 around the camera won't help.
It has to be the last #version that is set so it is the one used when
rendering.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom> , Ron Parker
<ron### [at] povrayorg> wrote:
> I think Thorsten probably has some input on this, so I'll defer to him,
> but I think the issue was that we thought some people might have already
> worked around the error in scenes where it was important.
Exactly that is the idea. I.e. if someone used to render icons with POV-Ray
the change would be noticeable and possibly even undesired as in such a case
it might even be that not the camera has been adjusted but the object
positions had been designed to meet the "old" behavior and simply undoing
the camera move would not help for those scenes as the camera hadn't been
moved in the first place...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> On the other hand, why would you want to use a #version older than 3.5
> for the camera?
> I think that the idea is that if you have an old scene, it won't break in
> any way if you write #version 3.1 at the beginning.
Well, OK, that's pretty minor. I'm just a very little bit annoyed
by the idea of keeping a known bug for compatibility issues, but
that one isn't going to get in my way, I think.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c42cc35@news.povray.org...
> In article <rsJ### [at] econymdemoncouk> , Mike Williams
> <mik### [at] nospamplease> wrote:
>
> > Isosurfaces *much* slower in beta 7?
> > (isosurfaces with "evaluate" are now very slow)
> > http://news.povray.org/3bdf24b3$1@news.povray.org
>
> Excuse me, but I am slowly getting upset you continue to fail to take this
> off the list. There is no point in keeping a list of bugs if you keep
> things on there that have been explained as user errors several times...
>
> Thorsten
I tried following all of the threads pertaining to this. I'm still confused
and/or just not remembering everything correctly. For clarity, is 'evaluate'
deprecated? (i.e. unnecessary from the user's perspective) Or, are there cases
where it might still be useful but, as with some other features, one can -- and
should -- expect it to be slower?
If so, then, in Mike's defense; until the documentation is updated doesn't its
presence here keep the changes from being continually re-reported as a bug?
--
light_source{0,1}#macro c(J,a)sphere{0,1pigment{rgb z}scale a translate J+O}
#end#macro B(R,V,O)c(0,4)intersection{c(V,R)difference{c(-z*4x+10)c(-z*4.1x+
10)c(0<7.5,45,5>)}}#end B(12,0z*25)B(8y*4<0,12,50>) // Batronyx ^"^
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams <mik### [at] nospamplease> wrote in
news:o44### [at] econymdemoncouk:
>>Function declaration and namespace
>>http://news.povray.org/l2ji3uc2k9su99o2gct3n2thgqoq7f4pd5%404ax.com
> I got totally confused by this thread, and can't seem to see if
> anything ever actually got confirmed, and if so, what.
To clarify, the original issue was that an identifier which has been used
to declare a function name cannot be reused as the name of a macro
parameter. I can specifically confirm that the sample code provided
(below) will not parse.
#local F=function {x}
#macro P(F) #end
While this might not look like a big deal, consider that the following
won't parse because Pt is a parameter used in transforms.inc:
#declare Pt=function{1}
#include "shapes.inc"
Nor, for that matter, will this parse:
#macro Pt(X) #end
#include "shapes.inc"
The net result is no macro or function may have the same name as _any macro
parameter name in the standard include files._ Given that none of the
parameter names in the standard macros comply with the traditional lower-
case only limitation on reserved names, nor are the names documented,
naming macros and functions has become somewhat of a gamble.
IMO, there's at least one problem here, in terms of the namespace
requirements, the naming of parameters in the standard macros, and/or in
the list of reserved keywords.
>>Wrong highlighting in editor (function_id)
>>http://news.povray.org/jfji3ug1faevn1jk3mlko64sb71ptmmn97%404ax.com
> Unconfirmed
Confirmed now.
Incidentally, do you have a current list of unconfirmed bugs? I'd like to
go through it and look for confirmable problems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 14 Jan 2002 19:45:45 +0000, Mike Williams <mik### [at] nospamplease> wrote:
> Tracking these was a bit of a nightmare because some of them arrived on
> my newserver with completely different subject lines and subtly
> different message ids. I can search my article database by either of
> those fields, or by author
You can always check via www-interface http://news.povray.org/.
It catch thread sometimes better then newsreaders.
> (but you wrote so many!).
I wait for place in Bug Reports Boulevard ;)
> > Crash with redeclared functions
> > http://news.povray.org/q6g83u4egq3ts0m8ip5nkn5lf0ljkacu8g%404ax.com
> > (Thorsten said it is not legal syntax but there is still bug becouse of crash)
>
> Original Subject: crash during function creation in loop
> Isn't this already reported in the thread that Thorsten referred you to?
Thorsten answered to both to point both use not legal syntax. However first
generates crash...
> >Not catched function redeclaration
> >http://news.povray.org/tis83ugh1kcc22h5o6is9qpkv61pjgunc0%404ax.com
> >(Thorsten said it is not catched illegal syntax, perhaps the same job number as
> >above)
>
> Original Subject: can't redefine identifier
> OK
... and second not generates warnings.
That's completly different behaviour.
> > Function declaration and namespace
> > http://news.povray.org/l2ji3uc2k9su99o2gct3n2thgqoq7f4pd5%404ax.com
>
> I got totally confused by this thread, and can't seem to see if anything
> ever actually got confirmed, and if so, what.
For me it is confirmed by Tor in
http://news.povray.org/3C3A373B.2AB132D2%40hotmail.com
> > Wrong highlighting in editor (function_id)
> > http://news.povray.org/jfji3ug1faevn1jk3mlko64sb71ptmmn97%404ax.com
>
> Unconfirmed
Confirmed now in
http://news.povray.org/Xns919716BADF51Dcsbhccse%40204.213.191.226
> > Splines - not working legal statement
> > http://news.povray.org/m7fq3u41ctia9e6i3tbnlstn6ek739vpke%404ax.com
>
> Original Subject: splines - documentation and reality
>
> I'm not logging documentation errors. If there's anything there that's
> not a documentation error, then I believe it's unconfirmed.
It was confirmed (with new code) by the author of spline patch two days befor
your list. See http://news.povray.org/3c3fc5ec%40news.povray.org
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Batronyx" wrote..
> I tried following all of the threads pertaining to this. I'm still confused
> and/or just not remembering everything correctly. For clarity, is 'evaluate'
> deprecated? (i.e. unnecessary from the user's perspective) Or, are there cases
> where it might still be useful but, as with some other features, one can --
and
> should -- expect it to be slower?
That is useful in some cases. For example, try the following JRG's
code with "evaluate 1.2, 1.1, 0.98" instead of "evaluate 1, 10, 0.99".
http://news.povray.org/3bdf2d82%40news.povray.org
The rendering speed would be faster than the fixed max_gradient.
Those parameters of the recent beta work as designed.
The description of those parameters can be seen at
http://news.povray.org/3be10cf9@news.povray.org
The max_gradient of above scene is less than 2.
Thus, 10 is too big for the second parameter of 'evaluate' if the user
want to render it as fast as possible.
If the user does not now the max_gradient, 10 would be good
for the first step as described in POV-Help 6.5.4.1.
However, to determine the parameters, the user need to know the
max_gradient value. But the current beta does not report the
max_gradient value if 'evaluate' is used... That is not consistent with
POV-Help.
R. Suzuki
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 16 Jan 2002 00:35:58 +0900, "R. Suzuki" <r-s### [at] aistgojp> wrote:
> However, to determine the parameters, the user need to know the
> max_gradient value. But the current beta does not report the
> max_gradient value if 'evaluate' is used... That is not consistent with
> POV-Help.
I can confirm with POV 3.5 b 10.icl on PII 233 128 MB with NT 4 Sp 6
ABX
--
disc{z,-z 5#macro O()asc(substr("-+((1*(,1,/.-,*/(,&.323/'1"e,1))*.1-4#declare
e=e-1;#end#local e=26;pigment{#local g=function(_){ceil(_)-_}function#local//X
k=function{pattern{object{sphere_sweep{linear_spline 13#while(e>0)<O(),O()//AB
>.01#end}}}}{k(g(atan2(x,y)),g(ln((y+x)^2+1e-5)),0)}}finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c444c4b@news.povray.org> , "R. Suzuki" <r-s### [at] aistgojp>
wrote:
> However, to determine the parameters, the user need to know the
> max_gradient value. But the current beta does not report the
> max_gradient value if 'evaluate' is used... That is not consistent with
> POV-Help.
It is by design for _this_ beta and part of the changes to the output that
have been in progress for several weeks now until a final solution can be
found. The previous beta versions' output was incorrect, the current change
only disables the incorrect output without providing the correct output yet.
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 is by design for _this_ beta and part of the changes to the output that
> have been in progress for several weeks now until a final solution can be
> found. The previous beta versions' output was incorrect, the current change
> only disables the incorrect output without providing the correct output yet.
>
I suppose this means that part is still subject to change and i should
wait with writing the announced doc part.
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
|
|
| |
| |
|
|
|
|
| |
|
|
