Hi,
yes, we have a very lean scene representation that we use to store
accumulated matrices, lights, resolved shader information and such. This
structure is synchronized with the DOM via adapters.
Setting data values efficiently is documented here:
https://github.com/xml3d/xml3d.js/wiki/How-to-efficiently-set-Xflow-input-with-TypedArrays
Hope that helps,
Kristian
> bleh sorry I apparently misunderstood a key part:
>
> On 09 Nov 2013, at 11:41, Toni Alatalo <toni at playsign.net
> <mailto:toni at playsign.net>> wrote:
>> https://github.com/xml3d/xml3d.js/blob/develop/src/renderer/scene/scene.js#L125
>> leads to ->
>> https://github.com/xml3d/xml3d.js/blob/develop/src/renderer/scene/rendernode.js#L45
>> So there's no internal representation for the full scene (apart from
>> how it proxies access to the DOM)
>
> RenderNode does say:
> this.children = [];
> in
> https://github.com/xml3d/xml3d.js/blob/develop/src/renderer/scene/rendernode.js#L23
>
> So actually there is a JS list internally for the full scene where all
> the scene nodes are as JS RenderNode objects etc --- so the DOM is not
> used as the internal structure for the scene, and the whole system
> resembles what we have in WebTundra's as well --- or?
>
> In Chiru-Webclient the corresponding collection of JS objects for the
> scene is
> https://github.com/Chiru/Chiru-WebClient/blob/master/src/ecmodel/ECManager.js#L24
> (that's not the three.js scene, the SceneManager there own both the
> ECManager instance and the three scene).
>
> ~Toni
>
>> About setting object positions, upon the root node creation scene
>> itself does this to set to initialise the position:
>> root.setLocalMatrix(XML3D.math.mat4.create());
>> in
>> https://github.com/xml3d/xml3d.js/blob/develop/src/renderer/scene/scene.js#L100
>>
>> That seems to access the matrix directly in the 'page' which
>> apparently is the memory management system you've referred to, and
>> set the transform dirty flag:
>> https://github.com/xml3d/xml3d.js/blob/develop/src/renderer/scene/rendergroup.js#L35
>>
>> So that would be one way for the network code to move objects within
>> xml3d.js. I suppose the same setLocalMatrix is called also when it is
>> manipulated via the DOM, but as these direct JS calls are what
>> xml3d.js scene code itself uses for it, perhaps it would be the way
>> for e.g. network code too? Or should it just go via DOM?
>>
>> I'm afraid that the xml3d.js JS API is not documented at all --- at
>> least I've been unable to find anything about it via
>> https://github.com/xml3d/xml3d.js/wiki
>>
>> ~Toni
>>
>>
>> On 09 Nov 2013, at 08:51, Philipp Slusallek
>> <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>> wrote:
>>
>>> Hi,
>>>
>>> Since many of us a traveling, let me take a stab at your questions.
>>> Kristian, Torsten, please correct any technical errors.
>>>
>>> Xflow (which Kristian refers to) is used for realtime animation of
>>> characters and such operations. We have shown real-time animation of
>>> more then 25 characters with skeletal animation and skinning
>>> completely running in JS (without HW acceleration yet). This should
>>> show that XML3D can well be used for real-time changes even for
>>> things like geometry.
>>>
>>> Xflow works on the internal data representation of XML3D which is
>>> tailored for fast rendering through WebGL (typed arrays and such).
>>> This internal data structures are similar to what three.js
>>> maintains. There is actually not much difference at this layer. When
>>> a frame needs to rendered, both renderers simply go through this
>>> "display list" as efficiently as possible.
>>>
>>> What Kristian refers to regarding memory management is the issues
>>> that we encountered with garbage collection in JS implementations.
>>> As a result we allocate large arrays once and manage the data within
>>> those arrays ourselves. This has turned out to avoid quite frequent
>>> rendering stalls whenever the JS garbage collector kicked in.
>>>
>>> Each of the XML3D elements (e.g. mesh, data) offers JS APIs (should
>>> be documented in the Wiki, I hope) to access these internal data
>>> structures directly and so other JS code can have equally good
>>> access to these data structures. You can (but should not) also go
>>> through the text based DOM attributes but this will be slow for
>>> large data (e.g. vertices). I believe its is till fine to use these
>>> interfaces for small things like changing the time for an animation
>>> or such.
>>>
>>> One thing where you have to go through the DOM is creating the DOM
>>> objects themselves. There is little we can do about that.
>>>
>>> Of course, if your modifications are about things that can be well
>>> described by Xflow, you ideally should use xflow and eventually
>>> benefit from the HW acceleration that we are implementing, where
>>> potentially all the computations would happen on the GPU and not be
>>> touched by JS any more. I am not sure what the status of this task
>>> is, though.
>>>
>>> Hope this helps. Kristian, Torsten: Feel free to add more detail and
>>> corrections.
>>>
>>>
>>> Best,
>>>
>>> Philipp
>>>
>>> Am 06.11.2013 12:06, schrieb Toni Alatalo:
>>>> Hi returning to this as it's still unclear for me and we need to
>>>> implement this for integrating the client side of the synchronisation
>>>> (that Lasse is working on) & the rest of the client:
>>>>
>>>> On 03 Nov 2013, at 11:19, Philipp Slusallek
>>>> <Philipp.Slusallek at dfki.de <mailto:Philipp.Slusallek at dfki.de>
>>>> <mailto:Philipp.Slusallek at dfki.de>> wrote:
>>>>> 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.
>>>>
>>>> Yes I think everyone agrees that the representation is good to have
>>>> there (also) but the question is indeed about efficient ways of
>>>> modification.
>>>>
>>>> Question: are those specialised access functions the same thing to what
>>>> Kristian refers to in this quote from September 2nd (Re: [Fiware-miwi]
>>>> massive DOM manipulation benchmark)? I think not as you & Torsten talk
>>>> about access to DOM elements whereas Kristian talks about something not
>>>> in the DOM, or?
>>>>
>>>> "The DOM is meant as in interface to the user. That's how we designed
>>>> XML3D. All medium-range modification (a few hundereds per frame) are
>>>> okay. One must not forget that users will use jQuery etc, which can --
>>>> used the wrong way -- slow down the whole application (not only for 3D
>>>> content). For all other operations, we have concept like Xflow, where
>>>> the calculation is hidden behind the DOM interface. Also the rendering
>>>> is also hidden behind the DOM structure. We even have our own memory
>>>> management to get a better JS performance."
>>>>
>>>> I'm referring to the parts about 'hidden behind the DOM', used by XFlow
>>>> and rendering.
>>>>
>>>> Do those use and modify some non-DOM data structures which xml3d.js has
>>>> for the scene internally?
>>>>
>>>> We are fine with reading existing docs or even just source code for
>>>> these things, you don't have to explain everything in the emails here,
>>>> but yes/no answers & pointers to more information (e.g. to relevant
>>>> code
>>>> files on github) would be very helpful.
>>>>
>>>> So now in particular I'm figuring out whether that kind of 'hidden' /
>>>> non-DOM interface would be the suitable one for network synchronisation
>>>> to use.
>>>>
>>>> I know that changes coming over the net are not usually *that* much,
>>>> typically within the max hundreds (and usually much less) for which
>>>> Kristian states that going via DOM manipulation is fine, but there can
>>>> be quite large bursts (e.g. at login to create the whole scene, or when
>>>> some logic changes a big part of it). And there are many consumers for
>>>> the cpu time available in the browser main thread so is perhaps good to
>>>> avoid wasting even a little of it in continuous movement update
>>>> handling
>>>> etc. And in any case it's good for us to know and understand how
>>>> the DOM
>>>> interfacing works --- even if it turns out the efficient alternative is
>>>> not necessary for networking.
>>>>
>>>> In the current WebTundras we have the same structure as in the native
>>>> Tundra, i.e. there are normal software objects (non-DOM) for the
>>>> entity-system level entities & components, and the 3d visual ones of
>>>> those are proxies for the concrete implementations of scene nodes and
>>>> meshes etc. in Three.js / Ogre respectively. And the experimental
>>>> DOM-integration that Jonne made in WebRocket then mirrors that JS EC
>>>> structure to the DOM periodically.
>>>>
>>>> These two old client architecture sketch diagrams illustrate the
>>>> options:
>>>>
>>>> a) net sync updates DOM, rendering gets updates via DOM:
>>>> https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg
>>>>
>>>> b) net sync updates JS objects, optimised batched sync updates DOM:
>>>> https://rawgithub.com/realXtend/doc/master/dom/rexdom-dom_as_ui.svg
>>>>
>>>> Until now I thought that we settled on b) back then in early September
>>>> as I understood that it's what you also do & recommend (and that's what
>>>> WebTundras have been doing so far).
>>>>
>>>>> Philipp
>>>>
>>>> ~Toni
>>>>
>>>>> 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>
>>>>>> <mailto: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
>>>>>>>> <mailto:Philipp.Slusallek at dfki.de><mailto: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/>
>>>>>>>>>> <http://www.meshmoon.com/> <http://www.meshmoon.com
>>>>>>>>>> <http://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>
>>>>>>>>>> <mailto: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>
>>>>>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu>
>>>>>>>>>> <mailto:Fiware-miwi at lists.fi-**ware.eu <http://ware.eu/>
>>>>>>>>>> <http://ware.eu
>>>>>>>>>> <http://ware.eu/>><Fiware-miwi at lists.fi-ware.eu
>>>>>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu>
>>>>>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu>>
>>>>>>>>>> https://lists.fi-ware.eu/**listinfo/fiware-miwi<https://lists.fi-ware.eu/listinfo/fiware-miwi>
>>>>>>>>>> <https://lists.fi-ware.eu/**listinfo/fiware-miwi%3Chttps://lists.fi-ware.eu/listinfo/fiware-miwi%3E>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ______________________________**_________________
>>>>>>>>>> Fiware-miwi mailing list
>>>>>>>>>> Fiware-miwi at lists.fi-ware.eu
>>>>>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu><mailto:Fiware-miwi at lists.fi-ware.eu>
>>>>>>>>>> https://lists.fi-ware.eu/**listinfo/fiware-miwi<https://lists.fi-ware.eu/listinfo/fiware-miwi>
>>>>>>>>>> <https://lists.fi-ware.eu/**listinfo/fiware-miwi%3Chttps://lists.fi-ware.eu/listinfo/fiware-miwi%3E>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> ------------------------------**------------------------------**
>>>>>>>>> -------------
>>>>>>>>> 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
>>>>>>>> <mailto: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 <mailto:Fiware-miwi at lists.fi-ware.eu>
>>>>>>> <mailto: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
>>>>>> <mailto:Fiware-miwi at lists.fi-ware.eu><mailto: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
>>>>> ---------------------------------------------------------------------------
>>>>> <slusallek.vcf>
>>>>
>>>
>>>
>>> --
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>> ---------------------------------------------------------------------------
>>> <slusallek.vcf>
>>
>
>
>
> _______________________________________________
> Fiware-miwi mailing list
> Fiware-miwi at lists.fi-ware.eu
> https://lists.fi-ware.eu/listinfo/fiware-miwi
--
_______________________________________________________________________________
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 at 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
_______________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131111/9760c6d1/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy