Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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 6502 times)
0 Members and 1 Guest are viewing this topic.
Offline zparticle

Senior Member




Thick As A Brick


« Posted 2003-12-29 17:26:44 »

I have started work on input/output of Xith3D scenegraphs from/to XML format. It appears to be working well so far with the demo programs. I have a few questions:

1> Shared objects. What should I be looking for here. I need suggestions on how to handle shared data.

2> Texture image data. I was hoping there would be some way to tie the images in Textures to the TextureLoader however there doesn't appear to be a way to connect a Texture2D/3D object back to the image used in the TextureLoader. Any suggestions?

3> Currently I'm thinking about using base64 encoding to place the texture bytes into the XML. If I could get all of the texture image info (filename, directory, etc.) I could avoid including the data in the XML. Thoughts?

Below is the output from the CubeTest demo with the number of cubes reduced to 2 instead of 300.

edit: I know it is a bit hard to read, the forum screwed up the indenting.

EDIT: I REMOVED THE XML POSTS TO CLEAN UP THE THREAD.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #1 - Posted 2003-12-29 20:25:26 »

Interesting project.

As for shared objects , I don't know exactly what you mean by that (being the j3d/xith3d clewbie that I am  Smiley) so I might be totally off track here, but maybe you could use XPath expressions to reference other nodes in the XML where those shared objects are described?

Forget this post if I'm totally misunderstanding you  Grin

Erik

Offline Jani Laakso

Junior Member




Do it with Java!


« Reply #2 - Posted 2003-12-30 06:34:14 »

XML could be excellent for defining Xith3D shape's or transformgroup's physical attributes.
How about adding an physics extension for your XML?
For each object one could define:

1. identity (or name) of object

2. collision primitive(s)
-geometry data like sizex,y,z (e.g. box)
-local position (x,y,z)
-complex composite objects have multiple primitives

3. mass distribution
-e.g. simply mass size which is centered

4. surface parameters
-frictions, bounciness..

There should be also common physics XML definition for the world itself that contains e.g. gravity or common friction values etc. Also joint node's would be good, these bind two different objects to each other (e.g. leg to body) and define their attributes (how much can I move my leg related to my body) and so on.

After these definitions, not only Xith3D objects but also their physic engine objects could be created automatically using XML definition, both sides would be neatly in the same place.

Here's one thing I'd like to clarify for people that haven't used physic engines yet. Why to define primitives two times per object, once for scenegraph (Xith3D) and once for physics engine? Think for example a human, it's quite complex object for 3D renderer, but for physics engine it consists of a sphere (head), cylinders (neck, arms, legs) and a torso (box). As physics calculations are quite complex it's best to simplify objects as much as possible on the physics engine side.

The reason I am writing this is that I've been thinking of creating some kind of physics definition for Odejava project (physics engine for Java, based on ODE). This definition would be perfect place for this and XML sure is the right tool to accomplish this.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jacko

Junior Member





« Reply #3 - Posted 2003-12-30 11:06:42 »

My take on this would be that you would need some sort of generic resource loading. You would give it a list of directorys, zip files or whatever, and it would serve up files for you on demand. You could reference this in your xml.

A good idea of what i'm trying to say is in ogre, which reads a list of locations for files, models, textures, etc at start up.

Of course this means writing a resource loader, and your idea of what it should do is probably different to mine.
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2003-12-30 11:07:41 »

How about the classpath, and the Class loader?

Kev

Offline zparticle

Senior Member




Thick As A Brick


« Reply #5 - Posted 2003-12-30 13:53:25 »

Quote
1> Shared objects. What should I be looking for here. I need suggestions on how to handle shared data.


I was mainly worried about things like: GeometryTranslocator and SharedGroup which I don't really understand the implications/use of.

Quote

2> Texture image data. I was hoping there would be some way to tie the images in Textures to the TextureLoader however there doesn't appear to be a way to connect a Texture2D/3D object back to the image used in the TextureLoader. Any suggestions?


I think I can use the TEX_STATE_ID_SEQ member of the Texture class to identify textures that have been used across more than a single object. I will need to add a method to allow me to get the value, any objections?

It would be very handy if ALL objects had a common unique ID that could be referenced. It only needs to be readable. Can this get implemented, what issues might this cause? I think an interface that defines a single method "long getRuntimeUniqueID()" or somthing like that would be nice to implement in the low level classes.

Quote

3> Currently I'm thinking about using base64 encoding to place the texture bytes into the XML. If I could get all of the texture image info (filename, directory, etc.) I could avoid including the data in the XML. Thoughts?

Quote
My take on this would be that you would need some sort of generic resource loading. You would give it a list of directorys, zip files or whatever, and it would serve up files for you on demand. You could reference this in your xml.



Okay, I tried this and it simply isn't going to work with large textures. So I'm going to try to load the textures via the TextureLoader and the XML will only contain attributes not image data. The getSearchPath() method will allow me to store the image paths in the XML and register them during read. I still need one of two things:

1> Add a method to TextureLoader to allow me to get the file name (mean other mods to the class) of a texture based on either the TEX_STATE_ID_SEQ of a Texture object or the Texture object itself.

or

2> Add the file name information to the Texture class. I like this idea better, keep the the data with the object that it belongs to. Thoughts?

Quote


As for shared objects , I don't know exactly what you mean by that (being the j3d/xith3d clewbie that I am  Smiley) so I might be totally off track here, but maybe you could use XPath expressions to reference other nodes in the XML where those shared objects are described?
Erik


XPath is an iteresting idea, I'll take a look at it. Right now if I could get the unique ID mentioned in number 2 above the problem basically solves itself. I would traverse the graph and write out an entity for each object, keeping track of the unique IDs already written. Then traverse the graph again writing out the actually graph structure using only ID references to point to the original elements.

Quote
XML could be excellent for defining Xith3D shape's or transformgroup's physical attributes.
How about adding an physics extension for your XML?


Would be glad to if I knew anything about it, perhaps you could help on that side. I need to get the basic scene graph stuf working first though.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #6 - Posted 2003-12-30 14:45:00 »

It occured to me that I might be able to use the java.lang.Object.hashCode() method to get my unique object identifiers for the graph objects. This would remove the need for adding code to every object type. However the javadoc description has me a bit worried.

Quote

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)


Don't those two statements contradict each other? ALso look at this statement from the equals() method.

Quote

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.


Offline abies

Senior Member





« Reply #7 - Posted 2003-12-30 15:21:05 »

System.identityHashCode, not Object.hashCode. But it is not guaranteed to be unique. Comment about it being mostly unique due to being pointer address is not true in presence of copying garbage collector (which is a standard currently AFAIK).

Artur Biesiadowski
Offline zparticle

Senior Member




Thick As A Brick


« Reply #8 - Posted 2003-12-30 16:04:53 »

Yep that method will have the same problems, I have to have unique values. However I think I may have found another way around this.

Writting the XML File:

Run the graph and for each object:

0> init objectCount variable to 0
1> Check an Object[] to see if the object is in already in the array using the == operator to compare the memory addresses.
2> If the object is already in the array skip it, go to step 1.
3> If the object is not in the array add it to the array
4> Increment objectCount variable and add the value to an array called objectIDs in the same position as the object was added to the Object[]
5> Write the object to the file with the current value of the objectCount variable as its ID
6> Run the graph again to write the graph structure to the file.
7> For each object find the reference in the Object[] using == operator and get the ID from the objectIDs array in the same position.
8> Write simple XML element for the Object type that contains only the ID

Reading the XML:

0> Read each of the objects elements in and create the Xith3D objects adding the Object ref to an Object[] and the ID to a long[] objectIDs in the same positions.
1> Read the Graph structure in.
2> For each graph xml element get the Object reference fromt he Object[] by finding the ID in the objectIDs array and getting the reference from the same position in the Object[].
3> Do what ever processing is needed on the Object, for instance adding a Locale to the VirutalUniverse.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #9 - Posted 2003-12-30 16:59:46 »

Would it make since to write the XML out to multiple files?

I was originally thinking that I would write the entire graph out to a single file. Now I'm wondering if it makes more scence to split them like the following.

You supply a root name for the files, such as "landscape" and pass in the VirutalUniverse object that contains the graph. The code would then create:

