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/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>
> 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/20131030/efe0b11a/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy