It sounds like you might be asking for the setTexProjector() call as described at the top of Projected Textures, which updates the UV’s from the other node’s position without doing a full lens-based projection.
Still seems wrong.
The source is the camera, might that be the issue? I still use base.enableMouse() controls, not directly call base.camera.setPos(). It also seems that texProjector ignores previous calls like setTexScale, huh? Seems like it
mynode.setTexProjector(myts, base.camera, mynode)
I also used this on the texture, might this be a problem?
If the first parameter to setTexProjector() is a Camera or LensNode, then it will also apply the perspective transform from the lens. If you want to project from the camera’s position without using the lens attributes too, then use base.camera instead of base.cam.
You don’t need to apply setTexProjector() in a task, once is sufficient. But it’s roughly equivalent to creating a task that does something like node.setTexTransform(from.getTransform(to)) every frame.
It will replace a previous transform you’ve established. If you want to apply an additional transform, then you can apply it to a lower node, e.g. use node.setTexTransform() on a parent node, then child.setTexScale() or whatever.
Neither setCombineRgb() nor setWrapU()/setWrapV() have anything to do with UV placement.
Perhaps it is working, but not in a way you expect. Can you clarify precisely what behavior you are expecting to find? If nothing else, you should be able to write a task to perform the precise operation you wish each frame.
I can’t tell you if it’s “right” because I don’t know precisely what you want to achieve. The above setTexProjector() call will apply the relative transform from base.camera to mynode to the texture coordinates of mynode each frame. That’s kind of a weird thing to do, but I don’t know what effect you’re trying to achieve, so I can’t tell you whether this is the way to achieve that or not.
setTexProjector() involves three NodePaths:
a.setTexProjector(ts, b, c)
It’s legal for b or c to be the same as a, but it’s not required. The operation of setTexProjector is to apply the relative transform of b to c to the texture coordinates of a. It’s the same as writing a task that does this each frame:
Your setTexPos() task will result in a similar effect, but again I can’t tell you whether it will be the effect you want or not, without having an understanding of precisely what effect you want.
I think I can explain my case in a simple way. Imagine the camera is really a node, the “mynode” is the ground and I want to project fake shadows based on “nodes” x, y position on “mynode” (the ground).
You mean you want to put a shadow on “mynode” that happens to be below “node”? Using setTexProjector(), or setTexTransform(), is only part of the solution. The rest of it is to do mynode.setTexGen(ts, TexGenAttrib.MWorldPosition), so that the texture coordinates you’re transforming are in the right space to begin with.
Or, you can just use mynode.projectTexture(), which does this sort of thing for you automatically, as described in the manual.
But your OP says you don’t want to use a projected texture, and yet what you describe is exactly what a projected texture is, so I still don’t understand what it is you do and don’t want to happen.
for this to work? Is this what converts the camera/ball/etc world units to texture’s UV units?
It looks pretty strange, it seems to take into account the camera angle, not position in that case.
And I think projectTexture() wouldnt work only because I only need to use the node’s x and y position.
Projected textures can be used to implement shadows, but they aren’t exclusively used for shadows. What you’re describing is a projected texture.
The reason that you need to do the setTexGen() call is because your UV’s don’t initially correspond to XYZ position, so the setTexTransform() call doesn’t make sense. In your case, though, it appears that your UV’s almost correspond to XYZ position, with the exception of a scale by 150, so doing the counterscale explicitly mostly works for you. So you can just do that if it makes more sense to you.
That value isnt 100% correct, it gets worse as yuo move farther.
Id like it to be 100% correct by doing that setTexGen you suggested, but like I said it seems to use the camera’s anles, not position. I could try it with a non camera node to see if something changes.