Just a quick note: thanks for the clarifications, I think it's all pretty clear for us from this now. Is similar to what we have within realXtend, where kNet is like KIARA and Tundra is like Fives, and the avatar example app built with Tundra again similar to your example app with AVs (the Tundra example / reference av app is https://github.com/realXtend/naali/tree/tundra2/bin/scenes/Avatar) So how will this be licensed once you publish it? And is the idea that this is somehow connected with other efforts in WP13 or a separate individual effort whereas the other parts in MIWI use networking from the Synchronization EPIC & the existing Tundra server? ~Toni On Sep 24, 2013, at 10:09 AM, Torsten Spieldenner <torsten.spieldenner at dfki.de> wrote: > Hello, > > thank you for your thorough feedback! > The code is not open source, but we plan to publish it for you to have a detailed look once we reached a stable version of the current functionality. We want to have this ready before Friday, there are still some parts under testing, but we think that the remaining issues should be solved soon. > > I noticed that I did cause some confusion concerning KIARA, FiVES and the actually documented application. > > KIARA is no application, but the communication middleware that is also part of FI Ware / WP 13. It hides actual protocols from the user by providing wrapper functions like those I've put into the documentation. All details about connection, serialization etc. are no longer to be taken care of by the developer. Data that is transmitted using KIARA can be provided using data structures like the Vector or Quat structure I've introduced in the documentation as well. Internal data structures of specific applications can be mapped to those KIARA data structures by providing respective mappings in an IDL file. KIARA then takes care of correctly serializing, transmitting and deserializing the data. > > FiVES is the application layer that provides the mechanisms to create Virtual World applications by putting together sets of plugins. If you start the server a second time with a different set of plugins than the first time, it will only use the data provided by the plugins at second start. So, in general, FiVES is actually not meant to be the basis for only a certain kind of application, but rather to provide a way to come up with any kind of synchronised world by creating and selecting a respective set of plugins. > > The documentation so far is a documentation of Plugins we have written for a specific example application, which will be a Virtual World Client with scriptable 3D objects and users represented as animated avatars. This is also the reason why "Avatar" depends on "Renderable" currently: In our case, an avatar is the 3D representation of a user in the world. As 3D renderable objects are already introduced by the Renderable plugin, we decided to use functionality introduced by this plugin and made avatar depend on that, rather then re-implementing what Renderable already does. If you like to run the world without having visible users (like the SimCity scenario you mentioned), all you have to do is to start FiVES without the avatar plugin. Users will then not be represented in the world. > The actual login information (like session tokens) is not managed by avatar, but by an Authentication plugin. Both Avatar and Authentication are currently still under testing, and the way how 3D entities representing users are connected to a specific user account is likely to change. > > Concerning and position, you are right with the assumption concerning default values. Those can either be specified when defining the Component Layout, or they are just set to a "default default" value by FiVES (if not specified by the plugin). > Separating scale from position and oriention was a decision we made, as we may have positionable objects without any visual appearance, so we saw no need for scaling those. The resulting over all transformation could of course also be managed via a transformation matrix. > > Concerning the Editing Plugin, you are right. We don't support adding non-visible objects to the world yet. > > Again, thanks a lot for the feedback. I will revise the documentation (and make the differentiation between the different parts of the application clearer as well) as soon as the we proceeded with testing and the interfaces are less likely to change to anymore. > > ~ Torsten > > > Am 9/23/2013 3:20 PM, schrieb Toni Alatalo: >> Thanks, we checked this quickly with Erno here and have a few questions: >> >> First, is the server implementation open source and, if yes, where is it? >> >> Then some points about the entity model and VW functionality: >> >> You have apparently kind of hardcoded the concept of the avatar, tied login information so some 3d positioned entity etc. This is something that we were very happy to *remove* in realXtend when switched away from LLUDP and Opensimulator. In Tundra the client connection information is in the UserConnection object and it's up for the application logic to decide whether and how user presences show in the ui / scene. I think we want to keep that. For example in a SimCity like scenario the users don't necessarily have any 3d presence at all even though they are all collaborating in the same 3d scene. Also when making e.g. a chat + whiteboard application without a 3d scene it's weird that the platform would insist putting some 3d position for the presences. Of course if the scope of FiVES is only for certain kind of applications, and not a more generic platform like with Tundra, this can make sense (I don't really know what FiVES is, only a glance from quick search). This is sup > po >> sing that the Avatar plugin in your doc is considered a 'core plugin', and it would seem so as ClientManager depends on it. >> >> Likewise in the messaging there are avatar specific messages etc. There we've resorted to generic attribute manipulation and entity-action triggering calls, not having application specific things in the platform. Perhaps I am reading this the wrong way -- KIARA being the generic application agnostic layer, whereas Fives is like one application (some system with avatars)? This probably also shows how we don't know what your effort is and how it is perhaps related to FI-WARE.. >> >> Also, we were curious about the rationale for separating the scenenode matrix to position, orientation and scale components. I'm not really criticizing that (yet :) but trying to understand. Usually it's a single 4x4 matrix in the end anyways so has seemed straightforward to handle as such in many places -- though in networking it is often handled with more granularity, perhaps net message optimisation is your motivation as well? Anyhow it seems a bit strange at first in the entity model that something could have an orientation without a position, or a position without scale .. I suppose then you'd default to 0 position and 1 scale etc? What happens for a piece of code that encounters a positioned object and tries to read it's scale - it gets the default value if the scale component doesn't exist? Or no value is returned, as the component doesn't exist? But the rendering uses the default value of 1 so it looks like the component existed? That would be confusing I think. >> >> For editing I'm not sure if the 'Location, Renderable' dependencies are necessarily - in Tundra we are used to having non-position so-called application entities which only have a script component. We can edit those (the script reference and parameters) over the wire without those entities being placable nor renderable. Your script component seems similar to realXtend's so perhaps the same logic for editing would apply, or do you mean something else with it? >> >> Cheers and thanks for sharing, >> ~Toni >> >> On Sep 23, 2013, at 3:44 PM, Torsten Spieldenner <torsten.spieldenner at dfki.de> wrote: >> >>> Hello, >>> >>> a first, very high level overview of FiVES Entity-Component-Model, list of Components, Plugins and the KIARA Interface for Server-Client-Synchronization are now available at >>> >>> https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/Current_FiVES_implementation_details >>> >>> Please note that the interface is still under design, and there will be slight changes to the existing Plugins / synchronisation functions, and new ones are very likely to come during the next days. >>> The client will then support rendering of entities by referenced XML3D mesh resources, as well as users that are represented as avatars, including a very basic user authentication. >>> >>> ~ Torsten >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130924/a0254772/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy