- From: Kristian Sons <kristian.sons@dfki.de>
- Date: Fri, 20 Jan 2012 08:00:45 +0100
- To: Chris Marrin <cmarrin@apple.com>
- CC: Johannes Behr <johannes.behr@igd.fraunhofer.de>, Dean Jackson <dino@apple.com>, public-fx@w3.org, igor.oliveira@openbossa.org, public-d3d mlist <public-declarative3d@w3.org>, Timm Drevensek <timm.drevensek@igd.fraunhofer.de>
Am 18.01.2012 16:29, schrieb Chris Marrin: > > On Jan 17, 2012, at 10:18 AM, Johannes Behr wrote: > >> >>> On 14/01/2012, at 2:49 AM, Johannes Behr wrote: >>> >>>> Before going into more details: Was there a good reason for just a >>>> single matrix interface and not a minimalistic but useful set of >>>> base types (e.g. Vec3, Vec4, Matrix4x4 or even Quaternion) which >>>> would be really helpful for various math related operations (e.g >>>> composition/decomposition)? We (especially Timm) thought about >>>> something similar for the dec3d group: >>>> http://www.w3.org/community/declarative3d/wiki/Base_Types >>> >>> I considered this. My main concern is fear of polluting the global JS >>> namespace with generic classes that might be better developed by the >>> official ECMAScript committee. Adding interfaces to the DOM when they >>> are clearly related to the Web and Web documents is ok, but I think >>> we need to show caution adding 6 interfaces that have broader use. I >>> believe this is why the WebGL group discussed the *Array classes with >>> ECMA. >>> >>> I would prefer to have the base types as you suggest, but I'm not >>> sure how to proceed. Maybe I'm being overly cautious. >> >> There are ways to deal with the polluting problem and I believe we >> should really wisely consider the correct representation. >> We really have to look at the use cases but there is real risk that we >> run into performance issues if we consider not the right set of base >> types and interfaces. >> There is already a essential fragmentation between different >> math/matrix libraries used in the various webgl-related projects. >> Code reuse or the mixture of interaction, physics simulation and >> rendering components in a single application is therefore not easy to >> achieve. >> This could be a real opportunity for a single adequate, efficient and >> minimal set of base-types which could be used for SVG, CSS, Dec3D and >> WebGL related interfaces. >> Just image a physics simulation package which could be use with SVG, >> CSS, Dec3D and WebGL. > > I don't think there will ever be a way to produce a library of linear > algebra classes that will be "adequate" for all purposes. I don't see > the plethora of matrix libraries as a source of fragmentation, but as a > reality of web development today. The more functional we make a set of > linear algebra classes the more change there is to miss the mark for a > large number of use cases. I agree to that. The minimum set will probably have the same effect as what happened for the Array type: People (and browser vendors) will add more functionality to the prototype and commonly used featured will be standardized later. One may consider this good or bad, but you cannot change it. Perhaps a way to go is to have the Float32Array representation as common ground. This would guarantee a good interoperability with those libraries out there. To make that more explicit there could be a read-only attribute to access (and modify via set/setter) the data as array instead of "conversion" functions. Also the methods such as multiply could directly accept a typed array, which would even save the conversion. > > Therefore I think we should focus on the absolutely minimum set of > functionality needed to solve the majority of the performance problems > that come up with these classes. I think Dean's current design is very > close to that. It may be desirable to have a 3D Vector class with dot(), > cross() and other common functions, but is it necessary for maximum > performance? Are these functions going to be in the inner loop enough > that they become a significant performance bottleneck? I'd say probably > not for the majority of use cases. > > I understand your desire to have a complete and elegant set of classes > to support 3D functionality. But the real goal of this exercise is to > produce a common and efficient matrix class for use in WebGL and other > 3D use cases. For a declarative 3D approach the complete set is not as important as for other use cases. Normally you don't dig into the scene graph internas - that's probably one of the reasons why the user has chosen to use a declarative approach. Of course we want to provide access to it according to the principle "Make the simple things simple, but the complex things possible". But for that, we just need a convienent way to access the Matrix/Vector/Rotation via IDL. Just my two cents, Kristian > > ----- > ~Chris > cmarrin@apple.com <mailto:cmarrin@apple.com> > > > > -- ________________________________________________________ Kristian Sons Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realität Campus, Geb. D 3 2, Raum 0.77 66123 Saarbrücken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775–2235 kristian.sons@dfki.de http://www.xml3d.org Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ________________________________________________________
Received on Friday, 20 January 2012 07:01:31 UTC