|
114 | Preview | Definite Bug | 3.70 beta 37a | Very Low | Low | Mosaic Preview not displaying properly | Closed | |
|
Task Description
Mosaic preview display didn’t work as expected, given these command line options: +sp64 +ep16. The preview was solid colored instead of the coarse preview that you’d expect.
I’ve tested a fix to unix/disp_sdl.cpp from clipka and it appears to work.
|
|
116 | Texture/Material/Finish | Definite Bug | 3.70 beta 37a | Very Low | Low | assertion fails when using "filter all" with small-pale ... | Closed | |
3.70 beta 38 |
Task Description
When using “filter all VALUE” with an image_map using a 4-bit (16-color) paletted bmp image, debug builds of POV-Ray fail with an assertion.
According to code analysis, other paletted image formats with <256 palette entries are also likely to be affected; similar assertion fails can be expected when using the “filter INDEX, VALUE” feature on such files with an index exceeding the palette size. “transmit” shows the same flaws.
|
|
156 | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Crash when reading from DF3 file with no data, using in ... | Closed | |
3.70 RC4 |
Task Description
A df3 file is written, with header 00 00 00 00 00 00 and no data (hypothetically valid df3 file). This file is used as density file for media, using interpolation. This causes a crash once Pov-Ray starts rendering the pixels that contain media. All pixels rendered before that render fine. Using no interpolation does not cause a crash.
Sample Scene: #fopen out “random.df3” write #write (out, uint16be <0,0,0>) #fclose out
box{0,1 pigment{rgbt 1} hollow interior{media{ density{density_file df3 “random.df3” interpolate 1}}}} // interpolate 2 also crashes, interpolate 0 does not.
System: Win7 x64, 3.7 Beta 38
|
|
158 | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Antialias Gamma reporting error | Closed | |
3.70 beta 39 |
Task Description
value is erroneously clipped to the range 0..1 before being displayed
|
|
162 | Geometric Primitives | Definite Bug | 3.6 | Very Low | Low | Character 101 (0x65) not found in /usr/share/fonts/true ... | Closed | |
3.70 beta 39 |
Task Description
The text object isn’t working with /usr/share/fonts/truetype/freefont/FreeSans.ttf. Used to work - taken from an old .pov file of mine.
Rebuilt from http://www.povray.org/redirect/www.povray.org/ftp/pub/povray/Official/Unix/povray-3.6.tar.bz2
$ povray +ifonttest.pov +ofonttest.png
Persistence of Vision™ Ray Tracer Version 3.6.1 (g++ 4.4.3 @ x86_64-unknown-linux-gnu) This is an unofficial version compiled by: darxus [at] chaosreignscom
.....
File: fonttest.pov Line: 8 Parse Warning: Character 101 (0×65) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf File: fonttest.pov Line: 8 Parse Warning: Character 115 (0×73) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf
Verification that the problem is not in the .ttf file, this works (imagemagick):
convert -background lightblue -fill blue -pointsize 48 -font /usr/share/fonts/truetype/freefont/FreeSans.ttf label:test fonttest.png
Problem verified when compiled from source on Ubuntu Lucid. Also exists in Ubuntu binaries from Lucid and Hardy.
|
|
165 | Photons | Definite Bug | 3.6 | Very Low | Low | photon problem: image of projected image_map is clipped ... | Closed | |
3.70 RC4 |
Task Description
Hi,
I have a problem with photons. The following stripped down code simulates a slide projector:
#include "colors.inc"
global_settings {
#if (1) // switch photons on/off
photons { count 1000000 }
#end
}
camera { location <0, 0, 200> sky<0,1,0> look_at <0,200,-200> angle 90 }
// projection screen
plane { z, -200 texture { pigment { White } finish{ diffuse 1 ambient 0.1} } }
// slide
polygon {
5, <0,0,0>, <1,0,0>,<1,1,0>,<0,1,0>,<0,0,0>
pigment { image_map {jpeg "s7_0.9_320.jpg" interpolate 2 filter all 1.0 } }
translate <-0.5, 0.2, -0.3>
photons { target refraction on reflection off collect off }
}
// projector lamp
light_source { <0, 0, 0> color <1,1,1> }
——————————————-
A point light source projects through a image_map onto a screen.
Without photons the projected image is ok: http://img838.imageshack.us/i/test4woph.png/
With photons the left and right bottom corners of the image will be clipped: http://img101.imageshack.us/i/test4wph.png/
The size of clipped corners depends on the y-offset in the translate command.
The povray Version is: Persistence of Vision™ Ray Tracer Version 3.6.1 (Debian (x86_64-linux-gnu-g+ + 4.3.3 @ x86_64-pc-linux-gnu)) (the 3.7 beta has the same problem)
I posted this question in the general news group and got an answer by Christian Froeschlin, who could reproduce the problem and suggested as workaround to divide the slide into small stripes
http://news.povray.org/povray.general/thread/%3Cweb.4c972bdffcc128eac947b6de0%40news.povray.org%3E/
This works, but doesn’t explain the problem.
Does anyone have an idea, whats wrong?
Many thanks, Corvin
|
|
166 | Texture/Material/Finish | Definite Bug | 3.70 beta 38 | Very Low | Low | quick_color does not work | Closed | |
|
Task Description
the quick_color feature doesn’t work when +qN or Quality=N is set to 5 or below
|
|
171 | Geometric Primitives | Definite Bug | 3.62 | Very Low | Low | CSG bounding box computation broken with shearing trans ... | Closed | |
|
Task Description
Bounding box computation for CSG intersection appears to be broken when one member is an arbitrarily transformed plane.
// +W640 +H480 +MB1
#include "transforms.inc"
camera {
location <-0.2, 0.5, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <-30, 30, -30>
}
plane {
y, -1
pigment { color rgb <0.7,0.5,0.3> }
}
intersection {
sphere {
0.0, 1 }
plane { -x, 0 transform { Shear_Trans(x,y+x*0.3,z) } }
texture {
pigment {
radial
frequency 8
color_map {
[0.00 color rgb <1.0,0.4,0.2> ]
[0.33 color rgb <0.2,0.4,1.0> ]
[0.66 color rgb <0.4,1.0,0.2> ]
[1.00 color rgb <1.0,0.4,0.2> ]
}
}
finish{
specular 0.6
}
}
rotate -y*5
}
|
|
184 | Radiosity | Definite Bug | 3.70 RC1 | Very Low | Low | Too many pretrace steps when pretrace_start < pretrace_ ... | Closed | |
3.70 RC2 |
Task Description
If pretrace_start is set below pretrace_end, POV-Ray will run a high number of pretrace steps (without changing pretrace resolution).
|
|
186 | Geometric Primitives | Definite Bug | 3.70 RC1 | Very Low | Low | numeric precision problem with polygon start/end points | Closed | |
3.70 RC2 |
Task Description
polygon objects comprised of multiple “sub-polygons” don’t work properly if start/end points of sub-polygons do not exactly match, as can be demonstrated by the following code:
#default { texture { pigment { rgb 1 } finish { ambient 1.0} } }
camera {
orthographic
up 3.5*y
right 3.5*x*image_width/image_height
location <0,0,-4>
look_at <0,0,0>
}
polygon { 8,
// outer triangle
0.70 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.70 * < cos(360 *pi/180),sin(360 *pi/180),0>
// inner triangle
0.35 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.35 * < cos(360 *pi/180),sin(360 *pi/180),0>
}
Note that the end points /should/ be identical. There are however some minor rounding differences, which mess up polygon computations. Compare with the following code, which leads to the desired results:
polygon { 8,
// outer triangle
0.70 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.70 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
// inner triangle
0.35 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
0.35 * < cos( 0 *pi/180),sin( 0 *pi/180),0>
}
Code inspection shows that the polygon insideness testing code tests for precise equality of the points, whereas the general policy of POV-Ray is to accept slight rounding differences.
|
|
191 | Texture/Material/Finish | Definite Bug | 3.70 RC1 | Very Low | Low | Using interpolated image_maps in functions results in p ... | Closed | |
3.70 RC4 |
Task Description
Using interpolated image_maps in functions results in pixel-sized dot-artifacts when using the functions back into pigments.
This problem doesn’t shows using the same code on POV-Ray 3.6.
I qualified it as “low severity” because is not going to happen to most users: it will show only when using some advances techniques, for example when you want to decompose an image_map into the RGB components, perform operations, and mixing them back with an averaged pigment (example attached).
|
|
194 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | command line parse error | Closed | |
3.70 RC4 |
Task Description
povray +Imesh_camera.pov +Omesh_camera.png +FN +W800 +H600 produces a “Failed to parse command-line option” error. when I rename my pov source file to ess_mesh_camera.pov it runs fine. seems to be pointing to a clash with the +im option. i also had another file that renaming it got me going.
|
|
196 | Subsurface Scattering | Definite Bug | 3.70 RC3 | Very Low | Low | More SSLT Caveats | Tracked on GitHub | |
Future release |
Task Description
when a prism is differenced with a primitive (cylinder in this case) if sslt is used it causes a seq fault. Reference distribution file logo.inc and the Povray_Logo_Prism definition.
|
|
197 | Other | Definite Bug | 3.70 RC3 | Very Low | Low | -J by itself does nothing | Closed | |
3.70 RC4 |
Task Description
The documentation says:
“-J Sets aa-jitter off”
However, it seems to have no effect. -J0 will turn off jittering.
|
|
200 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Calibri TrueType font garbled | Closed | |
3.70 RC4 |
Task Description
original post on povray.beta-test:
POV-Ray 3.7.0.RC3 on Slackware 13.0 x86_64.
I pointed povray to use the calibri.ttf font over on my Windows 7 partition.
The result is garbled - strange letters with accents appear instead of the
expected text. (KDE's kfontview opens calibri.ttf OK, with nothing strange).
Pointing povray to use other fonts of Win7, e.g. comic.ttf and arial.ttf, was
OK.
I solved the problem by pushing calibri.ttf through fontforge and resaving it
as mycalibri.ttf.
Cheers,
Peter
Confirmed with development version on Windows XP x64.
Possibly a similar problem as FS#162 .
|
|
202 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Numerical oddities in Julia_Fractal | Tracked on GitHub | |
|
Task Description
I understand that some things have changed in the way certain computations in POV-Ray decide when something is “good enough” and I think this is biting me in Julia_Fractal (where, of course, the highest-resolution computations are needed).
The bug has been posted here:
http://news.povray.org/povray.bugreports/thread/%3Cweb.4dbf2e26b56a53c15b4449250%40news.povray.org%3E/
Including a short .pov file and instructions that reproduce it.
(It pops up in other configurations and view angles as well, but this one captures in in a way that makes it clear it’s a bug: the distance of the camera from the origin appears to change the shape of the rendered object).
This appeared first on a Windows Server 2003 machine, it is apparently confirmable on at least one other system as per that thread.
|
|
203 | Radiosity | Definite Bug | 3.70 RC3 | Very Low | Low | Radiosity artifacts at low error_bound | Closed | |
3.70 RC4 |
Task Description
A scene of a hollow sphere viewed from the inside:
difference {
sphere { 0, 100 }
sphere { 0, 99 }
pigment { rgb 1 }
finish { ambient .4 }
}
global_settings {
radiosity {
error_bound .1
}
}
Rendering produces dark splotches at the centers of the pretrace blocks, as shown in the attached image. Blocks rendered earlier have darker splotches. They also differ in shape between renders even with +HR (but not with +WT1).
Turning “always_sample” on, changing “pretrace_end” to 0.01, or increasing “count” past 1000 makes them imperceptibly faint (they can still be seen by increasing image contrast).
This is possibly a bug, as 3.6 doesn’t produce these artifacts regardless of additional settings.
povray.beta-test thread
|
|
207 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Attempted to redefine float identifier as function ide ... | Closed | |
Future release |
Task Description
#macro A()
#local f = function { x }
#end
#local f = 1;
A()
This gives:
File 'bug.pov' line 2: Parse Error: Attempted to redefine float identifier as
function identifier.
The problem is that this makes using functions in library macros difficult. Basically, they must have a globally unique name that’s not used in any of the macros or files that call the macros. #undef doesn’t really help, because it destroys the identifier in the calling scope.
For example, one of the macros in the standard include files names a function “fn”, so this doesn’t work:
#include "transforms.inc"
#local fn = 42; // fnord?
#local fn_pos = vtransform(x, transform { rotate 30*y } );
The reason for this restriction is explained in Parse_RValue in source/backend/parser/parse.cpp:
// Do NOT allow to redefine functions! [trf]
// #declare foo = function(x) { x }
// #declare foo = function(x) { foo(x) } // Error!
// Reason: Code like this would be unreadable but possible. Is it
// a recursive function or not? - It is not recursive because the
// foo in the second line refers to the first function, which is
// not logical. Further, recursion is not supported in POV-Ray 3.5
// anyway. However, allowing such code now would cause problems
// implementing recursive functions after POV-Ray 3.5!
In this case the restriction is applied too broadly: it should be safe to redefine anything other than a function to a function and still avoid it looking like recursion. In fact, there’s a restriction in Parse_Declare specifically to prevent redefining functions.
|
|
214 | Other | Definite Bug | 3.70 RC3 | Very Low | Low | Failed to parse command-line option in Debian | Closed | |
3.70 RC4 |
Task Description
I tried to use 3.7 RC3. This was my first time with 3.7.
I got source, configured and compiled it and installed into Debian with checkinstall. And then I tried to use it. First run was with -benchmark (it took about 9 minutes, ok). Then I tried very simple scene:
rekcahx@oah:~/pov$ povray +Iaa.pov povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. Failed to parse command-line option
I tried to debug with strace:
rekcahx@oah:~/pov$ strace -o debug.strace povray +Iaa.pov povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (g++ 4.6.1 @ x86_64-unknown-linux-gnu) This is a release candidate of POV-Ray version 3.7.0. General distribution is strongly discouraged.
POV-Ray is based on DKBTrace 2.12 by David K. Buck & Aaron A. Collins Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.
Primary POV-Ray 3.7 Architects/Developers: (Alphabetically)
Chris Cason Thorsten Froehlich Christoph Lipka
With Assistance From: (Alphabetically)
Nicolas Calimet James Holsenback Christoph Hormann Nathan Kopp
Juha Nieminen
Past Contributors: (Alphabetically)
Steve Anger Eric Barish Dieter Bayer David K. Buck
Nicolas Calimet Chris Cason Aaron A. Collins Chris Dailey
Steve Demlow Andreas Dilger Alexander Enzmann Dan Farmer
Thorsten Froehlich Mark Gordon James Holsenback Christoph Hormann
Mike Hough Chris Huff Kari Kivisalo Nathan Kopp
Lutz Kretzschmar Christoph Lipka Jochen Lippert Pascal Massimino
Jim McElhiney Douglas Muir Juha Nieminen Ron Parker
Bill Pulver Eduard Schwan Wlodzimierz Skiba Robert Skinner
Yvo Smellenbergh Zsolt Szalavari Scott Taylor Massimo Valentini
Timothy Wegner Drew Wells Chris Young
Other contributors are listed in the documentation.
Support libraries used by POV-Ray:
ZLib 1.2.3.4, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
LibPNG 1.2.44, Copyright 1998-2002 Glenn Randers-Pehrson
LibJPEG 62, Copyright 1998 Thomas G. Lane
LibTIFF 3.9.5, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Boost 1.46, http://www.boost.org/
OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.
Parser Options
Input file: aa.pov
Remove bounds........On
Split unions.........Off
Library paths:
/usr/share/povray
/usr/share/povray/ini
/usr/share/povray/include
Clock value: 0.000 (Animation off)
Image Output Options
Image resolution.....320 by 240 (rows 1 to 240, columns 1 to 320).
Output file..........aa.png, 24 bpp PNG
Dithering............Off
Graphic display......Off
Mosaic preview.......Off
Continued trace......Off
Information Output Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
[Parsing...]
Parse Warning: This scene did not contain a #version directive. Please be aware that as of POV-Ray 3.7, unless already specified via an INI option, a #version is expected as the first declaration in a scene file. POV-Ray may apply settings to some features that are intended to maintain compatibility with pre-3.7 scenes. You are strongly encouraged to add a #version statement to the scene to make your intent clear. Future versions of POV-Ray may make the presence of a #version statement mandatory.
Parser Statistics
Finite Objects: 1 Infinite Objects: 0 Light Sources: 1 Total: 2
Parser Time
Parse Time: 0 hours 0 minutes 0 seconds (0.001 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
—————————————————————————- Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........Off
[Rendering...]
Rendered 76800 of 76800 pixels (100%)
Render Statistics Image Resolution 320 x 240
Pixels: 76800 Samples: 0 Smpls/Pxl: 0.00 Rays: 76800 Saved: 0 Max Level: 1/5
Ray→Shape Intersection Tests Succeeded Percentage
Box 78226 1426 1.82
Shadow Ray Tests: 1426 Succeeded: 0
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 0 seconds (0.016 seconds)
using 4 thread(s) with 0.036 CPU-seconds total
POV-Ray finished
—
Every now and then all other command line options than –version, -version, -V, –help, -help -h, -?, –benchmark and –benchmark without leading strace in command line produces “Faild to parse command-line option” error.
My system: ebian GNU/Linux unstable (sid), quadcore AMD Phenom 2.6 GHz, 8GB ram. Povray: rekcahx@oah:~/pov$ povray –version povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged. POV-Ray 3.7.0.RC3
This is a release candidate of POV-Ray version 3.7.0. General distribution is strongly discouraged.
Copyright 1991-2003 Persistence of Vision Team Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.
Built-in features:
I/O restrictions: disabled
X Window display: enabled (using SDL)
Supported image formats: gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -
Compilation settings:
Build architecture: x86_64-unknown-linux-gnu
Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
Compiler vendor: gnu
Compiler version: g++ 4.6.1
Compiler flags: -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread
|
|
215 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Double Error Reporting | Closed | |
3.70 RC4 |
Task Description
Certain types of errors are being reported twice. For example:
Parse Error: Expected ‘numeric expression’, } found instead Parse Error: Expected ‘object’, undeclared identifier ‘foo’
The first error was a user typo when not enough parameters were specified, and the later when calling a yet to be declared object.
During investigation it was also discovered that improperly formed scale statements also produced the double error report: <scale 1,0.5,1>
Verified on linux and windows platforms.
|
|
216 | Sample scenes | Definite Bug | 3.70 RC3 | Very Low | Low | raddem.ini is not parsable by 3.7RC3 | Closed | |
3.70 RC4 |
Task Description
in the sample scenes, animations/raddem/raddem.ini is not parsable by current versions of povray. (3.7RC3 and upto #5476)
Radiosity= is a gone away option.(from a bit of time in the 3.7 branch)
|
|
221 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Undefined looks_like object causes hard crash | Closed | |
3.70 RC4 |
Task Description
The following SDL code causes a hard crash during parsing if _3024_dot_dat is undefined:
light_source {
<0, 0, 0>
color rgb 0.5*<1,0.905882,0.211765>
fade_distance 500
fade_power 1.6
looks_like {_3024_dot_dat texture {
pigment { rgbf <1,0.905882,0.211765,0.90> }
finish { ambient 0.6 diffuse 0 phong 0.5 phong_size 40
reflection 0.9
refraction 1 ior 1.25
}
}
} }
|
|
222 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | incorrect render of CSG merge with radiosity | Tracked on GitHub | |
Future release |
Task Description
The problem arises when I am trying to trace a radiosity scene without conventional lighting that has a GSG merge object. There are a coincident surfaces, but these surfaces are first merged, then the texture applied. The texture is a simple solig color non-transfluent pigment, default normal, default finish etc..
Problem consists when adding antialiasing, changing resolution, changing camera view-point etc.; when I replace merge with union, the problem disappeared.
The scene was checked on two different machines with different versions of POV-Ray:
Gentoo Linux, kernel 2.6.39-r3, i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel, 2G RAM (this is Dell PowerEdge 2650 server with 2 dual-core Intel Xeon MP processors); Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (i686-pc-linux-gnu-g++ 4.5.3 @ i686-pc-linux-gnu)
Gentoo Linux, kernel 2.6.37-r4, x86_64 AMD Athlon™ X2 Dual Core Processor BE-2350, 2G RAM (non-branded machine); Persistence of Vision™ Ray Tracer Version 3.6.1 (x86_64-pc-linux-gnu-g++ 4.4.4 @ x86_64-pc-linux-gnu)
(scene has been adapted slightly to be rendered with 3.6, the adaptation was to change “emission” with “ambient” and replace gamma “srgb” with “2.2”)
Both machines generate similar images.
The attachment is an archive containing sources of minimal scenes with these problems, and sample pictures I generated from them on my machines.
|
|
223 | Geometric Primitives | Definite Bug | 3.70 RC3 | Very Low | Low | Artifacts in thin torus | Closed | |
|
Task Description
Thin tori exhibit artifacts in 3.7.0 RC3 when the camera is placed inside the torus close to its “center plane”, as can be demonstrated with the following scene:
camera {
location <0.0, 0.0, -0.5>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
angle 1
}
light_source { <-30, 30, -30> color rgb 1 }
torus {
1, 0.001
texture { pigment { color red 1 } }
}
|
|
225 | Light source | Definite Bug | 3.70 RC3 | Very Low | Low | translating a light source fails to translate looks_lik ... | Closed | |
3.70 RC4 |
Task Description
The following scene reders differently with POV-Ray 3.7.0.RC3 than with POV-Ray 3.6.2:
camera
{
right x*image_width/image_height
location <0, 0, -5>
look_at <0, 0, 0>
}
light_source
{
<0,0,0>
color rgb 1
looks_like
{
box {
<-1,-1,-0.1>, <1,1,0.1>
pigment { wood }
finish { ambient 5.0 diffuse 0 specular 0 phong 0 reflection 0 }
scale 0.5
}
}
translate <1,0,0>
}
plane
{
<0, 1, 0>, -1
texture
{
pigment { color rgb <0.5, 0.5, 0.55> }
finish { specular 1.0 }
}
}
See attachments for the output. As can be seen, POV-Ray 3.7 does translate the shape of the looks_like object along with the light source, but fails to translate the textures.
|
|
232 | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | illegal map_type usage reporting | Closed | |
3.70 release |
Task Description
parser fails to report when an illegal map_type is used. For example map_type 10 and map_type 100 doesn’t produce an error
|
|
234 | Frontend | Definite Bug | 3.70 RC3 | Very Low | Low | The +GD flag does not work | Closed | |
3.70 RC7 |
Task Description
The +GD flag gives me an “Invalid parameter” error, whether on the command line or in a .ini file.
Debug_File= still works.
I reported this in povray.beta-test, but did not receive a response.
The problem occurs in both Windows 7 and in Linux.
|
|
241 | Photons | Definite Bug | 3.70 RC4 | Very Low | Low | Photons not working correctly | Closed | |
3.70 RC6 |
Task Description
~scenes/advanced/optics.pov not rendering correctly. See the post in povray.beta-test “Photons not working as expected” for additional information.
|
|
249 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | UTF-8 files with BOM not accepted | Closed | |
3.70 RC7 |
Task Description
POV-Ray fails to accept UTF-8 encoded files with a leading Byte Order Mark.
According to the code it was intended to recognize a leading BOM (or, more precisely, leading non-ASCII code sequences) and automatically switch to UTF-8, so this must be considered a bug rather than a missing feature.
|
|
252 | Photons | Definite Bug | 3.70 RC6 | Very Low | Low | photons and light_group is broken | Tracked on GitHub | |
|
Task Description
photons are not working when used with a light_group. verified in NG posting in p.general a simple scene file is attached.
|
|
257 | Other | Definite Bug | 3.70 RC6 | Very Low | Low | POV-Ray cannot find input file when resuming to render ... | Closed | |
3.70 RC7 |
Task Description
How to reproduce:
# An empty directory, an empty source file.
$ mkdir test && cd test && touch test.pov
# Generate the first 24 frames.
$ povray -D +KFF24 +Itest.pov +Otest.png
# Try to generate the 25th frame.
# `25' after `+KFF' can be changed to any integer greater than 24.
$ povray -D +C +KFF25 +Itest.pov +Otest.png
What happens:
==== [Parsing...] ==========================================================
Possible Parse Error: Cannot find file 'test.pov', even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed
OS: Gentoo AMD64 unstable POV-Ray version: 3.7.0 rc5
|
|
258 | Editor | Definite Bug | 3.70 RC6 | Very Low | Low | backspace problem at start of line | Closed | |
3.70 RC7 |
Task Description
Using POV-Ray 3.7 RC6 64bit for Windows I have problems in the POV-Ray editor with ‘backspace’:
When using backspace at start of line it does not only kill the return/line feed, but also everything of the line what’s beneath the upper line.
Sample: (here ‘|’ is used for the current cursor position!)
//--------------------------------------
texture { pigment{ Red }
| normal { bumps 0.5 scale 0.1 }
//--------------------------------------
hitting backspace results in:
//--------------------------------------
texture { pigment{ Red }| 0.5 scale 0.1 }
//--------------------------------------
and not as expected:
//--------------------------------------
texture { pigment{ Red }| normal { bumps 0.5 scale 0.1 }
//--------------------------------------
With 3.6.2 and with RC3 (latest old beta I found on my computers) this was no problem!
I already reported this on 17-Sept-2012 at http://news.povray.org/povray.beta-test/thread/%3C5056f452%241%40news.povray.org%3E/
|
|
259 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | Stack Overflow with the write-directive with missing cl ... | Closed | |
|
Task Description
As I posted yesterday to the POV bugreports, I observed a bug with the #write directive, having forgotten the closing bracket. I looked a little bit closer and found different behaviours of POV with different array sizes.
With ArrayDim=100 (please look at the attached SDL-code, which is reduced as much as possible and produces only the bug and no scene) one get the Parse Error: “Expected ‘string’, End of File found instead” and the last line is highlighted. With ArrayDim=1024 you get an Stack Overflow and POV crashes.
I observed this at two different core i7 windows machines. On one of them (16 GB RAM, if this is of importance) the threshold between both behaviours was between 300 and 400. Hope this helps.
Best regards, Michael
|
|
262 | Setup/Install | Definite Bug | 3.70 RC6 | Very Low | Low | sources are being compiled twice on Linux | Closed | |
3.70 release |
Task Description
When running make on Linux, the backend source files (and possibly others?) are apparently compiled twice: first from the .../source/backend/ directory, and another time from the .../source/ directory. As an example, here are the corresponding lines for sphsweep.cpp:
g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source -I../../source/base -I../../unix -I../../vfe
-I../../vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strin
gs -fno-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.
o `test -f 'shape/sphsweep.cpp' || echo './'`shape/sphsweep.cpp
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I.
./vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strings -fno
-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.o `test
-f 'backend/shape/sphsweep.cpp' || echo './'`backend/shape/sphsweep.cpp
This is especially annoying on platforms that are rather slow at compiling.
|
|
266 | Frontend | Definite Bug | 3.70 RC6 | Very Low | Low | command line options in ini files don't accept quoted s ... | Closed | |
3.70 RC7 |
Task Description
Quoted strings as parameters to command-line options work on the command line but not in INI files; e.g.:
+i"test.pov"
Root cause has already been identified (actually the problem was found during code inspection) and a fix is under way.
|
|
268 | Parser/SDL | Definite Bug | 3.70 RC6 | Very Low | Low | "naked" pigment statement does not properly override pr ... | Closed | |
|
Task Description
A pigment statement not wrapped in a texture statement does not properly override a pigment previously defined for the object. In the following SDL code:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
pigment { checker color red 1 color blue 1 scale 1.0 }
}
the scaling of the pigment previously specified for the PLANE object is retained for the new pigment. Compare:
#declare PLANE = plane { y,0
texture {
pigment { checker color rgb 1 color rgb 0 scale 0.1 }
} }
object { PLANE
texture {
pigment { checker color red 1 color blue 1 scale 1.0 }
} }
which behaves as expected.
The issue has been around at least since POV-Ray 3.6.2.
|
|
271 | Texture/Material/Finish | Definite Bug | 3.70 RC6 | Defer | Low | filter affects object's own brightness in an improper w ... | Closed | |
3.70 release |
Task Description
The following scene has four spheres with different pigment color & filter settings:
- Left: filter 1 - Right: filter 0
- Top: red 0.0 green 0.5 blue 1.0 - Bottom: red 0.00 green 0.05 blue 0.10 (10% of the above)
Background is set to black, so that we only see the diffuse component of the object’s effective color.
Theoretically, both left spheres should be invisible, as they are fully transmissive (with a filtering effect), but apparently with a high filter setting, reducing an object’s pigment color actually increases the object’s effective diffuse color.
//+w600 +h600
global_settings{ assumed_gamma 1.0 }
camera {
orthographic
location <0,0,-10>
right 4*x
up 4*y
look_at <0,0,0>
}
light_source{<10,10,-10> color rgb 1 parallel }
background { color rgb 0 }
default {
finish {
ambient 0
diffuse 1
specular 0
phong 0
reflection { 0.0 }
}
}
sphere { <-1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 1.0 } } }
sphere { < 1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 0.0 } } }
sphere { <-1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 1.0 } } }
sphere { < 1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 0.0 } } }
This bug has been around in 3.6 already.
|
|
274 | Subsurface Scattering | Definite Bug | 3.70 RC7 | Very Low | Low | light source fading doesn't work properly with area_ill ... | Closed | |
3.70 release |
Task Description
When using fade_distance and fade_power in combination with area_illumination, the light source fading is not applied to materials with subsurface scattering; see the following code for an example:
#version 3.7;
global_settings {
assumed_gamma 1.0
mm_per_unit 10
subsurface { samples 200,20 }
}
camera {
right x*image_width/image_height
angle 30
location <0,1.5,-4>
look_at <0,0,0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
plane {
y, 0
texture {
pigment {
checker
color rgb <1.0, 0.8, 0.6>
color rgb <1.0, 0.0, 0.0>
scale 0.5
}
}
}
light_source {
<50,50,50>
color rgb 30
area_light 5*x,5*y,17,17 adaptive 1 jitter circular orient
area_illumination on
fade_distance 10
fade_power 2
}
cylinder {
<0,0,0>, <0,0.2,0> 1
texture {
pigment { color rgb 1 }
finish {
ambient 0
diffuse 0.7
specular albedo 0.3
reflection { 0.3 fresnel }
conserve_energy
subsurface { translucency 0.1 }
}
}
interior { ior 1.5 }
}
sphere {
<0,0.4,0>, 0.2
texture {
pigment { color rgb <1,0.6,0.0> }
finish {
ambient 0
diffuse 0.0
specular albedo 0.8 metallic
reflection { 1.0 metallic }
conserve_energy
}
}
}
|
|
275 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | circular area lights exhibit anisotropy | Tracked on GitHub | |
Future release |
Task Description
circular area lights exhibit some anisotropy, being brighter along the diagonals than on average, as can be demonstrated with the following scene:
//+w800 +h800
#version 3.7;
global_settings{assumed_gamma 1}
plane{-z,-10 pigment{rgb 1} finish{ambient 0 brilliance 0}}
disc{0,z,10000,0.5}
camera{orthographic location z look_at 10*z up y*12 right x*12}
light_source{-10*z rgb 10 area_light 10*x 10*y 257 257 adaptive 4 circular}
|
|
284 | Documentation | Definite Bug | 3.70 RC7 | Very Low | Low | Add to documentation of "background" command a referenc ... | Closed | |
|
Task Description
Currently neither of these pages:
http://www.povray.org/documentation/view/3.7.0/253/
http://www.povray.org/documentation/view/3.7.0/90/
mention that the background can be transparent. Any normal user will try to give “background { ... }” a transparent color, see that it doesn’t work, and assume that POV-ray can’t do it.
The pages should mention the +UA command-line option, which enables the transparency.
|
|
287 | Light source | Definite Bug | 3.70 RC7 | Very Low | Low | area_illumination shadow calculation | Tracked on GitHub | |
Future release |
Task Description
not sure if this is something needing further work or an intended effect.
Shadows from and area light with area_illumination on seem to follow the same shadow calculation as a standard area light by giving more weight to lights near the center of the array. I would assume the shadows would be calculated similarly to individual lights in the same pattern as the array by evenly distributing the amount of shadow equally for each light. But this is not what I see.
The code sample below when rendered with scene 1 will show shadows grouped near the center from the area light with area_illumination. If scene 1 is commented out and scene 2 is uncommented then rendered, you will see evenly distributed shadows from individual lights. Area lighting with area_illumination I would assume should give a result identical to scene 2. If scene 1 is rendered with area_illumination off, the shadow calculation is exactly the same as with area_illumination on.
example images rendered on win32 XP
#version 3.7;
global_settings {
ambient_light 0
assumed_gamma 1
}
camera {
location <0, 3, -5>
look_at <0, 2, 0>
}
background { rgb <.3, .5, .8> }
plane { y,0 pigment { rgb .7 } }
torus { 1.5,.1 rotate 90*x translate 4*z pigment { rgb .2 } }
plane { -z,-7 pigment { rgb .7 } }
/*
// scene 1
light_source{
y
1
area_light 3*x, z, 7, 1
area_illumination on
}
union {
sphere { 0,.05 }
sphere { .5*x,.05 }
sphere { x,.05 }
sphere { 1.5*x,.05 }
sphere { -.5*x,.05 }
sphere { -x,.05 }
sphere { -1.5*x,.05 }
translate y
hollow pigment { rgbt 1 } interior { media { emission 10 } }
}
// end scene 1
*/
// scene 2
#declare Light = light_source {
0
1/7
looks_like { sphere { 0,.05 hollow pigment { rgbt 1 } interior { media { emission 10 } } } }
}
union {
object { Light }
object { Light translate .5*x }
object { Light translate x }
object { Light translate 1.5*x }
object { Light translate -.5*x }
object { Light translate -x }
object { Light translate -1.5*x }
translate y
}
// end scene 2
|
|
295 | User interface | Definite Bug | 3.70 RC7 | Very Low | Low | Minor GUI Bugs | Tracked on GitHub | |
|
Task Description
Here are two low-priority bugs in POV-Ray’s GUI, observed by me under Windows XP, which should be easy to fix I think:
In the “Insert” menu, there are sub-menus (e.g. “Radiosity and Photons”) in which there are menu seperators at the end of the popped-up menu bar.
The progress bar in the top-right corner of the editor window seems to be too large for the window (203px) and therefore clipped. As a result, progress seems to be 100% when it is not yet, e.g. at 90% progress. (Have not measured exactly.)
Both bugs are not severe at all, but it would be nice if they could be fixed. By the way, a second progress bar could be added to visualize the number of frames already rendered in an animation.
|
|
298 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | Low | the warning for isosurface does not appears as often as ... | Closed | |
|
Task Description
From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)
William F Pokorny anonymous@anonymous.org wrote: > It seems to be the case the gradient warnings are only generated if the > isosurface is naked. If it is wrapped in an object as was the case with > my thread safety example, we get no warnings.
Confirmed. If only I still had the concentration required to investigate computer code.
#version 3.7;
#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end
global_settings
{ assumed_gamma 1
radiosity {} //force isosurface calculations from all directions
}
light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }
camera
{ location <0.0000, 1.0000, -5.6713>
look_at <-0.7969, 1.2000, -0.0598>
angle 10.7447
}
#include "functions.inc"
#if (Naked)
isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
#else
#declare Test = isosurface
{ function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
max_gradient MG
pigment { rgb <1, 0.75, 0> }
scale 1/128
rotate -35 * x
translate y
}
object { Test }
#end
On the command line, try:
declare=MG=1 declare=Naked=1
and
declare=MG=1 declare=Naked=0
To lose the warning, I had to declare the isosurface. Just wrapping the naked isosurface in an object{} generated a warning.
Further analysis
isCopy seems to be intended to avoid displaying the same warning over and over for the same isosurface (as duplicated isosurface indeed are not copied but reference the same sub-structure).
#declare Ob = isosurface{...}; that’s not a copy object {Ob ... } that’s a copy
Previously (3.6.1) the warning was displayed at the destruction of the isosurface (when the sub-structure was actually referenced by no one else)
if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))
In 3.7, isCopy was introduced with change 4707, 16th February 2009, along with the change introducing means for objects to submit message on shutdown. It was reported in windows source with change 4714, 21th February 2009.
If the symptom “isosurface embbeded in object (CSG) does not show the warning” is correct, it might be a “feature/bug”. The parser copied the isosurface object and deleted the original before the render started. When the render ends, it find only copies and because the refcnt is not used anymore (for that purpose), it miss the last remaining true data to display.
Instead of isCopy, what about adding in mginfo a boolean “printed_warning” (actual name should be more appropriate), set to false on creation, and turn to true on the first call (instead of last for 3.6.1) of the warning displaying function (test for false, set to true if false) ? (and dropping isCopy in the process)
For instance, i’m afraid the following sequence would fails with current code:
#declare Foo = isosurface{ ... }; #declare Bar = object { Foo ... }; #undef Foo;
(or any pop of #local context, such as building the isosurface via macro or loop, or replacing the value of a previous #declare/#local )
|
|
301 | Other | Definite Bug | 3.70 RC7 | Very Low | Low | Fallback to default image size causes wrong values to b... | Tracked on GitHub | |
|
Task Description
When resolution is not specified (neither via POVRAY.INI nor via QUICKRES.INI nor via command line or custom .ini file), random values are displayed for image resolution in the Image Output Options message output. (The actual render will be performed at the default size of 160×120 pixels though.)
|
|
304 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | #for-loop may fail to perform last iteration | Closed | |
3.70 release |
Task Description
Using an end value of 1048576 or larger in a #for loop will cause the last iteration to be skipped, as can be demonstrated by the following code:
#declare N = 2000000; #debug concat(”N = “,str(N, 0,50),”\n”) #debug concat(”N-5 = “,str(N-5,0,50),”\n\n”) #for (I, N-5, N, 1)
#debug concat("I = ",str(I,0,50),"\n")
#end
(The limit was observed with a Win64 build; other builds may exhibit other limits or might even work fine, depending on the floating point engine used.)
As this limit is still far below the numeric precision limit, and a corresponding #while loop works fine with much higher values, this must be considered a bug rather than an inevitable limitation.
The bug can be tracked down to a faulty condition in tokenize.cpp, Parser::Parse_Directive(), CASE(END_TOKEN), case FOR_COND:
if ( ((Step > 0) && (*CurrentPtr >= End + EPSILON)) ||
((Step < 0) && (*CurrentPtr <= End - EPSILON)) )
which should instead be:
if ( ((Step > 0) && (*CurrentPtr > End + EPSILON)) ||
((Step < 0) && (*CurrentPtr < End - EPSILON)) )
|
|
307 | Image format | Definite Bug | 3.70 RC7 | Very Low | Low | netpbm, ppm, read bug where first data byte CR char | Closed | |
|
Task Description
I’ve recently been working with the netpbm ppm format and I have hit what I believe to be a bug in the way ppm files are read – very likely a bug in all netpbm formats. I am aware of the long standing povray issue with the netpbm file formats header where the height and width need to be on the same line as the magic number though that is not a requirement of the official format. This bug is different.
Namely in working with a larger number of ppm files I hit cases where a few would fail with the message : “Possible Parse Error: Unexpected EOF in PPM file” though the ppm files are fine. What is happening is that the first byte of data after the line feed (LF) (Ubuntu linux 12.04) happens to have a carriage return (CR) value.
The code which is set up to interpret the netpbm headers is reading a lines with “file→getline (line, 1024);” and this line reading code is pulling in the first byte of data with the CR value as part of the line. When the read by binary data, 8 or 16 bits at a time, starts, the povray read code is offset into the data by one byte too many.
The result from 10,000 meters, if input values were completely random file to file, would be netpbm read fails for size that make no sense in 1/256 files. In practice & depending on data some might never see fails while an unfortunate few might almost always fail.
I’d make some argument any CR following a LF character should not be pulled in as part of the line read even on windows/dos systems where CRLF is the usual line termination order. I think though the real fix is better netpbm header reading code which more strictly breaks apart the header on the first whitespace character doing the last depth break, aware of the file size, so it can decide what portion of any valid sequence of whitespce characters after the decimal depth value is data and not whitespace.
The attached tarball when unpacked has both a passing and failing case. To run “povray fails.pov” or “povray works.pov”. The only difference between the two ppm files if the fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C. The image rendered is meaningless.
Thanks for your time. Bill P.
|
|
309 | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | Warning Message Missing | Tracked on GitHub | |
3.71 release |
Task Description
Draw_Vistas, Light_Buffer, and Vista_Buffer (plus associated switches) do not issue warning when used, even tho code has been disabled.
|
|
315 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Low | inverse keyword does not work properly with quadrics | Closed | |
3.71 release |
Task Description
As the following scene demonstrates, the “inverse” keyword produces unexpected results with quadrics.
Left: a sphere primitive as reference Right: a sphere-shaped quadric primitive (sphere-shaped)
Top: plain Bottom: inverse
The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.
Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the quadric’s normal and textures erroneously remain uchanged.
// +w800 +h600
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }}
camera {
perspective
angle 40
right x*image_width/image_height
location <0,0,-10>
look_at <0,0,0>
}
light_source{ < 1000,3000,-3000> color rgb 1 }
background { color rgb 0.5 }
#declare T_White = texture { pigment { color rgb 1 } }
#declare T_Red = texture { pigment { color red 1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue = texture { pigment { color blue 1 } }
#declare TopLeft = sphere { 0, 1 }
#declare BottomLeft = sphere { 0, 1 inverse }
#declare TopRight = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 }
#declare BottomRight = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 inverse }
#macro Mac(Obj, P, D)
union {
#local N = <0,0,0>;
#local O = <-0.6,0.4,-10>;
#local Q = trace(Obj, O, D, N);
#if (vlength(N) > 0)
sphere { Q, 0.05 texture { T_Blue } }
cylinder { Q, Q + N, 0.02 texture { T_Green } }
#else
cylinder { O, O + D*10000, 0.02 texture { T_Red } }
#end
object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-1,-1,-1>, <0,1,1> rotate y*30 } } }
translate P
}
#end
Mac(TopLeft, <-1.2, 1.2, 0>, z)
Mac(TopRight, < 1.2, 1.2, 0>, z)
Mac(BottomLeft, <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)
|
|
316 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Low | inverse keyword does not work properly with fractals | Closed | |
3.71 release |
Task Description
As the following scene demonstrates, the “inverse” keyword produces unexpected results with fractals.
Left: a sphere primitive as reference Right: a julia fractal
Top: plain Bottom: inverse
The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.
Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the fractal’s normal and textures erroneously remain uchanged.
// +w800 +h600
#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }}
camera {
perspective
angle 40
right x*image_width/image_height
location <0,0,-10>
look_at <0,0,0>
}
light_source{ < 1000,3000,-3000> color rgb 1 }
background { color rgb 0.5 }
#declare T_White = texture { pigment { color rgb 1 } }
#declare T_Red = texture { pigment { color red 1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue = texture { pigment { color blue 1 } }
#declare TopLeft = sphere { 0, 1 }
#declare BottomLeft = object { TopLeft inverse }
#declare TopRight = julia_fractal{ <-0.083,0.0,-0.83,-0.025> quaternion sqr max_iteration 8 precision 20 scale 0.9 }
#declare BottomRight = object { TopRight inverse }
#macro Mac(Obj, P, D)
union {
#local N = <0,0,0>;
#local O = <-0.6,0.4,-10>;
#local Q = trace(Obj, O, D, N);
#if (vlength(N) > 0)
sphere { Q, 0.05 texture { T_Blue } }
cylinder { Q, Q + N, 0.02 texture { T_Green } }
#else
cylinder { O, O + D*10000, 0.02 texture { T_Red } }
#end
object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-2,-2,-2>, <0,2,2> rotate y*30 } } }
translate P
}
#end
Mac(TopLeft, <-1.2, 1.2, 0>, z)
Mac(TopRight, < 1.2, 1.2, 0>, z)
Mac(BottomLeft, <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)
|
|
318 | Texture/Material/Finish | Definite Bug | 3.70 release | Very Low | Low | method 3 (default) scattering media is too bright & cau ... | Closed | |
3.71 release |
Task Description
The following scene demonstrates how media sampling method 3 gives inaccurate results with scattering media.
The scene shows four spheres with uniform media, using (left to right) sampling methods 1, 2 and 3 with default settings, and sampling method 3 with high minimum sample count, respectively.
Note how changing the sample count significantly affects the result, despite the media being uniform.
Code analysis shows that the root cause is an underestimation of the extinction effect on the light scattered by the media, corresponding in order of magnitude to half the distance between mandatory samples (as defined by minimum sample count).
The effect also leads to visible artifacts when nesting hollow objects inside the media, as can be demonstrated by un-commenting the four smaller spheres.
#version 3.7;
camera {
perspective angle 25
location <0.0 , 0.0 ,-20.0>
right x*image_width/image_height
look_at <0.0 , 0.0 , 0.0>
}
light_source {
<0,3000,-3000> color rgb 1
}
background { color rgb 0.5 }
plane {
<0,1,0>, -1
texture { pigment { checker color rgb<1,1,1>*1.2 color rgb<0.25,0.15,0.1>*0 } }
}
#declare T_Transparent = texture {
pigment { color rgbt <1,1,1,1> } finish { diffuse 1 }
}
sphere { <-3,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 1
}
}
}
sphere { <-1,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 2
}
}
}
sphere { <1,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 3
}
}
}
sphere { <3,0,0>, 1.00
texture { T_Transparent }
hollow
interior {
media {
scattering { 1 color rgb 2 extinction 1 }
method 3
samples 100
}
}
}
/*
sphere { <-3,0,0>,0.8 texture { T_Transparent } hollow }
sphere { <-1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 3,0,0>,0.8 texture { T_Transparent } hollow }
*/
|