landscape_graph.xml <- just the structure with references to the other files

landscape_type_n_name.xml

Where:
type is the Object type
n is the unique ID I create during graph traversal
name is the name attribute of the object if it is set

This would allow me to add methods to the reader/writter classes for reading/writing indiviual objects. This way you wouldn't have to create the entire scene graph from a file. You could for instance create a tree object write it to a single file by itself (actually possibly two or more files tree_shape3d_1_bigoak.xml and tree_texture2d_1_bigoakbark.xml) and use it in other projects by having the reader load it and pass you back the Shape3D object which you could then add to a dynamically created graph.

Another up side to this would be we would have a DTD to conform to for each object type.  This means a published "standard" format for programmers to use to write converters, for instance OBJ to Xith3D.


eidt: Something along the lines of http://www.xglspec.org/XGLHowTo.htm

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

Senior Member





« Reply #10 - Posted 2003-12-30 17:46:11 »

With xml you are already paying big performance penalty. But if you will split it to file per node, overhead of file/xml processing will be even bigger. Please keep it in mind - it would be bad to spend a lot of time only to later discover than non-trivial scene requires 10 minutes to deserialize...

Artur Biesiadowski
Offline zparticle

Senior Member




Thick As A Brick


« Reply #11 - Posted 2003-12-30 18:04:51 »

I see your point. I guess I'm wondering if splitting them up (and taking the perf hit) would give the Xith3D community an opportunity to create some really nice tools. For instance imagine the following scenario happening over the next couple of years:

1> The XML formats get defined and readers/writers are coded.
2> Someone creates a tool to allow you to visually create textures and write out the XML files using #1.
3> Texture libraries become commonly available because of #2.
4> Someone creates a tool to allow you to visually create appearance objects and write out the XML files using #1.
5> Appearance libraries become commonly available because of #4.
6> Someone creates a tool to allow you to visually create object geometry and write out the XML files using #1.
7> Geometry libraries become commonly available because of #6.
8> Someone combine the tools and we have a full fledge visual modeling environment to work with like Lighwave3D Modeler.

The key here, at least in my mind Smiley , is to break things into small enough pieces to allow small tools to be created quickly. Another interesting possible side effect might be loaders that function over the network.

I realize this is all "pie in the sky" stuff at this point. I'm simply trying to think through the implications of the possilbe design choices.

As always all ideas are welcome.

Offline abies

Senior Member





« Reply #12 - Posted 2003-12-30 19:09:40 »

I understand the idea, but I'm not sure if it is a way to go. We need following things - loaders for various formats, plus ability to serialize and deserialize scenegraph from/to xith3d. You seem to think about writing plugins for various programs which would allow them to output serialized version of scenegraph directly. Is it needed ? Loaders need to be written anyway, to work with legacy data, is there a reason to write separate plugin for each possible modelling program out there ?

