Hi again, just a brief / quick note: Can well just be a misunderstanding I figure. This was referring to post-Winterthur discussions in telcos, or more like a side mention that came up in a discussion about some other topic that Jonne was describing then. I totally agree that it requires careful thought. Is also interesting -- though not too surprising -- to hear that proper Xflow integration to Three would require heavy modifications there. Would be actually, even just for curiosity / better general understanding, interesting to know more about those. I mean it may exemplify also what Xflow actually is. Is the matter in the direction of: 'being able to declare how things would be processed and drawn requires a renderer which enables you to plug in something derived from those declarations to perform custom drawing' .. or so? Or something different? One sentence answer suffices :) .. am sorry for my ignorance about this still. Anyhow, thanks for the comments and let's discuss more. Ah have time to mention one important thing still: We (Playsign) also settled on scalability matters today after ran through a shortlist of useful next steps. The new extended Oulu model is unfortunately not there yet so we need to get something else for test data. Is of course easy by many means -- one option I was thinking was Jarkko's Chiru-time Chesapeake Bay model based auto generated landscape thing. But I figure there are also nice existing models for city rendering testing so do recommend anyone if you already know good ones. I think they'll be easy to find too, we'll dig in tomorrow. The MultiPong test is finished for now, we'll update the web & docs about it still and post info soon. The dev version is actually playable with n participants over the net so that's gonna be online soon. I think the things that are left there will be more for Lasse and the synchronisation epic team. So we consider that done from here for now and focus on complex rendering now (the very light pong scene has been good to have around too, it's even playable with phones and works on very weak compus etc - even without webgl with the canvas2d runs with 5fps at least :p .. it supports touch input for playing with mobile devices, is nice with webgl on android) Cheers, ~Toni On Sep 30, 2013, at 3:55 PM, Kristian Sons <kristian.sons at dfki.de> wrote: > 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 >> >> >> 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 >> >> >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130930/7064968d/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy