|
100 | Texture/Material/Finish | Definite Bug | 3.70 beta 36 | Very Low | Low | cutaway_textures | Closed | |
3.70 beta 37 |
Task Description
When using cutaway_textures the differenced part traces black. Simple scene file attached.
|
|
101 | Include files | Feature Request | 3.70 beta 36 | Very Low | Low | woodmaps.inc dependency | Closed | |
3.70 beta 38 |
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
|
|
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.
|
|
103 | Image format | Definite Bug | 3.70 beta 37 | Very Low | Low | JPEG output does not conform to baseline JFIF standard | Closed | |
3.70 beta 38 |
Task Description
POV-Ray 3.7-generated JPEG image output files do not conform to the JFIF standard. Most importantly, the files written do not use the standard YCbCr color model (they seem to use plain RGB instead), nor do they have a proper JFIF tag.
As a consequence, some software may be unable to read the generated JPEG files properly. In addition, it seems that POV-Ray mixes up the Red and Blue channels.
|
|
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.
|
|
107 | Parser/SDL | Definite Bug | 3.70 beta 37 | Very Low | Low | Failed to parse INI file, over network | Closed | |
3.70 beta 38 |
Task Description
I can no longer run a Myfile.ini over a network, on a different computer.
Possiblely related to:
http://bugs.povray.org/task/97 FS#97 (Forward-slash pathnames not fully supported in Windows version)
- Cannot open INI file ‘\\STEPHEN-POVRAY\Bishop3d\Objects\Industrial_enclosure\Telco_enclosure_extra.ini’. Failed to start render: Failed to parse INI file
|
|
108 | Parser/SDL | Feature Request | 3.70 beta 37 | Very Low | Low | motion_blur feature similar to Megapov version | Tracked on GitHub | |
Future release |
Task Description
motion_blur which is a simple and effective feature to use in Megapov to simulate motion blur of, e.g. bird wings, propellers or running animals, would be a neat addition to version 3.7 and later.
In Megapov, the feature requires a line of code in the global_settings{} e.g.: motion_blur 10, 2 and a declaration for the moving object. e.g.:
motion_blur {
type 0
object{MyObject material{MyMaterial rotate x*clock*2}}
rotate x*clock*10
}
type represents several types of pre-defined motions.
Thanks,
Thomas
|
|
110 | Sample scenes | Definite Bug | 3.70 beta 37a | Very Low | Low | Sample Lathe Scenes no Longer work in 3.7 | Closed | |
3.70 beta 38 |
Task Description
The following line in the lathe1a.pov, lathe1b.pov, and lathe1c.pov appears to have an error in it.
<3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
Although it works in version 3.6, only in 3.7 does a render time error ocurr.
Scene source should be adjusted to the following
<3.6, 0.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,
|
|
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
|