Week 4 task description [Antti]
Ryan McDougall
Estimated time to completion: 4 days
Resesarch current solutions Authentication server, Identitiy(OpenID),
Registration, Web user interface (users.realxtend.net/rexauth), Cable
Beach, Rex and Opensim (UGAI) and try to wrap up a common
way/framework/the big picture to handle following issues:
- Avatar portability
- Distributed Identity System
- Flexible Authentication System
- Distributed Asset System
- Web-based Identity Registration System
Time breakdown:
- Research 2 days
- Evaluating/developing use cases and the big picture 2 days
Deliverables:
- Research results
- Use cases/framework that will represent the whole login/avatar
process and try to find a solution to fit all cases
- Means to fulfill the whole process
Toni Alatalo
from the editing tool draft codes that I wrote two weeks ago to get
insight to viewer requirements. You may have seen them already via the
wiki and svn, but in case not, here a summary of the results.
Back then drafted two tools: 1. a simple manipulator (now for moving
the selected object by dragging arrows) and 2. a ruler to measure the
distance of two selected objects, by drawing a line between them and
showing the dist in numbers. The wiki page has screenshots of two
similar tools elsewhere.
Framework reqs:
These components would need to subscribe to the following events:
manipulator: onObjectSelected, onObjectDeselected, onEnter, onLeave,
onDragStart, onDragStop
+ the leave/enter & drag callbacks would need to be attached to the
specific parts of the 3d widget
ruler: onSelected, onObjectChange (or somehow be notified of changes in
it's objects of interest)
For details see the code in branches/edittool/manipulator.py and
ruler.py
Besides subscribing to those events, they'd also need to draw freely in
within the 3d scene. However, they are not scene entities in the sense
that they are not a part of the world, presumably not communicated over
the network and the server nor do other clients need to know anything
about them. So they are just local UI widgets, just ones that need to
be drawn in 3d w.r.t to scene data. I guess they can be made as some
sort of entities too, if that is the best way to make the framework -
right now they are just general components / plugins that subscribe to
events and call viewer api to draw arrows. Also for collaborative
editing actually sharing them over the net might be interesting.
One open question is how such drawing should be provided: expose the
Ogre manual object API perhaps? Allow issuing OpenGL draw commands?
Offer primitive draw functions like line() from own API? Or require
them to be normal geometry like objects in the scene, which brings back
the question how to change them dynamically (in case of the ruler,
which needs to redraw itself always when either of the objects move),
for which and API like Ogre ManualObject is one option.
Along this route, the next thing I've planned is a similar
drawn-within-scene GUI widget, but instead of general editing it would
be a game specific aiming / targetter / crosshair thing (RTS-like).
It's based on one game prototype we did at Playsign last year - will
get back to that if/when get it written. The plan is that the server
could send such game specific UI code for the client to run, when
starting a game (similar to how javascript can be used to make custom
UIs in web browsers).
Probably can not come to the meeting tomorrow, so hopefully got the
results so far communicated this way. Haven't touched those in almost 2
weeks now, the plan is to refactor them to run against the actual
framework impl as it shapes, so input on how that should be done would
be welcome. Also they were written in a test driven fashion so may work
as sets of unit test code for the framework in the future too.
~Toni
Toni Alatalo
> showing the dist in numbers. The wiki page has screenshots of two
oops sorry forgot to add a direct link to that for convenience,
http://www.rexdeveloper.org/wiki/index.php?title=Client-side_plugins_-
_editing_tools
also edited the preliminary results from the mail to that page.
> ~Toni
the same.
Toni Alatalo
> Renderer will probably expose somekind of primitive drawing - could be
> Ogre manual object or something else. Ogre manual objects are probably
> needed anyway.
> Absolutely no raw OpenGL draw commands though. >:(
in my experience so far ogre manual objects, or something similar,
would cover the needs, and there's be no need for raw opengl or
similar.
was now thinking that the next targetter/aim thing should draw an arc -
haven't done that yet (also in the standalone protype we did didn't
have that yet), but am guessing that manualobject would be good for
that too.
thanks for the info!
> - Heikki
~Toni