Yes, indeed the shading is correct, so I think the normals are fine. So I wonder why:
cosAngle = dot(inNormal, normalize(m_ProjectorLocation – inPosition));
Doesn’t work right. Could it be the difference between the vertex normals and the normals of the surfaces the pixels are on? Seems unlikley…
@the_accidental said:
cosAngle = dot(inNormal, normalize(m_ProjectorLocation – inPosition));
I guess mProjectorLocation is in world space.
inNormal and inPosition are in model space.
you have to either transform m_ProjectorLocation in model space (multiply the InverseWorldMatrix with it) or transform inPosition and inNormal in worldspace.
WorldMatrix * inposition and InverseWorldMatrixTranspose * inNormal in order everything is in the same space.
2 Likes
could you try to disable depth test? to rule out the depth issue?
I’ve no time to do it right now, but if you could either post how (i’m new to jME) or I’ll do some reading in the morning.
ok to disable depth test on a material you can either set it on the mateiral in code by doing
material.getadditionalRenderState().setDepthTest(false);
or directly in the j3m ore j3md file by setting in the additional state area DepthTest false.
Ok, so it’s fixed!
Prize goes to @nehon, it was a co-ordinate system thing. Dunce-hat to me, for not realising at somepoint it stopped recompiling the shaders…what can I say, it was late, I was tired…
Anyway, the change needed for proper perspective projection is:
In the vertex shader:
cosAngle = dot(inNormal, normalize(m_ProjectorLocation - worldPos.xyz));
(worldPos is already defined there as vec4 worldPos = g_WorldMatrix * vec4(inPosition, 1.0)
@Survivor, I’ll leave it to you to test and add the change to your code, doesn’t seem worth me submitting a patch for one line?
It looks like the image is also projected on occluded surfaces (lumps facing the camera, but behind the hill) but that’s a problem for another day!
3 Likes
Space: the final frontier … 
A really stupid mistake. Thanks @the_accidental and @nehon for finding it and providing a solution. I’ve committed a fix. Once I’ve fixed the RC2 incompatibility @haze pointed out, I’ll create a new snapshot.
Edit: The rc2 incompatibility @haze pointed out was caused by r9956. If you want to have a parallel projection camera, you have to call “Camera.setParallelProjection()” after “setFrustumPerspective()”, because the latter sets the camera to perspective (again). This also explains why the frustum for the parallel projector had no longer the shape of a box after r9956. I’ve committed a fix and took a snapshot.
ProjectiveTextureMapping-2012-11-24.zip
Btw, the “space bug” doesn’t show up in my test apps because the geometry is located in world origin where model space == world space. This means the test cases are sh!t. Thanks again!
2 Likes
Thank you, it seems to work fine for me 
Indeed, it only needed a small inversion…I can replace my crappy simple textured quad
@survivor said:
Space: the final frontier ... :D
A really stupid mistake. Thanks @the_accidental and @nehon for finding it and providing a solution. I've committed a fix. Once I've fixed the RC2 incompatibility @haze pointed out, I'll create a new snapshot.
Edit: The rc2 incompatibility @haze pointed out was caused by r9956. If you want to have a parallel projection camera, you have to call "Camera.setParallelProjection()" after "setFrustumPerspective()", because the latter sets the camera to perspective (again). This also explains why the frustum for the parallel projector had no longer the shape of a box after r9956. I've committed a fix and took a snapshot.
ProjectiveTextureMapping-2012-11-24.zip
Btw, the "space bug" doesn't show up in my test apps because the geometry is located in world origin where model space == world space. This means the test cases are sh!t. Thanks again!
Curious what the use case is for calling setFrustumPrespective() when you actually don't want a perspective camera?
@pspeed said:
Curious what the use case is for calling setFrustumPrespective() when you actually don't want a perspective camera?
If there is a better way to initialize the camera matrix for parallel projection, then I guess there is none. I was (and still am) learning by doing. When I started ProjectiveTextureMapping, I didn't (and still don't) know better. That's also the explanation for the "space bug". I learned about "space" in my other project RealSlimShader, but forgot to transfer what I've learned back to this project.
Actually there is a setFrustum method that allows you to set the parallel planes (top, bottom, left, right , near, far).
By default a camera had no perspective so we agreed to default parallelProjection to true, and change it to false when setFrustumPerspective was called, because it’s, by definition, creating a perspective.
Before you were creating a camera, isParallelProjection was returning false even if the camera had no perspective set, which was not consistent.
That’s why you had your issue.
Now would be a good time to make an extension library (plugin) for this
@Momoko_Fan said:
@nehon: Did the change you mentioned to camera/frustum was actually made?
yeah, as survivor mentioned http://code.google.com/p/jmonkeyengine/source/diff?spec=svn9956&r=9956&format=side&path=/trunk/engine/src/core/com/jme3/renderer/Camera.java
@Momoko_Fan said:
@nehon: Did the change you mentioned to camera/frustum was actually made?
And the funny thing is that you and I were talking about it on the chat when I made the change. ;)
You can have perspective and still want to set the planes values, keeping the perspective. Can’t you?
Hmm, yeah. setFrustum() could be used for perspective projection if you pick the right values. Also the construction of the projection matrix depends on the parallel projection value so either way you have to know what you’re doing. I think its fine then.
@Momoko_Fan said:
Hmm, yeah. setFrustum() could be used for perspective projection if you pick the right values. Also the construction of the projection matrix depends on the parallel projection value so either way you have to know what you're doing. I think its fine then.
Which is EXACTLY the same conclusion you came to when we chatted about this as I was committing. :) It's like deja vu all over again. :)
1 Like
Just trying to download this. But both snapshots are missing the assets/Common/… folder containing all the shader information. It seems to be missing on the google code svn trunk as well. 
I would really love to try it out.