W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: Matrix4x4 proposal

From: Kristian Sons <kristian.sons@dfki.de>
Date: Fri, 20 Jan 2012 08:00:45 +0100
Message-ID: <4F19111D.3050804@dfki.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 January 2012 07:01:32 GMT