Hi, Thanks a lot for putting this info together. THis looks much easier than I had originally thought from our discussions in Winterthur. I have put together a quick first discussion of the mapping and a few questions and comments. I am putting all comments together into one email, but if there are further comments on specific components, it might make sense to break those into separate email per topic so we can keep those discussions focused on the separate component types. please feel free to correct, extend, and comment on my suggestions. I am simply trying to get us started here. > The Tundra component system is extendable, so anyone can define a > component and add it to the system. Usually outside of the Tundra > core SDK this happens by loading C++ plugins during runtime that > declare/register the component structure to both the server and > client. We take a very similar approach here except that we are not using C++ classes but KIARA services. They can map directly to C/C++ entities but could also refer to external services available through KIARA. > Main attributes: name (String), description (String) and group (String). It seems there needs to be at least some conventions of how to use these strings. XML3D has a hierarchical group system mainly for transformations. In Winterthur you indicated that you are want to introduce a hierarchy into your ECA system as well. How would that look like? -- EC_Placeable In the Network protocol Lasse writes that position, orientation, and velocity are most often updated. I wonder if it does not make sense to include velocity here as well and not just put it to the physics component. Each could have a default value and be optional, such that a very efficient encoding could be found for this data set. Anything else that would need to be here? BTW, is rot a 2D or a 3D orientation? This would most likely map well to a (special?) group node in XML3D. -- EC_Mesh This obviously maps well to our mesh element. We have separate shader elements (that Kristian and Felix are just expanding significantly). Our mesh pretty directly corresponds to a Vertex Array Object (VAO) and can have exactly one shader attached to it. I understand that your mesh is a complex Ogre object, which apparently can have many submeshes, which each have a material. So the best option would probably be to have a (sub-)group and put in there all the sub-meshes (so there would be a direct mapping from mesh->submesh to an XML3D mesh + shader). In XML3D textures are parameters of shaders (if I am not mistaken, we do not support textures as geometry attributes, which Ogre seems to do). We already support arbitrary other attributes and this does make sense to me. We might even be able to support texture arrays (which Ogre does not have). The mapping of textures would obviously not be per vertex but per VAO. Animation and Skeleton infos are completely separate from the mesh and are handled in Xflow. We consider LOD a purely application specific thing as there is no general notion of what a specific LOD level is and when to switch between them. It would be easy to have a group for each LOD level and have the client application switch between them as needed (e.g. based on distance). We currently have no support for attributes regarding shadow casting/receiving but this may be something that we should discuss as part of the shader work from Kristian/Felix. -- EC_Camera Seems to mapp directly. We currently handle near/far automatically based on the BBbox (right?). It seems a mixed approach where the given values are the min/max and we might be able to optimize beyond that might be interesting. Do you allow non-orthogonal cameras (e.g. for VR/stereo)? -- EC_Light We are aiming for a general approach where any 3D object can become a light source by assigning a light/emission shader to it. Not sure if we still support dedicated point light objects (the original idea was to do so via meshes consisting of one or more points that the shader gets assigned to). Kristian/Felix: What is the situation/plan here? -- EC_ParticleSystem Planned but not yet implemented, I believe. The goal is to do this through Xflow, where an particle update function is applied to a bunch of points which are then rendered through a mesh (possibly with shaders/texture arrays assigned to them). Will probably not happen until the shader stuff works. Felix? -- EC_Billboard Should easy to create simply in JS on top of existing assets, with JS taking care of orienting the object correctly. Unless there are thousands of billboards this should not be a performance issue. -- EC_Sky As discussed on the Hangout this should be easily possible with a procedural XFlow node or prototype that creates the necessary geometry with textures etc. -- EC_Water Again something that we would do through Xflow (there are some easy examples already). -- EC_WebBrowser Often discussed but not yet implemented, AFAIK. I let Kristian/Felix comment on the technical issues here. -- EC_Script This is probably the main issue here as the language and the runtime environment will be very different. We use JS both on the client and our (new) server, which shuld simplify things considerably. We probably need to discuss this in separately. A key element of our server is that a KIARA service description can directly be handed to the scripting engine which integrates it into the languages in a suitable and consistent manner. We should even be able to pass them through to a client and so have consistency. One main issue will be how to support HTML/DOM functionality on the server component. Again an important question in the scripting context. -- List of Attribute types Mostly straight forward, AFAIKT. Asset/Entity references would simply be (relative) URLs into the scene itself or into an external scene (which then gets loaded and referred to). QVariant: This corresponds to a Any type in middleware systems. We have postponed implementing this in KIARA but it seems we need to support this at least for DynamicComponents. We will discuss this. Again thanks a lot, Philipp Am 06.09.2013 14:03, schrieb Jonne Nauha: > My initial writeup on the Scene/Entity/Component/Attribute model of > realXtend Tundra: > > https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Scene_and_EC_model > > Best regards, > Jonne Nauha > Meshmoon developer at Adminotech Ltd. > www.meshmoon.com <http://www.meshmoon.com> > > > _______________________________________________ > 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/20130908/19d40c78/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy