|
321 | 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?
|
|
326 | Other | Definite Bug | 3.70 release | Very Low | Low | restricted setting ignored in 3.7 | Tracked on GitHub | |
|
Task Description
Due to a typo in the conf file parser (introduced, I think, in refactoring after 3.6), the restricted setting is ignored, and access checks aren’t performed.
Fixing this reveals some other issues:
%INSTALLDIR%/../../etc is incompletely canonicalized to /usr/local/share/../etc , not /usr/local/etc
read+write paths are added to the read list only, so writing is impossible
See attached patch.
Relatedly, I think it would be nice to add a new replacement token %CONFDIR% instead of %INSTALLDIR%/../../etc .
Also, there’s a realpath function that could simplify path handling, though I’m not sure if it’s available on all platforms.
|
|
327 | Parser/SDL | Feature Request | 3.70 release | Very Low | Low | Support for non-ASCII characters in filename strings | Tracked on GitHub | |
|
Task Description
pov 3.7 Can not identify the Chinese.I give the texture map filename in chinese,it turns out parse error.
|
|
329 | Documentation | Possible Bug | 3.70 release | Very Low | Low | Mesh_camera type 0 output seems | 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.
|
|
330 | 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
|
|
332 | User interface | Feature Request | 3.70 release | Very Low | Low | Progress animation in taskbar tabs | Closed | |
|
Task Description
On Windows 7 and newer operating systems, some programs are able to display their progress in the taskbar buttons.
Here is an example of Chrome downloading something and showing the progress in the taskbar:
http://www.winbeta.org/sites/default/files/news/oldfashinoned.jpg
Here is an example with Paint.NET instead:
http://www.getpaint.net/images/pdn351_superbarProgress.png
I think this feature would use fewer CPU resources than a) minimizing/maximizing the whole application window each time you want to check progress, or b) hovering the mouse over the taskbar button to show the thumbnails.
|
|
333 | User interface | Feature Request | 3.70 release | Very Low | Low | Make text in "about" alt+b dialog selectable with the m... | Tracked on GitHub | |
|
Task Description
When you press alt+b or access the “about” dialog in the Help menu it displays some text including software version number and list of contributors.
It would be nice to be able to select and copy this text using this mouse. Sometimes in the newsgroup I have to tell people what version of POVray I am using, and typing the version number can be a pain.
|
|
334 | Texture/Material/Finish | Feature Request | 3.70 release | Very Low | Low | HLS colors | Tracked on GitHub | |
|
Task Description
It would be nice to be able to specify colors in HLS as well as RGB.
Currently, you can use a macor to convert individual colors. But this does not work in color_maps where you want smooth gradations/interpolations between two or several colors.
|
|
335 | Parser/SDL | Possible Bug | 3.70 release | Very Low | Low | macro works in variable but not in array | Tracked on GitHub | |
|
Task Description
This doesn’t work:
#declare pavement_object = array[2] {
object {trash_can_macro() scale 3/4 translate -x * 1/2},
object {potted_plant_macro(_CT_rand2) scale 3/4 scale 3/2 translate -x * 1/2}
}
This does work:
#declare trash_can_object = object {trash_can_macro()}; #declare potted_plant_object = object {potted_plant_macro(_CT_rand2)}; #declare pavement_object = array[2] {
object {trash_can_object scale 3/4 translate -x * 1/2},
object {potted_plant_object scale 3/4 scale 3/2 translate -x * 1/2}
}
Logically, I cannot see a reason for this to be so.
|
|
336 | Parser/SDL | Definite Bug | 3.70 release | Very Low | Low | #fopen w/o OPEN_TYPE crash povray (segfault) | Closed | |
3.71 release |
Task Description
#fopen directive w/o OPEN_TYPE (yeah, I forgot it, some other languages have ‘read’ as default value)
expected behavior: Parse error msg “line XXX, OPEN_TYPE missing in #fopen directive”, then stop.
observed behavior: crash - Segfault err (core dump) in Parsing stage
minimal working example attached
|
|
12 | Texture/Material/Finish | Definite Bug | 3.70 beta 32 | Very Low | Very Low | facets pattern in normal map | Closed | |
3.70 RC6 |
Task Description
Using a facet pattern in a normal map results in a unspecified error in Evaluate_TPat at the render stage. This probably should be caught at parse time to give a more descriptive error and a line number.
Example:
sphere {
0, 1
texture{
pigment{rgb <1,1,1>}
normal {
facets
normal_map {
[0 bumps ]
[0.5 facets ]
[1 bumps ]
}
}
}
}
|
|
20 | User interface | Feature Request | 3.70 beta 32 | Very Low | Very Low | render window behavior | Tracked on GitHub | |
|
Task Description
When changing the behavior of the render window, “Keep above main”, requires restarting the POV editor to take effect. It would be nice either to get a warning to restart, or to get it to work without restarting.
|
|
30 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | Custom progress information during parsing | Closed | |
|
Task Description
For some particularly “heavy” SDL scripts, it might be desirable to override (or complement) the standard “Parsing 47110815K tokens” progress information with some more helpful custom info, e.g. “Planting trees... (37%)”, or “Generating terrain mesh row 47 of 500”.
|
|
83 | Source code | Possible Bug | 3.70 beta 36 | Very Low | Very Low | redundant code in pvengine.cpp | Closed | |
3.70 beta 37 |
Task Description
In pvengine.cpp (file revision 154), lines 4003-4006 are exact duplicates of lines 3999-4002:
3997 case KEYWORD_LOOKUP_MESSAGE :
3998 hh_aklink.pszKeywords = (LPCSTR) lParam ;
3999 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4000 hh_aklink.pszKeywords = "" ;
4001 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4002 hh_aklink.pszKeywords = "" ;
4003 if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4004 hh_aklink.pszKeywords = "" ;
4005 if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4006 hh_aklink.pszKeywords = "" ;
4007 HtmlHelp (NULL, engineHelpPath, HH_KEYWORD_LOOKUP, (DWORD_PTR) &hh_aklink) ;
4008 return (true) ;
This duplication appears pretty much useless to me - or am I missing something?
|
|
84 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | A for-loop construct | Closed | |
3.70 beta 37 |
Task Description
Many people clearly miss a simple for-loop construct in povray. It is indeed true that probably at least 99% of #while loops out there have the form of a simple for-loop. It’s much rarer to have to use more exotic forms of looping supported by the #while mechanism. Thus it would make sense if a #for construct would be added which would make writing such loops much easier and convenient.
The only remaining question would be the syntax.
IMO the for-loop construct should implicitly declare a local variable of a specified name, automatically increment it during the loop, and then undefine it after the loop ends. It could perhaps be something along the lines of:
#for(<identifier name>, <initial value>, <final value> [, <step>])
<loop body>
#end
Example:
#for(Counter, 1, 10) // 'Counter' gets values 1, 2, 3, ..., 10
#debug concat(str(Counter, 0, 0), "\n")
#end
#for(Counter, 1, 10, 3) // 'Counter' gets values 1, 4, 7, 10
#debug concat(str(Counter, 0, 0), "\n")
#end
I think this syntax ought to be relatively easy to implement (compared to more “traditional” syntaxes, such as something like “for Counter = 1 to 10” or the C syntax, which would be a lot more complicated).
Of course this raises a couple of questions:
1) What happens if ‘Counter’ was already declared as an identifier? One of three possibilities comes to mind:
2) Should the user be able to modify the counter variable from inside the body of the loop? Something like this comes to mind as viable:
// Prints the values 1, 2, 3, 9 and 10
#for(Counter, 1, 10)
#debug concat(str(Counter, 0, 0), "\n")
#if(Counter = 3) #local Counter = 8; #end
#end
Alternatively the counter variable could be read-only.
Additionally, it could be nice if #break could be used to immediately jump out of the current loop (either #while or #for).
|
|
86 | Parser/SDL | Feature Request | Not applicable | Defer | Very Low | Add support for more RNG types | Tracked on GitHub | |
Future release |
Task Description
The current 32-bit linear congruential generator used as RNG in POV-Ray is sometimes quite limited for some purposes and in a few cases its poor quality shows up (as has been demonstrated more than once in the newsgroup). Thus it would be nice if POV-Ray offered additional, higher-quality random number generators, besides the current one (which should probably remain for backwards compatibility). These RNGs could include algorithms like the Mersenne Twister and the ISAAC RNG, both of which have very decent quality and have an enormous periods (while at the same time being very fast).
After a long discussion, the following syntax for specifying the RNG type and seed (which may be larger than 32 bits) has been suggested:
seed(<value>) | seed(<type>, <value> [, <values>])
For example:
#declare Seed1 = seed(123); // Use the current RNG, with seed 123
#declare Seed2 = seed(1, 123); // Identical to the previous one
#declare Seed3 = seed(2, 456, 789, 123); // Use RNG algorithm #2,
// with a large seed (96 bits specified here)
A C++ implementation of the ISAAC RNG can be found at http://warp.povusers.org/IsaacRand.zip
|
|
87 | Geometric Primitives | Feature Request | Not applicable | Defer | Very Low | Add new feature: Reference object | Tracked on GitHub | |
Future release |
Task Description
When you instantiate an object several times, eg:
object { MyObj translate -x*10 }
object { MyObj translate x*10 }
POV-Ray will copy that object in memory, at least for most types of objects. Not for all of them, though. Most famously if MyObj is a mesh, it won’t be copied, but only a reference to the original will be used, thus saving memory. (There are a few other primitives which also don’t cause a copy, such as bicubic_patch and blob, but those are naturally not so popular as mesh, so it’s a less known fact.)
AFAIK the reason why referencing (rather than copying) is not used for all types of objects is rather complicated, and mostly related to how transformations are applied to these objects. For example if the object being instantiated is a union, the translates above will be (AFAIK) applied to the individual members of the union rather than to the union object itself.
Copying, however, can be quite detrimental in some situations. For example if you have a huge union, and you want to instantiate it many times, the memory usage will be that many times larger (compared to just one instance). This is sometimes something which the user would not want, even if it made the rendering slightly slower as a consequence. (In other words, better to be able to render the scene in the first place, rather than running out of memory.)
Redesigning POV-Ray so that all objects would be referenced rather than copied would probably be a huge job, and in some cases a questionable one. There probably are situations where the current method really produces faster rendering times, so redesigning POV-Ray so that it would always reference instead of copy, could make some scenes render slower.
So this got me thinking about an alternative approach: How hard would it be to create a special object which sole purpose is to act as a reference to another object, without copying it? This special reference object would act as any regular object, would have its own transformation matrix and all that data related to objects, but its sole purpose is to simply be a “wrapper” which references an existing object. It could be, for example, like this:
object_ref { MyObj translate -x*10 }
object_ref { MyObj translate x*10 }
The end result would be exactly identical as earlier, but the difference is that now MyObj behaves in the same way as a mesh (in the sense that it’s not instantiated twice, but only once, even though it appears twice in the scene), regardless of what MyObj is.
In some cases this might render slightly slower than the first version (because POV-Ray has to apply the transformations of the object_ref first, after which it applies whatever transformations are inside MyObj), but that’s not the point here. The point is to save memory if MyObj is large.
An object_ref would behave like any other object, so you could do things like:
#declare MyObjRef = object_ref { MyObj };
object { MyObjRef translate -x*10 }
object { MyObjRef translate x*10 }
(The only thing being instantiated (and copied) here is the “MyObjRef” object, not the object it’s referring to, so that actual object is still stored in memory only once.)
In some situations it might even be so that referenced objects actually render faster than if the objects were copied because references increase data locality, lessening cache misses.
I believe this could be a rather useful feature and should be seriously considered, unless there are some major obstacles in implementing it.
|
|
90 | Parser/SDL | Definite Bug | 3.70 beta 36 | Very Low | Very Low | POV-Ray accepts additional patterns after "slope" | Closed | |
3.70 beta 37 |
Task Description
The following code is erroneously accepted by POV-Ray (tested with 3.7.0.beta.36):
pigment{
slope { x }
checker
}
The result is a checker pattern.
Apparently there is an EXIT statement missing in the slope-pattern parsing code in parstxtr.cpp.
|
|
99 | Refactoring/Cleanup | Unimp. Feature/TODO | 3.70 beta 36 | Defer | Very Low | Refactor engine (front- & back-end) code for Unicode su... | Tracked on GitHub | |
Future release |
Task Description
Front- & Back-end code should be refactored for full Unicode support in scene files and strings.
|
|
109 | Other | Compatibility Issue | 3.70 beta 37a | Defer | Very Low | Debug_File No Longer Appends Frame by Frame Debug Data | Closed | |
Future release |
Task Description
The function of the “Debug_File=” .ini option has changed from 3.6 to 3.7.37a. In 3.6, when rendering multiple frames, a debug file would be created that then appended the debug lines for each frame into the file. It was therefore able to have debug data that identified what parameters were used in which frame in case a frame did not have the desired effect.
In 3.7.37a, the debug file does not perform this function. Instead it creates a new debug file (overwriting the prior) with each new frame. Therefore the debug data is only useful for the final frame (or wherever the render was halted). This is useful for a single frame render or for identifying a fault within a series of frames (because only the last one will remain) but it is not useful for many frames that render successfully.
This problem does not cause any rendering errors or other defects. The debug file specified will only contain the debug data for the last frame rendered.
Per discussion in the forum it was unknown if this was a bug or “feature”. At this time it is causing me a problem so I am submitting the bug. No related bugs were found searching for “output” or “debug” in any status.
Operating System in use is Windows XP. I cannot test 3.7.37a in additional OSes, but it does not seem like it would be OS-specific.
|
|
120 | Documentation | Compatibility Issue | 3.70 beta 37a | Very Low | Very Low | More library paths, wildcards | Closed | |
3.70 release |
Task Description
20 library paths is a bit small given the sheer number of include files I’ve collected over the years. An increase in the number, and/or the ability to include wildcards in the search path, would be great.
|
|
124 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | variable number of parameters in macros | Closed | |
Future release |
Task Description
Many programming languages support an indeterminate number of parameters in functions/macros.
JavaScript for instance supports an “arguments” object.
Lua for instance supports the “args” object.
I would like to see that added to POV as well.
Here’s an JavaScript example:
function ArgTest(a, b){
var i, s = "The ArgTest function expected ";
var numargs = arguments.length; //Get number of arguments passed.
var expargs = ArgTest.length; //Get number of arguments expected.
if (expargs < 2)
s += expargs + " argument. ";
else
s += expargs + " arguments. ";
if (numargs < 2)
s += numargs + " was passed.";
else
s += numargs + " were passed.";
s += "\n\n"
for (i =0 ; i < numargs; i++){ //Get argument contents.
s += " Arg " + i + " = " + arguments[i] + "\n";
}
return(s); //Return list of arguments.
}
|
|
125 | Parser/SDL | Feature Request | 3.70 beta 37a | Very Low | Very Low | System variable to track whether a file has been includ ... | Closed | |
|
Task Description
Request a system variable to test whether a scene file has been included by another scene file.
For instance:
#if (is_included)
camera {...}
#end
|
|
129 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | Hash arrays | Tracked on GitHub | |
Future release |
Task Description
Currently, array items may only be referenced by their index number (an integer). It would be nice to also be able to assign string values as array indexes, as in other scripting languages.
|
|
133 | Geometric Primitives | Feature Request | 3.70 beta 37a | Defer | Very Low | Subdivision support | Tracked on GitHub | |
Future release |
Task Description
Someone built a version of Povray with internal support for automatic subdivision of meshes. See:
http://www.cise.ufl.edu/~xwu/Pov-Sub/
Would like to see this feature added natively to Povray.
|
|
136 | Parser/SDL | Feature Request | 3.70 beta 37a | Defer | Very Low | String concatenation operator | Closed | |
|
Task Description
Using the concat function is tedious. Why not just have an operator with which to concatenate strings?
“Hello " + “world!”
“Hello " . “world!”
|
|
160 | Other | Feature Request | All | Very Low | Very Low | Parallel GPU processing support | Closed | |
|
Task Description
...for instance nVidia’s CUDA architecture, discussed here and other places.
General consensus is that it’s not worth the effort if only a partial set of POV-Ray’s features are possible.
|
|
185 | Other | Definite Bug | 3.70 beta 41 | Very Low | Very Low | wrong message about image resolution | Closed | |
3.70 RC2 |
Task Description
‘povray -H10 -W20 myscene.pov’ will generate a file with a picture 10 pixels high and 20 pixels wide, BUT in the message pane it displays
Image resolution.....20 by 10 (rows 1 to 20, columns 1 to 10)
instead of
Image resolution.....20 by 10 (rows 1 to 10, columns 1 to 20)
or
Image resolution.....20 by 10 (columns 1 to 20, rows 1 to 10)
|
|
193 | Sample scenes | Unimp. Feature/TODO | 3.70 RC3 | Very Low | Very Low | "pure white" typo in "Insert Menu" bitmap - simple solu ... | Closed | |
|
Task Description
In the folder “ready made scenes”, there is the file “B0 - Basic scene 11 - pure white background.txt”. The text string to be rendered lacks the “e” in “pure”. Unfortunately, this makes the typo visible in the “Insert menu” preview image.
If the “e” is added, the text needs to be scaled a bit smaller (0.43 instead of 0.44) to fit inside the view.
The following code contains a possible “fix” (whatever). It would be great if someone could fix this easy issue:
text { ttf "arial.ttf", "pure white background", 0.02, 0.0 // thickness, offset
texture{ pigment{ color rgb<1,0.6,0>*0.5 }
finish { phong 0.1 }
} // end of texture
scale<1,1.25,1>*0.43
translate<-2.10,-0.30,0.00 >
} // end of text object ---------------------------------------------
|
|
199 | Sample scenes | Definite Bug | 3.70 RC3 | Very Low | Very Low | typos in sample scenes prevent render | Closed | |
3.70 RC4 |
Task Description
.../scenes/objects/fractal2.pov
in global_settings "max_trace" should be "max_trace_level"
.../scenes/advanced/diffuse_back.pov
in global_settings assumed_gamma statement should not be followed by a semicolon
.../scenes/advanced/blocks/stackernight.pov
in global_settings "assummed_gamma" should be spelled "assumed_gamma"
.../scenes/portfolio/*.pov
in all files other than _empty.pov the parse stops at the lines containing "[frame_number-1]" I'm guessing it should be "[frame_number]-1"
|
|
237 | User interface | Definite Bug | 3.70 RC3 | Defer | Very Low | Glitch in displaying rendered pixels and percentage | Tracked on GitHub | |
|
Task Description
When rendering in multiple passes (radiosity in my case), the elapsed pixels and percentage, written to terminal are first displayed like this: Rendered 126202 of 360000 pixels (35%) Then on the second stage the output text becomes shorter and you see Rendered 25344 of 360000 pixels (7%)%) The contents of the previous status are not erased, so the longer text persists (note the duplicate percentage sign and closing parenthesis). Such a glitch could have more drastic effect in rare cases.
I’m running Version 3.7.0.RC3 (g++ 4.6.2 x86_64-unknown-linux-gnu) compiled for the Arch Linux package.
|
|
242 | Other | Feature Request | All | Defer | Very Low | Algorithm to fix the so-called shadow line artifact | Tracked on GitHub | |
|
Task Description
The so-called shadow line artifact (http://wiki.povray.org/content/Knowledgebase:The_Shadow_Line_Artifact) which affects objects with a ‘normal’ statement as well as smooth meshes and heightfields can be really annoying sometimes. Currently the only way to remove it is to make the object shadowless, which isn’t a good solution except in very special cases.
This algorithm could remove the artifact: If the actual normal vector of the object points away from the light source (its dot-product with the light vector is negative) but the perturbed normal points towards it (dot-product positive), then ignore the first shadow-test intersection with the object itself.
There are alternative ways of implementing an equivalent functionality:
- Don’t check the condition (if it’s too difficult to check due to how the code is designed) but always ignore the first intersection with the objects itself. This will work properly with closed surfaces but not with open ones, so it might need to be a feature for the user to turn on with a keyword (similar to eg. ‘double_illuminate’).
- Alternatively, don’t ignore the first intersection, but instead ignore the “opposite side” of the object’s surface (again, possibly only if a keyword has been specified). In other words, if we are rendering the outer side of the object, ignore its inner side when shadow-testing, and vice-versa.
- Perhaps simply add a feature to make surfaces one-sided (similarly to how they can be made so in OpenGL and similar scanline rendering systems). In other words, the inner side of a surface is completely ignored everywhere, making the object virtually invisible from the inside. The advantage of this feature would be that it can have uses other than simply removing the shadow line artifact.
|
|
272 | Other | Feature Request | 3.70 RC6 | Defer | Very Low | Minor change, significant speedup in cubic polynomial s... | Tracked on GitHub | |
3.71 release |
Task Description
While familiarizing myself with the code, I found some small changes in the solve_cubic function that lead to a significant speedup.
In my experience, “pow” is by far the slowest function in math.h and replacing it with simpler functions usually makes a tremendous impact on the speed (it’s an order of magnitude slower than sqrt/exp/cbrt/log).
solve_cubic has a “pow” function that can be replaced by cbrt (cubic root), which is standard in ISO-C99 and should be available on all systems. Separate benchmarks of solve_cubic function show this change almost doubles the speed and does not lower the accuracy. As solve_cubic is part of the solution of quartic equation, this improves the speed for many primitives. Testing with a scene containing many torus intersection tests (attached below) I still observed almost 10% speedup (Intel, 4 threads, 2 hyperthreaded cores, antialiasing on, 600×600: from 91 to 84 seconds). And this is for a torus, where a lot of time is spent in the solve_quartic and cubic solver is only called once! Similar speedup should be expected for prism, ovus, sor and blob.
I do believe the cubic solver can be done without trigonometry, but that would mean changing the algorithm, introducing new bugs and requiring a lot of testing. However, the trigonometric evaluation can still be simplified (3% speedup in full torus benchmark).
These changes don’t affect the algorithm at all, they are mathematically identical to the existing code, so the changes can be applied immediately. I also included other changes just as suggestions. Every change is commented and marked with [SC 2.2013].
This sadly does not speedup the sturm solver, which uses bisection and regula-falsi and looks very optimized already.
The test scene I used has a lot of torus intersections from various directions (shadow rays, main rays, transmitted rays).
|
|
300 | Other | Feature Request | 3.70 RC7 | Defer | Very Low | Reference Documentation Support | Tracked on GitHub | |
|
Task Description
As emerged as an idea during the discussion of FS#299, an SDL / POV-Ray editor feature would be useful that allows API documentation via formal comments, e.g. in include files:
/**
* Creates a car object.
* @param a
* description of param a
* ...
*/
#macro car(a,b,c)
...
#end
In addition to the ability of (auto-)generating a documentation file from such comments, an editor window feature would be convenient that allows popup display of a macro’s (object’s / parameter’s / ...) documentation section.
|
|
303 | Other | Definite Bug | 3.70 RC7 | Defer | Very Low | wrong bit depth reported for OpenEXR file format | Tracked on GitHub | |
|
Task Description
When using OpenEXR output file format, POV-Ray erroneously reports it as “24 bpp EXR” in the message output, while in fact it generates a 3×16 = 48 bpp file.
|
|
323 | User interface | Possible Bug | 3.70 release | Very Low | Very Low | Tooltip for render speed status bar has wrong unit | Tracked on GitHub | |
|
Task Description
Tooltip popup for render speed always displays as “Pixels per Second” rather than matching status bar. I’ve noticed it in 3 renders so far. Most of my renders are fast enough not to see any other unit besides PPS, but I should be able to reproduce again if necessary.
|