I do not see major benefit of designing yet another public model format for xith3d. Tools out there work a lot better with their native formats. Scenegraph serialization is needed, because sometimes preprocessing/converting data takes a lot of time. But personally, I don't think that anything outside xith3d should be aware how this format looks like. I also don't think that backward/forward compatibility of file format is really needed. To achieve that, you would either need to abstract away xith3d internals (this creating generic scenegraph format and there are plently of them out there, most notably http://www.web3d.org/x3d.html, with java3d loader at http://www.web3d.org/TaskGroups/source/xj3d.html) or stop evolving xith3d in any major way.

I do see a need for one kind of xith3d-specific file format - this is model geometry which can be directly memmapped from disk. But this is certainly different thing from what you want to achieve, as it would be not portable even between bigendian and littleendian machines.

I suppose you have seen
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1070234282
? I'm not working on this now and I probably won't in future, as it is not needed for any on my possible projects, but there is a bit of discussion there you may find useful.


Artur Biesiadowski
Offline zparticle

Senior Member




Thick As A Brick


« Reply #13 - Posted 2003-12-30 19:28:52 »

Thanks, I actually hadn't seen that thread. Good stuff to think about.


Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #14 - Posted 2003-12-31 08:07:25 »

Almost missed this thread...

OK, I was already using XML to dump Xith3D scenegraph to file, but this was never intended to act as serialization/deserialization, but was a kind for debugging tool used to visualize actuial programmatically-constructed scenegraph in XML viewer.

The idea was to get an easy overview of the scenegraph in human-readable format.

Quote
I was mainly worried about things like: GeometryTranslocator and SharedGroup which I don't really understand the implications/use of.


GeometryTranslocator is lamost nothing different than Shape3D with actual geometry constructed at run-time basing on reference geometry and set of transform groups.

For SharedGroup, it always accessible via Links, and should act as any other shared object (texture, appearance, etc.)

As of object identification, you can use scenegraph path concept to identify any piece of scenegraph. Think about groups as indexed arrays of their childs, and node components as attributes [which may also have attributes]. In this case you can serialize the 1st occurence of node/component in-place, mark it, and for all subsequent occurences place references in form of path, like
coloring=root.childs[2].childs[1].childs[2].appearance.coloring

Yuri


Yuri Vl. Gushchin
JProof Group
Offline abies

Senior Member





« Reply #15 - Posted 2003-12-31 09:04:49 »

Quote
In this case you can serialize the 1st occurence of node/component in-place, mark it, and for all subsequent occurences place references in form of path, like
coloring=root.childs[2].childs[1].childs[2].appearance.coloring

Maybe XPath can be used ? It was designed exactly for that reason
http://www.w3.org/TR/xpath

/root/childs[2]/childs[1]/childs[2]/appearance/coloring

small change and you could be compatible with another standard (which has an benefit of being able to use already written libraries for parsing/searching xml).

I would personally suggest sticking to numbers Smiley Simple implementation, easy to check and search in file by hand without counting children order, IMHO faster to save and load.

Artur Biesiadowski
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #16 - Posted 2003-12-31 09:18:16 »

As of numbers, in case of human-readable forms, I would prefer to stay with names (even for child indexes within the groups), so xml then can be human-editable (not only readable).

XPath is exactly thing I had in mind.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline abies

Senior Member





« Reply #17 - Posted 2003-12-31 09:37:43 »

Quote
As of numbers, in case of human-readable forms, I would prefer to stay with names (even for child indexes within the groups), so xml then can be human-editable (not only readable).


Exactly for the reason of human editability, numbers are better way Smiley

Imagine situation where you have 20 groups below the root. Now you want to delete one of these groups by hand, by just deleting entire node with subnodes. Simple ? Not, because in every group after your current one, you need to renumber child number by one down. With numbers, you don't care - they will be just not continious now, which is not a problem.

Do you want to add another node ? With numbers, you can add it anywhere, with paths it has to be at end - but it can be done. But now imagine that you have found geometry data you want to duplicate. With numbers, you just copy/paste it's id number. With path, you need to go from geometry to root, counting every subnode and determining at what place it is in group, constructing long and typo-prone string.

Additionally, if you allow string ids (with number ones being just a special case for automatic generation of missing ones), it becomes even more clear - "AppearanceGoldMetal" is a lot better than  "/root/childs[2]/childs[1]/childs[2]/appearance". But even with just integers, it is IMHO a lot easier to find 82378912 with editor in file to see appearance data then to count childs[2]/childs[1]/childs[2].

All this is just about hand editing, which IMHO is not a design criterium which is important, but IF it is, then I would suggest going for at least integer ids and even better string ids.

Artur Biesiadowski
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #18 - Posted 2003-12-31 10:23:09 »

Actually, the question we are discussing is just namespace/aliasing question. As in Java, system may allow accessing children either by path or by alias. The basic idea behind path concept was to be able to define shared node in-place, nested into other components, and be able to reference to it.

But all of this introduces additional complexity, and maybe it makes sense to look at X3D (XML-based alternative for VRML), and maybe just dump Xith3D scenegraph to X3D-compatible document.

See http://www.web3d.org/x3d.html for more details. Also I know they were working on Xj3D, Java3D-based player for X3D, so porting it to Xith3D would be really nice and practical step for wider Xith3D recognition as possible replacement for Java3D.

Yuri

P.S. I was not visiting that site for relatively long time and now recognized that X3D already promoted to be ISO standard as ISO/IEC 19775:200x, 19776:200x, 19777:200x.

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #19 - Posted 2003-12-31 20:33:39 »

Okay I've got the first version working with shared objects. What I need to know now is which of the following list of objects should be able to be shared. I'm sure there isn't anything in Xith3D stopping any of them but I want the XML to produce something that isn't "wrong".

The items that have "true" next to them are the objects I currently have picked as sharable.

//------------------------------------
// com.xith3d.scenegraph.Leaf
//------------------------------------
AlternateAppearance true
Background
Behavior
BoundingLeaf true
Clip true
ExponentialFog
LinearFog
Foreground
AmbientLight
DirectionalLight
SpotLight
PointLight
Link
Morph
OrientedShape3D true
Shape3D true
BackgroundSound
PointSound
Sound
//------------------------------------
// com.xith3d.scenegraph.Group
//------------------------------------
UIPositionedWindow
UIWindowManager
BranchGroup
DecalGroup
OrderedGroup
SharedGroup
Switch
View
TransformGroup true
Group
//------------------------------------
// com.xith3d.scenegraph.Locale
//------------------------------------
Locale
//------------------------------------
// com.xith3d.scenegraph.NodeComponent
//------------------------------------
Appearance true
ColoringAttributes true
DepthComponentFloat true
DepthComponent true
LineStripArray true
TriangleFanArray true
TriangleStripArray true
IndexedLineStripArray true
IndexedTriangleStripArray true
IndexedLineArray true
IndexedQuadArray true
IndexedTriangleArray true
IndexedTriangleFanArray true
LineArray true
PointArray true
QuadArray true
Billboard true
TriangleArray true
GeometryTranslocator true
GeometryArray true
Raster
ImageComponent2D true
ImageComponent3D true
LineAttributes true
Material true
MediaContainer
PointAttributes true
PolygonAttributes true
RenderingAttributes true
TexCoordGeneration true
Texture2D true
Texture3D true
TextureAttributes
TextureUnitState
TransparencyAttributes true
//------------------------------------
// other scene graph objects
//------------------------------------
BoundingBox
BoundingPolytope
BoundingSphere
Transform3D true
TextureLoader

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

You will be able to produce XML starting any place in the graph. This means you could produce an entire scene graph or specialized pieces like, Shape3Ds, Lights, Appearances, Textures.

You have the choice of inlining all objects or making them shared. Shared produces much smaller files when you have objects used in more than one location in the graph.


Offline zparticle

Senior Member




Thick As A Brick


« Reply #20 - Posted 2003-12-31 20:40:53 »

The following is output from the AmbientLightingTest example. Object inlining is turned off (looks for shared objects in the graph and produces references to them).

The BaseObjectReference element contains all of the potentially shared objects. Each of them has an objrefid attribute that uniquely identifies the object. Shared objects can reference any other shared object that exists above it in the file. To use a shared object the ObjectReference element is used.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
<?xml version="1.0" encoding="UTF-8"?>
<VirtualUniverse>
  <TextureLoader searchpath=".\;..\;"/>
  <BaseObjectReference>
    <PolygonAttributes cullface="0" polygonmode="2" polygonoffset="0.0"
      polygonoffsetfactor="0.0" duplicateonclonetree="false"
      capbits="{}" islive="false" name="" objrefid="0"/>
    <Appearance duplicateonclonetree="false" capbits="{}" islive="false"
      name="" objrefid="1">
      <ObjectReference id="0"/>
    </Appearance>
    <QuadArray duplicateonclonetree="false" capbits="{}" islive="false"
      name="" objrefid="2">
      <CoordinateData setindex="0" setcount="10" totalcount="12"
        commoninitialindex="0" data="-0.099999994,-0.70000005,0.0,-0.099999994,-0.099999994,0.0,-0.70000005,-0.099999994,0.0,-0.70000005"/>
      <CoordinateData setindex="1" setcount="2" totalcount="12"
        commoninitialindex="0" data="-0.70000005,0.0"/>
    </QuadArray>
    <Shape3D passid="0" ignorebounds="false" iscollidable="true"
      boundsautocompute="true" showbounds="false" isoccluder="false"
      pickable="false" renderable="true" capbits="{}" islive="true"
      name="" objrefid="3">
      <ObjectReference id="1"/>
      <ObjectReference id="2"/>
      <BoundingSphere radius="0.42426413" center="-0.40000007,-0.40000007,0.0"/>
    </Shape3D>
    <ColoringAttributes color="1.0,0.0,0.0" shademodel="3"
      duplicateonclonetree="false" capbits="{}" islive="false" name="" objrefid="4"/>
    <PolygonAttributes cullface="0" polygonmode="2" polygonoffset="0.0"
      polygonoffsetfactor="0.0" duplicateonclonetree="false"
      capbits="{}" islive="false" name="" objrefid="5"/>
    <Appearance duplicateonclonetree="false" capbits="{}" islive="false"
      name="" objrefid="6">
      <ObjectReference id="4"/>
      <ObjectReference id="5"/>
    </Appearance>
    <QuadArray duplicateonclonetree="false" capbits="{}" islive="false"
      name="" objrefid="7">
      <CoordinateData setindex="0" setcount="10" totalcount="12"
        commoninitialindex="0" data="0.70000005,-0.70000005,0.0,0.70000005,-0.099999994,0.0,0.099999994,-0.099999994,0.0,0.099999994"/>
      <CoordinateData setindex="1" setcount="2" totalcount="12"
        commoninitialindex="0" data="-0.70000005,0.0"/>
    </QuadArray>



[edit] removed the rest of the xml post to clean up the thread

Offline zparticle

Senior Member




Thick As A Brick


« Reply #21 - Posted 2004-01-01 16:32:31 »

One note for the future: In order to tell if an object is shared in the graph it is necessary to have acces to the objects handle so methods like:

void getLeftProjection(Transform3D transform3D)

in the View class prohibit the ability to determine if the Transform3D object is shared because the internal object is being coped to the passed object.

Offline abies

Senior Member





« Reply #22 - Posted 2004-01-01 21:32:22 »

Quote
One note for the future: In order to tell if an object is shared in the graph it is necessary to have acces to the objects handle so methods like:

void getLeftProjection(Transform3D transform3D)

in the View class prohibit the ability to determine if the Transform3D object is shared because the internal object is being coped to the passed object.


There are two schools of accessing objects - direct (return pointer to internal object and on set, just change pointer) and java3d-like (perform copy on set and allow only by-value copy getter). In first case, you can check for sharing, in second case, there is no such thing as sharing in fact, because even if you pass same pointer to many objects, data will be copied to internal strucure anyway.

Mess starts when direct setter is used in conjuction with java3d-like getter - and this is only case where IMHO code should be refactored. getLeftProjection is not implemented currently Smiley, so it is not a problem - but it is enough to implement setLeftProjection to copy parameter to avoid problem with sharing.

Artur Biesiadowski
Offline zparticle

Senior Member




Thick As A Brick


« Reply #23 - Posted 2004-01-04 17:29:23 »

Help, *snif*.  

The reading/writing from/to xml is working nicely now. I can manually create a graph write it to disc read it in and write it back to disk in another file and both files are identical and all objects are getting displayed.

However I have a problem, textures aren't working. When I load a graph, for instance the CubeTest, everything appears to be getting created and assigned but the texture isn't displayed.

To create a texture I do the following:

Create a new Texture2D object using the Texture2D() constructor.

For each ImageComponent sub-element in the XML create a new object using ImageComponent2D(int format, int width, int height, BufferedImage image).

The image I pass in is created by TextureLoader.getScaledImage(BufferedImage origImage, int width, int height, int method) whwre method is set to SCALE_DRAW_BEST.

For I add each of the ImageComponents to the Texture2D object using the setImage(int level, ImageComponent image) method to place the correct scaled image at the correct level.

Finally set all of the attributes of the Texture2D object using the setter methods.

Anyone have any idea where I should look to find the problem?

Obviously I'm doing doing something wrong. Is there a huge difference between doing it this way and using the TextureLoader.loadTexture methods? I need to create the ImageComponent object separately because you can manually set each level, I can't assume they all use the same image.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #24 - Posted 2004-01-05 08:24:36 »

Quote
Is there a huge difference between doing it this way and using the TextureLoader.loadTexture methods?


Would be better to look at the source code, so if you put together simple test case, we can check.

I personally use both TextureLoader and own texture creation mechanisms, and both work quite well for me.

Only thing you should take care that you have to use DirectBufferedImage to pass image data to ImageComponent:

1  
2  
3  
4  
5  
6  
7  
8  
9  
// pw and ph are image width and height
BufferedImage src = ...;
BufferedImage dst = DirectBufferedImage.getDirectImageRGB(pw, ph);
Graphics2D g2 = (Graphics2D) dst.getGraphics();
g2.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BICUBIC);
g2.setRenderingHint(RenderingHints.KEY_ALPHA_INTERPOLATION, RenderingHints.VALUE_ALPHA_INTERPOLATION_QUALITY);
g2.drawImage(src, 0, 0, pw, ph, null);
g2.dispose();
return dst;


