|
74 | Texture/Material/Finish | Possible Bug | All | Very Low | Medium | image_maps within pigment_maps are not rendered correct ... | Closed | |
|
Task Description
Hello,
when I use an image_map within a pigment_map (for example only a half of a box gets the image_map), the image_map is not rendered correctly.
For example when I have this box (scene and images are attached)
box {
0, 1
pigment {
gradient z
pigment_map {
[0.4 image_map { png "test.png" } ]
[0.4 color Cyan ]
}
}
}
So on the front you should see the image of test.png (in the attached scene it’s just red). But on some pixels of the front you see the cyan color of the distant half of the cube.
Rendering the scene mutliple times produces the same result.
Rendering the scene at 200×150 is sufficiant.
povray +W200 +H150 scene.pov
I tested it with 3.6.1 and 3.7.0 beta 32 on Linux
|
|
80 | Parser/SDL | Possible Bug | 3.70 beta 35a | Very Low | Medium | Bad behavior for missing image file | Closed | |
|
Task Description
The following SDL code
sphere {0, 1 pigment {image_map {png "missing.png"}}
yields “render failed” in 3.7b25 and the position of the error is not highlighted in source code, giving no clue what went wrong. In 3.6 this yields “Parse Error: Cannot open PNG file”.
|
|
81 | Geometric Primitives | Definite Bug | 3.62 | Very Low | Medium | sphere_sweep generating artifacts | Tracked on GitHub | |
|
Task Description
I’m running POV-Ray for (64 bit) Windows v3.62 on (64 bit) Windows Vista
This pov file:
#include "colors.inc"
#include "metals.inc"
light_source { <6, 9, -21> color White }
camera { location <0, 0, -3> look_at <0, 0, 0> }
sphere_sweep {
cubic_spline
6
<-2.0, 0, 0> 0.05
<0.000,0,0> 0.2
<0.025,0,0> 0.2
<0.050,0,0> 0.2
<0.075,0,0> 0.2
<3.0,0,0> 0.2
pigment { color White }
}
Produces two strange artifacts: A disk at the center of the sweep, and a faint “halo” or veil which shows as 4 faint hyperbolas centered around the origin.
I have tried tweaking tolerance (for no other reason than I saw that someone else was tweaking it to solve a problem) but this does not seem to change things.
For a look at MY result when I run this, view this image:
Alain reports the same behavior in the latest version: “It’s still there with the latest version: 3.7 beta 35a.” This MAY move the status to “confirmed”, but I can’t do that
Someone else says that changing the scale (!) “solves” the problem by moving the disk and the halo offscreen, but that sounds like a bad idea to me.
-Jeff Evarts, first-time POVRay bug reporter
|
|
167 | Other | Definite Bug | 3.70 beta 38 | Very Low | Medium | Core dump when rendering to huge dimensions | Closed | |
|
Task Description
From post in povray.general (circa 29 september 2010: “Maximum Resolution of Renders?”)
The ultimate goal would be a 41000×41000 image. However each time I have attempted to render that Pov-Ray has crashed on me. Even when using a single, simple test object (a plain white sphere that should use a single pixel). So I think this is running into a program limitation at present.
It won’t be for the faint hearted: a 30500 x 30500 does still produces the bug, but you’d better have 24 GB of true ram to test it. (it’s a render of a few “real” minutes if you do not swap, for any very quick scene (a 305 x 305 in 0.117s moved to 220s for 30500×30500 on my system when corrected))
With core-dumped enable, the issue is pointed in the creator of PixelContainer. The problem is due to the resize() parameter: despite the parameter being a size_t (8 bytes long on 64bits), the computation ( h * w * 5 ) use unsigned int for h & w (and signed int for 5).
As a consequence, the value of resize is computed as a signed int... havoc might happen when the signed bit (#31) is propagated to the #63 to #32 of size_t... vector does not enjoy a negative value for resize (and destroy itself: no iterator on coming soon call! hence the crash when the values in the vector are to be initialised)
30500²: (in hex)
1 15 3C 71 50 floats
4 54 F1 C5 40 bytes
Basic solution: promote the 5 to an unsigned long, forcing the computation to happen on unsigned long, avoiding promotion of silly sign-bit, and keeping the resize’s value as a good number.
aka: resize( w * h * 5) becomes resize ( w * h * 5ul )
This solution has been tested and seems fine (it’s just that in base/image/image.cpp, there is a lot of resize()!). For all resize(), the “ul” must be added. (and that means also that resize( w * h ) must be rewritten as ( w * h * 1ul ). )
|
|
181 | Backend | Unimp. Feature/TODO | 3.70 beta 40 | Very Low | Medium | Unimplemented, altered or missing features to document ... | Tracked on GitHub | |
|
Task Description
This is a list of unimplemented features and things to fix with respect to 3.7 vs 3.6 compatibility. They either need to be fixed in code, or failing that, to be documented prior to release.
Create_INI works differently from 3.6. Prior versions of POV-Ray would write all options to the file, even if they were not supplied by the user (non-supplied options would take the default value). Currently in 3.7, only supplied options are written, because the front-end does not send unused options to the back-end. The proper fix for this would be to have a set of defines that establish the defaults all in one place (currently we rely on hard-coded values scattered around the code), and for the Output_INI_Option() function to look up and use the default when not supplied. As this is not likely to be done before 3.7 release, we need to document it as a temporary situation.
The following messages are marked as ‘currently not supported by code’ in povmsgid.h. We need to check where this comment is correct and if so the docs need to be updated to indicate this (for items that are already documented). Some items may be re-implemented later, and some may never be:
kPOVAttrib_TestAbort
kPOVAttrib_TestAbortCount
kPOVAttrib_VideoMode
kPOVAttrib_Palette
kPOVAttrib_DisplayGammaType
kPOVAttrib_FieldRender
kPOVAttrib_OddField
kPOVAttrib_AntialiasGammaType
kPOVAttrib_LightBuffer
kPOVAttrib_VistaBuffer
kPOVAttrib_DrawVistas
This bug should be edited to add/remove items as time goes by.
|
|
195 | Other | Compatibility Issue | 3.70 RC3 | Very Low | Medium | povray-3.7.0rc3 incompatible with NetBSD | Closed | |
|
Task Description
While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:
1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe) 2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable. 3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix). 4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3. 5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is #ifdef HAVE_SYS_WAIT_H # include <sys/wait.h> #endif but this also needs a check in the configure script.
Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html. Backtrace is Program terminated with signal 11, Segmentation fault. #0 0x00000000004ac479 in boost::gregorian::date::date () (gdb) bt #0 0x00000000004ac479 in boost::gregorian::date::date () #1 0x00000000004d29f7 in boost::gregorian::date::date () #2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= () #3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= () #4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= () #5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName () #6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName () #7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName () #8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= () #9 0x00007f7ffd80d9cf in thread_proxy ()
from /usr/pkg/lib/libboost_thread.so.1.45.0
#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>) at /archive/cvs/src/lib/libpthread/pthread.c:473 #11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12
Please advise on how to proceed.
|
|
228 | Texture/Material/Finish | Possible Bug | 3.70 RC3 | Very Low | Medium | Emission Media does not show on Alpha background | Closed | |
|
Task Description
I tried to render a candle’s flame (an object with interior made of emission media) against an Alpha background. In 3.6, the “flame” appears as a bright object against the alpha background; but in 3.7, the flame disappears against the alpha (as the attached scene will make clear, the “flame” is still visible against opaque background objects). I used the settings “Output_Alpha=true Output_File_Type=N”.
If there is another (better?) way to achieve a similar effect, I am open to using a work-around.
|
|
236 | Animation | Possible Bug | 3.70 RC3 | Very Low | Medium | Segmentation fault with animation of large image | Closed | |
|
Task Description
If the image is more than 1270 pixels wide or more than 720 pixels high, animation fails with a segmentation fault during the second rendered frame. This happens after parsing is complete and the .pov-state file is created. The last message line is the “[Rendering...]” line. (There is also a separate, but possibly related, issue that the output display does not work for these renders.)
On one occasion, POV-Ray hung, and I had to ctrl-Z kill -9 out of it.
On another occasion, instead of the segmentation fault, I got the message:
povray: xcb_io.c:140: dequeue_pending_request: Assertion `req == dpy->xcb->pending_requests' failed.
Aborted
There is no crash when -D is used.
I have not run an animation this large in Windows, so I don’t know if it’s a problem there.
Neither problem occurs in POV-Ray 3.6.1.
I used the following source code:
global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
sphere { 2.5 * z, 1 pigment { red 1 } }
Operating system: openSUSE Linux 12.1 Hardware: HP Pavilion dv5030us Notebook PC (32 bits) RAM: 1GB Displays: 1280×800 built-in panel; 1680×1050 HP w2007 external monitor
Libraries
Boost 1.48.0 (Note: bzip2 and python dependent modules did not compile, and MPI support does not work.) Zlib 1.2.5 (LibXML 2.7.8) LibPNG 1.5.7 LibJPEG IJG 8d LibTIFF 3.8.2 OpenEXR 1.6.1 (IlmBase 1.0.1) SDL unknown
|
|
254 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | Mesh_camera type 0 output seems to be incorrect | Closed | |
|
Task Description
When using mesh_camera type ‘0’
The first line of the mesh output seems to be repeated resulting in incorrect light colour values.
If the first line of the texture is skipped then the values seem to be correct.
|
|
255 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | Mesh_camera type 0 should compute per vertex or per fac ... | Closed | |
|
Task Description
The documentation states mesh_camera 0 should produce 1 pixel per index but it currently seems to produce 1 lighting pixel per face.
This output seems fairly meaningless as using this data for vertex colours (presumably the intention for mesh_camera 0) would result in a flat shaded model.
Logically it would make more sense to output 1 pixel per vertex instead of 1 pixel per face. Another solution might 1 pixel per face index (as per documentation) although POV would need to record which indices had already been computed otherwise it could end up duplicating computation.
At the moment I’ve written a code workaround for my exporter which produces a special mesh but this is obviously a much more complex solution to a fairly simple problem.
|
|
261 | Camera | Definite Bug | 3.70 RC6 | Very Low | Medium | mesh_camera distribution type 3 output image is placed ... | Closed | |
|
Task Description
Output images are 0.5 pixels too right and 0.5 pixels too down (mesh_camera_bug.pov).
The error is cumulative when image files are used again as texture (run 10 times mesh_camera_bug_reuse.pov).
This can be compensated by adjusting UV maps (mesh_camera_fix.pov and mesh_camera_fix_reuse.pov).
Tested with and without anti-aliasing.
|
|
273 | Other | Definite Bug | 3.70 RC6 | Very Low | Medium | No automatic backup files from inc files | Tracked on GitHub | |
|
Task Description
If enabled, POVray always created backups of pov and inc files once per session. Now using 3.7 RC6 only pov file backups are created but not from inc files.
|
|
276 | Parser/SDL | Feature Request | 3.70 RC7 | Very Low | Medium | SDL Access to Spline Derivatives | Closed | |
|
Task Description
I would like to suggest an additional feature regarding splines. POV-Ray’s spline objects (spline {}) are very useful to create animation paths as a function of time from reference points; however, in many cases you do not only need a position to place an object correctly, but also its velocity etc., e.g. if you are animating a car moving along a spline you do not only need to know where the car is at a given clock value but also in which direction it is going. If you want to rotate the wheels correctly you even need to know how this direction is currently changing.
In a nutshell, if you are using splines to create an animation path, you might not only need the spline value itself, but also the value of its first and second derivative. So I suggest adding an SDL capability to access these values like it is possible to access the spline value for a given parameter.
I do not think it would be too difficult to add a feature like this as far as the backend is concerned, since for computing a (cubic) spline you need the first and second derivatives anyway. (They are probably not being stored separately, but a polynomial is not that hard to differentiate.)
Indeed I do not know how an SDL language construct for it should look like (i.e. whether to use ' and ‘’ like in mathematics or a second spline function parameter).
|
|
277 | Other | Possible Bug | 3.70 RC7 | Very Low | Medium | Max Image Buffer Memory Does not Seem to Work | Closed | |
|
Task Description
In POV-Ray’s documentation it says:
3.2.2.2 Max Image Buffer Memory
This INI parameter sets the number of megabytes of RAM to allow for output image caching. If the output image happens to use more than this, a file backed temporary image is used instead.
I used this INI file option because the default value (128 megabytes) seemed insufficient. pov-state backend files were always created and they were remarkably larger than the resulting image (bmp) files. Consequently, I set
Max_Image_Buffer_Memory = 3096
in the INI file so that POV-Ray should, according to the documentation, now be able to use 3 gigabytes of RAM so no backend temporary file would be needed at all (this large they were never).
However, while POV-Ray was rendering I still discovered a pov-state file and it still had a similar size.
Now I am confused: did the INI option not work or have I misunderstood the documentation? If the former is the case, that would be a bug, wouldn’t it?
I tested both under Windows XP and Debian 6.0.5.
|
|
278 | Backend | Feature Request | 3.70 RC7 | Very Low | Medium | Implement Lens Flare Rendering | Tracked on GitHub | |
|
Task Description
Currently POV-Ray does not support rendering lens flare effects, however, they can be simulated using a macro (include file) by Chris Colefax.
I would like to suggest adding a feature to POV-Ray to support lens effects “natively” since
as far as I know the macro has been designed for POV-Ray 3.1 so with each new POV-Ray version it gets more likely that this macro does not work properly any more
the macro does not work when rendering with radiosity, probably because the macro creates the lens effect by using a pigment with a high ambient value (which is ignored by POV-Ray 3.7’s radiosity algorithm).
Additionally, the macro is not quite easy to employ because
it needs to know the exact camera parameters (location etc.) and defines an own camera itself so any important camera information has to be stored if the effect has to work as expected
it does not (actually cannot) take into account that objects may (partially) hide the lens effect
reflections and refractions (of light sources) cannot be combined with it properly - the user would have to calculate both the point where the reflected/refracted light source can be observed and the shape it then has due to distortion, and in more complex scenes such computations are nearly impossible in SDL.
I would suggest integrating such a lens flare rendering feature with the “looks like” mechanism you already have for light sources. Several parameters that can currently be set for the macro - including effect brightness and intensity, lens options and whether to create a flare at all - could be set for the light source.
Then POV-Ray could store the location and colour of each ray that finally intersected the “looks like” object of a light source and, having finished the main rendering, from that data compute a partially transparent “lens flare layer” eventually mixed into the rendered image. By this, the above mentioned problems could be avoided:
an object fully or partially intersecting a light source’s “looks like” object would also reduce the number of pixels used to create a flare - and therefore reduce that flare until fully hiding it
the same goes for reflected and/or refracted versions of the “looks like” object
the camera’s location and other properties would be used automatically
and finally, as a feature supported by POV-Ray itself, there would be neither compatibility issues nor problems like the effect not fitting together with radiosity.
Do not get me wrong, I would not expect POV-Ray to really calculate intersections that naturally happen in a camera lens, causing lens flares. Effects looking appropriate can actually be created just in 2D space (as some graphics programs do support) so the work to be done would, as far as I have any overview, be:
storing, as mentioned above, the relevant data for pixels showing “looks like” objects
calculating a lens flare from that data after the render has finished
overlaying the rendered image with the newly created lens effect.
|
|
280 | Editor | Possible Bug | 3.70 RC7 | Very Low | Medium | editor issue | Closed | |
|
Task Description
The following editor issue experienced in 3.7 RC 6 under Win7/64::
Place the curser at the middle of a row. Press enter. Now the line has been split and the cursor is at the beginning of the new line, followed by the rest of the original line Press backspace. Instead of restoring the original line, the second part of the line disappears.
RC 3 under Vista/32 (and earlier versions) behave normally.
|
|
290 | Documentation | Possible Bug | 3.70 RC7 | Very Low | Medium | Windows. Editor context menu opens folder instead of ad ... | Closed | |
|
Task Description
This is an annoying little bug in the Windows GUI:
Installed 3.7 RC07 on Windows 8. No previous povray installation on this machine.
How to reproduce error :
- Open a file in the editor.
- Right click on the files tab. This opens a popup menu showing “Open containing folder/Copy file to clipboard/....”.
-Now each selection in this menu does open the containing Folder. I cannot close or run any of the other actions in this menu.
|
|
308 | Geometric Primitives | Definite Bug | 3.70 RC7 | Very Low | Medium | Heightfield computation from color (not palette) red/gr ... | Closed | |
|
Task Description
Due to a recent thread in povray.general (7th September 2013), I dive into the code of height field creation.
There is 2 TODO in source/backend/support/imageutil.cpp, for image_height_at() (circa line 512)
The first one is about using the index of palette-image: As far as *257 would indeed perform a better job to cover the full range than *256, it would break backward compatibility with previous versions of povray (3.6 included) which only promoted the index as the Most significant byte, keeping the least one at 0.
But on the second one, the new formula is plain wrong: (r*255+g)*255 should be (r*256+g)*255. In previous versions, r*255 was the Most significant byte, and g*255 was the least one. Ergo, the value was r*255*256 + g*255, which can and should be only factored as (r*256+g)*255;
I know it is damn late in the release schedule, but can that be either be fixed before final official delivery or a memo added to the release note that it would be fixed later and backward-bug will not be maintained for that specific point (using rgb-8 or less bit per channel-image for height field)
(it was not bugged in 3.6.1 nor before, it’s just that tiny little bit of 3.7 that would should that bug)
If you look carefully at the attached pictures (povray +I... +H700 +W700 +A0.01) of scene and scene36, there is a significant difference at the top. With 3.6, it matched exactly (hence the noise on the top pixels row) the view. With 3.7, it cannot reach the top and leave a white area (another difference is the slope on the side are also a bit more lower with 3.7, easier to spot when alternating the display of both pictures)
If you want to regenerate hf.png, it was rendered with povray 3.7RC7, +W400 +H400 +A0.01 +Ihf.pov
The white line at the bottom is expected, as the minimal value of the height field is “full green”
|
|
322 | Configure/Build | Definite Bug | 3.70 release | Very Low | Medium | ubuntu 14.04, boost 1.54, can not configure | Closed | |
|
Task Description
can not run POV-Ray on ubuntu 14.04, boost 1.54,
./configure COMPILED_BY=”Dmitry <my>”
...
Libraries
---------
checking whether to link with cygwin DLL... no
checking whether to enable static linking... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for boostlib >= 1.37... yes
checking whether the Boost::Thread library is available... yes
checking whether the boost thread library is usable... no
configure: error: in `/home/di/workspace2/povray-3.7-stable':
configure: error: cannot link with the boost thread library
log in attach file
|
|
325 | Subsurface Scattering | Possible Bug | 3.70 release | Very Low | Medium | SSLT Glow issue with radiosity | Closed | |
|
Task Description
Hi,
I think I may have found a bug in the subsurface/radiosity features of Povray 3.7 attached image showing the issue and sample files required to reproduce. The original files (on povray forum images thread) had different radiosity settings but these ones show the problem and only take a few seconds to render the image without AA so probably better for bug fixing/testing etc.
Thanks
Sean
|
|
328 | User interface | Definite Bug | 3.70 release | Very Low | Medium | Ascii char '=' in filenames causes command line parsing... | Tracked on GitHub | |
|
Task Description
The following command fails with parsing error: povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw==.pov +W1000 +H1000
The following command succeeds: povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.pov +W1000 +H1000
Any option that gets a filename as parameter will fail if it contains ‘=’.
It is a regression, as it worked fine with 3.6.
|
|
331 | Geometric Primitives | Definite Bug | 3.70 release | Very Low | Medium | Intersection causes quadric to disappear | Closed | |
|
Task Description
The following paraboloid renders correctly:
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { 0, y, 1 }
}
However, when I extend the clipping cylinder downward:
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { -y, y, 1 }
}
the object disappears completely in POV-Ray 3.7 and 3.7.1. In POV-Ray 3.6.1, it renders as expected.
POV-Ray 3.7.0.unofficial (self-compiled with g++ 4.8, but completely unaltered) POV-Ray 3.7.1-alpha.8150025.unofficial openSUSE 13.2 GNU/Linux
This scene file illustrates the problem:
// +w480 +h240
#version 3.6; //[sic]
global_settings { assumed_gamma 1 }
camera
{ location <0, 1, -7.5958>
look_at <0, 1, 0>
right 2 * x
up y
angle 43.1038
}
#default { finish { diffuse 0.6 ambient rgb 0.15618 } }
light_source
{ <-4.3125, 9.6250, -7.4695>,
rgb 6856.3
fade_power 2 fade_distance 0.10417
spotlight point_at <0, 1, 0> radius 45 falloff 90
}
box
{ -<9, 11, 9>, <9, 11, 9>
pigment { rgb 1 }
}
plane
{ y, 0
pigment { checker rgb 0.05 rgb 1 }
}
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { 0, y, 1 }
pigment { green 0.5 }
translate <-1.25, 1, 0>
}
intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
cylinder { -y, y, 1 }
pigment { green 0.5 }
translate <1.25, 1, 0>
}
On the right side, there should have been a cylinder capped with a paraboloid. A thread has been started in povray.bugreports. Jerome has started to look at it.
|
|
21 | Distribution | Definite Bug | 3.70 beta 32 | Very Low | Low | unix scripts have wrong version set | Closed | |
|
Task Description
In unix distribution these scripts
allscene.sh
allanim.sh
porfolio.sh
have the variable VERSION set to 3.6
|
|
25 | Animation | Definite Bug | 3.70 beta 32 | Defer | Low | Pause sometimes fails when rendering animation | Tracked on GitHub | |
|
Task Description
There is an issue where the pause button in POVWIN will sometimes not work during an animation (primarily where the frame rate is high), and furthermore, POVWIN can then get into a state where it’s not possible to use the pause until it is re-started.
Newsgroup report.
|
|
35 | Documentation | Feature Request | All | Very Low | Low | problem parsing +i option in povray-3.7.0.beta.32 on li ... | Closed | |
|
Task Description
The commands:
povray +i /home/ronis/Nm=500/povray.00001.pov
or
povray +i/home/ronis/Nm=500/povray.00001.pov
fail with: povray: this pre-release version of POV-Ray for Unix expires in 2 day(s) and 1 hour(s) Failed to parse command-line option
Going to the directory and simply running: povray +i povray.00001.pov works.
I came across this by accident trying to get emac’s povray mode to work; apparently it passes the full path name to povray.
I don’t think there is a problem in 3.6.1
|
|
36 | Documentation | Definite Bug | Not applicable | Very Low | Low | GuMax | Closed | |
|
Task Description
After a recent update on the POV-Wiki the GuMax skin doesn’t recognize MediaWiki:Common.css entries.
|
|
41 | Other | Feature Request | 3.70 beta 32 | Very Low | Low | improve command-line parsing error messages | Tracked on GitHub | |
|
Task Description
POV-Ray 3.6, upon encountering problems when parsing command line and/or .ini file options, would quote the offending option in the error message.
POV-Ray 3.7 currently just reports that there is some problem with the command line, without providing any details. I suggest changing this, as the information may be helpful at times.
|
|
47 | Preview | Possible Bug | 3.70 beta 32 | Very Low | Low | Render Preveiw window can become disabled | Tracked on GitHub | |
|
Task Description
If a render is continued with the +c option and the render had completed, the render preview window will disappear and the show/hide render window button will be grayed. Even after the scene is modified and the command line options have been changed, the show/hide button will still be grayed.
Opening or changing to another scene and rendering will not restore the button, nor will rendering with +d. However, if a trace is started using -d, halted, then continued using +d (or allowed to finish completely with -d and a new one is started using +d), then the preview window is restored.
This behavior is different from 3.6.1, which correctly always showed the preview window (since +d is default) unless -d was specified.
|
|
49 | Texture/Material/Finish | Possible Bug | 3.70 beta 32 | Very Low | Low | number_of_waves default value not properly initialized | Closed | |
|
Task Description
When rendering a series of scenes (e.g. animation, or render queue in POV-Ray for Windows), number_of_waves is not properly reset to its default value between scenes, causing the parameter to default to the value set by the previous scene.
For instance, rendering the following scenes from a queue will cause “arches.pov” to be rendered differently the second time:
scenes\textures\finishes\arches.pov
scenes\textures\normals\normavg.pov
scenes\textures\finishes\arches.pov (again!)
|
|
52 | Parser/SDL | Possible Bug | 3.70 beta 32 | Very Low | Low | inside() function does not accept meshes despite valid ... | Closed | |
|
Task Description
The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.
(see news://news.povray.org:119/4a983716@news.povray.org)
|
|
54 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Low | Multi-textured blobs fail to increment trace level | Closed | |
|
Task Description
Trace level is not handled properly with blobs using per-component reflective or refractive textures, leading to lockups. Stepping through the code, it seems that POV-Ray fails to properly mark the blob object as increasing the trace level.
(Until this bug is fixed, the issue can be worked around in most cases by assigning a reflective texture to the blob as a whole.)
|
|
58 | Parser/SDL | Unimp. Feature/TODO | 3.70 beta 32 | Defer | Low | allow SDL code to detect optional features | Tracked on GitHub | |
|
Task Description
Some features are optional in custom builds of POV-Ray (I’m thinking about OpenEXR in particular); it would be nice to have a syntax for an SDL script to check for support of such features, so it may take some fallback action if the feature is not supported.
|
|
62 | Geometric Primitives | Feature Request | Not applicable | Very Low | Low | Set and get font metrics | Closed | |
|
Task Description
Add a way to get and set font metrics.
Attached an image that shows what I’m talking about.
Thanks!!
|
|
63 | Geometric Primitives | Feature Request | Not applicable | Very Low | Low | Extend native support for 2D primitives | Closed | |
|
Task Description
Improve native support for 2D primitives. Ideally a 1:1 mapping of SVG primitives/shapes. They go a long way to making diagrams look a lot better. Having to create image maps based on externally created bitmaps slows the workflow down a lot!
|
|
66 | Texture/Material/Finish | Feature Request | 3.62 | Defer | Low | checker and cells pattern are slightly off-center | Closed | |
|
Task Description
In POV-Ray 3.6 (including 3.62), checker and cells patterns are off by 0.001 (1e-3) units, as can be demonstrated with this scene:
camera {
location <0.0, 0.0, -5.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
box { <-1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 0.2 translate <-0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 0.2 translate < 0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate < 0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { <-1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate <-0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }
The same can be demonstrated for the cells pattern.
POV-Ray 3.7 beta 34 is “clean”.
|
|
68 | Setup/Install | Possible Bug | 3.61 | Very Low | Low | Unix configure script does not accept newer libpng vers ... | Closed | |
|
Task Description
The configure script for unix uses a dumb string compare to test whether libpng version is 1.2.5 or higher, leading it to reject (for instance) libpng 1.2.27 and unnecessarily compile and statically link the older libpng version it comes with.
|
|
69 | Other | Compatibility Issue | Not applicable | Very Low | Low | #version fails to raise error | Closed | |
|
Task Description
Scenes starting with the incorrect syntax
version 3.7;
do not raise an error, instead they render a black screen with an empty scene warning. #version should fail with an error when the # is missing.
|
|
71 | User interface | Unimp. Feature/TODO | 3.70 beta 34 | Very Low | Low | raise warning when command line option has no effect | Tracked on GitHub | |
|
Task Description
Warnings should be raised when a command line option has no effect, for example...
pvengine +am
is legal, but without the number after it, it has no effect.
pvengine +am7
should be an error, and also raises no warnings.
|
|
72 | Platform-specific | Possible Bug | 3.70 beta 34 | Very Low | Low | Editor not saving preferences | Closed | |
|
Task Description
Windows 7, Home Premium 64bit In Options/Editor Window/Editor Preferences/Language Tabs saving a tab size of 4 does not work - on restart it reverts to the default of 8
In Options/Editor Window/Editor Preferences/Misc saving a Line numbering style of Decimal and a Start number of 1, does not work, on restart the defaults are restored.
|
|
82 | Other | Possible Bug | 3.70 beta 35a | Very Low | Low | correction to Shapes.pov | Closed | |
|
Task Description
When I try to re-render the insert menu bitmaps,on the Windows version 3.7b36 there is an error with the Shapes.pov file. line 474: Parse Error: Unexpected additional ‘.’ in floating-point number
line 474 is:
<2.6, 0>, <3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>
The second vector has two decimal points Change to <3.6,.9>
|
|
102 | Parser/SDL | Definite Bug | 3.6 | Very Low | Low | #switch directive parsing problem | Closed | |
|
Task Description
The #switch directive isn’t parsing correctly. In the following construct NO warning or error is generated:
#switch (RF)
case (0)
rotate z*355
#break
case (144)
rotate z*7.5
#break
case (216)
rotate z*5
#break
#end
RF is a variable passed to the macro in which this construct resides. The first ‘case’ action IS executed, but none of the others are on successive calls to the macro. If I properly add ‘#’ to the second case the 1st and 2nd condition are executed but not the last. If ‘#’ is REMOVED from any of the break directives an error is generated and parsing halts.
|
|
105 | User interface | Unimp. Feature/TODO | 3.70 beta 37 | Very Low | Low | output options not displayed | Closed | |
|
Task Description
POV-Ray 3.7 does not show output options, such as:
Output Options
Image resolution 640 by 480 (rows 1 to 480, columns 1 to 640).
Output file: D:\foo\test.png, 24 bpp PNG
Graphic display......On (gamma: 2.2)
Mosaic preview.......Off
CPU usage histogram..Off
Continued trace......Off
(the above is what 3.6 used to show)
|
|
106 | Distribution | Unimp. Feature/TODO | 3.70 beta 37 | Very Low | Low | Update sample scenes and include files for POV-Ray 3.7 ... | Tracked on GitHub | |
|
Task Description
Most sample scenes and include files were designed at times when POV-Ray did not to any proper gamma handling, or still used the inferior 3.6 “assumed_gamma” mechanism.
All the scenes and include files should be reviewed, and updated to fit the new 3.7 gamma model.
The primary task will probably be gamma-adjusting literal color values and ambient parameters; I suggest using macros (which ideally should be defined in an include file) to be set according to the #version statement, so the scene/include file could be kept compatible with older versions.
|
|
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.
|
|
117 | Sample scenes | Unimp. Feature/TODO | 3.70 beta 37a | Very Low | Low | Update Benchmark.pov | Closed | |
|
Task Description
The included scenes\advanced\benchmark.pov (v1.02)is different then the winpov menu render\run benchmark (v2.01).
The winpov menu render\run benchmark is missing some objects, turned off in early betas?
|
|
121 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Option to render pixels randomly, or in Nth pixel | Closed | |
|
Task Description
Assuming there are no performance issues, it would be nice to tell Povray to select the pixels to render randomly, so that the image gets filled in gradually instead of from top to bottom and from left to right.
Also, maybe an option to tell it to render every Nth pixel.
|
|
123 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | #BREAK statement inside #WHILE and #FOR loops | Closed | |
|
Task Description
Request #BREAK statement inside #WHILE and #FOR loops.
|
|
126 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Explicit #RETURN statement inside macros | Closed | |
|
Task Description
In POV SDL it can sometimes be ambiguous what exactly a macro returns. An explicit #RETURNS statement would make this unambiguous.
|
|
128 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Mixed-type arrays | Closed | |
|
Task Description
Currently, arrays may contain only one object type. Would be nice to eliminate this restriction and allow arrays to contain objects of different types.
|
|
132 | Geometric Primitives | Feature Request | 3.70 beta 37a | Very Low | Low | Native support for mesh-based surface approximations | Closed | |
|
Task Description
There are various scripts around the Net meant for approximating things like isosurfaces and parametric objects using meshes. It would probably run bit faster and be easier to use if this were supported natively within Povray. The feature would require an additional object parameter in order to toggle this behavior on/off.
|