EAVP JAXB XML optimization

[SmithRWORNL]

I'm starting a discussion about the XML used for our forthcoming JAXB support for the EAVP modeling data structures. I cannot attach an xml file directly and the formatting is messed up for xml when I try to insert it as text or code, so I'll send the list an example of a current BasicMesh with a few properties set and two children, although it is currently not working due to class casting issues from ElementNSImpl to IMeshCategory. One immediate way to clean this up would be to remove the previousTransformation, either from just the JAXB support or from IView entirely, as it is unused.

[jayjaybillings]

Robert and I just spent a lot of time looking at this. Here's some stuff we came up with.

We started messing around with the original file, test.xml, and cleaned it up as much as we could, step-by-step, in test_modified.xml. Finally we covered all the changes we want in meshFormateRefinements_20160427.txt. test.xml.txt test_modified.xml.txt meshFormatRefinements_20160427.txt

Robert is going to try to implement these updates using a custom JAXB adapter.

[SmithRWORNL]

Here is the proposed schema for the Geometry Editor.

The various types of shapes are each given their own block, inside of which they are given an ID and their rotation, scale, and translation are saved. IDs are saved, because currently two objects may be given the same ID, such as when one is copied.

The unions block is special. It also includes a name, as unions may be named either "Union" or "Replication" depending on how they were created. It also has a list of internal IDs for all the union's children, followed by a : to delimit when the IDs are finished and the union's transformation information has begun. An internal ID is formed by simply traversing down the blocks of shapes, assigning each one a unique ID in the order they were found in the file.

Geometry XML.txt

[jayjaybillings]

Okay, that won't work.

Our GeometryEditor is a Constructive Solid Geometry (CSG) editor, so it should output data similar to a standard CSG tree.

https://en.wikipedia.org/wiki/Constructive_solid_geometry

So, let us say that I have two circles that intersect each other (https://en.wikipedia.org/wiki/Intersection_(set_theory)). The "universe" in which they exist is a very large cube (infinite to the extent we can make it so). Then the output should look something like following:

<cube id=1 rot=... scale=... trans=... ...>
     <children>
            <intersection id=2>
                    <children>
                          <circle id=3 rot=... scale=... trans=... .../>
                          <circle id=4 rot=... scale=... trans=... .../>
                    </children>
            </intersection>
     </children>
</cube>

This is almost what it used to look like a few years ago before it was inexplicably broken. (Not saying @SmithRWORNL broke it, btw.) Geometries are hierarchical and should be managed as such so that moving the root object moves all of its children, including the operations applied to them. Positions, rotations, etc. are all relative to the parent. So, managing it in something other than a tree like this is a world of bookkeeping hurt.

[SmithRWORNL]

Regarding the optimizations we discussed earlier, it is not possible to move all the transformations out into their own block, as it is permissible for two shapes to share the same ID (Sphere 1 and Union 1, for example). However, that would provide only minimal space savings versus writing out the transformations as a single attribute for its shape's node.

The largest problem is the way the trees are structured. Currently, there is no way for one mesh to directly contain another as a child. Rather, one IController contains an IMesh which contains its children IControllers which each have their own IMesh, etc.This presents a problem, as according to the design of the data structures, we should not in general be instantiating IControllers ourselves, but rather getting them from an IControllerProvider we receive from the VizService. We could work around this by having our FXShapeController have special get and set operations for its model, callable only by JAXB, that will instantiate an FXShapeView itself, though this removes one of the nice features we had with the Mesh Editor: that its xml is not dependent on which rendering engine we are using, so that hypothetically we could save a mesh made with the JavaFX editor and open it with a JME3 editor implementation.

[jayjaybillings]

It doesn't necessarily save us anything. For n nodes in the geometry, we end up with n additional lines in the file, so reading it on the original line is probably just as fast when you take latency to reconstruct the properties into account.

As for your second paragraph, I'm not sure what you're talking about, but we can try to put together some sample cases and look at it.

In general, I'm getting cold feet about the viz data structures. We've had so many problems with erroneously named classes and I/O that I'm starting to feel like we need to to go back to the drawing board. I'm also more than a little disappointed that the link between the data structures and the EMF model has eroded. For now, don't worry about it, but submit another ticket for a full code review of the data structures and assign it to me please.

[SmithRWORNL]

As a sample case for the second issue, imagine we have a root IController with three children in the CSG tree. Then persisting it with JAXB naively, we get an IController node which has a child IMesh node which has three IController nodes each of which have their own IMesh node child. This is wasteful use of disk space, as the IController nodes will never contain any data except a single IMesh node.

Further, we should not be persisting IControllers in the first place, as they may be implementation specific. Imagine that in the future we write an implementation of the Geometry Editor with the new FOO rendering engine. Our FOOShapeView class has new functionality that ShapeViews in general will not have. We need to write a FOOShapeController that publishes this functionality, as our ShapeController should not assume that its ShapeView is a FOOShapeView. However, we should not be persisting these FOOShapeControllers, as the only difference between them and a ShapeController is the addition of new functions and because our .xml file should not be made specific to the VizService used to visualize it without good reason.

I'm currently working on designing some wrapper objects that will be persisted instead of the ShapeControllers, which can be converted back into a collection of IMeshes, which can in turn be fed into an IControllerProvider to reassemble the full tree.

[SmithRWORNL]

Version 0.3 will no longer handle management of data as used in ICE.