Talk:Headtracking

No pages link here

The only way to find this page is if someone sees it in the recent changes page like I did. Shouldn't there be a link on the Homebrew apps page? Chosen One 41 06:21, 25 July 2008 (CEST)

Shove it on there if you want to. If you make a mistake in the edit, or people don't want it there, the page and be reverted. Don't be afraid to edit. It IS a wiki after-all. Pertmywert 07:47, 25 July 2008 (CEST)

Added. --Lukegb 11:47, 26 July 2008 (CEST)

No Image Loading

When I try this on my wii no image loads. I can see debug data, but its all zeroes except the values mapped to wiimote buttons. Has anyone got this working? --Crump 11:21, 26 July 2008 (CEST)

I got it working just fine (through the HBB). --Lukegb 11:46, 26 July 2008 (CEST)

Sorry, I tried it again, does work! Still, it seems to work only half the time for me, sometimes it doesn't pick up any sensor bar info and I have to Home button back and restart it. Great app tho, it works best for me if you crank the zoom to 4 or 5.--Crump 14:09, 26 July 2008 (CEST)

Backwards zoom and pan

Great job friend, I always wanted to try out head tracking... I'm sure you haven't even thought about this app in ages but...

It seems some things are a little backwards. When the sensor bar gets close to the wiimote, it should zoom in, not pan out, and of course, vice versa. I went through your code to see if you mixed some things up there, (Little things like that always get me, especially since the left and right IS 'reversed', move left and you see more of whats to the right...) but you actually have a note describing it doing just that.

Simple fix, just thought you might want to know. Indy83 16:40, August 18 2008

It isn't backwards. If you get closer to a window of your house, you see more of the outside, not less. Think of it as a window to another dimension. Pinball wizard 00:59, 19 August 2008 (UTC)

This is true, but not quite in the context you have here, it's a very tricky situation. Sorry this is going to be fairly long, but like I said, it's a tricky situation, and no detail may be left out if it is to be correctly expressed.

Regaurdless, when you get closer to the window, whether or not you can see more (which you do, you are right there), the objects get LARGER, not smaller. Try this exercise, get a tube of some manner (or use your hands to form a tube), and look out the window through your tube, or at your desk and identify an object. Now 'zoom in' towards it, keeping the tube affixed to your eye, as you get closer the object will get larger and the area around it you see will become less and less.

Now, keep the tube at a fixed distance (dont keep it affixed to your eye this time). And move your head closer to the tube. AH! True to what you have stated you now see more around the object as your head gets closer! THIS is a truer representation of the window theme! BUT contradictory to your demo, the size of the object increases as well, it zooms in! Not out. Whacky as it may seem, a combination of BOTH must take place! Zoom in and more environment seen.

With a window you are seeing more, but it's NOT because of a zoom out, it's because you can see more AROUND the object in the foreground the closer you get. This will happen naturally in a 3d environment by simply moving the camera forward at the same rate as the user, but in a 2d environment, the effect you observed can not be represented so easily (but it can be simulated to 'appear' correct).

The simplest correct looking (emphasis on looking and not on correct) way to represent it in a 2d environment is with a zoom in, not a pan out. Human nature expects objects to get closer when they move closer more than it expects to see more of the environment as it gets closer. No rate of any kind need be established, as long as environments get bigger as the user gets closer, the effect will be accepted. This is the method I suggested in my previous comment. But you want more than just that. Kudos!

Past that, is to find a balance between a pan out RATE (not max or min zoom size) and the distance the user moves, the panout rate should NOT appear to exceed the rate the user moves in, (if the pan out rate exceeds the zoom in rate the effect is broken, and simply zooming in would give the more convincing effect). That way, the size of the objects in the background should APPEAR to never change or even increase slightly, while more of the environment can be seen around it. This is of course an illusion created by the fact the users own eyes is doing the zooming in work, while the computer is doing the panning out work, which when perfectly in and ONLY when in sync, creates something VERY near the effect we discussed in the exercise.

Indy83 9:01, August 23 2008

Target Demo

I really wish it was possible to port Johnny Lee's target demo. I tried but it didn't seem like there was a way in libogc to do perspective matrices... Someone correct me if I'm wrong (or if there's another way).

In answer to your question above, you would use GX_LoadProjection(p, GX_PERSPECTIVE) to load your perspective matrix, where p is your 4x4 perspective matrix.