Scenegraph to/from XML

Engines, Libraries and Tools Xith3D Forums
#41

I see no reason (in this case) to separate system metadata and user metadata.

What we want to do in this case is let TextureLoader to associate some information with scenegraph node, just to be able to distinguish resources loaded by TextureLoader and resources, loaded another way. But TextureLoader is just one of subsystems, even potentially optional one - just as any other geometry, sound and image loader, while the scenegraph is a core part. Similar way, Physics engine connector may be a subsystem of an application, but this does not make its metadata a system metadata.

I understand the need of associating metadata with scenegraph nodes, and I think keeping metadata in common storage is a good idea.

Few examples:

JAR file manifest: Main-Class attribute is one of JAR file metaattributes, and completely equivalent to any user metaatributes associated with JAR file, besides of it can be produced by “system” component JAR utility.

Java class files: Class files may hold custom named attributes for almost every entity (method, field, etc.), and debugging information is just one of them, besides of it is typically produced by “system” component java compiler (OK, there was no direct way to associate custom attributes in Java prior to 1.5, there will be @interface [metadata] mechanism for that).

Yuri

#42

Okay, so named userdata. I was simply concerned that without some sort of separation the names could conflict. Will one of the xith devs be implementing this or should I take a stab at it?

#43

Would be great if you can do that.

The suggested API can be:

void setUserData(Object key, Object value);
Object getUserData(Object key);
Map getUserDataMap();

