Friday, January 21, 2005

Picking in overlays now working.

David Smith just made my life my easier by modifying TSpace & TUserCamera so picking in an overlay just falls out naturally from building an overlay with a TUserCamera. It's a little frustration that David can solve a problem that has been plaguing me for weeks with a couple of deep tweeks...and now pretty much any mistake with an overlay results in the image freezing...but such is life on the cutting edge.

Having a working top-down overlay in the corner of the screen makes me want to be able to toggle the two views: have the top-down view be the dominant image and the front facing view be in the corner. This could get confusing - there is one TUserCamera that managers the other TUserCameras as overlays. It seems like TUserCamera was originally a kind of catch all for all the things they didn't want to put into the TeapotMorph & I bet it was intented to be a singleton. The main TUserCamera (activeCamera of the TeapotMorph) is resistant to tampering, but what about creating an additional overlay with the front view in it?

Yay, that works. I wonder if David would consider killing the main Camera render and just render it as an overlay. very flexable.

Friday, January 14, 2005

Pointer Enter & Poiner Leave

More event passways. The last entry discribed how a pointerDown event makes it to a componant that the mouse is over. This path is the same for pointerUp and pointerMove, but pointerEnter & pointerLeave have their own thing going on.

Those events are generated in TRay >> resetSelected, which is called for the activeCamera's pointer in TUserCamera preRender. Remeber that any TRay in a scene will select an object that it is pointing at in the render loop. resetSelected examins the ray's current selectedObject and it's lastSelection object to generated appropriate calls to pointerEnter, pointerLeave & oh yeah, pointerOver (which is called continuously on the selected object for as long as the TRay points at it).

Notes:
1) The TRay only generates the pointerX events if it's doSelect is true, so the camera's downRay does not trigger events.
2) The TRay is handed to the componant with the event, so you could have an object that responds differently to being selected by different pointers.
3) I wondered why these events were render based & not based on mouse event until Orion reminded me that objects in the scene can move themselves in front of the pointer. The render bases select can succesfully select those moving obejcts.

Friday, January 07, 2005

More Event Processing

I am still working to get a complete mental image of the event flow. Lets follow a left mouse down event from Morph to TObject in the world.

TeapotMorph >> handlesMouseDown is true, so TeapotMorph >> mouseDown is called, which calls activeCamera mouseDown.
TUserCamera >> mouseDown determines that it is a left (red) button, and calls
avatar selection: pointer selection pointerDown: evt.

"pointer selection" returns the TObject picked by the activeCamera's TPointer the last time the TPointer was rendered, which is happening constantly, whenever the TSpace is rendered.

TAvatar >> selection:pointerDown is where it gets fuzzy for me. The TAvatar belonging to the activeCamera has it's own distinct TCamera and TPointer. The class comments say that the TPointer is a replicated copy of the pointer in the activeCamera, but the only replication I have found refers to positioning the avatar's TLaser. It is also unclear what purpose the avatar's camera serves - the comments refer to it as a pseudo-camera.

Anyway, TAvatar >> selection:pointerDown first sets the avatar's camera's localtransform to that of the selected TObject, then sets the avatar's pointer's selected TObject, and then calls pointerDown on the avatar's pointer. Note: TAvatar has a selection:x: message for each possible event and they all do the same thing.

TPointer >> pointerDown then examines the pointer's selected TObject, and if it returns true for isComponant and handlesPointerDown, it's handlePointer message is sent. Thus the mouse click has made it from the morph to the TObject.