User:Burhop Piccard/Geometry Based Architecture View - Revision history

Saijanai Kuhn: /* Viewer Evolution */

2008-10-01T15:42:07Z

Viewer Evolution

← Older revision		Revision as of 08:42, 1 October 2008
Line 67:		Line 67:


	[[Category: AW Groupies]]		[[Category:AW Groupies]]
			[[Category:Grid Interoperability]]
			[[Category:AW Groupies User Pages]]

Burhop Piccard at 21:18, 7 November 2007

2007-11-07T21:18:36Z

← Older revision		Revision as of 14:18, 7 November 2007
Line 68:		Line 68:

	[[Category: AW Groupies]]		[[Category: AW Groupies]]
	~~[[Category:Architecture Working Group]]~~

Burhop Piccard: Adding back AWG

2007-11-07T15:55:17Z

Adding back AWG

← Older revision		Revision as of 08:55, 7 November 2007
Line 68:		Line 68:

	[[Category: AW Groupies]]		[[Category: AW Groupies]]
			[[Category:Architecture Working Group]]

Liana Linden at 23:24, 6 November 2007

2007-11-06T23:24:08Z

← Older revision		Revision as of 16:24, 6 November 2007
Line 68:		Line 68:

	[[Category: AW Groupies]]		[[Category: AW Groupies]]
	~~[[Category:Architecture Working Group]]~~

Liana Linden: Geometry Based Architecture View moved to User:Burhop Piccard/Geometry Based Architecture View: AWG wiki restructuring edit

2007-11-06T23:21:30Z

Geometry Based Architecture View moved to User:Burhop Piccard/Geometry Based Architecture View: AWG wiki restructuring edit

← Older revision	Revision as of 16:21, 6 November 2007
(No difference)

Burhop Piccard: Viewer Evolution

2007-11-04T21:54:12Z

Viewer Evolution

@@ Line 54: / Line 54: @@
 As stated earlier, the viewer can not be expected to display any possible geometric format (just as a web browser can not display all types of internet content). Plugins are a possibility for supporting additional rendering needs and creation tools. There may be other solutions.
 [[Category: AW Groupies]]
 [[Category:Architecture Working Group]]

Burhop Piccard: /* Communication */

2007-11-03T22:49:31Z

Communication

