Dear all, very confusing the discussion. I was not in Winterthur, but I think we are very open for your idea to use three.js to implement XML3D and we proposed several approaches how to start this. However, I also want to highlight, that this will be some work and some overhead that each of the approaches will induce. Especially a good integration of Xflow is not trivial. It would require some heavy adoptions of three.js which in turn invalids the argument having better maintenance. It would be a pity to spend all the resources to create something that is similar or less to what xml3d.js can do today. Arguing with number of contributors within a project that's intended to _promote_ the GEs is not very smart. However, I fully understand the SMEs POVs and their concerns. I'm pretty sure that we can come up with something that fulfills the project's requirements (DOM-integration, declarative data flows) but still generates added value for the SMEs. I like Toni's idea to look into scalability of large scene etc. Best, Kristian Am 30.09.2013 13:53, schrieb Jonne Nauha: > Yeah, the people who are doing the 3D GEs should really evaluate > different renderers and their maturity. The things is that three.js > does have a lot of stuff out there that works and is in production, I > bump to a new 3D web projects pretty much every week and if you check > what it is using, it's always three.js. The lib has kind of defacto > statutus right now, which does not mean it cannot be replaced but > means that some performance, functionality or "nice to program > against" etc. reasoning is needed. > > The companies involved from Oulu already have multiple prototypes, > demos and developer experience with the three.js library. Us at > Adminotech have a very functional virtual world client WebRocket, that > uses three.js and we have been working on it for a long time, long > before we applied to FIWARE. For me as the maintainer of that project > would need very good reasons to move to XML3D renderer as I would need > to rewrite parts of our product with that jump. Product that is > already used for commercial application. I can surely make that jump > if I get better visuals and better performance. But with the WebRocket > product I'm less interested in things like XFlow or DOM integration, I > just don't see these things very useful/important for the end user > that actually is using the web app. I know these exact things are > important for MIWI and we would need to do some work on for example > XFlow integration/extension to three.js, if its picked. > > As Toni said the declarative scene parts and showing the active scene > in the DOM is already been discussed to do with XML3D, its the best > thing out there for defining your scene in the DOM. The thing that > needs to be investigated is if XML3D is practical to use as a renderer > over something else. This is what I was referring too when at the > London even when we had the hangout, that we would like to use the DOM > spec from XML3D, to do declarative scenes and show the scene state > always in the DOM, but does it also imply we must use your rendering. > > Best regards, > Jonne Nauha > Meshmoon developer at Adminotech Ltd. > www.meshmoon.com <http://www.meshmoon.com> > > > On Mon, Sep 30, 2013 at 8:12 AM, Tomi Sarni > <tomi.sarni at cyberlightning.com <mailto:tomi.sarni at cyberlightning.com>> > wrote: > > Although i am not really working on rendering in FI-WARE GEs I > feel Toni builds a strong case here. Please have a look at GitHubs, > > https://github.com/mrdoob/three.js > https://github.com/xml3d/xml3d.js/ > > Other one has 5 contributors and other 200. > > just my 5 cents > > > On Sun, Sep 29, 2013 at 10:22 AM, Toni Alatalo <toni at playsign.net > <mailto:toni at playsign.net>> wrote: > > There is nothing up from the DFKI side for the 3D GE specs yet > so I don't know whether those texts will address this. > However, I think it is time to raise this important question > regarding the 3D UI Epic: what tech should we use for > rendering, and why? If the GE spec texts answer this, great, > as then we have both the question and the answer. > > I know Philipp already once stated that he does not even want > to discuss this as XML3d was defined in the proposal. This is > a misunderstanding due to the fact that XML3d means two > things: The proposal defined the 1. spec, the XML schema and > the way of DOM integration, over e.g. X3D and X3DOM or TXML. > The proposals from all stages explicitly define how the 2. > rendering technology is to be investigated -- that's why we > had the discussions in Winterthur about for example whether it > would work to use Three for rendering within the XML3d.js > framework etc. This was also made explicit in the architecture > diagram that we delivered in the negotiation phase in spring. > > My main point here is: no matter what tech we decide to use, > we must have a solid explicit rationale for choosing it. When > a realXtend user asks me why we chose that particular tech I > want to be able to explain it clearly and even point to a > design rationale document with more details. It is such an > important decision in this very important project so we can't > just overlook it and go with something. > > Regarding the goals of FI-WARE, in my understanding, this is a > business decision. That is: the purpose of FI-WARE is to boost > Internet application business, and the evaluation criteria is > the rate and success in adoption by developers. If someone > knows a useful framework for business decision evaluation or > has experience in doing this kind of analysis, please do tell. > I'm only formally educated in tech (and humanities) and just a > self-taught businessman (though for 19 years already :) > > My simple view from a business perspective is this: when > targeting business use, it helps to start the use as soon as > possible. This way you get developers and even end users > involved right in the beginning, get feedback of how things > work for them and can continue development in a more informed > manner. Community is born and knowledge about your offering > starts to spread. Ideally other platform developers join you > in the effort or start developing their own related product so > you start getting an economy with multiple parties etc. (I've > heard of the the term time-to-market, probably means something > at least close to this). > > To end this post, where the aim is only to rise the question > and not have answers yet, a concrete example about the > situation we have here right now: The Oulu3DLive city model is > now being prepared for first launch. With some simple > applications that hopefully are already useful for the > citizens. The Oulu3DInfra-project on the University of Oulu > side got a grant (800kEUR for 2013-2014) for the modeling and > city-specific applications. There we have -- together with the > Oulu3d Ltd. company which the city chose to operate the > service and develop it into a business -- decided to target > already the first major public launch with the Web client to > not require the masses to install Tundra or anything. The > Infra-project knows about FI-WARE and, I think rightfully, > expects MIWI to deliver a functional Web client and the whole > platform for the launch. > > So where are we with the tech on the FI-WARE side? The first > rendering test with the old optimized 9-blocks model has been > made both with XML3d.js in Three.JS (linked from the reqs/use > cases doc). Both load and show the geometry OK. XML3d.js > misses most of the textures, I think because they are not in a > compressed format so they won't fit memory? The Three.JS > version shows all the textures from the desktop-gpu friendly > compressed data from DDS files. XML3d folks have already > described how they plan to add support for compressed textures > and how it should be easy enough. > > So one way forward would be to work on improvements to > XML3d.js: compressed texture use, shadows (discussed in > Winterthur), what else is missing? > > But how would that make sense businesswise? As with Three.JS > we already have all that working and a successful test has > been online for weeks now so that the potential platform users > (e.g. app developers e.g. at Oulu3d Ltd. and university) have > been able to verify that it works etc. Why would we go back, > instead of continuing forward to meet new challenges? For > example the culling / resource management that the extended > model (>30 blocks heavily textured) will require and probably > there are other things too. It would be nice to have a first > solution for that scalability challenge in a few weeks > already. It does not require novel research, I think, as > dealing with complex scenes is already well known in the > literature. > > Please don't get me wrong: I don't have anything against > XML3d.js. If there are good reasons to use it -- for example > better performance, a good architecture that facilitates > scalability for large complex scenes well, and a great API for > app development -- that's great! It then solves business > problems for us and makes good sense. I just want to point out > that we should know that explicitly, and am willing to work on > this analysis if we figure it's useful (the reqs & use cases > doc already gives some ground for this effort too). Ease of > XFlow integration is an important point in my understanding: > for example if an app dev uses XFlow to declare a generated > GLSL shader, is it then easy to use that with whatever > renderer, or much more straightforward with XML3d.js? > > ~Toni > > P.S. I'm not discussing the declarative authoring & the scene > serialization formats etc. here as, like mentioned above, that > was settled to begin with in favour of XML3d. > > _______________________________________________ > 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 <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 -- _______________________________________________________________________________ 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/20130930/faccedf8/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy