Well. My understanding is that we are building as easily programmable 3D
SDK for the web. What you are suggesting is we offload everything to the
DOM and to XML3D and forget about designing a nice JavaScript API?
If we are talking about the raw DOM API I don't really consider it to be
nice at all. I don't know anyone who would make a serious web application
in JavaScript without using jQeury or something similar to access and
manipulate the DOM? jQeury has a nicer API to do the same things that can
be done with the standard functions, it just builds around it so developers
have a easier time. To be more productive, write less and more
understandable code.
This is ofc only my view an am not implementing the 3D GE, but whatever the
renderer might be it should be encapsulated as much as we can behind the
"renderer" object. What happens under the hood should be an implementation
detail. Using XML3D as the renderer is fine but imo all code that wants to
do rendering in WebTundra should not need to know exactly how to interact
with XML3D. You will use our scene-entity-component API with
avatarEntity.placeable.setPosition(10,-10,0); in your application code and
the right thing happens in the selected renderer.
XML3D is also a javascript library, I'm assuming that you provide functions
and objects that can be used to develop XML3D apps. Or is it really just
auto monitoring the DOM for XML3D nodes and acts on them? Why should the
even more elaborate WebTundra SDK have some kind of structure and easy to
understand and convenient API? XML3D is after all a renderer (if I've
understood your scope correctly). WebTundra should be a lot more complete
SDK like Tundra is to develop 3D web applications.
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 just would not like to see a path where XML3D is tied to all the aspects
of WebTundra and becomes essentially just a minimal network sync extension
to XML3D. I think we all from realXtend want to develop a Tundra style SDK
for the web for developers to use. This would also include hiding the
rendering implementation behind the renderer, and if its done well enough
there can even be multiple renderers in the future. This is one of the big
problems on the desktop Tundra, we did not abstract Ogre rendering engine
enough. It creeped all over the codebase and now its impossible to make
another renderer implementation without breaking everything while we
refactor 50% of the codebase. I'd like for us not to make the same mistake
on the web now that we actually have a change to start from scratch again.
Sure we need to utilize the power of the web technologies and the DOM. But
I don't think this says that we should not build utilities around the 3D
aspect of it to make it nice to use.
Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.
www.meshmoon.com
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
> ------------------------------**------------------------------**
> ---------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20131031/6c9ccf59/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy