User talk:Burhop Piccard/Geometry Based Architecture View

Given Zero Linden's discussion on Oct 30th and an earlier disucssion at the AWGroupies meeting, I'm hoping we can reformulate the Geometry and Physics discusions to provide better input to the AWG. This is an intial stab at something that:

• Provides useful information to the AWG as they define the components and comunication protocols.
• Meets the needs of content creators that want greater variety of geometric content and better support for current and future creation tools.
• Can be incrementally implemented starting with existing SL geometry.

It needs much discussion so please feel free to add your thoughts here. --Burhop Piccard 19:17, 30 October 2007 (PDT)

I updated the geometry model following the SLDEV discussion on this topics (see https://lists.secondlife.com/pipermail/sldev/2007-October/006237.html and additional emails in November for more information) The main differences are:

• Changes to the "Client Side Library" so only one Application plugs into a "Reusable Client Side Library".
• Clarification on SL data versus non-SL data.
• More explicit link between non-SL data stored on the Agent domain and the Viewer. Data in Format F or G must have an equivilent F or G Renderer in the Viewer

Burhop Piccard 15:21, 3 November 2007 (PDT)

Overview

• I suggest that you label the brown box not "Viewer", but "Comms Mux/Demux" or "Client Front-end" or something like that. The old term "Viewer" or "Client" needs to become an outer dotted line that encloses all 4 of your client-side boxes, after the refactoring that's implicit in your article. --Morgaine Dinova 15:05, 4 November 2007 (PST)

Communication

• QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."

I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --Morgaine Dinova 13:47, 4 November 2007 (PST)

• I'm actually wondering why data is uploaded to servers in the Agent Domain at all in the diagram, since this data is in transit to asset storage and doesn't get instantiated as in-world objects until either Agent or Region domain servers pull it in from asset storage. In other words, uploads are unnecessarily traversing the Agent Domain and reducing its ability to scale.

Although the loading created by data uploads will not be large, the loading on Agent Domain servers from normal agent duties will be extreme, and therefore any additional loading is a very bad idea. Whatever processing can be removed from Agent Domain servers, should be removed. In this particular case, what's needed is a new server pool of data upload or asset proxies --- in keeping with the "Domain" terminology, this pool might as well be labelled Asset Domain or similar. --Morgaine Dinova 02:21, 5 November 2007 (PST)

Components

• I'll explain what I wrote in the "Overview" section about the diagram, as you've elaborated on it under "Components".

Your two renderers Fand G and the special application E need to plug in somewhere to what you label the "viewer", but think about this for a minute. Is it really the old viewer, with a superficial external interface, or does the nature of E/F/G require deep coupling into the inner recesses of the client? There is no doubt that it is the latter case, because renderers are necessarily very deeply integrated into the client's rendering susbsystem, and because tools like app E deal with object representation, and therefore must necessarily pass low level data across the interface.

What this means then is that the client must have been refactored first in order to provide the strong integration capability that you require for advanced geometry. But, if it's been refactored, then it would make very little sense to keep the rest of the client from benefitting from that refactoring, for instance by making the existing prim types also defined through plugins plus corresponding renderers, and indeed by making the whole UI structured as plugins as well, and the audio player, etc.

Notice that this leaves only the comms front end as the fixed portion of the client, which is as it should be given our plans for very wide client diversity.

I hope this explains my remarks under "Overview" better. :-) --Morgaine Dinova 14:55, 4 November 2007 (PST)