Projective texture mapping: Difference between revisions

Revision as of 23:29, 2 February 2006

Revision as of 18:17, 3 February 2006

Line 8:

Historically{{ref|nvsdk_ptm}}, using projective texture mapping involved considering a special form of eye linear texture coordinate generation{{ref|glEyeLinear}} transform (''tcGen'' for short). This transform was then multiplied by another matrix representing the projector's properties which was stored in texture coordinate transform matrix{{ref|glTCXform}}. The resulting concatenated matrix was basically a function of both projector properties and vertex eye positions.

The key points of this approach are that eye linear tcGen is a function of vertex eye coordinates, which is a result of both eye properties and object space vertex coordinates (more specifically, the object space vertex position is transformed by the model-view-projection]] matrix).

Because of that, the corresponding texture matrix can be used to "shift" the eye properties so the concatenated result is the same as using a eye linear tcGen from a point of view which can be different from the observer.

== Programmable pipeline approach ==

A less involved method to compute this approach became possible with [[vertex shaders]]. Readers are encouraged to check this method is essentially the same as before.

For readers not familar with this newer graphicgraphics technology, this feature allowallows to override the default vertex and pixel processing allowing a user defined program to be used.

The aboveprevious algorithm can then be reformulated by simply considering two model-view-projection matrices: one from the eye point of view and the other from the projector point of view.

In this case, the projector model-view-projection matrix is essentially the aforementioned concatenation of a eye-linear tcGen and with the intended projector shift function.

By using those two matrices, a few instructions are sufficient to output the transformed eye space vertex position and a projective texture coordinate. This coordinate is simply obtained by considering the projector's model-view-projection matrix: in other words, this is the eye-space vertex position if the considered projector would have been an observer.

Line 26:

According to the used texture wrap mode various artifacts may occur but it's obvious a shift and scale operation is definetly necessary to get the expected result.

The other problem is actually a mathematical issue. It is well known the matrix math used produces a back projection. This artifact has istoricallyhistorically been avoided by using a special black and white texture to cut away unnecessary projecting contributions. Using pixel shaders a different approach can be used: and a coordinate check is sufficient to discriminate between foward (correct) contributions and backward (wrong, to be avoided) ones.