Hi,
No, we would still have to maintain the scene representation in the DOM.
However, we can use the specialized access functions (not the
string-valued attributes) to access the functionality of a (XML3D) DOM
node much more efficiently than having to parse strings. Torstens
example with the rotation is a good example of such a specialized
interface of an (XML3D) DOM node.
Best,
Philipp
Am 31.10.2013 10:42, schrieb Toni Alatalo:
> On 31 Oct 2013, at 11:23, Torsten Spieldenner
> <torsten.spieldenner at dfki.de <mailto:torsten.spieldenner at dfki.de>> wrote:
>> On top the capabilities of the DOM API and additional powers of
>> sophisticated JavaScript-libraries, XML3D introduces an API extension
>> by its own to provide a convenient way to access the DOM elements as
>> XML3D-Elements, for example retrieving translation as XML3DVec3 or
>> Rotation as XML3DRotation (for example, to retrieve the rotation part
>> of an XML3D transformation, you can do this by using jQuery to query
>> the transformation node from the DOM, and access the rotation there
>> then: var r = $("#my_transformation").rotation).
>
> What confuses me here is:
>
> earlier it was concluded that ‘the DOM is the UI’, I understood meaning
> how it works for people to
>
> a) author apps — e.g. declare that oulu3d scene and reX avatar & chat
> apps are used in my html, along this nice christmas themed thing I just
> created (like txml is used in reX now)
>
> b) see and manipulate the state in the browser view-source & developer /
> debugger DOM views (like the Scene Structure editor in Tundra)
>
> c) (something else that escaped me now)
>
> Anyhow the point being that intensive manipulations such as creating and
> manipulating tens of thousands of entities are not done via it. This was
> the response to our initial ‘massive dom manipulation’ perf test.
> Manipulating transformation is a typical example where that happens — I
> know that declarative ways can often be a good way to deal with e.g.
> moving objects, like the PhysicsMotor in Tundra and I think what XFlow
> (targets to) cover(s) too, but not always nor for everything so I think
> the point is still valid.
>
> So do you use a different API for heavy tasks and the DOM for other
> things or how does it go?
>
> ~Toni
>
>>> If we think that XML3D (or the DOM and XML3D acts on those manipulations)
>>> is already this perfect API I'm not sure what we are even trying to
>>> accomplish here? If we are not building a nice to use 3D SDK whats the
>>> target here?
>> I totally agree that we still need to build this easily programmable
>> 3D SDK. But XML3D makes it very simple to maintain the 3D scene in the
>> DOM according to the scene state of the application.
>> You may want to have a look at our example web client for our FiVES
>> server (https://github.com/rryk/FiVES). Although I admit that the code
>> needs some refactoring, the example of how entities are created shows
>> this nicely : As soon as you create a new Entity object, the DOM
>> representation of its scenegraph and its transformations are created
>> automatically and maintained as View of the entity model. As
>> developer, you only need to operate on the client application's API.
>> This could be an example, of how an SDK could operate on the XML3D
>> representation of the scene.
>>
>>
>> ~ Torsten
>>
>>> On Wed, Oct 30, 2013 at 11:35 PM, Philipp Slusallek <
>>> Philipp.Slusallek at dfki.de> wrote:
>>>
>>>> Hi Jonne, all,
>>>>
>>>> I am not sure that applying the Tudra API in the Web context is really the
>>>> right approach. One of the key differences is that we already have a
>>>> central "scene" data structure and it already handles rendering and input
>>>> (DOM events), and other aspects. Also an API oriented approach may not be
>>>> the best option in this declarative context either (even though I
>>>> understands that it feels more natural when coming from C++, I had the same
>>>> issues).
>>>>
>>>> So let me be a bit more specific:
>>>>
>>>> -- Network: So, yes we need a network module. It's not something that
>>>> "lives" in the DOM but rather watches it and sends updates to the server to
>>>> achieve sync.
>>>>
>>>> -- Renderer: Why do we need an object here. Its part of the DOM model. The
>>>> only aspect is that we may want to set renderer-specific parameters. We
>>>> currently do so through the <xml3d> DOM element, which seems like a good
>>>> approach. The issues to be discussed here is what would be the advantages
>>>> of a three.js based renderer and implement it of really needed.
>>>>
>>>> -- Scene: This can be done in the DOM nicely and with WebComponents its
>>>> even more elegant. The scene objects are simple part of the same DOM but
>>>> only some of them get rendered. I am not even sure that we need here in
>>>> addition to the DOM and suitable mappings for the components.
>>>>
>>>> -- Asset: As you say this is already built-into the XML3D DOM. I see it a
>>>> bit like the network system in that it watches missing resources in the DOM
>>>> (plus attributes on priotity and such?) and implements a sort of scheduler
>>>> excutes requests in some priority order. A version that only loads missing
>>>> resources if is already available, one that goes even further and deletes
>>>> unneeded resources could probably be ported from your resource manager.
>>>>
>>>> -- UI: That is why we are building on top of HTML, which is a pretty good
>>>> UI layer in many requests. We have the 2D-UI GE to look into missing
>>>> functionality
>>>>
>>>> -- Input: This also is already built in as the DOM as events traverse the
>>>> DOM. It is widely used in all WEB based UIs and has proven quite useful
>>>> there. Here we can nicely combine it with the 3D scene model where events
>>>> are not only delivered to the 3D graphics elements but can be handled by
>>>> the elements or components even before that.
>>>>
>>>> But maybe I am missunderstanding you here?
>>>>
>>>>
>>>> Best,
>>>>
>>>> Philipp
>>>>
>>>>
>>>> Am 30.10.2013 14:31, schrieb Jonne Nauha:
>>>>
>>>>> var client =
>>>>> {
>>>>> network : Object, // Network sync, connect, disconnect etc.
>>>>> functionality.
>>>>> // Implemented by scene sync GE (Ludocraft).
>>>>>
>>>>> renderer : Object, // API for 3D rendering engine access, creating
>>>>> scene nodes, updating their transforms, raycasting etc.
>>>>> // Implemented by 3D UI (Playsign).
>>>>>
>>>>> scene : Object, // API for accessing the
>>>>> Entity-Component-Attribute model.
>>>>> // Implemented by ???
>>>>>
>>>>> asset : Object, // Not strictly necessary for xml3d as it does
>>>>> asset requests for us, but for three.js this is pretty much needed.
>>>>> // Implemented by ???
>>>>>
>>>>> ui : Object, // API to add/remove widgets correctly on top
>>>>> of the 3D rendering canvas element, window resize events etc.
>>>>> // Implemented by 2D/Input GE (Adminotech).
>>>>>
>>>>> input : Object // API to hook to input events occurring on top
>>>>> of the 3D scene.
>>>>> // Implemented by 2D/Input GE (Adminotech).
>>>>> };
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Jonne Nauha
>>>>> Meshmoon developer at Adminotech Ltd.
>>>>> www.meshmoon.com <http://www.meshmoon.com>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 30, 2013 at 9:51 AM, Toni Alatalo <toni at playsign.net
>>>>> <mailto:toni at playsign.net>> wrote:
>>>>>
>>>>> Hi again,
>>>>> new angle here: calling devs *outside* the 3D UI GE: POIs,
>>>>> real-virtual interaction, interface designer, virtual characters, 3d
>>>>> capture, synchronization etc.
>>>>> I think we need to proceed rapidly with integration now and propose
>>>>> that one next step towards that is to analyze the interfaces between
>>>>> 3D UI and other GEs. This is because it seems to be a central part
>>>>> with which many others interface: that is evident in the old
>>>>> 'arch.png' where we analyzed GE/Epic interdependencies: is embedded
>>>>> in section 2 in the Winterthur arch discussion notes which hopefully
>>>>> works for everyone to see,
>>>>> https://docs.google.com/**document/d/**1Sr4rg44yGxK8jj6yBsayCwfitZTq5
>>>>> **Cdyyb_xC25vhhE/edit<https://docs.google.com/document/d/1Sr4rg44yGxK8jj6yBsayCwfitZTq5Cdyyb_xC25vhhE/edit>
>>>>> I propose a process where we go through the usage patterns case by
>>>>> case. For example so that me & Erno visit the other devs to discuss
>>>>> it. I think a good goal for those sessions is to define and plan the
>>>>> implementation of first tests / minimal use cases where the other
>>>>> GEs are used together with 3D UI to show something. I'd like this
>>>>> first pass to happen quickly so that within 2 weeks from the
>>>>> planning the first case is implemented. So if we get to have the
>>>>> sessions within 2 weeks from now, in a month we'd have demos with
>>>>> all parts.
>>>>> Let's organize this so that those who think this applies to their
>>>>> work contact me with private email (to not spam the list), we meet
>>>>> and collect the notes to the wiki and inform this list about that.
>>>>> One question of particular interest to me here is: can the users of
>>>>> 3D UI do what they need well on the entity system level (for example
>>>>> just add and configure mesh components), or do they need deeper
>>>>> access to the 3d scene and rendering (spatial queries, somehow
>>>>> affect the rendering pipeline etc). With Tundra we have the
>>>>> Scene API and the (Ogre)World API(s) to support the latter, and also
>>>>> access to the renderer directly. OTOH the entity system level is
>>>>> renderer independent.
>>>>> Synchronization is a special case which requires good two-way
>>>>> integration with 3D UI. Luckily it's something that we and
>>>>> especially Lasse himself knows already from how it works in Tundra
>>>>> (and in WebTundras). Definitely to be discussed and planned now too
>>>>> of course.
>>>>> So please if you agree that this is a good process do raise hands
>>>>> and let's start working on it! We can discuss this in the weekly too
>>>>> if needed.
>>>>> Cheers,
>>>>> ~Toni
>>>>>
>>>>> ______________________________**_________________
>>>>> Fiware-miwi mailing list
>>>>> Fiware-miwi at lists.fi-ware.eu <mailto:Fiware-miwi at lists.fi-**ware.eu<Fiware-miwi at lists.fi-ware.eu>
>>>>> https://lists.fi-ware.eu/**listinfo/fiware-miwi<https://lists.fi-ware.eu/listinfo/fiware-miwi>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> Fiware-miwi mailing list
>>>>> Fiware-miwi at lists.fi-ware.eu
>>>>> https://lists.fi-ware.eu/**listinfo/fiware-miwi<https://lists.fi-ware.eu/listinfo/fiware-miwi>
>>>>>
>>>>>
>>>> --
>>>>
>>>> ------------------------------**------------------------------**
>>>> -------------
>>>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
>>>> Trippstadter Strasse 122, D-67663 Kaiserslautern
>>>>
>>>> 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
>>>>
>>>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>>>> USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3
>>>> ------------------------------**------------------------------**
>>>> ---------------
>>>>
>>>
>>>
>>> _______________________________________________
>>> Fiware-miwi mailing list
>>> Fiware-miwi at lists.fi-ware.eu
>>> https://lists.fi-ware.eu/listinfo/fiware-miwi
>>
>> _______________________________________________
>> Fiware-miwi mailing list
>> Fiware-miwi at lists.fi-ware.eu <mailto:Fiware-miwi at lists.fi-ware.eu>
>> https://lists.fi-ware.eu/listinfo/fiware-miwi
>
>
>
> _______________________________________________
> Fiware-miwi mailing list
> Fiware-miwi at lists.fi-ware.eu
> https://lists.fi-ware.eu/listinfo/fiware-miwi
>
--
-------------------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern
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
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slusallek.vcf
Type: text/x-vcard
Size: 441 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131103/ad372c34/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy