1. Render each pickable object to a backbuffer with a slightly different colour.

2. Get the colour at the pixel your mouse is at.

3. See if it matches up with anything in the scene that is pickable. If so, you have a match.

It seems simple enough, but there’s a lot of little things that needed to be taken care of before it would actually work.

- It needed to be flat shaded, no lights at all.

- Nothing should affect the color (such as texture, wireframe mode, ambient, specular, etc..). So the material has to be completely different, and wireframe mode on the scene object needs to be set off.

- gl.readPixels() does not work on Google Chrome without setting preserveDrawingBuffer to true when getting the WebGL context

- CubicVR stores colors as floats between 0 and 1, gl.readPixels() gives you bytes. You need to take that into account.

- The mouse position y you send to gl.readPixels() has to be flipped, so you use height – mouseY instead.

To test this, I took the CubicVR picking demo that already existed, and tried to use my colour picking code instead of scene.bbRayTest(). Click here to view this test, and here to view the original test. It’s amazing how something simple can have a lot of edge cases you need to take care of before anything will work.

Edit: It seems that in the example, I actually had a couple of issues that I still didn’t catch. Mainly that I was doing the picking code in the main loop, creating the backbuffer every check, and creating a new material for each object every check. Firefox didn’t like this if left alone. So, I cached both the unique material, and the drawing buffer. Then I only called the picking code on movemove, an recreated the buffer during window resize. That should solve the earlier issues I had.

Last Sunday, I converted the CubicVR FPS Demo to use Mouse Lock. All of our current demos are up over here, if you have one of our current builds with mouse lock in it. It showed it off pretty well how Mouse Lock in the browser can work for a game.

Now I also have to write a few tests, mainly to see if pointer.lock() and pointer.unlock() are working as they should under different conditions, and that the success and failure callbacks from pointer.lock() are firing at the right times. So I looked at the current mouselock mochitest example, which had some of this already done (mouselock/test_fullscreen.html). The first thing I saw was that it was trying to work off a setTimeout for mozRequestFullScreen(), instead of doing it on load, so I changed that. I ended up doing most of my logic inside the “mozfullscreenchange” event, since it’s pretty easy to check for different things relating to mouse lock in there. So I’m doing different tests, and find out randomly that pointer.lock(null) will actually break the browser in the current build. So I look at the stack trace the test gave me, and luckily it showed the exact line number/file it happened in.

nsCOMPtr<nsIDOMNode> targetNode(do_QueryInterface(aTarget));
nsCOMPtr<nsIDOMNode> parentNode;
targetNode->GetParentNode(getter_AddRefs(parentNode)); // This is going to crash if targetNode is NULL.

Therefore, before targetNode is deferenced, I had to check for targetNode being NULL, just a simple

if (!targetNode) return false;

I rebuilt and tested for the same thing, and now it doesn’t crash.

Hooray for testing!

nsEventStateManager will store if mouse lock is on. And the MouseLockable on lock() and unlock() will set that boolean value. When the mouse is moved and mouse lock is on, the nsEventStateManager will call aEvent->widget->SynthesizeNativeMouseEvent() with the coordinates of center of the screen, and the appropriate native message based on the OS. nsIWidget’s SynthesizeNativeMouseEvent() calls SetCursorPos() on windows just like I was doing, and the correct version for each OS. So it looks like everything is still working, but with a lot less code, and a lot more code that works on all supported operating systems.

The only problem is that not all operating systems have nsIWidget’s SynthesizeNativeMouseEvent() function implemented, so we’re going to have to do some research for the ones that don’t (for example, the GTK2 Linux one was oddly absent), and implement it ourselves.

(In GenerateMouseEnterExit(aEvent)) http://pastebin.com/pt0u2vdr

I also ran into a little bug with the DOM’s movement deltas when centering the mouse cursor every mouse move while in mouse lock. (it kept reporting opposite values). The solution was actually simple. Just report the last mouse position value as width/2, height/2, just like what I set the cursor too. If it’s anything but that, it must have moved from the center.

No clue if anything is in the right place of course. But it feels great to have some stuff actually working.

Time to test this with some games!

What I did was added a non-scriptable method to an nsIDOMWindow that saves the X/Y so that the next mouse event could get it, as well as attributes for the previous x/y.

(in nsIDOMWindow.idl)
[noscript] void saveScreenPosition(in long x, in long y);
readonly attribute long lastScreenX;
readonly attribute long lastScreenY;

Then, in nsGlobalWindow, that function simply sets the two members. When an nsDOMMouseEvent is created, it stores the movement deltas based on the previous/current values, then tells the nsGlobalWindow to save the current one.

(In nsDOMMouseEvent’s constructor, mView is the nsIDOMWindow)
if (mView) {
PRInt32 screenPosX, screenPosY, lastScreenPosX, lastScreenPosY;
GetScreenX(&screenPosX);
GetScreenY(&screenPosY);
mView->GetLastScreenX(&lastScreenPosX);
mView->GetLastScreenY(&lastScreenPosY);
mMovement.x = screenPosX – lastScreenPosX;
mMovement.y = screenPosY – lastScreenPosY;
mView->SaveScreenPosition(screenPosX, screenPosY);
}

And that was pretty much it, success.

As well, I followed another post which describes how to add movement into the MouseEvent interface. That’s all well and good until you find out that no where actually stores Mouse X/Y. It simply wasn’t built for it. Calling GetScreenPoint() in the event goes to the OS native code via the widget and gets the position directly and puts it inside refPoint. That’s all well and good, but events are created and destroyed in the blink of an eye, you can’t store previous mouse coordinate values there. So, seeing as the event stores an nsIBaseWidget, and nsWindow is one, it seems like previous/current mouse coordinate values should be stored there. That’s fine until I remembered that pointer is to an nsIBaseWidget, and I don’t know how to detect the type to cast it up safely to get those values. So I’m at a bit of a dead end here, hopefully tomorrow’s class can clear some things up.

Since the code base is so large it’s very easy to get lost, and I still feel pretty lost in all of this myself. Within the next few weeks I hope a lot of things can be cleared up. I think a lot of us feel this way right now.

Here’s my little snippet that does just that:

http://pastebin.com/gNmh1uhz

The only problem was, this doesn’t track mouse deltas, it doesn’t seem to allow for it. So I looked up the Win32 API some more on how to set the mouse position directly. I found SetMouseCursor(x,y), perfect. So my new logic was, if the mouse is not in the center, it must have moved. If it has moved, track the movement change then force it back into the center. It seems to have worked, but I still have to test it a bit more.

So I ended up with this (requires adding the mMousePos and mMouseLock member variables):

http://pastebin.com/3YBfXxM2

I have no clue if this is right, but I’m guessing it’s a step in the right direction in terms of what to do on Windows. Next time I’ll have to research more about getting the mouse lock/unlock functions visible on the DOM.

And this time I was finally successful!

Now other students should be able to take any other server test tickets that go up in the GameSaver Pivotal, once this gets in.