Sunday, September 26, 2004

Pointer/Avatar/Camera change

Much of this is quite technical and total gibberish to anyone who
doesn't know anything about the architecture of Croquet. As we get
closer to release, I intend to spend some time writing more useful
notes for people interested in developing for the system. For now, I am
just using this forum so that people can keep track of our progress.
Please feel free to comment, or ask questions. I will endeavor to reply
as quickly as I can.


I have modified the system to generate a TPointer inside of the
replicated TAvatar. The way this works is the original TUserCamera
still has it's own, non-replicated, pointer. This is used to determine
which object is being interacted with at render time. Once this object
is determined, when an event is triggered (pointerDown, up, etc) we
send the TSelection object via the replicated TAvatar, as well as the
event itself. It then transfers the TSelection to it's replicated
TPointer and sends the requested event to it.

There are a number of reasons to NOT just put this pointer into the
array of TRays that the TSpace manages.

First, there is a need to traverse portals. The TCamera manages this
nicely, and it makes little sense to do such a complex transform
multiple times, with the additional overhead of querying the target to
determine if it is a portal and acting accordingly. This may change, as
I may want objects to be able to fall through portals that might be on
the ground, but for now, this is not a priority.

Second, the TPointer can only act on objects that are visible to the
camera, hence there is a significant paring of the tree to a small
subset of the objects in the environment that we need to deal with.

The replicated TPointer has it's own replicated TCamera which is a
non-functioning camera. It maintains a number of key values including
the bounds of the users screen, the viewAngle, and the current camera
transform. These are values that are used for some of the actions that
occur in the world such as the TAvatar jumping to a window. The
distance from the window is determined by these two values and could be
different from each user.

There is still a problem with the avatar after it enters a remote space
that is not fixed by this change set, but I think we are closer to
fixing it with this change.

I also moved the TRay tests into a separate teatime based iteration.
This fixes a big problem that we have glossed over. Since the ray tests
were only being performed at render time, if we have different machines
rendering, this could cause divergent behaviors of things that depended
upon these rays, such as the mars rover.

No comments: