Lib3d - help with 'setCameraTarget'

I'm having some trouble using the lib3d 'setCameraTarget' routine... it's not acting anything like I'd expect. As I don't see 'setCameraTarget' used in any of the example code that comes with lib3d, I may be expecting it to do things it wasn't designed to do (?) - though it is a public interface.

What I'm trying to accomplish is to wander the camera around in the scene - translation (setCameraOrigin) acts like I'd expect. I'm trying to also use the 'setCameraTarget' rotate the camera around the Y axis ('camera turn left or right'). I've tried various flavors/combination of first translating the camera to world origin, applying a 'look at', translating it back again, etc. etc. and things are just acting strange.

To keep this question/example simple, as a test case I leave the camera origin fixed at 0,1.5,0 - so I'm basically trying to rotate a slightly elevated camera while sitting at the scene origin. Initial camera parms are:

local cameraX = 0
local cameraY = 1.5
local cameraZ = 0
local cameraAngle = 90		-- init: looking from world origin, up the Z axis

I create a simple wire cube (four faces, wireframe, 2 units length for each edge) centered at 0,0,10 and place it in the scene. This gives us a view like this:

All good so far.

So now, I'm trying to just spin the camera around the Y axis at the center of the scene, I'd expect that cube to go left or right (eventually going past the edge / behind the camera eye) depending on the direction of the spin.

I put together a little trig in a function to compute a simple 'look at' point - the x,z coordinates on the edge of a unit circle lying flat, with it's normal pointing up the Y axis:

local function applyPlayerAngleToCamera()
	-- assumption for this test is that camera _position_ remains at 0,cameraY=1.5,0
	-- we're just spinning the camera around the Y axis
	local lookX = math.cos(math.rad(cameraAngle))
	local lookZ = math.sin(math.rad(cameraAngle))

	scene:setCameraTarget(lookX, cameraY, lookZ)
end

But when I bump 'cameraAngle' (one degree per update cycle using left/right buttons), I don't see the cube moving off the left or right edge as I'd expect - instead the cube remains centered in the camera view while spinning around its y-axis:

ezgif-4-cd1e5f9312

This is acting like the camera 'look at' is locked on the aggregate center of the nodes of the scene, and somehow results in panning the camera around that (and even if it was doing that I don't see how unit circle coords could result in something that looks like the camera is being swung around some arbitrary point in the scene on a string 10 units long).

I think I'm really missing something. Is 'setCameraTarget' supposed to be used by a client application? Am I just using it wrong? Is my math just wrong (quite possible)? Or am I completely off base and I should leave the camera where it is at the origin and instead move the scene nodes around (translation and rotation matrix magic using node:addTransform) to get the desired effect (edit: and if that's the case, why are 'setCameraOrigin' and 'setCameraTarget' even there)?

Edit edit: I guess what I'd really like is, in addition to 'setCameraOrigin(x,y,z)' a 'setCameraRotation(xDegrees, yDegrees, zDegrees)' and bypass the 'setCameraTarget' function altogether. I know that's not in there now, but I'm effectively trying to write one on my own and it definitely isn't working :wink: .

Any advice/help appreciated! :slight_smile:

Aha! Taking a look at the kart code from NaOH here - will pull things apart and see if that helps me grok things better.

Aye, that's a modified lib3d mind you. As I recall, the camera code was bugged. It may still be buggy.

1 Like

Yes, I'm aware of the kart modifications (lots!, and very cool). I'm trying to stay vanilla-lib3d for now, though, as that's what ships with the SDK (in my mind that means it serves as sort of a benchmark/reference implementation). And all I'm trying to do is wireframe, for now.

If there are camera bugs, though, I'll follow up with more details from my results as a bug report in the appropriate forum section.

Thanks!

I think you might be looking at lib3d the wrong way. It's an example of C code, not intended to be a fully usable Lua library. As a C example, it is already effective for educational purposes, even with some bugs. (This isn't even the only one.)

If you're interested in solving the bug, I would encourage delving into the C code. I would appreciate a PR to mini3d-plus if you have the bandwidth, or you could fork mini3d/lib3d into your own library. I think that might be more pragmatic than a bug report.

1 Like

I think you might be looking at lib3d the wrong way. It's an example of C code, not intended to be a fully usable Lua library.

It's part of the Playdate SDK. Why wouldn't it then be intended to be fully usable? (puzzled - is there a disclaimer I missed along the way?)

... effective for educational purposes, even with some bugs. (This isn't even the only one.)

We may have some disagreements about what a SDK is for :wink: .

If you're interested in solving the bug, I would encourage delving into the C code.

Oh, I have been. But I haven't done any linear algebra or 3D math since 35 years or so, so I'm more than a but rusty. Consider me a 'consumer' of lib3d, not a contributor.

I would appreciate a PR to mini3d-plus if you have the bandwidth...

Sorry, I'm old (soon to be 65), I don't understand what 'PR' means in this context ('Public Reminder'? 'Puerto Rico'? - no idea).

...or you could fork mini3d/lib3d into your own library. I think that might be more pragmatic than a bug report.

As someone who has written a few (both internal and external) SDKs of their own, IMO if there's a bug it's better to either fix, post a workaround for, or deprecate an API rather than fork.

Anyhow, it's too late, I already did :slight_smile: .

I just mean the C library is in the examples directory. It's not really part of the API. But it's true, even examples should not have bugs if possible.

Sorry! I'm too entrenched in Github lingo. It means Pull Request -- a contribution, basically.

Anyway, I can take a look at trying to fix the camera functions. Unless I'm misremembering, the problem is that the 'zenith' vector -- the 'up' coordinate -- is completely ignored in some crucial subroutine. It's actually a surprisingly tough linear algebra problem to write a generic solution to. If a complete and easily-mergeable fix for this is put together, they may integrate it. There's a cost to maintaining code, even as an example, and the examples aren't really high priority, so it's important to make a contribution like this as frictionless as possible.

1 Like