← Older revision		Revision as of 15:49, 3 November 2007
Line 10:		Line 10:
	[[Image:Geomcomunication.gif \|Overview]]		[[Image:Geomcomunication.gif \|Overview]]

	Communication between components is represented by red arrows. This is expected to be carried out by a services based ~~Rest~~ protocol and defined by the AWG.		Communication between components is represented by red arrows. This is expected to be carried out by a services based [http://en.wikipedia.org/wiki/Representational_State_Transferprotocol REST protocol] and defined by the AWG.

	The requirement from the geometry perspective varies depending on the path. Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity.		The requirement from the geometry perspective varies depending on the path. Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity.

Burhop Piccard: /* Components */ Updated model and descriptions of the components

2007-11-03T22:37:21Z

Components: Updated model and descriptions of the components

← Older revision		Revision as of 15:37, 3 November 2007
Line 31:		Line 31:
	'''Web Application B''' represents a web based client with no persistent storage. It might be a web Application that creates geometry and stores it in the Agent Domain. For example, it might create a cube, combine it with pictures from Flickr and upload a "picture cube" to the asset server. Initially, Web Application B might be limited to existing SL geometry types but could expand to other areas as the architecture progresses.		'''Web Application B''' represents a web based client with no persistent storage. It might be a web Application that creates geometry and stores it in the Agent Domain. For example, it might create a cube, combine it with pictures from Flickr and upload a "picture cube" to the asset server. Initially, Web Application B might be limited to existing SL geometry types but could expand to other areas as the architecture progresses.

	'''Application C and D''' represent applications (new or existing) that communicate directly with the Agent Domain. For ~~exmaple~~, these might be programs like Maya, Blender, 3D CAD applications or user created tools. These applications might connect directly with the Agent Domain ~~but it is expected A~~ client side library ~~would be created to~~ handle the ~~common~~ marshalling/unmarshalling of data that is common for these tools.		'''Application C and D''' represent applications (new or existing) that communicate directly with the Agent Domain. For example, these might be programs like Maya, Blender, 3D CAD applications or user created tools. These applications might connect directly with the Agent Domain or they could make use of a common client side library that handle the marshalling/unmarshalling of data that is common for these tools.

	'''Plugin E''' Is a tool made to integrate with the viewer. It might provide "in world" geometry creation tools.		'''Plugin E''' Is a tool made to integrate with the viewer. It might provide "in world" geometry creation tools.

	'''Render Plugin''' Inherent in this design is the ability to work with all types of geometry, not just the existing SL data types. To provide support for other data formats, it will be necessary to be able to render this data. Based on the data provided by the Agent Domain (and Region Domain?), the viewer will need to call the required functions in the rendering plugin to display the data.		'''Render Plugin''' Inherent in this design is the ability to work with all types of geometry, not just the existing SL data types. To provide support for other data formats, it will be necessary to be able to render this data. Based on the data provided by the Agent Domain (and Region Domain?), the viewer will need to call the required functions in the rendering plugin to display the data. For example, geometry represented by format F or G and stored on the Agent Domain would require an equivelent plugin for the client that is able to display format F or G.

			In the view above, no SL renderer plugin is displayed. In a more pure or non-SL view, one would expect that SL data would have its own plugin. For example, this would be the case where a non-SL viewer was displaying SL geometric like Prims and Sculpties.

	=Persistant Storage=		=Persistant Storage=

Burhop Piccard: /* Viewer */

2007-11-01T03:04:46Z

Viewer

← Older revision		Revision as of 20:04, 31 October 2007
Line 51:		Line 51:
	There are a number of different ways in which a viewer might be defined architecturally. One possible version is included here mainly in recognition of some of the requirements of content creators. That includes better building tools (in world) and support for non-native formats.		There are a number of different ways in which a viewer might be defined architecturally. One possible version is included here mainly in recognition of some of the requirements of content creators. That includes better building tools (in world) and support for non-native formats.

	As stated earlier, the viewer can not be expected to display any possible geometric format (just as a web browser can not display all types of internet content). Plugins are a ~~posibility~~ for supporting additional rendering needs and creation tools. There may be other solutions.		As stated earlier, the viewer can not be expected to display any possible geometric format (just as a web browser can not display all types of internet content). Plugins are a possibility for supporting additional rendering needs and creation tools. There may be other solutions.

	[[Category: AW Groupies]]		[[Category: AW Groupies]]
	[[Category:Architecture Working Group]]		[[Category:Architecture Working Group]]

Burhop Piccard: /* Persistant Storage */

2007-11-01T03:03:21Z

Persistant Storage

← Older revision		Revision as of 20:03, 31 October 2007
Line 44:		Line 44:
	While these formats may be very good for storing data, few are suited to what SL and other VW's need. They may be too bulky, or represent multiple geometric assets. Implicit in this diagram is the conversion of data to more VW friendly formats before adding them to the Agent domain. This "optimized" data would initially be the existing SL supported data types."		While these formats may be very good for storing data, few are suited to what SL and other VW's need. They may be too bulky, or represent multiple geometric assets. Implicit in this diagram is the conversion of data to more VW friendly formats before adding them to the Agent domain. This "optimized" data would initially be the existing SL supported data types."

	In some cases data may be useable in a VW environment but is not in a format supported by the current Agent domain or Viewer. This is indicated as "Client Specific" data. It is expected that the AWG based architecture provides a way to ~~comunicate~~ this data to the Agent Domain and the Agent Domain provides a way to store this data. ~~Furthere~~, the AWG based protocols are able to pass this data to the Viewer (provided the Viewer has a plugin or other solution for rendering this data).		In some cases data may be useable in a VW environment but is not in a format supported by the current Agent domain or Viewer. This is indicated as "Client Specific" data. It is expected that the AWG based architecture provides a way to communicate this data to the Agent Domain and the Agent Domain provides a way to store this data. Further, the AWG based protocols are able to pass this data to the Viewer (provided the Viewer has a plugin or other solution for rendering this data).

	=Viewer=		=Viewer=