Yuri

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #25 - Posted 2004-01-05 12:45:13 »

Thanks for the info, as it turned out I was using the wrong method to set the texture coordinates on the GeometryContainer objects.

For anyone that is interested the current code is in the following zip file.

http://www.scottshaver2000.com/files/sgxith.zip

The file contains the src and demo directories (no image/sound files). I had to make a number of minor modifications to the Xith code to make this work. All changes are marked with a comment that looks like this:

// TODO SAS

Most of the classes in com.xith3d.test have been modified to write the scene graph out to disk in the current directory.  The filename will be that of the test class minus the "Xith3D" prefix. So if you run Xith3DAmbientLightTest.bat from the demo directory you will end up with a file named AmbientLightTest.xml in the demo directory.

For some of the classes I have added a sister class that will read in the xml file, creating a scene graph, write the scene graph out to a second file and then show the loaded graph.

So for Xith3DAmbientLightTest there is a sister class Xith3DAmbientLightReadTest which will produce AmbientLightTest2.xml. I have added batch files in the demo directory for these new classes as well.

There are still some issues I need to deal with but things seem to be working for the most part. I would be insterested to hear from someone with a scene graph that is more complicated than the demo classes.

Have fun.

BTW the code in the zip file is based on the code from the Xith3D_2003-12-23_cvs.tar.gz file.

***EDIT*** Noe that this code is dependant on the Xerces project classes. The old version of Xerces will work and the batch files included in the zip look for it in the third-party directory as xerces.jar.

The new Xerces2 jars can be used if you change the runtest.bat file to include  ../third-party/xmlParserAPIs.jar;../third-party/xml-apis.jar;../third-party/xercesImpl.jar in the classpath.

These can be downloaded at http://www.apache.org/dist/xml/xerces-j/binaries/Xerces-J-bin.2.6.0.zip.

Warning that download is pretty big but the jar total only about 1 meg.

Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #26 - Posted 2004-01-05 13:38:57 »

Any plans to put this to xith-tk?

Yuri

Yuri Vl. Gushchin
JProof Group
Offline zparticle

Senior Member




Thick As A Brick


« Reply #27 - Posted 2004-01-05 13:50:13 »

I figured you folks would decide where you want it to go (if you want it at all) after you looked at the code. I don't have a place I can use CVS from currently as I don't have a personal inet connection anymore.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #28 - Posted 2004-01-07 12:29:02 »

even if you don't put it in the xith-tk you can still list it in the "file sharing area".

Of course I think it'd be nice to see all code in CVS but like yourself, not everyone has convenient CVS access.

The reason it's nice to have it there is because it's a central location where people know where to look.

Will.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #29 - Posted 2004-01-07 15:12:44 »

Well there isn't much point in placing it in he file sharing section until someone can make the minor "fixes" I had to make to the code in the Xith project.

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.

pw (18 views)
2014-07-24 01:59:36

Riven (17 views)
2014-07-23 21:16:32

Riven (14 views)
2014-07-23 21:07:15

Riven (17 views)
2014-07-23 20:56:16

ctomni231 (45 views)
2014-07-18 06:55:21

Zero Volt (40 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (36 views)
2014-07-16 23:30:00

Cero (51 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!