1. Additional Services
The SVG to X3D translation process has limitations. The coordinate origin is different between SVG and X3D. Also, the way in which objects are positioned is different (top left-hand corner versus middle of an object).
Currently, these coordinate transformations are not performed by the mapping process. In order to support this, a new services is required which supports attribute transformations.
2. Semantic Approximation - Objects
When translating from SVG (2-dimensional) to X3D (3-dimensional) an approximate match is made between objects types.
For example, an SVG rect is approximated as an X3D box. This approximation is currently set by the
user during the mapping process. It would aid the user if the choice of objects to map were decided (or at least proposed)
by the system. This would increase the automaticity of the system.
Also, the Z (depth) attributes of the X3D box must be assigned a value.
Currently the value assigned is defaulted by the user.
The system would behave in a more intelligent manner if the depth value were calculated based on the geometry of the object
and its surrounding objects. Again, this would increase the automaticity of the system.
3. Automaticity: Bi-directional mapping
It is not expected that a totally automatic mapping process could be built. However, there are certain tasks which the system
could perform better than a human user. For example, repeated tasks with a similar pattern. One particular challenge occurs
if the user tries to build a mapping for both translation directions at the same time.
Bi-directional mapping with automatic intelligence for concept bridges and in particular property bridges.For example, if a user specifies a Property Bridge where there is a Concatination operation, the system could try to produce the parameters for the reverse Split operation.
4. Dithering
In the House example, the X3D renderer will sometimes render objects incompletely. This can be seen as dithering
on certain objects (see the door handle and letter box below). This is caused by overlapping objects having the same
coordinates in at least one of their planes. In this case, the depth (Z positioning) of the door is the same value as for
the door handle and letter box. This results in the X3D renderer not knowing which object's surface to show.
Obviously it is a physical impossibility for two objects to have the same coordinates when they overlap each other. So in this case, the translator needs to take into account that overlapping objects in 2D must not have the same depth value in the 3D scene. Therefore, the translator needs to know when objects overlap each other and which one is the top-most one. This information can then be translated into depth information for the 3D scene.
There are likely to be further examples of semantic challenges which will occur when dealing with support for more objects and scenes with greater complexity.
5. X3D to SVG
Currently the system performs translation from SVG to X3D. There would be value in creating a translator in the opposite
direction (i.e. X3D to SVG), since this would provide further challenges for semantic approximation. For instance, one
possible method for dealing with the reduction in information from 2D to 3D would be to generate 3 separate SVG target
translations: one each for the front, side and top views of the source X3D file.
6. Visualisation
This work has been concerned with translation between graphics formats. It would be relatively simple to use the
knowledge gained to build some basic visualisation mappings. For example, news feeds in RSS format could be visualised
by creating a mapping to SVG. Likewise, simple ontologies could be visualised by creating a mapping from RDFS to SVG.