The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

IDCategoryTask TypeReported InPrioritySeverity  descSummaryStatusProgressDue In Version
242OtherFeature RequestAllDeferVery LowAlgorithm to fix the so-called shadow line artifactTracked 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.

86Parser/SDLFeature RequestNot applicableDeferVery LowAdd support for more RNG typesTracked 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

87Geometric PrimitivesFeature RequestNot applicableDeferVery LowAdd new feature: Reference objectTracked 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.

Showing tasks 101 - 103 of 103 Page 3 of 3 - 1 - 2 - 3

Available keyboard shortcuts


Task Details

Task Editing