|
253 | POV-Ray | Backend | Possible Bug | 3.70 RC6 | Very Low | Low | Segmentation fault | Closed | |
|
Task Description
I’ve had a series of what appear to be a hang up’s. They passed parse, reported some stats and issued the Rendering... message and opened the preview window, but never progressed. They continued to accumulate cpu time until I eventually had to kill -9, softer didn’t work.
I’ve been dismissing them up until now wanted to speak up because I finally got this crash:
29623 Segmentation fault
Here’s some observed behaviors:
In my scene I have a Round_Box_Union with /just/ a pigment that rendered fine, but when I added a wood texture from the distribution includes, it hung up after I tried to transform the texture in any way. Tried other distribution textures ... same thing.
I spent time going through different scenarios looking for a common cause (thinking I’m doing something wrong). Eventually I arrived at the point that I killed a hung render, and restarted the same render with no changes. Sometimes it would render, sometimes not ... I finally got the above mentioned Round_Box_Union to behave with a simple reflective texture, and the rounding parameter had to be above 0.1 ... I settled at 0.125. OK by now you’re thinking WTF right?
No more problems until I accidentally (typo) put an additional light_source at the same location as another light_source. It also hung sometimes, and rendered fine sometimes after a kill ... no SDL changes.
Now I can’t tell you exactly what I was doing when the seg fault happened, but I /do/ know I just restarted the render with no changes. I’m starting to think there’s some kind of instability happening here. I realize that I’m probably the only team member spending any real time with the application, so none of you probably haven’t noticed anything suspicious.
Any comments ... ideas ... suggestions?
|
|
21 | POV-Ray | 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
|
|
37 | POV-Ray | Documentation | Unimp. Feature/TODO | 3.70 beta 32 | Low | Medium | Find Documentation Editors | Closed | |
|
Task Description
Recruit version 3.7 documentation editors from the users community.
|
|
36 | POV-Ray | 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.
|
|
38 | POV-Ray | Documentation | Unimp. Feature/TODO | 3.70 beta 32 | Very Low | Low | POVDocGen extension | Closed | |
|
Task Description
Develop MediWiki extension to extract documentation sets from the POV-Wiki.
|
|
161 | POV-Ray | Image format | Definite Bug | 3.70 beta 38 | Very Low | Medium | error when writing jpg format (linux build) | Closed | |
2010-12-31 |
Task Description
There is a confirmed bug when writing jpg file format with the current linux build (beta39). when specifying +fj output format the following error occurs:
JPEG parameter struct mismatch: library thinks size is 372, caller expects 376 JPEG parameter struct mismatch: library thinks size is 372, caller expects 376 Render failed
this has been confirmed on ubuntu 10.4 and openSuSe 11.2 (assuming 32 bit version) as openSuSe 11.2 64-bit reports no problem
there has been a proposed fix to ~smp/source/base/image/jpeg.cpp that appears to work, however it requires some additional work to make it a platform (linux) and compiler (gcc) specific fix.
|
|
101 | POV-Ray | Include files | Feature Request | 3.70 beta 36 | Very Low | Low | woodmaps.inc dependency | Closed | |
|
Task Description
woodmaps.inc depends on colors.inc, more specifically the definition of the color “Clear” perhaps a #ifndef colors.inc belongs in woodmaps.inc or probably more correctly changing the call of “Clear” to rgbf 1
|
|
279 | POV-Ray | Light source | Possible Bug | 3.70 RC7 | Very Low | Low | area_illumination causes artifacts when used with radio ... | Closed | |
|
Task Description
see my post titled: “area light and radiosity problem?” in povray.binary.images [Edit - copied that post’s text here - clipka]
wondering about what’s going on here with this series of images. the radiosity and area light settings are unchanged from image to image, and all I did was radiosity on/off and area_light on/off (btw: using rad_def “Normal” settings)
the 1st image is radiosity only, the 2nd is area light only, and the 3rd combines them:
what’s up with blotches? change #5819/5820 (octree) or maybe something still with area lights?
|
|
158 | POV-Ray | Other | Definite Bug | 3.70 beta 38 | Very Low | Low | Antialias Gamma reporting error | Closed | |
|
Task Description
value is erroneously clipped to the range 0..1 before being displayed
|
|
321 | POV-Ray | Other | Definite Bug | 3.70 release | Very Low | Low | bounding threshold inconsistency | Tracked on GitHub | |
|
Task Description
User reported documentation inconsistency. Investigation led to the discovery of a bug in the setting of the current default value.
~source/frontend/renderfrontend.cpp reports the value “3” while ~source/backend/scene/scene.cpp sets a default value of “1”
Before for addressing this issue, are there any thoughts as to what the default value should be?
|
|
163 | POV-Ray | Parser/SDL | Unimp. Feature/TODO | 3.70 beta 38 | Very Low | Medium | no pigment warning | Closed | |
|
Task Description
no warning is issued when an object/primitive has no pigment type given
|
|
102 | POV-Ray | 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.
|
|
189 | POV-Ray | Parser/SDL | Possible Bug | 3.70 RC1 | Very Low | Low | segmentation fault | Closed | |
|
Task Description
I got a 29023 Segmentation fault ... but it was NOT repeatable. I reran the render job repeatedly and it displayed appropriate error message. I had renamed a texture identifier but missed an occurrence inside texture_map.
FYI: I did a build off the depot last evening.(21:13)
|
|
194 | POV-Ray | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | command line parse error | Closed | |
|
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.
|
|
215 | POV-Ray | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | Double Error Reporting | Closed | |
|
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.
|
|
232 | POV-Ray | Parser/SDL | Definite Bug | 3.70 RC3 | Very Low | Low | illegal map_type usage reporting | Closed | |
|
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
|
|
309 | POV-Ray | Parser/SDL | Definite Bug | 3.70 RC7 | Very Low | Low | Warning Message Missing | Tracked on GitHub | |
|
Task Description
Draw_Vistas, Light_Buffer, and Vista_Buffer (plus associated switches) do not issue warning when used, even tho code has been disabled.
|
|
190 | POV-Ray | Photons | Feature Request | 3.70 RC1 | Very Low | Low | photon message reporting | Closed | |
|
Task Description
couple of observations:
if no photons are gathered (hey it happens ... my typo) when attempting to save a photon map the warning message just indicates that it couldn’t save the map, maybe the message could be enhanced to say something like: No photons were gathered so no map information was saved. At first I thought something had changed in my I/O restrictions (I’m writing to an image directory not current or work directory)
when reading a previously saved photon map there is no indication that it was read in other than the end stats showing a small amount of photon time. I don’t recall but didn’t v3.6 indicate that the a previously saved map was being used? Just for the heck of it I moved the map file aside and it did prove to me that it was indeed being input. Some sort of message at the time the file is read in might be helpful.
|
|
241 | POV-Ray | Photons | Definite Bug | 3.70 RC4 | Very Low | Low | Photons not working correctly | Closed | |
|
Task Description
~scenes/advanced/optics.pov not rendering correctly. See the post in povray.beta-test “Photons not working as expected” for additional information.
|
|
252 | POV-Ray | 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.
|
|
330 | POV-Ray | Platform-specific | Definite Bug | 3.70 release | Very Low | Low | Typo in QUICKRES.INI | Closed | |
|
Task Description
Height=36084
[640×360, AA 0.3] Width=640 Height=36084 Antialias=On Antialias_Threshold=0.3
should be:
[640×360, AA 0.3] Width=640 Height=360 Antialias=On Antialias_Threshold=0.3
|
|
114 | POV-Ray | 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.
|
|
227 | POV-Ray | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 RC3 | Very Low | High | Fixed Vector Limitations | Tracked on GitHub | |
|
Task Description
See this documentation entry for more details.
|
|
196 | POV-Ray | Subsurface Scattering | Definite Bug | 3.70 RC3 | Very Low | Low | More SSLT Caveats | Tracked on GitHub | |
|
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.
|
|
100 | POV-Ray | Texture/Material/Finish | Definite Bug | 3.70 beta 36 | Very Low | Low | cutaway_textures | Closed | |
|
Task Description
When using cutaway_textures the differenced part traces black. Simple scene file attached.
|
|
115 | POV-Ray | Texture/Material/Finish | Feature Request | 3.70 beta 37a | Very Low | Low | More cutaway_textures | Tracked on GitHub | |
|
Task Description
Think this is still a problem. See the attached scene file. Find the WindowFrameSegment declaration for more info. The scene as-is shows the problem (SOME portions of the difference inherit the color of the room) the window opening is scaled larger to show that they AREN’T touching. The problem goes away when (in WindowFrameSegment) the 1st occurrence of the applied texture is commented out and the 2nd occurrence is uncommented, and cutaway_textures is commented out.
|
|
166 | POV-Ray | 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
|