BTW,
as soon as xml3d.org is up again, we will release a version of xml3d.js
that will contain the new format handling API that allows for
asychronous loading of data blocks. As an example, we'll add a OpenCTM
loader that exploits WebWorkers for asychnronous decoding.
Best,
Kristian
Am 11.11.2013 09:00, schrieb Kristian Sons:
> 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
> _______________________________________________________________________________
>
>
> _______________________________________________
> 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/ba061987/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy