Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (116)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Scenegraph to/from XML  (Read 6756 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #30 - Posted 2004-01-07 18:47:54 »

can you post a patch to IssueZilla?

Will.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #31 - Posted 2004-01-07 20:42:23 »

okay the patch/issue has been entered

Offline zparticle

Senior Member




Thick As A Brick


« Reply #32 - Posted 2004-01-08 13:27:23 »

Although I can't seem to get it to show up using the query page. Sad

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jens

Senior Member




Java for games!


« Reply #33 - Posted 2004-01-08 14:43:44 »

Don't know what went wrong, but you didn't commit an issue.

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline zparticle

Senior Member




Thick As A Brick


« Reply #34 - Posted 2004-01-08 16:00:32 »

Okay I must have screwed up yesterday. It is issue #57.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #35 - Posted 2004-01-09 06:59:02 »

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.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #36 - Posted 2004-01-09 12:46:38 »

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()  <- 2D
byte[] 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.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #37 - Posted 2004-01-09 15:39:57 »

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.

What about adding another set of methods to SceneGraphObject:

public void putMetaData(String key, String value)
public String getMetaData(String key)
public Iterator getAllMetaDataKeys()

Keys that are prefixed with "XITH3D" are keys added by the system. In the case of the file name a key XITH3DImageFileName, would be added to ImageComponents via the TextureLoader class automatically.

Keys without the above prefix are assumed to have specific meaning to a programmers application and the system never deals with them.

Again this has no impact on the renderer and allows me to store information in the XML output that may or may not have meaning to the Xith3D system as a whole.

Any thoughts?


Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #38 - Posted 2004-01-09 16:12:53 »

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

Yuri

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #39 - Posted 2004-01-09 16:46:49 »

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

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

public String userDataToString(Object userData);
public Object userDataToObject(String userData);

Then when writing if I come across a non-null userData object I can simply pass it to the implmenting class and let it give me back a string to place in the XML. Reverse for the read process.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #40 - Posted 2004-01-10 06:48:11 »

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

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #41 - Posted 2004-01-10 16:12:23 »

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?

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #42 - Posted 2004-01-10 16:39:39 »

Would be great if you can do that.

The suggested API can be:

1  
2  
3  
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.


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.

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #43 - Posted 2004-01-12 14:40:14 »

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.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #44 - Posted 2004-01-12 21:13:54 »

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.

Will.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #45 - Posted 2004-01-13 14:16:03 »

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

Offline zparticle

Senior Member




Thick As A Brick


« Reply #46 - Posted 2004-01-13 19:22:38 »

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

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #47 - Posted 2004-01-15 18:09: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.

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.

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

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #48 - Posted 2004-01-19 17:01:51 »

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

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #49 - Posted 2004-01-20 16:15:09 »

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

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #50 - Posted 2004-01-20 17:21:57 »

Quote

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.


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.

Offline Jens

Senior Member




Java for games!


« Reply #51 - Posted 2004-01-20 18:54:02 »

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

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline zparticle

Senior Member




Thick As A Brick


« Reply #52 - Posted 2004-01-20 20:47:34 »

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

    public void setColor(int vertexIndex, float[] floatArray) {
          assert floatArray.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.
     */

    public void setColor(int vertexIndex, float[] floatArray) {
          assert floatArray.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.
     */

    public void setCoordinate(int vertexIndex, float[] floatArray) {
          assert floatArray.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.
     */

    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.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #53 - Posted 2004-01-21 06:41:51 »

Quote
or am I totally messed up


zparticle, I am really sorry, but looks like...  Wink

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

    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:

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}.
     */

    public void setColors(int vertexIndex, float[] floatArray) {
          assert floatArray.length % colorSize == 0;
          colors.setFloats(vertexIndex*colorSize,floatArray);
    }


The same is for coordinates.

Yuri


Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #54 - Posted 2004-01-21 12:38:39 »

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

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.

Offline pedro

Junior Member




Java games rock!


« Reply #55 - Posted 2004-04-17 21:46:39 »

Quote


Note I'll worry about a version that outputs X3D XML format when I get this all working with my format.



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

Offline zparticle

Senior Member




Thick As A Brick


« Reply #56 - Posted 2004-04-17 22:38:16 »

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.

Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (30 views)
2014-09-21 02:42:18

BurntPizza (20 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (28 views)
2014-09-20 20:14:06

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!