I added some comments to proposed patch in IssueZilla. Please comment especially on point 2, point 1 is not so important, but you should know that compatibility of serialized versions for point 1 (billboards) will be very probably broken in future. The rest is OK.

Well I don't appear to have the ability to modify my own issues so I'll post here.

Quote

1. Billboard class. I believe it should be made compatible with Java3D Billboard, so existing functionality will become an extension for more generic functionality.

2. Texture Loader and ImageComponent. You definitely know that TextureLoader is not only way to load textures into scenegraph. I will vote against adding storage-specific functionaloty/data to rendering classes, and image components of course can be generated on the fly. File name is loader specific, but not node-specific.

As for number one I can just leave the Billboard objects out of the graph I suppose. I have already assumed that the classes will change making them incompatible with the XML reader/writer at times. So if we can go ahead and add the methods I need for now I can deal with the changes when they occur.

As for number two I'd be happy to do it some other way if you can tell me how else I can make sure I get a filename based on an ImageComponent.

I realize that there are other methods of generating the texture data. Right now if I don't find a file name in the IC I use the methods

byte[] getByteData() <- 2Dbyte[] getImage(int index) <- 3D

to get the image data and write it into the XML file. However I belive this to be unreasonable in situations where the data was not generated but was loaded from an image file. I only need the file name not the path.

I also understand that people may not use the TextureLoader to load the images and they may create the ImageComponent object by hand. If this is the case and they want the XML to not contain huge blocks of image data they simply have to follow one rule: set the filename in the ImageCompoent objects by calling setFileName().

As for "adding storage-specific functionaloty/data to rendering classes", well it's meta-data, it doesn't effect the render process in any way, it needs to be there unless another method of finding the file name for an IC object can be found.

Another possibility would be to tackle the problem in a more general way. I know we have the setUserData method in the SceneGraphObject class. However there is no way to effectively output this as XML since it could be anything.

I have already assumed that the classes will change making them incompatible with the XML reader/writer at times. So if we can go ahead and add the methods I need for now I can deal with the changes when they occur.

This is what I thought to do. I just wanted to make a clear statement about possible future incompatibility.

Quote

As for "adding storage-specific functionaloty/data to rendering classes", well it's meta-data, it doesn't effect the render process in any way, it needs to be there unless another method of finding the file name for an IC object can be found.

For Metadata, Java3D assumed to use userData. In this specific case the major concern is that if we will add all the possible metadata fields as fields in core classes, they will become enormously big very very soon, and every time it will be "one more very small addition".

Instead of this I will suggest to introduce either alternate mechanism for associating metadata with the scenegraph, or adding an option to TextureLoader to allow identifying textures loaded by TextureLoader and retrieving their name. We anyway need more sophisticated mechanism for annotating scenegraph with application-specific data to add, for example, physical properties, which may differ from one physics engine to another.

We can extend userData support by adding named user data, that will be stored in internal hashMap, so any other application will be able to associate its own data with given node.

It is generally not possible to store metadata as a part of serialized scenegraph until they have their own well-defined persistence support, so we will not break XML serialization anyway.

The bottom line: I just don't think that placing workaround for specific problem is a good idea, because of more generic solution seems for me easy to implement.

It would be good to have an option to say to texture loader to place its annotations in userData (or metaData) or not, and I see it disabled by default.

Okay so you think that extending the user data mechanism is the way to go here then? I wonder if it may make sense to add the meta data methods above AND extend the user data methods to allow for named objects.

The meta data methods I have suggested would be used ONLY for system generated information then. The user data remains for program specific related data only. The separation of the two types of data makes sense to me (although maybe not to anyone else ).

This allows serialization code to have a general rule: USER DATA IS NOT SERAILIZED (or requires special handling), SYSTEM METADATA IS SERIALIZED.

Also I'm thinking there may be a way for me to allow the user to help me understand how to serialize/deserialize the user data by passing in an object to the reader/writer that implements an interface such as

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).

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.

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.

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.

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?

3) 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.

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.

2. 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();

3. Changes made to TextureLoader are in some parts incompatible with existing Xith3D codebase: at least one class compile failed.

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(...)).

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

1 2 3 4 5 6 7 8 9 10

/** * 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. */publicvoidsetColor(intvertexIndex, float[] floatArray) {assertfloatArray.length >= colorSize;colors.setFloats(vertexIndex*colorSize,floatArray, 0, colorSize); }

should be

1 2 3 4 5 6 7 8 9 10

/** * 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. */publicvoidsetColor(intvertexIndex, float[] floatArray) {assertfloatArray.length >= colorSize;colors.setFloats(vertexIndex*colorSize,floatArray, 0, floatArray.length);}

and

1 2 3 4 5 6 7 8 9

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

should be

1 2 3 4 5 6 7 8 9

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

/** * 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. */publicvoidsetColor(intvertexIndex, float[] floatArray) {assertfloatArray.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:

1 2 3 4 5 6 7 8 9

/** * 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}. */publicvoidsetColors(intvertexIndex, float[] floatArray) {assertfloatArray.length % colorSize == 0;colors.setFloats(vertexIndex*colorSize,floatArray); }

- 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.

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:

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org