Talk:Geometry and Physics VAG - Revision history

Morgaine Dinova: /* View Point Modification */

2007-11-27T13:43:24Z

View Point Modification

← Older revision		Revision as of 06:43, 27 November 2007
Line 39:		Line 39:
	One key thought was to be more user oriented than architecture oriented with an example being a "Builder VAG". So perhaps a "Physical Content creation" VAG makes better sense for this. I would expect this to include bringing in 3D geometric assests from other VWs, user created and professional tools, file formats, etc. It would also include scalability issues (see above). I'm thinking this better follows the sucessful "sculpted prim" work which has engaged people so well. Thoughts? --[[User:Burhop Piccard\|Burhop Piccard]] 09:43, 25 October 2007 (PDT)		One key thought was to be more user oriented than architecture oriented with an example being a "Builder VAG". So perhaps a "Physical Content creation" VAG makes better sense for this. I would expect this to include bringing in 3D geometric assests from other VWs, user created and professional tools, file formats, etc. It would also include scalability issues (see above). I'm thinking this better follows the sucessful "sculpted prim" work which has engaged people so well. Thoughts? --[[User:Burhop Piccard\|Burhop Piccard]] 09:43, 25 October 2007 (PDT)

			* I'm a big fan of partitioning the workspace, not only for the more technical benefits of decomposition but also because it leads to tighter groups where all the people talk the same language and are pulling in the same direction. As the Geometry and Physics VAG encompasses such a large area, I think your suggestion is a good one. --[[User:Morgaine Dinova\|Morgaine Dinova]] 05:43, 27 November 2007 (PST)

			* Physics is somewhat orthogonal to most of the geometry topics discussed here so far, and would probably benefit from separate treatment. The word "Physical" should probably be omitted from the name of a VAG that deals primarily with geometry and rich object creation --- it conveys the wrong meaning, namely that the objects are necessarily subject to physics, which is not usually the case. "Geometry VAG" or "3D Objects VAG" or "3D Content VAG" all work for me, the important point being to not mention Physics and to differentiate this VAG from 1D/2D media VAGs, ie. those concerned with sound, video, MIDI, and so on. --[[User:Morgaine Dinova\|Morgaine Dinova]] 05:43, 27 November 2007 (PST)

	= Use Case =		= Use Case =

Morgaine Dinova: /* List of concerns addressed by this viewpoint */

2007-11-27T13:13:06Z

List of concerns addressed by this viewpoint

← Older revision		Revision as of 06:13, 27 November 2007
Line 25:		Line 25:

	::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)		::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)
			::* Those are interesting questions. From a scalability perspective,
			::# The client typically operates in a "max scaled out" mode, in the sense that it already has all the hardware resources that it's ever going to get, either already in use or at least easily available (eg. more memory ready to be allocated), so we're not really talking about its scalability but about how it avoids overload. That's highly client-specific, but in general there are two avenues taken (often in combination), one being to reduce the number of objects considered at the macro level (eg. quicker falloff with distance), and the other being to reduce level of detail at the micro level (representational changes like ghosting, and LOD/CLOD-type approaches). Falloff can be handled in a generic manner in clients, but representational changes require specific consideration from proponents of new geometry types. That's more work for you here. :-)
			::# I can't really comment on the effect of overload on graphics hardware itself, but it's worth pointing out that object overload often affects '''drivers''' adversely too, as they and the PCIe bus that they feed are both choke points. The best approach under high load is usually to limit the amount of data before it reaches the driver at all.
			::# The amount of server->client traffic under high load is clearly an important issue, especially for region scalability. Fortunately this area is fairly well suited to measurement and analysis. What's more, capability-based clients which turn off undesired objects in the streaming download are already being discussed, and this is very important for the fortunes of both regions and clients. This is the area of scalability-related work that has seen most progress so far, although that is not saying much since there isn't even any agreement yet (from LL) that object downloading will be amenable to such control.
			::# Because there is a lot of interest in Limited Capability Clients, this may be the determining factor in ensuring that the previous 3 points are actually addressed. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 05:13, 27 November 2007 (PST)

	This is a VAG that has a great deal of crossover to the issues concerning the viewer. Also when considering geometry, is this only in reference to prims, or to all geometry - remember the avatar is also "geometry" as well. When considering geometry and 3d modelling in general - we're talking a very complex subject, which will end up encompassing far more than just the modelling (a bias of many modellers, to forget about properly addressing animation and texturing), but also the rigging/animation, plus the uvmapping information which enables proper texturing of the geometry. I've been told via Qarl Linden's office hours, that Runitai Linden is already working on skeletal rigging for sculpties, likely first working with the avatar rig. Skeletal rigging is superior to morph animation, in regards to efficiency. Currently with sculpties, all we have is a rudimentary "morph animation" through scripting. When giving geometry formats some thought, I would consider a format that is both open and extensible for animation/rigging would be an ideal choice. NURBS in general I am unsure about, given the restrictions of graphics cards. Everything ends up as triangulated mesh as far as your graphics card is concerned, it will eventually have to be converted by the viewer in some way, just as sculpties are essentially NURBS surfaces approximated to a mesh. So actually, we have a NURBS format already, in the form of sculpt maps. I believe NURBS (and by extension, sculpties) cannot work well for more complex surfaces, these would better utilise progressive meshes, in my opinion. So an exploration of progressive meshes would be in order, I think. I've since added the U3D format to the Wiki page as a possible format. (it is the only open progressive triangle mesh standard optimised for transmission over a network, that I know of, currently in use in Adobe Acrobat and CS3 - feel free to point out others) --[[User:Hypatia Callisto\|Hypatia Callisto]] 13:20, 1 November 2007 (PDT)		This is a VAG that has a great deal of crossover to the issues concerning the viewer. Also when considering geometry, is this only in reference to prims, or to all geometry - remember the avatar is also "geometry" as well. When considering geometry and 3d modelling in general - we're talking a very complex subject, which will end up encompassing far more than just the modelling (a bias of many modellers, to forget about properly addressing animation and texturing), but also the rigging/animation, plus the uvmapping information which enables proper texturing of the geometry. I've been told via Qarl Linden's office hours, that Runitai Linden is already working on skeletal rigging for sculpties, likely first working with the avatar rig. Skeletal rigging is superior to morph animation, in regards to efficiency. Currently with sculpties, all we have is a rudimentary "morph animation" through scripting. When giving geometry formats some thought, I would consider a format that is both open and extensible for animation/rigging would be an ideal choice. NURBS in general I am unsure about, given the restrictions of graphics cards. Everything ends up as triangulated mesh as far as your graphics card is concerned, it will eventually have to be converted by the viewer in some way, just as sculpties are essentially NURBS surfaces approximated to a mesh. So actually, we have a NURBS format already, in the form of sculpt maps. I believe NURBS (and by extension, sculpties) cannot work well for more complex surfaces, these would better utilise progressive meshes, in my opinion. So an exploration of progressive meshes would be in order, I think. I've since added the U3D format to the Wiki page as a possible format. (it is the only open progressive triangle mesh standard optimised for transmission over a network, that I know of, currently in use in Adobe Acrobat and CS3 - feel free to point out others) --[[User:Hypatia Callisto\|Hypatia Callisto]] 13:20, 1 November 2007 (PDT)

Hypatia Callisto: /* List of concerns addressed by this viewpoint */

2007-11-02T00:37:55Z

List of concerns addressed by this viewpoint

← Older revision		Revision as of 17:37, 1 November 2007
Line 26:		Line 26:
	::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)		::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)

	This is a VAG that has a great deal of crossover to the issues concerning the viewer. Also when considering geometry, is this only in reference to prims, or to all geometry - remember the avatar is also "geometry" as well. When considering geometry and 3d modelling in general - we're talking a very complex subject, which will end up encompassing far more than just the modelling (a bias of many modellers, to forget about properly addressing animation and texturing), but also the rigging/animation, plus the uvmapping information which enables proper texturing of the geometry. I've been told via Qarl Linden's office hours, that Runitai Linden is already working on skeletal rigging for sculpties, likely first working with the avatar rig. Skeletal rigging is superior to morph animation, in regards to efficiency. Currently with sculpties, all we have is a rudimentary "morph animation" through scripting. When giving geometry formats some thought, I would consider a format that is both open and extensible for animation/rigging would be an ideal choice. NURBS in general I am unsure about, given the restrictions of graphics cards. Everything ends up as triangulated mesh as far as your graphics card is concerned, it will eventually have to be converted by the viewer in some way, just as sculpties are essentially NURBS surfaces approximated to a mesh. So actually, we have a NURBS format already, in the form of sculpt maps. I believe NURBS (and by extension, sculpties) cannot work well for more complex surfaces, these would better utilise progressive meshes, in my opinion. So an exploration of progressive meshes would be in order, I think. I've since added the U3D format to the Wiki page as a possible format. (it is the only progressive triangle mesh standard optimised for transmission over a network, that I know of, currently in use in Adobe Acrobat and CS3 - feel free to point out others) --[[User:Hypatia Callisto\|Hypatia Callisto]] 13:20, 1 November 2007 (PDT)		This is a VAG that has a great deal of crossover to the issues concerning the viewer. Also when considering geometry, is this only in reference to prims, or to all geometry - remember the avatar is also "geometry" as well. When considering geometry and 3d modelling in general - we're talking a very complex subject, which will end up encompassing far more than just the modelling (a bias of many modellers, to forget about properly addressing animation and texturing), but also the rigging/animation, plus the uvmapping information which enables proper texturing of the geometry. I've been told via Qarl Linden's office hours, that Runitai Linden is already working on skeletal rigging for sculpties, likely first working with the avatar rig. Skeletal rigging is superior to morph animation, in regards to efficiency. Currently with sculpties, all we have is a rudimentary "morph animation" through scripting. When giving geometry formats some thought, I would consider a format that is both open and extensible for animation/rigging would be an ideal choice. NURBS in general I am unsure about, given the restrictions of graphics cards. Everything ends up as triangulated mesh as far as your graphics card is concerned, it will eventually have to be converted by the viewer in some way, just as sculpties are essentially NURBS surfaces approximated to a mesh. So actually, we have a NURBS format already, in the form of sculpt maps. I believe NURBS (and by extension, sculpties) cannot work well for more complex surfaces, these would better utilise progressive meshes, in my opinion. So an exploration of progressive meshes would be in order, I think. I've since added the U3D format to the Wiki page as a possible format. (it is the only open progressive triangle mesh standard optimised for transmission over a network, that I know of, currently in use in Adobe Acrobat and CS3 - feel free to point out others) --[[User:Hypatia Callisto\|Hypatia Callisto]] 13:20, 1 November 2007 (PDT)

	= View Point Modification =		= View Point Modification =

Hypatia Callisto: /* List of concerns addressed by this viewpoint */

2007-11-02T00:36:48Z

List of concerns addressed by this viewpoint

← Older revision		Revision as of 17:36, 1 November 2007
Line 26:		Line 26:
	::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)		::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)

	This is a VAG that has a great deal of crossover to the issues concerning the viewer. Also when considering geometry, is this only in reference to prims, or to all geometry - remember the avatar is also "geometry" as well. When considering geometry and 3d modelling in general - we're talking a very complex subject, which will end up encompassing far more than just the modelling (a bias of many modellers, to forget about properly addressing animation and texturing), but also the rigging/animation, plus the uvmapping information which enables proper texturing of the geometry. I've been told via Qarl Linden's office hours, that Runitai Linden is already working on skeletal rigging for sculpties, likely first working with the avatar rig. Skeletal rigging is superior to morph animation, in regards to efficiency. Currently with sculpties, all we have is a rudimentary "morph animation" through scripting. When giving geometry formats some thought, I would consider a format that is both open and extensible for animation/rigging would be an ideal choice. NURBS in general I am unsure about, given the restrictions of graphics cards. Everything ends up as triangulated mesh as far as your graphics card is concerned, it will eventually have to be converted by the viewer in some way, just as sculpties are essentially NURBS surfaces approximated to a mesh. So actually, we have a NURBS format already, in the form of sculpt maps. I believe NURBS (and by extension, sculpties) cannot work well for more complex surfaces, these would better utilise progressive meshes, in my opinion. So an exploration of progressive ~~meshs~~ would be in order, I think. --[[User:Hypatia Callisto\|Hypatia Callisto]] 13:20, 1 November 2007 (PDT)		This is a VAG that has a great deal of crossover to the issues concerning the viewer. Also when considering geometry, is this only in reference to prims, or to all geometry - remember the avatar is also "geometry" as well. When considering geometry and 3d modelling in general - we're talking a very complex subject, which will end up encompassing far more than just the modelling (a bias of many modellers, to forget about properly addressing animation and texturing), but also the rigging/animation, plus the uvmapping information which enables proper texturing of the geometry. I've been told via Qarl Linden's office hours, that Runitai Linden is already working on skeletal rigging for sculpties, likely first working with the avatar rig. Skeletal rigging is superior to morph animation, in regards to efficiency. Currently with sculpties, all we have is a rudimentary "morph animation" through scripting. When giving geometry formats some thought, I would consider a format that is both open and extensible for animation/rigging would be an ideal choice. NURBS in general I am unsure about, given the restrictions of graphics cards. Everything ends up as triangulated mesh as far as your graphics card is concerned, it will eventually have to be converted by the viewer in some way, just as sculpties are essentially NURBS surfaces approximated to a mesh. So actually, we have a NURBS format already, in the form of sculpt maps. I believe NURBS (and by extension, sculpties) cannot work well for more complex surfaces, these would better utilise progressive meshes, in my opinion. So an exploration of progressive meshes would be in order, I think. I've since added the U3D format to the Wiki page as a possible format. (it is the only progressive triangle mesh standard optimised for transmission over a network, that I know of, currently in use in Adobe Acrobat and CS3 - feel free to point out others) --[[User:Hypatia Callisto\|Hypatia Callisto]] 13:20, 1 November 2007 (PDT)

	= View Point Modification =		= View Point Modification =

Hypatia Callisto: /* List of concerns addressed by this viewpoint */

2007-11-01T20:20:35Z

List of concerns addressed by this viewpoint

← Older revision		Revision as of 13:20, 1 November 2007
Line 25:		Line 25:

	::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)		::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard\|Burhop Piccard]] 12:26, 24 October 2007 (PDT)

			This is a VAG that has a great deal of crossover to the issues concerning the viewer. Also when considering geometry, is this only in reference to prims, or to all geometry - remember the avatar is also "geometry" as well. When considering geometry and 3d modelling in general - we're talking a very complex subject, which will end up encompassing far more than just the modelling (a bias of many modellers, to forget about properly addressing animation and texturing), but also the rigging/animation, plus the uvmapping information which enables proper texturing of the geometry. I've been told via Qarl Linden's office hours, that Runitai Linden is already working on skeletal rigging for sculpties, likely first working with the avatar rig. Skeletal rigging is superior to morph animation, in regards to efficiency. Currently with sculpties, all we have is a rudimentary "morph animation" through scripting. When giving geometry formats some thought, I would consider a format that is both open and extensible for animation/rigging would be an ideal choice. NURBS in general I am unsure about, given the restrictions of graphics cards. Everything ends up as triangulated mesh as far as your graphics card is concerned, it will eventually have to be converted by the viewer in some way, just as sculpties are essentially NURBS surfaces approximated to a mesh. So actually, we have a NURBS format already, in the form of sculpt maps. I believe NURBS (and by extension, sculpties) cannot work well for more complex surfaces, these would better utilise progressive meshes, in my opinion. So an exploration of progressive meshs would be in order, I think. --[[User:Hypatia Callisto\|Hypatia Callisto]] 13:20, 1 November 2007 (PDT)

	= View Point Modification =		= View Point Modification =

Dzonatas Sol: /* Physical Assets (And Geometric) */ "the wedge"

2007-10-28T18:43:09Z

Physical Assets (And Geometric): "the wedge"

← Older revision		Revision as of 11:43, 28 October 2007
Line 58:		Line 58:
	* It becomes a pain to try to classify objects early on in the design, but we have tools to make a design and then abstract objects from its own structure. That provides an ability to redesign areas of interest. See?: [[User:Dzonatas Sol/Abstract/AWG Prim]] --- [[User:Dzonatas Sol\|Dzonatas Sol]] 10:55, 28 October 2007 (PDT)		* It becomes a pain to try to classify objects early on in the design, but we have tools to make a design and then abstract objects from its own structure. That provides an ability to redesign areas of interest. See?: [[User:Dzonatas Sol/Abstract/AWG Prim]] --- [[User:Dzonatas Sol\|Dzonatas Sol]] 10:55, 28 October 2007 (PDT)

	* One thing to note is that it is mandatory to classify objects early on in object-oriented design, and that mandate has become a premature paralyzation to progress. The object-oriented design is one that got marketed and became widespread by popularity, so it is a logical fallacy of <i>argumentum ad populum</i> to use it as a standard for design. Especially, it is that logical fallacy because it is a product of object-orientated design. This is found true by the nature of the licenses of the popular object-oriented design languages, such as Java, that bar its language usage to create further object-orientated design tools. That license tidbit of Java has been a means of protection and a thorn to developers. Notice the slight distinction in the words oriented and orientated. [[User:Dzonatas Sol\|Dzonatas Sol]] 11:19, 28 October 2007 (PDT)		* One thing to note is that it is mandatory to classify objects early on in object-oriented design, and that mandate has become a premature paralyzation to progress. The object-oriented design is one that got marketed and became widespread by popularity, so it is a logical fallacy of <i>argumentum ad populum</i> to use it as a standard for design. Especially, it is that logical fallacy because it is a product of object-orientated design. This is found true by the nature of the licenses of the popular object-oriented design languages, such as Java, that bar its language usage to create further object-orientated design tools. That license tidbit (i.e. "the wedge") of Java has been a means of protection and a thorn to developers. Notice the slight distinction in the words oriented and orientated. [[User:Dzonatas Sol\|Dzonatas Sol]] 11:19, 28 October 2007 (PDT)

	= JIRA Issues =		= JIRA Issues =
	I did some digging though the JIRA issues trying to pull out those that probably require an architectural solution rather than just more coding within the existing SL design. --[[User:Burhop Piccard\|Burhop Piccard]] 10:16, 28 October 2007 (PDT)		I did some digging though the JIRA issues trying to pull out those that probably require an architectural solution rather than just more coding within the existing SL design. --[[User:Burhop Piccard\|Burhop Piccard]] 10:16, 28 October 2007 (PDT)

Dzonatas Sol: /* Physical Assets (And Geometric) */

2007-10-28T18:19:55Z

Physical Assets (And Geometric)

← Older revision		Revision as of 11:19, 28 October 2007
Line 57:		Line 57:

	* It becomes a pain to try to classify objects early on in the design, but we have tools to make a design and then abstract objects from its own structure. That provides an ability to redesign areas of interest. See?: [[User:Dzonatas Sol/Abstract/AWG Prim]] --- [[User:Dzonatas Sol\|Dzonatas Sol]] 10:55, 28 October 2007 (PDT)		* It becomes a pain to try to classify objects early on in the design, but we have tools to make a design and then abstract objects from its own structure. That provides an ability to redesign areas of interest. See?: [[User:Dzonatas Sol/Abstract/AWG Prim]] --- [[User:Dzonatas Sol\|Dzonatas Sol]] 10:55, 28 October 2007 (PDT)

			* One thing to note is that it is mandatory to classify objects early on in object-oriented design, and that mandate has become a premature paralyzation to progress. The object-oriented design is one that got marketed and became widespread by popularity, so it is a logical fallacy of <i>argumentum ad populum</i> to use it as a standard for design. Especially, it is that logical fallacy because it is a product of object-orientated design. This is found true by the nature of the licenses of the popular object-oriented design languages, such as Java, that bar its language usage to create further object-orientated design tools. That license tidbit of Java has been a means of protection and a thorn to developers. Notice the slight distinction in the words oriented and orientated. [[User:Dzonatas Sol\|Dzonatas Sol]] 11:19, 28 October 2007 (PDT)

	= JIRA Issues =		= JIRA Issues =
	I did some digging though the JIRA issues trying to pull out those that probably require an architectural solution rather than just more coding within the existing SL design. --[[User:Burhop Piccard\|Burhop Piccard]] 10:16, 28 October 2007 (PDT)		I did some digging though the JIRA issues trying to pull out those that probably require an architectural solution rather than just more coding within the existing SL design. --[[User:Burhop Piccard\|Burhop Piccard]] 10:16, 28 October 2007 (PDT)

Dzonatas Sol: /* Physical Assets (And Geometric) */

2007-10-28T17:55:41Z

Physical Assets (And Geometric)

← Older revision		Revision as of 10:55, 28 October 2007
Line 55:		Line 55:

	* Zha - yes, a better explanation. One could think of the geometry as metadata for an asset (I wouldn't but I can see the argument). So the misunderstanding could be due to defining what the core object is.--[[User:Burhop Piccard\|Burhop Piccard]] 10:07, 28 October 2007 (PDT)		* Zha - yes, a better explanation. One could think of the geometry as metadata for an asset (I wouldn't but I can see the argument). So the misunderstanding could be due to defining what the core object is.--[[User:Burhop Piccard\|Burhop Piccard]] 10:07, 28 October 2007 (PDT)

			* It becomes a pain to try to classify objects early on in the design, but we have tools to make a design and then abstract objects from its own structure. That provides an ability to redesign areas of interest. See?: [[User:Dzonatas Sol/Abstract/AWG Prim]] --- [[User:Dzonatas Sol\|Dzonatas Sol]] 10:55, 28 October 2007 (PDT)

	= JIRA Issues =		= JIRA Issues =
	I did some digging though the JIRA issues trying to pull out those that probably require an architectural solution rather than just more coding within the existing SL design. --[[User:Burhop Piccard\|Burhop Piccard]] 10:16, 28 October 2007 (PDT)		I did some digging though the JIRA issues trying to pull out those that probably require an architectural solution rather than just more coding within the existing SL design. --[[User:Burhop Piccard\|Burhop Piccard]] 10:16, 28 October 2007 (PDT)

Burhop Piccard at 17:16, 28 October 2007

2007-10-28T17:16:27Z

← Older revision		Revision as of 10:16, 28 October 2007
Line 55:		Line 55:

	* Zha - yes, a better explanation. One could think of the geometry as metadata for an asset (I wouldn't but I can see the argument). So the misunderstanding could be due to defining what the core object is.--[[User:Burhop Piccard\|Burhop Piccard]] 10:07, 28 October 2007 (PDT)		* Zha - yes, a better explanation. One could think of the geometry as metadata for an asset (I wouldn't but I can see the argument). So the misunderstanding could be due to defining what the core object is.--[[User:Burhop Piccard\|Burhop Piccard]] 10:07, 28 October 2007 (PDT)

			= JIRA Issues =
			I did some digging though the JIRA issues trying to pull out those that probably require an architectural solution rather than just more coding within the existing SL design. --[[User:Burhop Piccard\|Burhop Piccard]] 10:16, 28 October 2007 (PDT)

Burhop Piccard: /* Physical Assets (And Geometric) */

2007-10-28T17:07:23Z

Physical Assets (And Geometric)

← Older revision		Revision as of 10:07, 28 October 2007
Line 42:		Line 42:
	The physical attributes, I had a concern about them. I'm pretty sure there has to be a separate interest for this even if it gets combined together on the record. If there was no virtual world, there would be no concern. There are, however, physics as in math and physics as in real world cause and effect. We can map out real world events with math or like data structure, but to communicate the distinction is hard because of how the features and terms just meshes together tightly. I'm not sure if a wedge is really needed. Instead, COLLADA used "digital asset" for a term. I suggest we use an "AWG Digital Asset" like name to create the distinction of more pure geometric assets and the combined form of all interest that gets put together on the record. That way, in one aspect, we can say the physical attributes are metadata to the {{AWG\|Geometric Asset}}.		The physical attributes, I had a concern about them. I'm pretty sure there has to be a separate interest for this even if it gets combined together on the record. If there was no virtual world, there would be no concern. There are, however, physics as in math and physics as in real world cause and effect. We can map out real world events with math or like data structure, but to communicate the distinction is hard because of how the features and terms just meshes together tightly. I'm not sure if a wedge is really needed. Instead, COLLADA used "digital asset" for a term. I suggest we use an "AWG Digital Asset" like name to create the distinction of more pure geometric assets and the combined form of all interest that gets put together on the record. That way, in one aspect, we can say the physical attributes are metadata to the {{AWG\|Geometric Asset}}.

	*** [[User:Dzonatas Sol\|Dzonatas Sol]] 06:41, 27 October 2007 (PDT)		* [[User:Dzonatas Sol\|Dzonatas Sol]] 06:41, 27 October 2007 (PDT)
			** I'm not trying to go into design but conceptually I almost see "geometric assets" as a sub-class of assets that have some type of geometric representation (as apposed to, say, notecards). Futher, the physics part becomes a sub-type of this (can you have an asset with physics but no geometry? then maybe it is better thinking of assets as a composition)--[[User:Burhop Piccard\|Burhop Piccard]] 10:07, 28 October 2007 (PDT)

	I think this is a misunderstanding of the usage of meta-data. In general, the software engineering term refers to extrinsic things about a data element, such as access control, or encoding format, not intrinsic content. The physical attributes of an asset, are going to be part of the core model of that asset, not a description of the asset. In general, ~~meata~~-data is stuff we attach to a resource, object or such to further describe it orthogonally to its primary description.
			I think this is a misunderstanding of the usage of meta-data. In general, the software engineering term refers to extrinsic things about a data element, such as access control, or encoding format, not intrinsic content. The physical attributes of an asset, are going to be part of the core model of that asset, not a description of the asset. In general, meta-data is stuff we attach to a resource, object or such to further describe it orthogonally to its primary description.

	-- [[User:Zha Ewry\|Zha Ewry]] 09:31, 27 October 2007 (PDT)		-- [[User:Zha Ewry\|Zha Ewry]] 09:31, 27 October 2007 (PDT)
Line 50:		Line 52:
	Zha, you mentioned you did not want to get into virtualization details, so on that presumption, Zha, your statement is not clear.		Zha, you mentioned you did not want to get into virtualization details, so on that presumption, Zha, your statement is not clear.

	*** [[User:Dzonatas Sol\|Dzonatas Sol]] 15:40, 27 October 2007 (PDT)		* [[User:Dzonatas Sol\|Dzonatas Sol]] 15:40, 27 October 2007 (PDT)

			* Zha - yes, a better explanation. One could think of the geometry as metadata for an asset (I wouldn't but I can see the argument). So the misunderstanding could be due to defining what the core object is.--[[User:Burhop Piccard\|Burhop Piccard]] 10:07, 28 October 2007 (PDT)