[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting discussions:Declarative 3D interest group at W3C

GLG info at 3dnetproductions.com
Thu Jan 6 03:52:52 PST 2011


>I believe you misunderstood some basic pricibles. Both
>systems
>have WebGL and Native implementations. XFlow is a (not yet


According to x3dom.org there is "native WebGL support" but
that is still WebGL. No? Please enlighten me on that meaning
if you can; I am only aware of one version of X3DOM. 



>publicly available) data Flow system which could sit on top
>of any data-contatiner.
>It should work with XML3D, X3DOM or anything else it could
>interface.
>

That XFlow would actually work with X3DOM I have never heard
either but possible. Perhaps someone else can add to this. 

Lauren



>best regards
>johannes
>
>
>> more debate is needed, but it seems to me we do need to
>make
>> a choice. Perhaps a chart outlining the characteristics
>of
>> both systems in detail would be useful, but I am not sure
>we
>> need it.
>>
>> Lauren
>>
>>
>>> -----Original Message-----
>>> From: Johannes Behr
>>> [mailto:johannes.behr at igd.fraunhofer.de]
>>> Sent: Thursday, January 06, 2011 3:30 AM
>>> To: info at 3dnetproductions.com
>>> Cc: 'Chris Marrin'; 'Philipp Slusallek'; 'Joe D
>Williams';
>>> 'Len Bullard'; x3d-public at web3d.org
>>> Subject: Re: [X3D-Public] Fwd: Re: [X3D] X3D HTML5
>meeting
>>> discussions:Declarative 3D interest group at W3C
>>>
>>> Hi,
>>>
>>> this discussion is not some form of beauty contest to
>pick
>>> one of the systems as winner.
>>> You misunderstood the current status. The current
>systems
>>> are the input and not the output of the incubator group.
>>> Both demonstrate that value in the general idea:
>>> Declarative 3D in the Web.
>>> But we are still in the process of understanding the
>>> requirements.
>>> How a final system looks like is totally open.
>>>
>>> regards
>>> johannes
>>>
>>>>>> I think talking about changing the node
>>>> hierarchy, DOM or event system will result in failure.
>>>>>>
>>>>>> We all agree! This will not happen. We see the
>current
>>>> DOM structure and event system as building ground. We
>>> build
>>>> on existing W3C standards.
>>>>>> The question is only how we utilize what is already
>>>> there.
>>>>>
>>>>> Right, and I think the way to start is to try it, see
>>>> where the ragged edges are, and then sand those smooth.
>>> The
>>>> real question is what applications are you trying to
>do?
>>>>
>>>> Every application which can be mapped to a scene-graph
>and
>>>> heavily depends on user-interaction.
>>>> High-End games are not on this list. Applications like
>the
>>>> Body-Brower must be easy to build with the final
>system.
>>>
>>> Hello All,
>>>
>>> I think the above touches the heart of the problem.
>>> Defining
>>> exactly what it is we are trying to accomplish is
>crucial.
>>> My take on it can be summarized with the following
>>> evaluation criteria, which I have placed in reversed
>order
>>> of priority (to assign weight to each criterion - see
>>> below). You are of course welcome to voice your opinions
>>> for
>>> changes within the parameters of this discussion.
>>>
>>> CRITERIA:
>>>
>>> 5- Compliance with existing W3C standards; more advanced
>>> capabilities can always be added via plugins if no other
>>> solutions can be found.
>>>
>>> 4- Long term potential for use and upgradeability of the
>>> implementation. Something that is as solidly grounded as
>>> possible, so there is excellent potential for building
>on
>>> top of it. Foresight is very important here, so that
>>> content
>>> will not get broken down the road.
>>>
>>> 3- While user applications should be easy to build, this
>>> should not take precedence over the flexibility of the
>>> system, limiting it in some way.
>>>
>>> 2- The implementation's speed to market should not take
>>> undue precedence either; It is worth the wait to do
>>> something the best possible way, rather than choosing
>the
>>> fatest, easiest route. But how close we are to an actual
>>> working implementation should be taken into account.
>>>
>>> 1- Baby step vs Big step. I have added this here because
>it
>>> is a point of contention. So the requirement here would
>be
>>> -
>>> the consensus of all involved. IOW, objectively, how
>>> popular
>>> is the proposed implementation.
>>>
>>>
>>> Having laid down the above criteria, now let's try to
>>> measure the proposed solutions with relation to those
>>> criteria and associated weight. In the left column of
>each
>>> list is the criteria number and thus its weight. In the
>>> middle column is the 'grade' I have given each solution
>on
>>> a
>>> scale of 1 to 9 (This is of course my opinion and highly
>>> subjective - your input is welcome). In the right column
>>> you'll see the calculated rating for each criteria. The
>>> TOTAL at the bottom should be an good indicator of where
>we
>>> stand. I have tried to be as objective as possible,
>taking
>>> into account many of the opinions encountered. I do not
>>> know
>>> the results before attempting this, but this is fun so
>>> let's
>>> so how it turns out. Here we go:
>>>
>>> ---------------------------
>>> Weight * Grade = Rating
>>> ---------------------------
>>> X3DOM
>>>
>>> 5 * 7 = 35 (W3C Compliance)
>>> 4 * 5 = 20 (Foresight)
>>> 3 * 6 = 18 (Flexibility)
>>> 2 * 7 = 14 (Close to Market)
>>> 1 * 7 = 7  (Popular)
>>> TOTAL: 94
>>> ---------------------------
>>> XML3D
>>>
>>> 5 * 7 = 35 (W3C Compliance)
>>> 4 * 8 = 32 (Foresight)
>>> 3 * 9 = 27 (Flexibility)
>>> 2 * 5 = 10 (Close to Market)
>>> 1 * 5 = 5  (Popular)
>>> TOTAL: 109
>>> ---------------------------
>>>
>>> Here we have XML3D given an advantage of 15 points. So
>>> perhaps XML3D should be the starting implementation when
>>> attempting to integrate one into the other. The area
>where
>>> I
>>> am having the most indecision is with each proposed
>>> implementation's adherence to W3C standards. I simply do
>>> not
>>> know at this point, so I gave them both the same value.
>But
>>> if each one of us here give their opinion for the grade
>of
>>> each criteria, we can average the results and get over
>with
>>> this discussion quickly. This would allow us to reach a
>>> consensus upon which to act in a coordinated effort.
>>>
>>> You might be wondering how I came up with this scheme. I
>am
>>> simply applying the same basic 'fuzzy' principle that my
>>> Windows Mobile application called PocketAI 2.2 uses.
>Back
>>> in
>>> 2003 I think it was, I built this to help the decision
>>> process when encountering difficult choices. I have used
>it
>>> numerous times and so have countless users, and I can
>>> honestly says that it generally works; breaking down
>>> complex
>>> issues into smaller parts. Please see
>3dnetproductions.com
>>> to download a copy if you are interested to try it for
>>> yourself (Make sure to read the Help file so you
>understand
>>> how the app works before attempting to use it. I can
>also
>>> email you the above *.pai2 decision problem file if
>you'd
>>> like, and provide free license key to members of this
>group
>>> so you can save your own files).
>>>
>>> Not detailed here, is also a Boolean method of
>computation
>>> that is part of the application. This also gives XML3D a
>>> slight advantage (34 to 32), but is less precise since
>no
>>> weight can be assigned to the criteria.
>>>
>>> This is not a shameless plug but a genuine attempt at
>>> reconciling the issues at hand.
>>>
>>> Cheers,
>>> Lauren
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> X3D-Public mailing list
>>> X3D-Public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>
>--
>Dr. Johannes Behr
>Leiter Projektbereich VR
>
>Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>Tel +49 6151 155-510  |  Fax +49 6151 155-196
>johannes.behr at igd.fraunhofer.de  |  www.igd.fraunhofer.de





More information about the X3D-Public mailing list