Also I would suggest to preserve older (unnamed) userdata for Java3D compatibility reasons, and leave it as separate mechanism (we anyway isolated by API, so we can always merge it internally inside Xith3D and add to map of named data without breaking API.

[quote]I was simply concerned that without some sort of separation the names could conflict.
[/quote]
This can be easily prevented with API suggested: note that key value is not String, but Object, so application or system component can always define its own key class (you can call it “local or app-specific namespace”, and use it to associate metadata with the node. This ensures that two apps will not have intersecting metadata sets.

Yuri

P.S. I am sorry if I was pushing you too much - I am sure you inderstand we all are trying to do our best.

#44

Okay I have submitted a patch, isssue #58. You may want to take a look at the way I decided to declare the keys in:

SceneGraphObejct - XITH3D_USERDATAKEY_OLDUSERDATA
ImageComponent - XITH3D_USERDATAKEY_FILENAME

as you may different thoughts about how it should be handled.

The remaining items in issue #57 still need to be included for me to move forward with placing the files into the toolkit project.

The code currently includes four files in the com.xith3d.io.sg package:

SceneGraphReader (Interface)
SceneGraphWriter (Interface)
SceneGraphReaderException (Class)
SceneGraphWriterException (Class)

The rest of the code is in the package com.xith3d.io.sg.xml. I have a couple of questions:

1> Does it make sense to include the com.xith3d.io.sg classes/intefaces into the core project for other serialization schemes to follow?

2> If #1 is yes, are the simple interfaces I have defined sufficient?

3> What should the package names be for toolkit code? I currently have my code in com.xith3d.io.sg.xml and I’m concerned that it might not be appropriate given that you all don’t want the code in the core project.

#45

  1. Not sure - it’s a valuable feature but it’s also quite independant so there are arguments either way. Maybe it’s best as a seperate tool to keep the girth of the core package to a minimum?

  2. We encourage using “org.xith3d.*” for Xith3D tools but of course that’s only a recommendation. You are correct that “com.xith3d” is best avoided for anything which is not part of the core to avoid confusion.

Will.

#46

Okay, well for now I’ll just put it all under org.xith3d then. I have placed the same license agreement you guys use in my files, is that okay?

edit: I changed it so it doesn’t mention Xith3D Project Group

#47

XML Scene Graph I/O Library For Xith3D

Can be found here

https://xith-tk.dev.java.net/servlets/ProjectDocumentList?folderID=628

This is the first version and I know it has some things missing. It is however usable. Supports full and partial scene graph reading/writing.

#48

Hi,

  1. I do not agree on placing key for filename into ImageComponent.java. ImageComponent does not deal with storage details for image data. This namespace (key) is specific for TextureLoader, so should be declared there.

If other classes will decide to use that namespace, they assumed to know the meaning of metadata defined by TextureLoader.

  1. I suggest to replace String key with Object instance key, because of String key potentially may conflict with application-specific namespaces.

Replacement code is:

/**
 * This is the key used to store the user data from the setUserData(Object)
 * method. Used to maintain Java3D compatability. 
 *
 * Note that Object-type key is used to guarantee that conventional 
 * (old) user data namespace will never intersect with 
 * other user-defined namespaces.
 */
public static final Object XITH3D_USERDATAKEY_OLDUSERDATA = new Object();
  1. Changes made to TextureLoader are in some parts incompatible with existing Xith3D codebase: at least one class compile failed.

[javac] Compiling 383 source files to D:\CVS\xith3d\classes
[javac] D:\CVS\xith3d\src\com\xith3d\test\Xith3DCollisionDropTest.java:173: cannot resolve symbol
[javac] symbol : method loadTexture (com.xith3d.image.DirectBufferedImage,java.lang.String,boolean,int,int,int)
[javac] location: class com.xith3d.loaders.texture.TextureLoader
[javac] Texture2D tex = (Texture2D) TextureLoader.getInstance().loadTexture(grid,“RGBA”,true,
[javac] ^
[javac] 1 error

The reason is that for methods that now accept filename and were exposed as public (at least, constructTexture), there is no delegation peer for preserving compatibility with older codebase. Additionally, there is no need to set filename metadata if it is set to null.

Summary: Changes to SceneGraphObject may be accepted with note 2, changes for ImageComponent I suggest to reject and move key declaration into TextureLoader, and TextureLoader changes should be refactored to preserve compatibility with existing codebase.

Yuri

P.S. Changes made really good. With these minor modifications, we can apply them to CVS. In fact, I already applied them to my local sources, but had to revert back because of TextureLoader incompatibility (method constructTexture(…)).

#49

changes/resposes submitted to the issues list now that I can reply to them there.

#50

Changes in their final edition now committed to CVS. Please check if everything is OK to work with XML reader/writer.

Maybe we should ask our Community Build Maintainer to make next community build so you can refer it as compatibility point for those interested in using XML RW for Xith3D.

Yuri

#51

Thanks for making the changes. I will need a new community build done because I can’t get the network guys here to allow me to use CVS, so I can’t pull the code.

#52

I’m currently uploading a new community build. (Will is on holidays.)

#53

Thanks, however somthing very bad has happened. The GeometryContainer class has two methods that appear to have changed and I think are now wrong.


    /**
     * Sets the color of the vertex at the specified index.
     * @param vertexIndex The index of the vertex to modify
     * @param floatArray The new color data. The first {@link #colorSize} elements
     * will be used.
     */
    public void setColor(int vertexIndex, float[] floatArray) {
          assert floatArray.length >= colorSize;
          colors.setFloats(vertexIndex*colorSize,floatArray, 0, colorSize);
    }

should be


    /**
     * Sets the color of the vertex at the specified index.
     * @param vertexIndex The index of the vertex to modify
     * @param floatArray The new color data. The first {@link #colorSize} elements
     * will be used.
     */
    public void setColor(int vertexIndex, float[] floatArray) {
          assert floatArray.length >= colorSize;
      colors.setFloats(vertexIndex*colorSize,floatArray, 0, floatArray.length);
}

and


    /**
     * Sets the coordinates of the specified vertex.
     * The coordinates should occupy the first three indices of the given array.
     */
    public void setCoordinate(int vertexIndex, float[] floatArray) {
          assert floatArray.length >= 3;
          coords.setFloats(vertexIndex*3,floatArray, 0, 3);
          setBoundsDirty();
    }

should be


    /**
     * Sets the coordinates of the specified vertex.
     * The coordinates should occupy the first three indices of the given array.
     */
    public void setCoordinate(int vertexIndex, float[] floatArray) {
          assert floatArray.length >= 3;
          coords.setFloats(vertexIndex*3,floatArray, 0, floatArray.length);
          setBoundsDirty();
    }

or am I totally messed up.

#54

[quote]or am I totally messed up
[/quote]
zparticle, I am really sorry, but looks like… :wink:

    /**
     * Sets the color of the vertex at the specified index.
     * @param vertexIndex The index of the vertex to modify
     * @param floatArray The new color data. The first {@link #colorSize} elements
     * will be used.
     */
    public void setColor(int vertexIndex, float[] floatArray) {
          assert floatArray.length >= colorSize;
          colors.setFloats(vertexIndex*colorSize,floatArray, 0, colorSize);
    }

This is setColor, not setColor_s_. It sets only color of ONE vertex. For multiple vertexes, there is a different method:

    /**
     * Sets the colors of the vertices starting at the specified index.
     * @param vertexIndex The index of the first vertex to modify
     * @param floatArray The new color value. Its size must be a multiple of {@link #colorSize}. 
     */
    public void setColors(int vertexIndex, float[] floatArray) {
          assert floatArray.length % colorSize == 0;
          colors.setFloats(vertexIndex*colorSize,floatArray);
    }

The same is for coordinates.

Yuri

#55

;D - Arrggghhh. I thought that it not being plural was weird, so it was broken before. It is obviously correct now. I was using the wrong method but it worked for me before the new build occured so I didn’t think to look closer.

No biggy, at least I got rid of a big mistake in my code. :slight_smile:

So the XML R/W is now working with the latest community build, yea! The toolkit project has the correct files and it is extreemly easy to use. To use the library you need:

1> The Xith3D library from http://xith.org/download/builds/?M=D . The 2004-01-20_cvs build is the first to be usable with this library.

2> A version of the Xerces jars. The old Xerces project had only one jar. The new Xerces2 project has 3 jar files you will need: xercesImpl.jar, xml-apis.jar and xmlParserAPIs.jar. These can be downloaded from http://xml.apache.org/xerces2-j/index.html

EDIT: Note that for reading any DOM parser library should work, you only have to have Xerces if you are writting XML files out. So once you have all of the XML output you need you can use a smaller DOM library to read them.

#56

Hi zparticle,

thanks for the Xml reader/writer. It was quite useful for my project.

A quick question, are you going to attempt to ouput to X3D format? How would you start the job? I had a look at the X3D specification, and it’s looks a bit daunting…

#57

Honestly, I haven’t looked at this stuff in a while I’m too busy with work. However, it would be nice if someone could take a look at my code, see the faults and build a good X3D reader/writter library. I would like to update my XML lib but won’t do it until Xtih reaches 1.0. They haven’t yet, have they?

I’m thinking the tricky part about X3D will be fitting Xith’s concepts into it. It will take very careful mapping (Xith to X3D) and somethings will have to be left out.