|
111 | Parser/SDL | Definite Bug | 3.70 beta 37a | Very Low | Low | Remove_Bounds=off / -UR does not work properly | Closed | |
3.70 beta 38 |
Task Description
Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.
|
|
112 | Image format | Definite Bug | 3.70 beta 37a | Very Low | Low | OpenEXR alpha is only written when it shouldn't be | Closed | |
3.70 beta 38 |
Task Description
OpenEXR output currently writes an alpha channel when Output_Alpha=off (-UA), and does not write an alpha channel when Output_Alpha=on (+UA), i.e. doing it just the wrong way round.
|
|
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.
|
|
115 | Texture/Material/Finish | Feature Request | 3.70 beta 37a | Very Low | Low | More cutaway_textures | Tracked on GitHub | |
Future release |
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.
|
|
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.
|
|
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?
|
|
118 | Light source | Feature Request | 3.70 beta 37a | Very Low | Low | More efficient handling of fading lights | Tracked on GitHub | |
3.71 release |
Task Description
Currently, fading light sources are used for lighting and shadow calculations even when so far away as to no longer have any effect on the outcome. The proposed solution is to add a new keyword fade_cutoff_distance which tells povray to ignore the light source when alluminating a point at larger distance.
A sample implementation is provided in the attached files. These changes are still based on beta 34 as sources for the current beta are not yet available, and starting to merge changes to beta 35 only at this time didn’t seem worth the effort. Also, please disregard, changes in the CVS header comments (I also use CVS locally for managing source files).
Further considerations regarding this feature:
- For special effects this feature can also be used if the light source does not actually use fading. On the other hand, cutting the light at some distances can be considered an extreme form of fading which may justify the keyword name anyhow.
- Depending on how FS#46 is implemented, the test for cutoff may then be needed at another location as well.
- The default value currently is 0 (or *no* cutoff distance). For #version 3.7 of higher, the default could be chosen automatically based on the light source intensity and adc_bailout, although it may then need to be overriden by the user for extreme pigments.
|
|
119 | Documentation | Feature Request | 3.70 beta 37a | Very Low | Low | Table of Contents in each page of the docs | Closed | |
3.70 release |
Task Description
There should be a table of contents on each page of the documentation, or at least on the very long pages. Scrolling through the entire page to figure out what topics are covered sucks.
|
|
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.
|
|
122 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | #ELSEIF statement | Closed | |
3.70 beta 38 |
Task Description
Request an #ELSEIF statement in POV SDL.
|
|
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.
|
|
127 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Expandable arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, arrays are of a fixed size. You can’t add or remove items to/from an array. I think it would like arrays to be expandable with no fixed and pre-determined size.
|
|
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.
|
|
131 | Other | Feature Request | 3.70 beta 37a | Very Low | Low | Ability to change the order of editor tabs by dragging ... | Tracked on GitHub | |
Future release |
Task Description
See Notepad++ or EditPad Lite for examples.
It would be nice to be able to drag tabs in the editor window to change their order, so as to group opened files together by relevance for instance.
|
|
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.
|
|
134 | Image format | Feature Request | 3.70 beta 37a | Very Low | Low | INI option to overlay render information on output imag ... | Closed | |
|
Task Description
It would be nice to configure an INI option to add render information like render time, date, and input file to output images.
|
|
135 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | Right-click menu when clicking on editor tab | Closed | |
3.70 beta 38 |
Task Description
When right-clicking on a tab in the editor window a list of options should appear, such as:
* Close * Close all but this * Save * Save as * Print
See Notepad++, EditPad Lite, and Firefox for examples.
|
|
137 | Include files | Feature Request | 3.70 beta 37a | Very Low | Low | atand function | Closed | |
3.70 beta 38 |
Task Description
There already exist atan, atan2 and atan2d functions, why not atand?
|
|
138 | User interface | Feature Request | 3.70 beta 37a | Very Low | Low | "Rename" option in File menu | Tracked on GitHub | |
|
Task Description
Would be great if there were a “Rename” option in the editor File menu to rename the current file name. Otherwise, you have to close the file, rename it in file manager, then open the file again, thus loosing the current tab position and undo history for the file.
|
|
139 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | "Delete" option in File menu | Closed | |
|
Task Description
Would be nice to have a “Delete” option in the File menu to delete the current file from disk.
|
|
140 | Platform-specific | Feature Request | 3.70 beta 37a | Very Low | Low | "Reload" option in File menu | Tracked on GitHub | |
|
Task Description
Would be great to have a “Reload” option in the File menu to manually reload the current file from disk, discarding all subsequent changes since the last save.
|
|
141 | Documentation | Compatibility Issue | 3.70 beta 37a | Very Low | Low | Document changed behavior processing INI files | Closed | |
3.70 release |
Task Description
The documentation assumes that INI files (as well as the command line!) are parsed and processed instantly. This no longer holds true for POV-Ray 3.7, where parsing INI files (and the command line) and processing it are separate operations that occur at different times. As such, one consequence is that INI file options only take effect after reading the whole INI file, and possibly later.
As such, documentation statements such as <http://www.povray.org/documentation/view/3.6.1/222/> “Note: that these options take effect immediately when specified. Obviously any error or warning messages that might occur before the option is read will not be affected.”
Are no longer correct. It needs to be explained that options only take effect after the INI file has been read. An error in the INi file causes other options _not_ to take effect because reading of the INi file is aborted prematurely.
|
|
142 | Texture/Material/Finish | Feature Request | 3.70 beta 37a | Very Low | Low | camera_view pigment from MegaPOV | Tracked on GitHub | |
Future release |
Task Description
I probably don’t have to explain why the camera_view pigment in MegaPOV was important, but I will list some reasons anyway:
1) post-processing could be performed in-scene 2) new types of focal blur effects could be created 3) feedback fractals were possible
I’m sure there are many others, as this is one of those features that has undetermined potential!
|
|
143 | Backend | Feature Request | 3.70 beta 37a | Very Low | Low | explicit Output_File_Name for images/animations | Closed | |
|
Task Description
The ability to specify an exact name for output images during animations would be great. As it is, POV-Ray appends a numerical designation to each image (e.g. image001.png, image002.png, etc. Overriding this behavior would allow certain tasks to be accomplished without cluttering the hard drive. For instance, an image could be rendered over and over again. Certain things like cellular automata, ripple tank simulations and feedback fractals could be performed without the resulting long list of images in a given directory.
The command line option could be in the form of +oefile/+Output_File_Name_Exact=file or some such.
|
|
145 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Stack trace report on error | Tracked on GitHub | |
|
Task Description
In other languages if you encounter an error you’ll often be presented with a stack trace showing not only the file and line number the error occurred at, but also any calling functions and _their_ calling functions and so on.
Currently, Povray reports the line number of the error as well as the last five or so lines prior to the error. This is usually OK in simple scenes, but breaks down when you start making use of inclusion and macros.
Let’s say you have a macro located in a file that you then include in your scene. Within your scene you call the macro multiple times, passing input to it. However, by accident you pass _invalid_ input to the macro at some point, resulting in an error when parsing. In this case Povray will report the error as belonging to the macro whereas the actual bug exists in the calling code. If the macro is called more than once in your scene it can be difficult to figure out _which_ instance is the one supplying the bad input.
Not sure how much of this is achievable in Povray.
|
|
146 | Parser/SDL | Possible Bug | 3.70 beta 37a | Very Low | Low | Macros are finnicky about how you type your code | Closed | |
|
Task Description
Macros are finicky about how you type your code. What works outside macros sometimes fails inside them. For more information see the threads:
“Problems with macro (3.6)”, in p.a-u, 06-09-10 “Bad operands”, in p.g, 05-20-10
Still not sure *what* exactly the problem was, but one of my workarounds ended up working.
|
|
147 | Frontend | Possible Bug | 3.70 beta 37a | Very Low | Low | Statistic_File not working? | Closed | |
|
Task Description
In POV 3.6 you could set the Statistic_File option to a custom file and folder path. In the beta I get an “Cannot open file” error. Has the feature been intentionally removed or did it become broken?
|
|
148 | Documentation | Feature Request | 3.70 beta 37a | Very Low | Low | Thumbnails in docs for shapes.inc, shapes_old.inc, shap ... | Closed | |
|
Task Description
The documentation entries for shapes.inc, shapes_old.inc, shapes2.inc, shapesq.inc, etc. should have thumbnails next to the object descriptions.
|
|
149 | User interface | Feature Request | 3.70 beta 37a | Very Low | Low | Tray icon: show render progress | Closed | |
|
Task Description
In the tray icon, I’d like to see the render progress indicated somehow icon itself. Either a set of numbers (percents), or a change in color of the icon (e.g. from top to bottom). Something like the attached images.
|
|
150 | Frontend | Compatibility Issue | 3.70 beta 37a | Very Low | Low | Windows file association problems (Win7 only??) | Closed | |
|
Task Description
Windows allows you to associate programs with file extensions using the “Open with” file manager right-click menu extension.
I’m running Windows 7 64bit, and installed the 64 bit versions of 3.6.2 and the beta appropriately.
A couple of problems that I haven’t tested very thoroughly:
1. If you have both POV 3.6.2 and the beta installed at the same time, you can no longer using this dialog change the association to the beta once it has been created for 3.6.2. There’s no error or anything; it just opens the file inside 3.6.2 instead. Maybe because both versions appear as “POV-Ray for Windows” to this dialog? Would adding the version number to the name fix things? Anything I can do on my end of things to resolve this?
2. In POV-Ray 3.6.2, I can use this dialog to open *.inc, *.txt and other files in POV-Ray, but only if POV-Ray isn’t already running. If POV-Ray is already running I get an “Only /EDIT and /RENDER may be passed to previous instance” error. Files with the *.pov extension open properly regardless, without any error. I am unable to test this in the beta at the moment due to the first problem unfortunately. Could someone please test this with the beta and confirm whether the behavior also exists?
3. With the POV-Ray 3.7 beta, entering the following command in the command prompt results in the same error:
"C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"
If I change it to the following it works however:
"C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" /EDIT "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"
Is this error/behavior really necessary? Would it be OK to instead change the behavior when the /EDIT flag is omitted in the command-line such that the file is opened in the editor by default, without throwing an error?
|
|
151 | Runtime error | Possible Bug | 3.70 beta 37a | Very Low | Low | No way to cancel save while parsing, never ending error... | Tracked on GitHub | |
|
Task Description
On Windows, when I try and save a file while it is being parsed prior to rendering, I get an error, “Failed to save file: The operation completed successfully”, with a single OK button to click. Despite the weird wording, I’m OK with that.
However after clicking OK I get the error, “Failed to save file ‘...’“, with three buttons: Cancel, Try Again, Continue. Not sure what “Continue” means in this context, given that the possibilities would seem to be covered by the other two buttons. Whatever.
Also, sometimes I get a message with only a single “Retry” button. Not sure what the exact message was.
Anyway, the real problem is that, regardless of which button I press, the program continues to spawning the same error message endlessly. Luckily there is a delay between them, but still it would be nice to have at least one of the three buttons *stop* POV-Ray from asking me again.
Also, once the program finishes parsing the file and it becomes possible once again to save the file, it does nothing. I.e. it doesn’t save the file. So what’s the point of the message and all the options? Why not just say, “Unable to save the file, file is parsing” and be done with it?
I think I recall the same behavior in 3.6.2, so it’s nothing new that’s been introduced.
|
|
152 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Low | Camera in object, union statements | Closed | |
|
Task Description
Currently, cameras placed inside object or union statements will halt the render with an error. Take for instance the following case:
#local temp_camera_1 = camera
{
orthographic
location z*-12
direction z
up y
right x*image_width/image_height
scale 32
}
#local temp_light_1 = light_source
{
0
color rgb 1
translate <-30, 30, -30>
}
#local temp_light_2 = light_source
{
0
color rgb 1
translate <-30, 30, +30>
}
union
{
object {temp_light_1}
object {temp_light_2}
// camera {temp_camera_1} // doesn't work!!!
}
//object {temp_camera_1} // doesn't work!!!
camera {temp_camera_1} // works!!!
Changing this behavior would make it possible to more easily apply transformations to scene objects and the camera at the same time in situations where the scene’s frame of reference is in motion relative to the rest of the scene, for instance in animations.
|
|
153 | Runtime error | Possible Bug | 3.70 beta 37a | Very Low | Low | Error determining I/O permissions when using .ini file | Closed | |
3.70 release |
Task Description
clipka anonymous@anonymous.org wrote: > Am 29.06.2010 04:27, schrieb jberry02: > > > First, note that this is the Windows version. > > Second the issue is not with opening the ini file, but with opening the scene > > file from within the ini file. > > > > I have a scene.ini file, that has a line: > > > > Input_File_Name=scene > > > > under POV-Ray 3.5 *and* POV-Ray 3.6, the scene defined in the file scene.pov is > > rendered properly using the parameters specified in the scene.ini file. The ini > > file is opened from the POV-Ray GUI, and run using the “Run” button. > > > > under POV-Ray 3.7, I get an error - I originally thought that it was simply not > > looking for scene.pov (i.e., it wasn’t adding the .pov extension when trying to > > open the scene file), but looking closer the error is *actually*: > > > > Input file ‘C:\[...]\scene’ not found; cannot determine I/O permission for > > write. > > Failed to start render: Cannot open file. > > > > In other words, it appears that the problem is that it isn’t adding the default > > ..pov extension when it is trying to do the I/O permission check. I do not have > > any special I/O permisssions configured for any version of POV-Ray (I get the > > pop-up dialogs), and this is a change in behavior from 3.6 to the current beta > > of 3.7. The scene.pov file is not in any of the POV-Ray directories - it is in > > a separate tree where I keep my scene files. > > Having looked at it in a debugger, I can confirm that there is a > problem, and that you don’t seem to be far off the mark: > > The error occurs when POV-Ray tries to determine the I/O permissions for > the /output/ file. If that isn’t explicitly specified with a path, > POV-Ray will try to get the path from the input file; however, it will > take the unprocessed parameter (in the sample case “scene”) rather than > the file name POV-Ray makes of it (”scene.pov”), and then attempts to > get the full /long/ path name of the file (remember the good old 8.3 > filenames for compatibility with 16-bit programs?), which only works > when the file exists. > > Would you mind submitting a bug report to <http://bugs.povray.org>?
|
|
154 | Setup/Install | Possible Bug | 3.70 beta 37a | Very Low | Low | Installation on linux (unix ?) in $HOME/.povray/3.7 set ... | Closed | |
|
Task Description
Installation script (from sources) when run with a classical “sudo make install” would create povray.ini & povray.conf in $HOME/.povray/3.7 (so far so fine) with the owner as root and the permission to readonly for the real user.
Same goes for the owner of the 3.7 directories tree : .povray & .povray/3.7 are created with root owner, despite being in $HOME of the performing user.
Please fix ?
|
|
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
|
|
159 | Frontend | Possible Bug | 3.70 beta 38 | Very Low | Low | Test bug for checking features of flyspray | Closed | |
|
Task Description
Test bug for checking features of flyspray.
|
|
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.
|
|
164 | Other | Feature Request | 3.70 beta 38 | Very Low | Low | Date/time stamp on rendered images | Closed | |
|
Task Description
I’d like to request the ability to create a date/time stamp on output images so that new renders don’t always overwrite old ones. Thanks.
|
|
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
|
|
169 | Parser/SDL | Possible Bug | 3.6 | Very Low | Low | Error in Linux version using #while loop and SweepSplin ... | Closed | |
3.70 RC4 |
Task Description
I used POV-Ray to make an animation of my Morgan driving around a slalom course. (If you are curious, you can see the output on youtube under my user name, nojonushi.) To make the long swooping fenders I used Mike William’s SweepSpline macro.
The code rendered the 1189 frames in one go with no problems. But the wheels in that animation do not rotate, so I then added code to rotate the wheels. In the calculations I added I used a #while loop to step through the spline containing the route coordinates and total up the distance traveled. Running POV-Ray on this file produced a random number of images and then issued an error, e.g.
0:00:00 Processing Frame 456 of 1189
0:00:00 Parsing
File: mogslalom.pov Line: 1918 Parse Warning: Patch objects not allowed in intersection. File: mogslalom.pov Line: 2988 File Context (5 lines):
object {
SweepSpline(TFSpline,
Parse Error: Identifier expected, incomplete function call or spline call found instead.
Most of the parameters for the macro are missing. But this is after successfully generating, in this case, 455 images.
I have attached a text file with set-up and sample code that has given the error on two different machines.
|
|
170 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 39 | Very Low | Low | Reduce memory footprint of output image buffer | Closed | |
3.70 release |
Task Description
Currently, output image is buffered using POV-Ray’s RGBFT color model and floating point values, leading to a memory consumption of 20 bit per pixel. This is an unproportionally large memory footprint, given that the only further processing performed on the buffered data is conversion of the data to the desired output file format, which will typically use only 3 bytes per pixel (at most 12 bit per pixel).
The situation can be improved by choosing the output image buffer container based on the desired output file format and parameters. To this end, the following code changes should be made:
Bundle image file format handler code into classes (typically one per file format)
Include a method to determine the best data container type for the image buffer
Instantiate the desired image file format handler object prior to rendering, querying the handler object for an image buffer
In addition to picking a suitable image data container from the already existing palette, careful design might also allow to use custom containers to directly pass the data to a library (in case the library provides its own buffering anyway), or write it directly to the output file (e.g. when writing image data to stdout). To make this compatible with multithreaded rendering, the following changes would have to be made:
Add code to detect when a row of SMP blocks has been finished, and call a certain method on the image handler object
Design the custom containers in such a way that they can buffer any number of unfinished SMP block rows as needed
|
|
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
}
|
|
172 | Image format | Unimp. Feature/TODO | 3.70 beta 39 | Very Low | Low | Re-implement progressive image output | Tracked on GitHub | |
Future release |
Task Description
With previous versions of POV-Ray, it was possible to turn off display output, but still assess the output during render by viewing the output file as it was progressively generated. This allowed e.g. to run a long render on a remote machine as a background process, and check the output from time to time via FTP or similar.
|
|
173 | Other | Feature Request | 3.70 beta 39 | Very Low | Low | Prevent POV-Ray for Windows from stealing focus | Closed | |
|
Task Description
In some cases it may be desirable to run POV-Ray from a batch file, without causing it to “steal the focus”.
I suggest making this dependant on whether POV-Ray is run with the /EXIT parameter.
|
|
175 | Radiosity | Feature Request | 3.70 beta 39 | Very Low | Low | Radiosity. Emissive and scattering media don't illumina ... | Closed | |
|
Task Description
Tested with beta 40. Also affect version 3.6.1 as reported in the discution group.
When using radiosity and emissive media. Any object, or part of, that is inside the media container is not affected by the illumination comming from the media.
When using scattering media, the light scattered by the media also don’t affect objects that are inside it’s container.
http://news.povray.org/povray.newusers/thread/%3C4cf8fe22%241%40news.povray.org%3E/
|
|
176 | Other | Feature Request | Not applicable | Very Low | Low | Raise maxpower of the Poly Oject to 16. | Closed | |
|
Task Description
At the moment in the Poly Object the maximum power is 15. The mathematics for converting the three parametric equations for x, y and z into a formula for the Poly Object require that the equations are squared several times given max-powers of 4, 8 and even 16. I’ve one eqaution that needs power 16. At the moment this is just one power short. Please raise this to 16. That’s all I ask for.
|
|
177 | Light source | Feature Request | 3.70 beta 39 | Very Low | Low | Add support for conserve_energy to shadow computations | Tracked on GitHub | |
|
Task Description
The following scene gives a comparison of current conserve_energy handling in standard shadow computations vs. photons.
Note how the rather highly reflective slabs fail to cast shadows, except where the photons target sphere enforces computation of shadow brightness to be done by the photons algorithm.
For more realistic shadowing without the need to enable photons, I suggest do add proper conserve_energy handling to the shadow computation code (which shouldn’t be too much effort).
global_settings {
max_trace_level 10
photons { spacing 0.003 media 10 }
}
camera {
right x*image_width/image_height
location <-2,2.6,-10>
look_at <0,0.75,0>
}
light_source {
<500,300,150>
color rgb 1.3
photons {
refraction on
reflection on
}
}
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 { color rgb 0.7 } }
}
#declare M_Glass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0
specular 0.2 // just to give a hint where the sphere is
}
}
interior { ior 1.0 }
}
#declare M_PseudoGlass=
material {
texture {
pigment {rgbt 1}
finish {
ambient 0.0
diffuse 0.5
specular 0.6
roughness 0.005
reflection { 0.3, 1.0 fresnel on }
conserve_energy
}
}
interior { ior 1.5 }
}
sphere {
<1.1,1,-1.3>, 1
material { M_Glass }
photons {
target 1.0
refraction on
reflection on
}
}
// behind target object
box {
<-0.2,0,-2.3>, <0.0,4,0.3>
material { M_PseudoGlass }
rotate z*1 // just to better see the reflection of the horizon
}
// before target object
box {
<2.4,0,-2.3>, <2.6,4,-0.3>
material { M_PseudoGlass }
photons { pass_through }
rotate z*1 // just to better see the reflection of the horizon
}
|