 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Skiba <abx### [at] babilon org> wrote:
>> Because there is change 1526...
>
> Then the name of 1526 fix should be fixed to "Final fix for radiosity
> recursion problems" in next RC then ;-)
No, because it did not fix the problem, it simply restored the old behavior.
The changes which caused the problems were made because some other part was
using much more stack space then really necessary. The best solution was to
move some arrays that were allocated on the stack into arrays allocated in the
heap and to add a pool that prevents frequent (and thus time-consuming)
allocating/freeing. The side effect of this is that more layers are now
supported in texture tests (which is noted in the same change). So fixing one
bug (http://news.povray.org/povray.beta-test/21445/) adds a feature as well
:-)
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 <3CC54881.BC5FFDD5@gmx.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
> All right, but i'm afraid it's no more that short then.
I found the problem. There currently is no workaround other than using less
complex functions.
In fact the problem is fairly serious but random in nature because it is
related to a changed pointer returned by a realloc() not getting used
everywhere...
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:
>
> [...]
>
> I found the problem.
Nice.
> In fact the problem is fairly serious but random in nature because it is
> related to a changed pointer returned by a realloc() not getting used
> everywhere...
Does this mean it will be fixed in next beta?
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3CC5A8C0.5E74D59B@gmx.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
> Does this mean it will be fixed in next beta?
Of course :-)
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:
> In article <2oY### [at] econymdemoncouk> , Mike Williams
> <mik### [at] nospamplease> wrote:
>
>
>>Text objects appear to be slightly tilted
>>http://news.povray.org/3C306096.7040705@videotron.ca
>>
>
> Was explained in the thread.
No. What was explained was that I had to scale the text object by 10000
to make the problem visible to the naked eye.
It appears that as the truetype font is parsed, a little error is added
to the z component of every control point. Since this is not reported
with other splines or polygons*, I must assume that it is a problem with
the code that converts the 2D set of control points of a truetype font
to POV 3D points.
*I'm downloading RC2 as we speak, I'll test my theory tonight.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* videotron.ca */}camera{location<6,1.25,-6>look_at a orthographic}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3CC### [at] videotronca> , Francois Labreque
<fla### [at] videotronca> wrote:
> It appears that as the truetype font is parsed, a little error is added
> to the z component of every control point. Since this is not reported
> with other splines or polygons*, I must assume that it is a problem with
> the code that converts the 2D set of control points of a truetype font
> to POV 3D points.
But in order to assume this you already assume that (a) text characters are
internally presented by the same primitive as other objects and (b) that
characters are converted to 3d shapes before being rendered. Both assumptions
are incorrect.
There is no "little error is added to the z component of every control point"
as the source code (of 3.1 for you right now, but nothing changed in 3.5)
clearly shows.
As I have pointed out numerous times before, this is simply a precision error
no matter how much you or others test your "theory", looking at the "fact" -
the source code - easily proves your "theory" wrong.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> In article <3CC### [at] videotronca> , Francois Labreque
> <fla### [at] videotronca> wrote:
>
>
>>It appears that as the truetype font is parsed, a little error is added
>>to the z component of every control point. Since this is not reported
>>with other splines or polygons*, I must assume that it is a problem with
>>the code that converts the 2D set of control points of a truetype font
>>to POV 3D points.
>>
>
> But in order to assume this you already assume that (a) text characters are
> internally presented by the same primitive as other objects and (b) that
> characters are converted to 3d shapes before being rendered. Both assumptions
> are incorrect.
I didn't mean to say that truetype fonts were converted to meshes or
prism objects, if that's what you think. I made these "assumptions"
assumption because, as you recommend below, I looked at the source code
before making that reply and misinterpreted what GetZeroOneHits() does.
>
> There is no "little error is added to the z component of every control point"
> as the source code (of 3.1 for you right now, but nothing changed in 3.5)
> clearly shows.
Again, sorry for using the wrong words. but...
>
> As I have pointed out numerous times before, this is simply a precision error
> no matter how much you or others test your "theory", looking at the "fact" -
> the source code - easily proves your "theory" wrong.
You said "precision error", I said "little error addred to the z
component". Don't you think that amounts to the same thing?
The fact remains that:
- the longer the string, the larger the imprecision.
- this only affects text objects.
- it always increases in a left-to-right, top to bottom fashion.
- By the same amount.
It seemed to me like something that could be fixed. But if you say it
can't, then I'll drop the issue.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* videotron.ca */}camera{location<6,1.25,-6>look_at a orthographic}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3cc34e42@news.povray.org:
From the fixed bugs section:
> * Function namespace problem
> (Declared function names can't be used as macro parameter names. Might
> not be possible to be fixed with the current parser. This is being
> investigated.)
> Reported in:
> function declaration and namespace
> http://news.povray.org/l2ji3uc2k9su99o2gct3n2thgqoq7f4pd5@4ax.com
This one is still present / back in part in Windows RC3 with regard to
#macro names rather than functions.
Example scene:
#macro Center(obj)
object {obj}
#end
#include "shapes.inc"
Parsing fails on line 248 of shapes.inc when the Spheroid macro attempts to
use 'Center' as a parameter name.
If this can't be fixed in the parser, could the standard includes be
modified so their parameter names are all lower case (like all other Pov
keywords) or otherwise mangled to reduce the chances of collisions with
user macros? Coming up with macro names that don't collide is a real
headache as long as this bug is in place because so name good names are
already wasted on macro parameters.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226> , che### [at] sympaticoca
(Coridon Henshaw) wrote:
> Parsing fails on line 248 of shapes.inc when the Spheroid macro attempts to
> use 'Center' as a parameter name.
>
> If this can't be fixed in the parser, could the standard includes be
> modified so their parameter names are all lower case (like all other Pov
> keywords) or otherwise mangled to reduce the chances of collisions with
> user macros? Coming up with macro names that don't collide is a real
> headache as long as this bug is in place because so name good names are
> already wasted on macro parameters.
Well, how is a limitation going to be removed if nobody in the past four years
complained about it?
It isn't a new limitation in 3.5 also you seem to give that impression.
Having the same name twice in the same namespace simply cannot work. It is
definitely not a bug and the documentation explains the namespace rules.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Coridon Henshaw wrote:
>
> This one is still present / back in part in Windows RC3 with regard to
> #macro names rather than functions.
>
> Example scene:
>
> #macro Center(obj)
> object {obj}
> #end
>
> #include "shapes.inc"
>
> Parsing fails on line 248 of shapes.inc when the Spheroid macro
> attempts to use 'Center' as a parameter name.
>
> If this can't be fixed in the parser, could the standard includes be
> modified so their parameter names are all lower case (like all other
> Pov keywords) or otherwise mangled to reduce the chances of collisions
> with user macros? Coming up with macro names that don't collide is a
> real headache as long as this bug is in place because so name good
> names are already wasted on macro parameters.
A consistent naming scheme will alleviate this problem.
For instance, I prefix vector names with a v, scalars with s,
index variables with i, and so on.
Regards,
John
--
Rusty is rendering!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
