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 On Mon, Sep 30, 2013 at 8:12 AM, Tomi Sarni <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> 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 (800k€ 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 >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130930/93a3048c/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy