Am 17.03.2011 16:00, schrieb Trevor G Quayle:

> 1) have the trace function return the perturbed intersection point, not the
> triangle surface:  this would have to be done in the POV source.  I imagine this
> is difficult if not nearly impossible, hence we still get the shadow line issue
> with meshes. Not likely solution at present.

At present, POV-Ray does not have any code to compute such a thing as a 
"pertubed intersection point".

> 2) have the trace function return the unperturbed normal at the intersection:
> again this would have to be done in the POV source and would be much simpler, if
> not trivial to do compared to 1.  However this would change the way trace works
> and, in most situations, may not be desirable, and could break older scenes.
> Not likely solution.

While indeed being simpler than 1), the changes would still be 
non-trivial; however, virtually all of the necessary changes should be 
done anyway sooner or later to address some issues with smooth meshes, 
triangles and height fields.

(Internally, POV-Ray is currently aware of two different normal vectors: 
The "pertubed" normal vector after applying "normal{}" blocks, and a 
"raw" normal vector as specified by geometry, /after/ "fake smoothing" 
where applicable (e.g. smooth meshes). For certain computations the true 
non-smoothed geometric normal would be better suited though, so in the 
long run POV-Ray should be made aware of this as a third normal.)

And yes, changing the behaviour of trace() could indeed break older scenes.

> 3) manual method of 2), have two instances of the mesh used, one smoothed, one
> not. the smoothed one gets used for rendering, the unsmoothed for tracing:  Not
> an elegant solution as it requires creating and loading two separate instances
> of the same mesh.

... but possible without any modifications to the POV-Ray code.

Post a reply to this message