[Fiware-miwi] XML3D in WebTundra internal scene & sync: planned improvements for the reX EC model

[Toni Alatalo]

Notes from the live meet from a week ago, about XML3D and the reX EC model and how everything could and should work in WebTundra / FI-WARE. Focus here is on the network synchronisation and related internal client architecture — that is, at least in the current implementation these points do *not* depend on what is used for rendering. Even if we implement a Xml3dView, the internal scene model used for the sync is now the reX EC one. Even when loading a xml3d from a HTML doc, instead of receiving the scene over websocket, it is still mapped to the internal scene EC implementation which the view then uses.

So, currently the sync uses the reX EC model as is. But the goal is to support XML3D data. We already support that by having a mapping from XML3D scene descriptions to the internal EC model in WebTundra’s XML3D scene reader. reX EC is not hierarchical but supports parenting only via the by-id references in the Placeable component — so the current reader maps XML hierarchy to those. This is weak, but fortunately Lasse has all along planned to add proper hierarchy support to Tundra & the reX EC model as a part of Ludocraft’s FI-WARE work. With this the reX EC model & XML get identical and we get a straightforward lossless mapping, we’re unaware of problems that will remain.

Other problem is XML elements for which there is no corresponding reX Component, for example the <data> and XFlow <computation> elements, or any html element if someone wants to sync those. Currently we’d have two options: 

1. Use Tundra’s DynamicComponent mechanism to map unknown elements/components to DC’s named ‘data’ or ‘computation’. Then if we e.g. have a Xml3dView in WebTundra for running XFlow apps it could handle those. But this is fragile as the DC name is not a strong typing mechanism. Someone could use the name ‘data’ for his DC for other purposes and things might break. 

2. Implement server-side equivalents of the needed components in C++. At least the quick consensus was to not go there — is useless for the C++ server to have components with which it doesn’t do anything. Is also very cumbersome to require C++ work & compiling Tundra just to have sync work for some new xml tag when e.g. introducing a new one.

In the meet we came up with a new plan: let’s allow use static type IDs, the kinds used for normal components now, for proper typing of arbitrary components. We can still use the DynamicComponent mechanisms in the server and in the network protocol to have the sync work. This way the component handling in the client can use the type info properly and the name remains free for app devs to use. I didn’t get every detail of how this implementation would work but understood from Jonne and Lasse that it’s clear and straightforward. This is not scheduled yet but I propose we put this in the roadmap. This is not only for XML3D (or generic HTML doc) sync but for any reX app dev to support custom components from JS-only app code better.

These were the main problems and solutions we identified.

Additionally, we discussed a couple smaller issues with this combined XML3D & reX EC usage:

1. If we want to use XML3D as a replacement for TXML, which we are already doing quite happily with WebTundra’s XML3D loader to load scenes locally without needing a Tundra server, what should we do with the extra data we have in the ECs? For example reX Mesh has drawDistance and castShadows, whereas xml3d mesh does not: http://doc.meshmoon.com/doxygen/class_e_c___mesh.html vs. http://www.xml3d.org/xml3d/specification/current/#mesh . My understanding is that as the ‘X’ in XML is for extensible, it is fine to put non-standard additional attributes to the elements .. so we can save <mesh src=“mymesh” drawDistance=“10"> etc. Some things we could of course consider for standardization in XML3D specs but I’m sure many our current things are not really suitable for that.

2. Attribute names differ. For example in Mesh we have reX’s self-invented mesh.meshRef (as there is only skeletonRef and materialRefs) vs. xml3d’s web-standard src attribute. Technically it is ok to map these but I’ve only recently realized that that’s not good in the end as it gets confusing for the app developers. Is weird if you have src=“mymesh” in xml but then must say mesh.meshRef in code. I propose that the realXtend side would be open for harmonization here, as in considering changes to attribute names at least in cases where they are the same thing. In the Web client we could also work via the DOM or support alternative names in WebTundra’s EC implementations but I think that would be bad and only add to the confusion in the (typical) case where also server-side code is needed. Best would be to have xml and client & server APIs have the same names, like we have now with TXML.

There’s also a bigger similar issue we did not discuss: in reX EC model and consequently TXML we define whether entities or components are Local or Replicated, i.e. whether they should exist only where they are created or synchronized also to others. A simple way to do this would be again just to extend XML3D elements with the ‘sync’ attribute, i.e. just doing what we do with TXML now. But do the XML3D folks here find that some other mechanism for this would be better? You can see an example for example in this TXML, there the sync=“1” means Replicated, https://github.com/realXtend/tundra/blob/tundra2/bin/scenes/Physics/scene.txml and the doc in http://doc.meshmoon.com/doxygen/class_entity.html#a12e886ac19fc9d279ea0746432f8f6bc . Obviously in a human-friendly XML such as XML3D we should at least say “replicated” instead of the int constant 1 used in the machine readable TXML.

Looking the other way, the XML3D ‘defs’ system is something we don’t have in reX. Currently the XML3D reader in WebTundra supports them but it just applies the values to the components and the defs library itself is lost after the initial reading. We don’t know yet whether the defs are supposed to work so that if you change e.g. a position defined there at runtime it is supposed to be applied to all objects using that pos. That might translate to many entities sharing the same placeable component in reX — which is not supported, would have to be implemented with a parenting (this we actually discussed in the meet too).

I think this sums ups the talks and plans, hopefully gives some background for today’s talks too.

~Toni