Talk:Geometry and Physics VAG

From Second Life Wiki
Jump to navigation Jump to search

Metadiscussion

  • For now, I think geometry and physics are too closely related to be split. However, I can certainly understand a perspective that there might be two closely related viewpoints here. Geometry really doesn't need material properity information or have to participate in a physics engine. On the other hand, physics really has not meaning at the user level without something to act on. So in the end, I see geometry that has optional physical properties and a single viewpoint the covers both. Do others have thoughts on this? --Burhop Piccard 19:04, 16 October 2007 (PDT)
  • I liked the structure of your VAG and so used it as a template for Scalability and QA VAGs ... well done. :-) --Morgaine Dinova 02:56, 18 October 2007 (PDT)
    • Always good to be emulated :-) BTW, I tweaked the usecase part a bit to hopefully give a bit of structure. --Burhop Piccard 06:32, 18 October 2007 (PDT)
  • The use of the name VAG is unofficial still. There are issues about it that have gone unanswered as a "group" structure. The use of these "VAGs" in their current state is like force implementation without any design. The concerns are expressed about the VAGs being implemented, but they are not being addressed. If that kind of progress mimics any future software design and implementation, I'd say this already demonstrates that goals won't be followed. I hope that not be the case, and I urge that these VAGs evolve into a methodology that can follow the goals. I think you, Burhop, have put a lot of work into this and it deserves the right attention and implementation. Dzonatas Sol 07:36, 18 October 2007 (PDT)
    • Yes, I saw the discussions but didn't want to sit idle while it gets resolved. If VAG changes to something else I'll be glad to update the pages. If a VAT/VAG methodology becomes more clear I would expect us to line up with this too. I think the core information we are collecting now (i.e. usecases, JIRAs, links, etc.) will keep us busy while some of these organizational issues are resolved (as long as you don't take too long :-) --Burhop Piccard 08:26, 18 October 2007 (PDT)
  • There is no place to put design related jira issues right now. The projects listed in jira.secondlife.com do not have space for the AWG project. I get the hint from LL that they are pleased to incubate this project, but AWG needs to quickly evolve into its own hosted site. That evolution needs design and consensus. Without such design and consensus, these VAGs will continue to use LL's resources to "keep us busy" while the organization needs to be resolved. It appears a few others understand that hint. =) Where will AWG related jira issues get entered? Dzonatas Sol 08:36, 18 October 2007 (PDT)

List of concerns addressed by this viewpoint

  • Burhop, does "Efficient communication of Geometric and physical properties" include client communication efficiency? From the scalability perspective, I'm interested in anything related to reduction or optimization of server->client object traffic, including negociated reductions in that traffic for example. --Morgaine Dinova 01:59, 22 October 2007 (PDT)
    • Yes, I think thats a primary driver. One aspect of the viewpoint (in my opinion) is that we want richer and more detailed geometry with more motion and interaction without a perception of sluggishness in the system. The two work against each other so how do you trade off?
I think there are a several scalability axes here.
1.) How does the viewer scale as its geometry engine is overloaded?
2.) How does this affect the graphics hardware?
3.) How does this affect the network and comunication betweewn servers?
4.) How does this scale to different configurations of computer hardware, viewers, network speeds.
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. --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. --Hypatia Callisto 13:20, 1 November 2007 (PDT)

View Point Modification

There have been a number of VAG and AWG organizational discussions and I think it might be time to reformulate this VAG in light this.

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? --Burhop Piccard 09:43, 25 October 2007 (PDT)


Use Case

I've tried to add some one-line use cases to give better feel for what the VAG might be. These are either my own or ones I've discussed with SL content creators. I'm flexible about changing these. Some of the Sculptie Dev people have had some excelent ideas.--Burhop Piccard 16:18, 26 October 2007 (PDT)

Physical Assets (And Geometric)

The Geometric Asset idea is a really good interest for this. I actually see how that could be integrated with MediaWiki with some other ideas on here to bring the efforts of unrelated groups more in-line.

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 Geometric Asset.

  • 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)--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, meta-data is stuff we attach to a resource, object or such to further describe it orthogonally to its primary description.

-- Zha Ewry 09:31, 27 October 2007 (PDT)

Zha, you mentioned you did not want to get into virtualization details, so on that presumption, Zha, your statement is not clear.

  • 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.--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 --- 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 argumentum ad populum 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. Dzonatas Sol 11:19, 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. --Burhop Piccard 10:16, 28 October 2007 (PDT)

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:Geometry_and_Physics_VAG&oldid=38798"