 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Re: trivial question on topic (job000038)
(Poly Object Bug: heart has a dark line of artifacts)
http://news.povray.org/3BEBEB4C.CA854309@pacbell.net
Highlight bug (job000137)
(highlights are sometimes visible where they should be in shadow)
http://news.povray.org/3bb4cf08@news.povray.org
Macro bug (job000146)
(POV can dereference a deallocated pointer if you return a local from a
macro.)
http://news.povray.org/3BB4ED11.8EC69CEC@hotmail.com
(also reported as: strings operations crash with both compiles
http://news.povray.org/e3piut8anmf4cli4pnfmstadgc3nleqvb2@4ax.com)
Radiosity sampling, with fix method (job000177)
(radiosity sample counter is reset to the start every time, sampling
artefacts are produced)
http://news.povray.org/3BC5A13E.9C022BD6@reading.ac.uk
Strange spline problem (job000181)
(Changes from render to render. Control points are sometimes missing.)
http://news.povray.org/Xns9136AC2E64F60seed7@povray.org
Spline bug (job000182)
(The spline path is all wrong when certain time values are used.)
http://news.povray.org/3bb41dc8@news.povray.org
Blob problem (job000189)
and Blob : Toward a solution
(blob surface develops holes when "radius" is very small)
and Possible bug with blobs
(blob surface develops holes when the traced ray starts close to its
surface)
http://news.povray.org/3b99052c@news.povray.org
http://news.povray.org/3B991C90.D715B7A3@free.fr
http://news.povray.org/3c407ad3$1@news.povray.org
Additional (?) blob bug (job000189)
(blob component disappears when radius is 317 or greater)
http://news.povray.org/Xns9115B92CF7D8ACQ@204.213.191.226
(also reported as: Blob rendering error (job000136))
http://news.povray.org/Xns91203DC7F3CCQ@204.213.191.226
Bug with blobs and media (job000189)
(possibly related to blob surface develops holes when "radius" is very
small)
http://news.povray.org/3be5f0b2@news.povray.org
Blob component textures transformed twize (job000189)
http://news.povray.org/3bf70645@news.povray.org
Superellipsoid epsilon to big ? (job000190)
(strange dark patches occur on a superellipsoid when the east-west-
exponent is set very small)
http://news.povray.org/3b992a81@news.povray.org
Slow rendering when using +ua and antialiasing method 1 (job000191)
(No details available)
http://news.povray.org/3bbf6347@news.povray.org
Bug: dispersion_samples affects photon brightness (job000193)
(higher dispersion_samples also gives brighter refractive photons)
http://news.povray.org/MPG.1631c5fca936293298969e@news.povray.org
Another strange photon behavior (job000195)
(a: bright colored caustics. b: holes/circular black spots)
http://news.povray.org/MPG.16510f3e44067d3f9896ae@news.povray.org
panoramic projection bug? (job000196)
(In progress)
http://news.povray.org/avnfut8fof5ualgf8hnrtpl1knlg8828sp@4ax.com
Light_sources in light_groups don't cast shadows (job000197)
(rendering without light buffers (-UL) puts the shadows back)
http://news.povray.org/3bfd4d63@news.povray.org
no_image, merge and shadows (job000198)
(setting no_image to an object in a merge causes that object to stop
casting shadows)
http://news.povray.org/vqfd0ucm5276q9j8sdh34afjliapc1kj0n@4ax.com
Re: triangle texture interpolation (job000199)
(the second texture is on the first point and the third texture is used
on the second and third points)
http://news.povray.org/3C0A8288.DDA0905B@free.fr
bug in sphere_sweep for removing parts of an object (job000200)
(discontinuous normals on inverse of sphere_sweep)
http://news.povray.org/3C1A5D47.EA38F6E5@amc.uva.nl
bug in sphere_sweep for removing parts of an object
(parameterised sphere_sweeps are very slow. May or may not be related to
job000176)
http://news.povray.org/3C1A5D47.EA38F6E5@amc.uva.nl
color dot operators (job000201)
((Color.red) doesn't work as a macro parameter)
http://news.povray.org/ofpr1ug9r6q3cak417pmj72bck6ufmgbtg@4ax.com
Bicubic patch triangles disappear (job000202)
(When the triangles are fairly small)
http://news.povray.org/3c23b26c@news.povray.org
Array assignment crash (job000203)
(It should overwrite the old array with the newly created, correct
array, but crashes)
http://news.povray.org/3bcc54ab$1@news.povray.org
Photon Problems (job000204)
(Rendering the file makes the image strangely bright)
http://news.povray.org/3bc4d0a9$1@news.povray.org
crash during debugging of parsing (job0205)
http://news.povray.org/332m2uspk9nfqfq6g7oc8qtmkcu5higjs7@4ax.com
crash with loop (job000205)
(infinite loop of "#local"s causes stack fault)
http://news.povray.org/3c2cb9b7@news.povray.org
#macro crush (job000206)
http://news.povray.org/3c2c78cf$1@news.povray.org
double_illuminate only works with direct lighting (job000207)
http://news.povray.org/3BF6F1FE.D21B0C6@oreka.com
Strange alpha channel bug
(assumed_gamma affects the transparency of shadowed areas)
http://news.povray.org/3c1168c5$1@news.povray.org
Slow render time after several runs
(when stopped during radiosity calculations and restarted)
http://news.povray.org/3bd40c6d$1@news.povray.org
Crash with no objects in scene
(Doesn't happen on most people's machines. Only crashes on my machine
when bounding_threshold=0)
http://news.povray.org/3bd985b0@news.povray.org
(also reported as http://news.povray.org/3C19B9EA.D2E16FBC@gmx.de)
problem with transparent image_maps
(Objects with transparent image_maps have "non-transparent" shadows)
http://news.povray.org/3c24d1b3@news.povray.org (cancelled)
http://news.povray.org/eGSwuBAritK8EwLH@econym.demon.co.uk
CSG difference with text
(Text objects appear to be very slightly tilted)
http://news.povray.org/3c304eaf@news.povray.org
Julia object bug (Michael McKnight)
(Visually similar to coincident surfaces)
http://news.povray.org/3839f08c@news.povray.org
Problem with #read
http://news.povray.org/3c33b55d@news.povray.org
tiff problems in reading (including crash, including [doc])
(beta9: LZW decompression fails. 4-bit scrambles the colours. 1-bit and
24-bit upside down. JPG decompression crashes)
http://news.povray.org/n96b3uk1ft7mvb991s3htjt14ekb7j8fn7@4ax.com
crash with some boxes /infinite boxes
http://news.povray.org/3c375d62$1@news.povray.org
#while crash..
http://news.povray.org/3c38646f@news.povray.org
Mapping warp and render window bugs
(Object lighting is calculated incorrectly when mapping warps are used
in normals and the object is rotated)
http://news.povray.org/Xns9190F27EBFE9Bcsbhccse@204.213.191.226
Mapping warp and render window bugs
(Maximizing the render window during a trace will occasionally leave a
partial line of the checkerboard background visible)
http://news.povray.org/Xns9190F27EBFE9Bcsbhccse@204.213.191.226
Small window title bug
(Title switches back to "POV-Ray for Windows" after minimize or
restore.)
http://news.povray.org/3ba92966$1@news.povray.org
Black outline in smooth meshes
(The outline of smooth meshes exhibit black dots or areas (which go away
with double_illuminate))
http://news.povray.org/3bf6794e$1@news.povray.org
Render Window Bug
(Render window pops up when application minimised, after which the
application doesn't open when clicked on the task bar.)
http://news.povray.org/3bde157e@news.povray.org
Povray main window disappears during rendering
(Possibly the same as the above)
http://news.povray.org/3c1350f4@news.povray.org
installer behaves strangely
(one would expect povray to install after pressing the "next" button and
not the "button")
http://news.povray.org/Xns916AE9B08012frankverlaathotmailc@204.213.191.2
26
Little render window bug?
(If either the width or the height of an image you're rendering is
bigger than the screen's size, then the sliders of the render windows
show in both (height and width) sizes and you can't see the full image
at once, even if one of the image_sizes is smaller than the screen)
http://news.povray.org/3c3746d6@news.povray.org
silly winpov bug
(Double clicking the title bar on some machines causes "text selection
not supported")
http://news.povray.org/3c3b7a3f@news.povray.org
crash inside two #while
(Possibly specific to Windows 2000)
http://news.povray.org/3c3f1f29$1@news.povray.org
bug : declared camera with normal statement crashes
http://news.povray.org/3C41A226.7030703@skynet.be
crash with photons, union, ior, lathe
(Intel compile only)
http://news.povray.org/vfra4u0ndv4rf951196881cpt842an4906@4ax.com
can't redefine identifier
(Parser fails to trap some attempts to illegally redefine functions)
http://news.povray.org/tis83ugh1kcc22h5o6is9qpkv61pjgunc0@4ax.com
Wrong highlighting in editor
(function_id)
http://news.povray.org/jfji3ug1faevn1jk3mlko64sb71ptmmn97%404ax.com
[Windows] Save As... with same filename doesn't work
http://news.povray.org/3c44497e$1@news.povray.org
max_trace_level affects radiosity recursion_limit
((beta 10) max_trace_level sets an upper bound on recursion_limit)
http://news.povray.org/3BE40295.6C3D54DE@engineer.com
Media visible container line in front of object
(a visible whitish line appears at the edge of a transparent container
box for media)
http://news.povray.org/3bf45a3d@news.povray.org
[win gui] line with error highlighted but render finished succesfully
http://news.povray.org/va2tvt4tuitd67ik5t9ps334sbg6205bt3@4ax.com
transform syntax
(transform {test_trans} sometimes requires {} and sometimes doesn't)
http://news.povray.org/3C09EE1B.A38DC91A@gmx.de
media & fog bug?
http://news.povray.org/3c1379e0$1@news.povray.org
Re: Mosaic... some clarifications
(#local A2=P(1,2,3).hf; fails)
http://news.povray.org/9n9j1uo0mdlrs4i5toupujr0pqrj4vvb8d@4ax.com
Re: hollow in light groups
http://news.povray.org/3c21172d$1@news.povray.org
Bug with transform syntax
http://news.povray.org/chrishuff-5FC1B7.19310427122001@netplex.aussie.or
g
Minor Windows annoyance
http://news.povray.org/3c2bec89@news.povray.org
Function declaration and namespace
(?)
http://news.povray.org/l2ji3uc2k9su99o2gct3n2thgqoq7f4pd5@4ax.com
splines - documentation and reality
(?)
http://news.povray.org/m7fq3u41ctia9e6i3tbnlstn6ek739vpke@4ax.com
Beta 10 bugs
(2.3 The inside_vector keyword is highlighted in the editor)
http://news.povray.org/Xns9197A5B08390CCQ@204.213.191.226
Mapping warp and render window bugs
(2. Maximizing the render window during a trace will occasionally leave
a partial line of the checkerboard background visible)
http://news.povray.org/Xns9190F27EBFE9Bcsbhccse@204.213.191.226
[win] "cpu time used" not works properly
(CPU time used not reported in stream when render completes normally.)
http://news.povray.org/llj84uk2findr74u9jpge6dlteqf19c70o@4ax.com
[std include] hf_* macros doubts
http://news.povray.org/1dtd4ug8htn1ns9md3vp9i1mbcq5qf10sb@4ax.com
sin(X)^sin(X) -> crash! (job000179 and job000180)
http://news.povray.org/3baf7992@news.povray.org
another crash with max_intersections
http://news.povray.org/j8fo2u8mbo97gi3as0udmab7t9ttap2iom@4ax.com
Partial render memory leak
http://news.povray.org/3C47228A.D7680441@twoalpha.net
Axis_Rotate_Trans
(doesn't work with Axis = <-1, 1, -1>)
http://news.povray.org/3c47c315@news.povray.org
Re: IsoCacti.pov
(Falls foul of b10 camera syntax changes)
http://news.povray.org/1$sqAKA8LkR8Ewk5@econym.demon.co.uk
Insertmenu rerender - some strange scenes
(Fall foul of b10 camera syntax changes)
http://news.povray.org/3c492689@news.povray.org
continue trace fails with pngs
http://news.povray.org/3c487cf8@news.povray.org
Doc in Apple Help Viewer
(The POV-Ray documentation isn't listed in the "Help Center")
http://news.povray.org/B86F3A84.2A31%cwa### [at] gmx ch
radiosity problem
http://news.povray.org/3c49968f@news.povray.org
blob casting incorrect shadows on itself
http://news.povray.org/Xns919C1CAA3E23Egerovandordatanethu@204.213.191.2
26
<1, 0, 0> + 1*t
(Vector arithmetic using "t" behaves oddly)
http://news.povray.org/3c4bb31d$1@news.povray.org
Initialisation of a 4-vector array
(Vector arithmetic using "t" behaves oddly)
http://news.povray.org/3c4fe83b@news.povray.org
Severe Lightbug, probably concerned with Macros... (long post)
(Objects with doubly rotated warp turbulence normals appear to
illuminated incorrectly)
http://news.povray.org/3C4ABED3.F038E200@gmx.de
Heightfield bug (most probably an inverted normals problem)
http://news.povray.org/3c4ca8ff@news.povray.org
Beta10-Linux Segmentation Fault
(while sorting photons)
http://news.povray.org/3C4D93F1.2000005@gmx.de
[wingui] EAccess violation
(POV reopenned with scene file network disk unmapped)
http://news.povray.org/krjv4u0lvc9k5h9hm05hk6onvvh43phqle@4ax.com
rare conic prism bug
(strange behaviour of illumination/texture of conic prisms)
http://news.povray.org/3C51212E.9090707@irrwerk.de
macros without commas takes parameter wrongly
http://news.povray.org/bp925u4upa1gl9kih2pikg4qusf0lr03kg@4ax.com
[scenes] Beta 10 syntax changes
http://news.povray.org/joMfFCAyfTS8EwOo@econym.demon.co.uk
Shadow faults
http://news.povray.org/3c53b38e@news.povray.org
FIXED IN NEXT BETA
Camera is off by half a pixel (job000209)
http://news.povray.org/3bccc696@news.povray.org
(possibly the same as: the lowest pixel getting dimmed)
http://news.povray.org/3c23cd13@news.povray.org
How to Unexpire POV Ray Beta
(Beta expiry code is insufficiently secure)
http://news.povray.org/3c453246@news.povray.org
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams <mik### [at] nospamplease> wrote:
: Black outline in smooth meshes
: (The outline of smooth meshes exhibit black dots or areas (which go away
: with double_illuminate))
: http://news.povray.org/3bf6794e$1@news.povray.org
: Heightfield bug (most probably an inverted normals problem)
: http://news.povray.org/3c4ca8ff@news.povray.org
AFAIK these two are symptoms of the same problem, which I discussed in the
latter thread.
It's not really a bug in smooth meshes nor in heighfields (they work
flawlessly in this context, ie. they always return the correct normal), but
the problem (not really a bug, as it's not a programming mistake) is at a
higher level.
The problem happens when the actual surface normal is pointing at the
incoming ray (ie. the angle between the incoming ray vector and the surface
normal vector is >90 degrees) but the object returns a normal vector which
points away from the incoming ray (ie. the angle is <90). This happens in
certain cases in smooth heighfields and smooth meshes.
The flaw is not in the heightfield or the mesh code: They return the correct
normal vector.
The flaw is in the calling routine, which inverts this normal vector if it
sees that its angle is <90 with respect to the ray vector.
This inversion is essential for the lighting to work and it's ok when the
object returns the actual surface normal.
However, this inversion routine does not take into account that the normal
returned by the object may not be the actual surface normal, but a perturbed
normal. It *assumes* that the normal vector the object returns is the actual
surface normal. This is the flaw.
The only solution I can think of is that this routine does not perform the
inversion if the condition described above is fullfilled. (And I think that
it has to be checked in both ways, as it has to work with the same idea also
when the ray hits the object from inside.) Thus, the normal inversion routine
would need to do something like this:
if(weWantToInvertTheNormal &&
dotproduct(Ray,RealNormal)*dotproduct(Ray,ReturnedNormal) >= 0)
{
invert(ReturnedNormal)
}
The problem is that the object does not return the real normal of the surface
but just the perturbed one. Thus the inversion routine can't do that.
To fix this problem, it would be necessary to somehow get the real surface
normal from the object.
This is probably something that will be possible (in a nice way) only in
povray 4, where the whole code is rewritten (as it's completely rewritten, then
this kind of thing can be taken into account).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Strange alpha channel bug
> (assumed_gamma affects the transparency of shadowed areas)
> http://news.povray.org/3c1168c5$1@news.povray.org
Logged as job000210.
> problem with transparent image_maps
> (Objects with transparent image_maps have "non-transparent" shadows)
> http://news.povray.org/3c24d1b3@news.povray.org (cancelled)
> http://news.povray.org/eGSwuBAritK8EwLH@econym.demon.co.uk
Logged as job000211.
> CSG difference with text
> (Text objects appear to be very slightly tilted)
> http://news.povray.org/3c304eaf@news.povray.org
While very extreme, this is still a coincident surface problem. Using less
excessive scales will make it go away.
> Julia object bug (Michael McKnight)
> (Visually similar to coincident surfaces)
> http://news.povray.org/3839f08c@news.povray.org
The supplied scene is absolutely unsuitable to say anything, not even detailed
enough to say it is a problem or not.
> Problem with #read
> http://news.povray.org/3c33b55d@news.povray.org
Unless someone cleans up the mess of examples reported as not working as
expected there, it will be assumed to be a user error. Having the same file
open for read and write is plain nonsense, and the given scenes are incomplete
as the don't close the files at all. Incomplete scenes are not suitable to
reproduce or confirm bugs. Sorry!
> crash with some boxes /infinite boxes
> http://news.povray.org/3c375d62$1@news.povray.org
Not a bug. Using values that are 10e45 in size is not supported nor
documented to be supported. Future versions of POV-Ray may not allow such
misuse of syntax flexibility.
> #while crash..
> http://news.povray.org/3c38646f@news.povray.org
Assumed to be same as job000205.
> Mapping warp and render window bugs
> (Object lighting is calculated incorrectly when mapping warps are used
> in normals and the object is rotated)
> http://news.povray.org/Xns9190F27EBFE9Bcsbhccse@204.213.191.226
Logged as job000212.
> Black outline in smooth meshes
> (The outline of smooth meshes exhibit black dots or areas (which go away
> with double_illuminate))
> http://news.povray.org/3bf6794e$1@news.povray.org
Afaik double_illuminate is supposed to be used in this case. The issue of
"inverted normals" is a general problem and not specific to this object as it
has been discussed elsewhere (not sure in which thread). Reference should be
given to that thread so it can be added to the list of known bugs while this
one can be kept as a special case of a more general problem.
> silly winpov bug
> (Double clicking the title bar on some machines causes "text selection
> not supported")
> http://news.povray.org/3c3b7a3f@news.povray.org
Wasn't this fixed in beta 10 or said to be fixed in beta 11?
> crash inside two #while
> (Possibly specific to Windows 2000)
> http://news.povray.org/3c3f1f29$1@news.povray.org
Same as job000179.
> crash with photons, union, ior, lathe
> (Intel compile only)
> http://news.povray.org/vfra4u0ndv4rf951196881cpt842an4906@4ax.com
Logged as job000213.
> Wrong highlighting in editor
> (function_id)
> http://news.povray.org/jfji3ug1faevn1jk3mlko64sb71ptmmn97%404ax.com
Reported as fixing in next beta afaik.
> max_trace_level affects radiosity recursion_limit
> ((beta 10) max_trace_level sets an upper bound on recursion_limit)
> http://news.povray.org/3BE40295.6C3D54DE@engineer.com
Has not been confirmed. No example provided either.
> Media visible container line in front of object
> (a visible whitish line appears at the edge of a transparent container
> box for media)
> http://news.povray.org/3bf45a3d@news.povray.org
The example scene is too complex and it hasn't been confirmed either.
> [win gui] line with error highlighted but render finished succesfully
> http://news.povray.org/va2tvt4tuitd67ik5t9ps334sbg6205bt3@4ax.com
Isn't the highlighted error simply a text selection? Either way, the bug has
not been confirmed.
> transform syntax
> (transform {test_trans} sometimes requires {} and sometimes doesn't)
> http://news.povray.org/3C09EE1B.A38DC91A@gmx.de
Logged as job000214.
> media & fog bug?
> http://news.povray.org/3c1379e0$1@news.povray.org
This is not confirmed and there is even disagreement noted in the thread if
this is a bug at all!
> Re: Mosaic... some clarifications
> (#local A2=P(1,2,3).hf; fails)
> http://news.povray.org/9n9j1uo0mdlrs4i5toupujr0pqrj4vvb8d@4ax.com
This is not a bug at all and not documented to work the way it is used.
".hf" is only supported to help port MegaPOV functions more easily. It will
be removed completely in future versions, that is why it is simply marked as
experimental.
> Re: hollow in light groups
> http://news.povray.org/3c21172d$1@news.povray.org
>
> Bug with transform syntax
> http://news.povray.org/chrishuff-5FC1B7.19310427122001@netplex.aussie.org
Same as job000214.
> another crash with max_intersections
> http://news.povray.org/j8fo2u8mbo97gi3as0udmab7t9ttap2iom@4ax.com
Note that setting "max_intersection 0" is simply brain-dead.
> blob casting incorrect shadows on itself
> http://news.povray.org/Xns919C1CAA3E23Egerovandordatanethu@204.213.191.226
Same as the other blob bugs.
> <1, 0, 0> + 1*t
> (Vector arithmetic using "t" behaves oddly)
> http://news.povray.org/3c4bb31d$1@news.povray.org
Works as designed - not a bug. Adding 3D and 4D vectors the promotion of the
vectors is undefined, adding 4D and 4D vectors or 3D and 3D vectors is the
correct way to do it. Future versions of POV-Ray may not allow such misuse of
syntax flexibility.
> Initialisation of a 4-vector array
> (Vector arithmetic using "t" behaves oddly)
> http://news.povray.org/3c4fe83b@news.povray.org
Works as designed - not a bug. The array is created with 3D vectors and later
an attempt is made for a 4D vector into it. Future versions of POV-Ray may
not allow such misuse of syntax flexibility.
> Severe Lightbug, probably concerned with Macros... (long post)
> (Objects with doubly rotated warp turbulence normals appear to
> illuminated incorrectly)
> http://news.povray.org/3C4ABED3.F038E200@gmx.de
Assumed to be same as job000212 until someone can demonstrate it is not the
same.
> Heightfield bug (most probably an inverted normals problem)
> http://news.povray.org/3c4ca8ff@news.povray.org
See note somewhere above regarding inverted normals.
> rare conic prism bug
> (strange behaviour of illumination/texture of conic prisms)
> http://news.povray.org/3C51212E.9090707@irrwerk.de
Not properly confirmed. Just being able to reproduce the exact behavior is
not enough. At least a tiny bit of experimentation should be done to be able
to say it is a bug and not a precision problem.
> macros without commas takes parameter wrongly
> http://news.povray.org/bp925u4upa1gl9kih2pikg4qusf0lr03kg@4ax.com
Works as designed - not a bug. Commas between macro parameters are required.
Future versions of POV-Ray may not allow such misuse of syntax flexibility.
> Shadow faults
> http://news.povray.org/3c53b38e@news.povray.org
The simplified version works correctly. The long version is to complex. Not
properly confirmed.
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 <tho### [at] trfde> wrote:
:> Black outline in smooth meshes
:> (The outline of smooth meshes exhibit black dots or areas (which go away
:> with double_illuminate))
:> http://news.povray.org/3bf6794e$1@news.povray.org
: Afaik double_illuminate is supposed to be used in this case. The issue of
: "inverted normals" is a general problem and not specific to this object as it
: has been discussed elsewhere (not sure in which thread). Reference should be
: given to that thread so it can be added to the list of known bugs while this
: one can be kept as a special case of a more general problem.
It was me who studied and discussed this problem in my report about wrong
smooth heighfield lighting (inversion of normals problem). I also posted a
summary of my findings as a followup to this thread.
As I mentioned, it's most probably something that will be most easily fixed
with a full rewrite of the rendering engine in pov4. Fixing it in pov3.x would
be just a dirty hack and lot of work. (Of course this is only my opinion based
on studying the source code; I'm not a developer, so I can't speak for sure.)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Problem with #read
The following code produces this error:
#local ohh=ahh <----ERROR
Parse Error: Cannot assign uninitialized identifier.
Code:
#fopen wfile "nothing.txt" write
#fclose wfile
#fopen rfile "nothing.txt" read
#read(rfile,ahh)
#ifdef(ahh)
#local ohh=ahh;
#end
#fclose rfile
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3c596886@news.povray.org:
>> silly winpov bug
>> (Double clicking the title bar on some machines causes "text selection
>> not supported")
>> http://news.povray.org/3c3b7a3f@news.povray.org
>
> Wasn't this fixed in beta 10 or said to be fixed in beta 11?
Still present in beta 10. The behavior of this bug appears to depend on
the position of the Pov window and can be reliably repeated on all Win2K
systems I checked.
>> max_trace_level affects radiosity recursion_limit
>> ((beta 10) max_trace_level sets an upper bound on recursion_limit)
>> http://news.povray.org/3BE40295.6C3D54DE@engineer.com
>
> Has not been confirmed. No example provided either.
Confirmed in <Xns### [at] 204213191226>
Code used:
box {<-4,0,-4> <4,4,4> pigment {rgb 0.5} hollow}
box {<3.75,1,-3> <4,3,3> pigment {rgb 1} finish {ambient 10}}
sphere {y,1 pigment {rgb 0.5}}
light_source {y*3.99 rgb 1}
camera {location <0,2,-3.5> look_at <0,2,0>}
global_settings {
max_trace_level 1
radiosity {
recursion_limit 10
pretrace_start 0.08 pretrace_end 0.04 count 35 nearest_count 5
error_bound 1.8 low_error_factor .5 gray_threshold 0.0
minimum_reuse 0.015 brightness 1 adc_bailout 0.01/2
}
}
>> Media visible container line in front of object
>> (a visible whitish line appears at the edge of a transparent container
>> box for media)
>> http://news.povray.org/3bf45a3d@news.povray.org
> The example scene is too complex and it hasn't been confirmed either.
Confirmed in <Xns### [at] 204213191226>
>> [win gui] line with error highlighted but render finished succesfully
>> http://news.povray.org/va2tvt4tuitd67ik5t9ps334sbg6205bt3@4ax.com
>
> Isn't the highlighted error simply a text selection? Either way, the bug
> has not been confirmed.
Confirmed in <Xns### [at] 204213191226> The problem is not a
text selection but rather that the error highlight bar is not always
cleared even after a successful render.
>> media & fog bug?
>> http://news.povray.org/3c1379e0$1@news.povray.org
> This is not confirmed and there is even disagreement noted in the
> thread if this is a bug at all!
Confirmed in the original thread and in
<Xns### [at] 204213191226>.
Ken Tyler was the only person who asserted that the behavior described
should not be fixed. His rationale was that this bug shouldn't be fixed in
3.5 because it existed in 3.1g.
Bob H ultimately agreed with Kevin Ellis that "the box container object
itself does seem to cast a shadow when it should not be."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Coridon Henshaw" <che### [at] sympaticoca> schrieb im Newsbeitrag
news:Xns### [at] 204213191226...
> "Thorsten Froehlich" <tho### [at] trfde> wrote in
> news:3c596886@news.povray.org:
>
> >> silly winpov bug
> >> (Double clicking the title bar on some machines causes "text selection
> >> not supported")
> >> http://news.povray.org/3c3b7a3f@news.povray.org
> >
> > Wasn't this fixed in beta 10 or said to be fixed in beta 11?
>
> Still present in beta 10. The behavior of this bug appears to depend on
> the position of the Pov window and can be reliably repeated on all Win2K
> systems I checked.
I tried it (under 2K) and you are right.
Note sure if this was noted before, but after resizing the mouse position
needs to be inside the message window area. If it is not, nothing happens
of course.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3c5a585f$1@news.povray.org:
> Note sure if this was noted before, but after resizing the mouse
> position needs to be inside the message window area. If it is not,
> nothing happens of course.
Yep; it's been noted. I posted that observation a while back.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Thorsten Froehlich who wrote:
>> Shadow faults
>> http://news.povray.org/3c53b38e@news.povray.org
>
>The simplified version works correctly.
No way! The shadows are missing until the boxes are put into a merge.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 31 Jan 2002 16:53:39 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > [win gui] line with error highlighted but render finished succesfully
> > http://news.povray.org/va2tvt4tuitd67ik5t9ps334sbg6205bt3@4ax.com
>
> Isn't the highlighted error simply a text selection?
Text selection is black on my computer while highlighted error makes whole line
yellow.
> Either way, the bug has not been confirmed.
confirmed in http://news.povray.org/Xns9198AD4D5BBF4CQ@204.213.191.226
I can describe additional situation when it appear if necessary.
> > another crash with max_intersections
> > http://news.povray.org/j8fo2u8mbo97gi3as0udmab7t9ttap2iom@4ax.com
>
> Note that setting "max_intersection 0" is simply brain-dead.
Is this logged or not ? When I reported it I know nonsense of this but when
somebody do this with wrongly constructed loop he shouldn't crash his engine.
> > rare conic prism bug
> > (strange behaviour of illumination/texture of conic prisms)
> > http://news.povray.org/3C51212E.9090707@irrwerk.de
>
> Not properly confirmed. Just being able to reproduce the exact behavior is
> not enough. At least a tiny bit of experimentation should be done to be able
> to say it is a bug and not a precision problem.
I confirmed this behaviour but you are right, this can be typicall precision
problem of orthographic camera. removing of "orthographic" keyword returns
functionality. Adding rotate y*3 to prism with orthographic camera also makes
all parts visible. So it is possible that it precision problem just like my old
report about tours in orthographic camera.
> > macros without commas takes parameter wrongly
> > http://news.povray.org/bp925u4upa1gl9kih2pikg4qusf0lr03kg@4ax.com
>
> Works as designed - not a bug. Commas between macro parameters are required.
If commas are required then why parser not stoped parsing at macro declaration
with message like: "comma expected but T found" ? If it looks like feature
request then ignore it.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
