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 (532)
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  
  Xith vs jME  (Read 11138 times)
0 Members and 1 Guest are viewing this topic.
Offline dranonymous

Junior Member




Hoping to become a Java Titan someday!


« Posted 2004-09-15 04:37:58 »

Can someone cover some of the differences between the two scene graphs?

I like both web sites and they both look like great APIs.  When the time comes to use a scene graph, I don't want to dabble, I'd rather really commit to learning one or the other.

I don't want to know which is better, as I'm sure they both have the strengths.

Regards,
Dr. A>
Offline cep21

Junior Member




Java games rock!


« Reply #1 - Posted 2004-09-15 04:46:36 »

They both have strenghts.  My advice, look at the starter guide for jME at their web page.  Look at how the code is structured.  Go through about 2-3 programs.  Then look at the Xith3D starter guide at their web page.  Look at their code structure.  Go through about 2-3 programs.  Pick the API who's code feels more natural for you.

That's about as unbias as I can be Smiley
Offline abies

Senior Member





« Reply #2 - Posted 2004-09-15 10:18:56 »

Xith3d API is based on java3d, so if you have experience in it, you can start coding almost straight away. Other than that, jME is probably a bit easier to grasp for beginner.

As far as internals are concerned, xith3d state management/sorting is a more sophisticated at the moment, so there is a chance you might get better performance - but this comes at cost of less trivial library code, so changes are rather harder.

Xith3d is a more complete currently, but jME is a lot more active.

jME contains a bit more things inside - while xith3d is mainly visualisation api (game oriented, but focused on graphics/3d world), jME seems to extend in other areas with more game engine functionality outside this area. You have to decide if you want AI routines bundled in same package - there are pros and cons to this.

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

Senior Member




Go Go Gadget Arms


« Reply #3 - Posted 2004-09-16 14:58:28 »

the AI routines will never be incoorporated into the same package as jME. They will be a seperate jar to download. So if you feel you cant be bothered to write your own AI routines/library, you can use jME's which integrates nicely into jME.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline VeeJay

Senior Newbie




Java games rock!


« Reply #4 - Posted 2004-09-17 02:42:49 »

Hi there,

I tested last release version of Xith using latest JOGL against JME 0.7 using LWJGL 0.9, the test consisted of loading 600000 triangles of geometry with one light source. Xith rendered around 16fps, while jME was giving me 4-5fps.  

Tested on GF4600Ti Athlon 1800, Java 1.4.2 and 1.5b
     
Offline cep21

Junior Member




Java games rock!


« Reply #5 - Posted 2004-09-17 03:10:44 »

I'ld be interested in seeing the source code.
Offline SpuTTer

Senior Member


Medals: 1


Lazy Middle Class Intellectual


« Reply #6 - Posted 2004-09-17 06:32:02 »

I'd like to see the source as well!

Sacramento Volleyball
"Whitty phrase goes here."
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #7 - Posted 2004-09-17 17:48:11 »

Screen shots from similar vantage points might also be interesting.

We've recently added a few things in CVS that would give jME a nice  in scenesgraphs with many objects, if your scene is one mesh of 600,000 tris...  well is that normal for games?  Even so, we haven't run into that situation much yet so there's probably room for good improvements.

Renanse  (ruh-NON-say)
Offline VeeJay

Senior Newbie




Java games rock!


« Reply #8 - Posted 2004-09-18 02:24:30 »

Hi,

Xith:



JME



The model has around 30000 polygons, I was experimenting with large models coz I am working on a visualization system that will have high res models.

I can't provide the source code for the Xith demo coz it is big, but it is pretty much the same concept as the jME test, I loaded all the objects in to the scene graph, added one light source and moved the camera. Xith objects were loaded from 3DS file while on jME side I used MilkShape loader. I have coded my own camera movement in Xith app, while on jME side I used the default stuff.

I just found that I used Spot Light in Xith, and Point Light in jME, could that make such a big difference?

and here is a jME code...

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  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
public class TestMilkLoader extends SimpleGame{
    public static void main(String[] args) {
        TestMilkLoader app=new TestMilkLoader();
        app.setDialogBehaviour(ALWAYS_SHOW_PROPS_DIALOG);
        app.start();
    }

    // The new loader
   protected void simpleInitGame() {
        //  Idealy this could be replaced by
       // Loader mi=new AutoCadLoader(); ect
       LWJGLCullState s = new LWJGLCullState();
        Loader mi=new MilkLoader();
        //mi.setLoadFlag(Loader.LOAD_CONTROLLERS);
       mi.setLoadFlag(Loader.PRECOMPUTE_BOUNDS);
        URL MSFile=TestMilkLoader.class.getClassLoader().getResource(
        "jmetest/data/model/msascii/body.ms3d");
        mi.setBase(TestMilkLoader.class.getClassLoader().getResource(
        "jmetest/data/model/msascii/"));
        Node mi1=mi.load(MSFile);
        //mi1.setLocalScale(.1f);
       //mi1.getController(0).setSpeed(10f);
//        ((MilkAnimation) mi1.getController(0)).setSkipRate(.01f);
       rootNode.attachChild(mi1);
        s.setCullMode(CullState.CS_BACK);
        s.setEnabled(true);

        Node mi2=mi.load(MSFile);
        Node mi3=mi.load(MSFile);
        Node mi4=mi.load(MSFile);
        Node mi5=mi.load(MSFile);
        Node mi6=mi.load(MSFile);
        Node mi7=mi.load(MSFile);
        Node mi8=mi.load(MSFile);
        Node mi9=mi.load(MSFile);
        Node mi10=mi.load(MSFile);
        Node mi11=mi.load(MSFile);
        Node mi12=mi.load(MSFile);
        Node mi13=mi.load(MSFile);
        Node mi14=mi.load(MSFile);
        Node mi15=mi.load(MSFile);
        Node mi16=mi.load(MSFile);
        Node mi17=mi.load(MSFile);
        Node mi18=mi.load(MSFile);
        Node mi19=mi.load(MSFile);
       
       
        mi19.setLocalTranslation(new Vector3f(0,0,-360));
        mi18.setLocalTranslation(new Vector3f(0,0,-340));
        mi17.setLocalTranslation(new Vector3f(0,0,-320));
        mi16.setLocalTranslation(new Vector3f(0,0,-300));
        mi15.setLocalTranslation(new Vector3f(0,0,-280));
        mi14.setLocalTranslation(new Vector3f(0,0,-260));
        mi13.setLocalTranslation(new Vector3f(0,0,-240));
        mi12.setLocalTranslation(new Vector3f(0,0,-220));
        mi11.setLocalTranslation(new Vector3f(0,0,-200));
        mi10.setLocalTranslation(new Vector3f(0,0,-180));
        mi9.setLocalTranslation(new Vector3f(0,0,-160));
        mi8.setLocalTranslation(new Vector3f(0,0,-140));
        mi7.setLocalTranslation(new Vector3f(0,0,-120));
        mi6.setLocalTranslation(new Vector3f(0,0,-100));
        mi5.setLocalTranslation(new Vector3f(0,0,-80));
        mi4.setLocalTranslation(new Vector3f(0,0,-60));
        mi3.setLocalTranslation(new Vector3f(0,0,-40));
        mi2.setLocalTranslation(new Vector3f(0,0,-20));
//        ((MilkAnimation) mi2.getController(0)).setSkipRate(.05f);
//        mi2.setLocalScale(.5f);
       rootNode.attachChild(mi2);
        rootNode.attachChild(mi3);
        rootNode.attachChild(mi4);
        rootNode.attachChild(mi5);
        rootNode.attachChild(mi6);
        rootNode.attachChild(mi7);
        rootNode.attachChild(mi8);
        rootNode.attachChild(mi9);
        rootNode.attachChild(mi10);
        rootNode.attachChild(mi11);
        rootNode.attachChild(mi12);
        rootNode.attachChild(mi13);
        rootNode.attachChild(mi14);
        rootNode.attachChild(mi15);
        rootNode.attachChild(mi16);
        rootNode.attachChild(mi17);
        rootNode.attachChild(mi18);
        rootNode.attachChild(mi19);
       
        //rootNode.attachChild(new Box("axisX",new Vector3f(5,0,0),5f,.1f,.1f));
       //rootNode.attachChild(new Box("axisY",new Vector3f(0,5,0),.1f,5f,.1f));
       //rootNode.attachChild(new Box("axisZ",new Vector3f(0,0,5),.1f,.1f,5f));
       rootNode.setRenderState(s);

    }
   

and there you go...
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #9 - Posted 2004-09-18 03:29:20 »

Ah, well are the models static or animated?  I'm not sure how/if Xith handles this, but I would recommend enabling VBO support in jME.  We ran into a similar thing with large terrains running at 40-45 FPS and then developed VBO support and saw that number jump up to 300-400 FPS.  I'd be happy to help you fix that up if you like...  Also, you might think about converting your .ms3d file to a .jme file prior to execution for quicker loading (won't likely affect FPS, but the jme loader is easier to use and easier to enable features with.)

Renanse  (ruh-NON-say)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #10 - Posted 2004-09-18 03:32:22 »

One other thing, if your model is something you are willing to share, I'd love to get a copy to use for stress testing and general improvement of jME.  

Regards.

Renanse  (ruh-NON-say)
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #11 - Posted 2004-09-18 11:04:58 »

Could you please run the jME program in fullscreen and see what FPS you get? Cause on my card, i see a ~100FPS jump when I switch to fullscreen.

Also, in jME, with a poly count that big, you would generally use LOD on the furthurest models to decrease Polycounts and hence increase FPS.

The uses of Xith and jME are different so it is hard to test both. E.g. We use TriMesh, but I know Xith has a CompositeMesh which triangle strips/fans can reduce the number of calculations down.

So you might be using different methods to do the same thing, one being more advantageous over another.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline VeeJay

Senior Newbie




Java games rock!


« Reply #12 - Posted 2004-09-18 21:50:49 »

Hi,

Quote

I'd be happy to help you fix that up if you like...  


Sure, I need 100% static geometry so it would be great if you can give me a hint on how to use VBO, I also suspected that this will improve speed a lot.

Quote

One other thing, if your model is something you are willing to share, I'd love to get a copy to use for stress testing and general improvement of jME.  


yes you can get a copy of it, I am willing to share it for the purposes of testing

Quote

Could you please run the jME program in fullscreen and see what FPS you get?


Just tested running in fullscreen but got exactly the same results

Quote

Also, in jME, with a poly count that big, you would generally use LOD on the furthurest models to decrease Polycounts and hence increase FPS.


Well, my point was, jME has all the LOD tools, while Xith has only switch node, which has some problems as I read in Xith forum. I just wanted to compare raw rendering speed. I definetely like LOD stuff in JME but still I will have large polycounts (maxing at 300K with LODs) since I am not building a game.


Offline cep21

Junior Member




Java games rock!


« Reply #13 - Posted 2004-09-18 22:39:19 »

Email me the model you're using.  I wrote the ms3d loader so I may be able to debug if there's something that needs it.  I'ld only use the model for testing.  There's a newer version of the loader in the current CVS.  cep221atgmaildotcom


PS:  Is it just me, or do the jME models look way, way better?  I guess it's the lighting direction.
Offline Badmi

Senior Newbie




Java games rock!


« Reply #14 - Posted 2004-09-19 02:51:09 »

JME contains many ways to improve the fps including impostere and lod (I do not know about Xith3D). If you are considering witch engine to use take this into account.
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #15 - Posted 2004-09-19 09:06:43 »

I've not use jME (I intend to at some point soon). I have however used Xith quite a bit. jME appears to be more feature rich although most features are bespoke to certain types of games.

jME does seem to be more targeted towards first person shooters (at least thats my perception looking at the feature list). Xith was originally attempting to be more generic (a la Java3D).

The main point I've seen as an issue so far is the superb HUD support in jME and the lack of anything reliable or decent in Xith (the original overlay stuff is unpredictable at best). However, I've just seen that work has started on providing a HUD system for Xith.

In short I don't know, but I thought the viewpoint might be useful.

Kev

PS. I suspect the models are absolutely identical Smiley I would say that tho.

Offline Jens

Senior Member




Java for games!


« Reply #16 - Posted 2004-09-19 09:59:58 »

Quote
jME does seem to be more targeted towards first person shooters (at least thats my perception looking at the feature list). Xith was originally attempting to be more generic (a la Java3D).


I'd say Java3D is still more generic than Xith3D. Java3D is targeted towards all kinds of 3D simulations, whereas Xith3D concentrates more on games (it's thread unsafe, uses only floats, doesn't use capabilities, ...), which leads to a better performance.

It would be good to have people using both, Xith3D and jME, so they can provide feedback of the strengths and weaknesses of both APIs. Maybe some kind of official "project goal comparision" would be helpful.

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

Senior Member




Go Go Gadget Arms


« Reply #17 - Posted 2004-09-19 15:06:16 »

I know a couple of people who have made RTS games with jME. OutRunner, if your outhere (hehe), show em your RTS Game.

Im making a Hitman type game. So really, you can do everything in jME  Grin

PS. I agree that we should have some sort of official comparison between the two. ChrisM might do it, he is as unbiased as they come  Wink

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2004-10-13 11:47:28 »

I tried, pretty hard, to get some people to write up biased articles on their particular engine about 6 months ago. I was then going to work with a couple of less-biased people to mesh these into a series of unbiased articles. The problem with starting out writing unbiased articles is you end up only covering the highest common factor - which is useless to games programmers. I knew I could trust myself to be impartial IF I had the evidence/facts from biased people in front of me (because I could check everything they said!), and I know a couple of people around here who have shown their ability and willingness to be impartial already - and who have useful real experience with using some or all of these 3D engines.

OK, so it was a miserable failure. All I ever achieved was to get a short article from Cas on LWJGL (too short, sadly - needed more biased details. I was surprised he was so unevangelical - he must have been tired or something Wink).

So. Chalk that one up to experience.

....

Here's another idea, which I suspect will work MUCH better: having thought about it, I wondered what I'd do if I were an expert in each engine already and able to write the entire review series myself. Ummm...aha! Unit tests! Use cases!

The *users*, between us, should be able to work out a series of small independent tests - much like the demos that already exist for each API. The API authors / most prolific users then have to code up those tests. It would be best if they could do two versions of each - one which is just the "off the top of my head, not trying to be clever" and then one which "optimizes performance, and perhaps cheats a little here and there" (e.g. in the screenshots in this thread the plain version would have to render all those polys, and the optimized version could use LOD to its heart's content). This answers two of the most common questions:

 - How easy is it to do X in Y (don't care about speed, just as long as it displays correctly)?
 - How fast is it *possible* to do X in Y using optimizations etc?

I'm too busy to do much on this myself right now, but...I'd suggest the following list for starters (would like to cross-post to Xith forums...):

- a Terrain demo, plain multicoloured shaded polygons, fills the view window mostly to the horizon
- ditto, but with blended textures (no harsh edges when texture changes from one to another)

- a clone of the nVidia ToySoldiers (very large number of identical models loaded at  once, all animated in lock-step - i.e. under the hood ought to be using onboard T&L etc, as well as testing the SG's culling effectiveness)
- ditto but with each model in a different state of animation at the same time (c.f. what happens when the robot appears in the NV demo - they scatter and are no longer in lock-step, so their polygons are no longer identical)

- a 3D maze, from 3rd person floating perspective, with a model running around it at random, and a simple HUD overlayed on top, showing various things
- ditto, with a detailed HUD and lots of models running around it (these simple tests would expose current known problems in Xith's HUD/Overlay system)

...etc. Of course, each test needs MUCH more detailed descriptions than that, with a checklist of requirements, and precise dimensions, and actual model files and texture files, to make for fair comparisons (and to make implementation easy!).

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #19 - Posted 2004-10-13 12:01:51 »

I have a feeling this might go the same way as the last idea simply because its too much like hard work Wink

Shame JCD isn't still active round here, he'd love to sit and write the same demo over and over in Xith and JME. After all, didn't he do just that for the Xith vs Java3D comparison?

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2004-10-13 13:11:31 »

Quote
I have a feeling this might go the same way as the last idea simply because its too much like hard work Wink


But...surely not!

The test cases can be invented by anyone who has a decent grasp of what they'd like to do in a game, and then they can be implemented by any user of the API - each could easily be written by a differnet person (a la NeHe conversions to JOGL. LWJGL, etc).

The individual tests themselves are pretty trivial - they should be typically hardly any more complex than the demos that each engine already has and maintains, but the advantage is that they come from a common root, allowing an (approximate) like for like comparison (which is what no-one has access to right now).

I agree the best thing to make sure this happened would be to define a couple and implement them myself for one API, and I'm sure other people would then say "what the heck" and have a go at doing it for their own API...but, sadly, I'm too busy.

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #21 - Posted 2004-10-13 13:29:24 »

Unfortunately I think most everyone else is also too busy for this sort of task. There just always seem to be more important tasks at hand.

Tcomparison to the NeHe ports, no disrespect to the providers (of what I'm sure is a fundamentally useful resource), however they're a trivial (in terms of engineering) porting exercise in comparison to developing the sort of demos you're talking about.

As to the validity of these things as a benchmarking tool after development while I don't think there is any reason to believe that there would be anything wrong with them they'd never be kept up to date with the latest developments in the APIs or be 100% understood and accepted.

I applaud the thought and the intent but doubt the action.

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #22 - Posted 2004-10-13 14:18:45 »

Quote
As to the validity of these things as a benchmarking tool after development


Perhaps this explains our different perspectives a little - I'm not thinking of benchmarking as being part of the purpose (despite references to making versions tuned for performance) but instead ONLY thinking of using them as a comparison for people trying to appreciate the differences as potential users.

For instance, 10 minutes looking at JOGL code side-by-side with LWJGL code to do the same kind of thing is enough for a lot of people to quickly decide which one they want to use. In that case it's easier because you're only considering low-level differences, e.g. method-signatures etc. You either see C syntax and think "yes! Want that!" or you see a more OOP approach to OGL and have similar thoughts (both of those being aspects that leap out at you as soon as you get the code in front of your eyes).

But right now we can only compare apples to oranges with X and J etc - there are no "common" cases Sad.

malloc will be first against the wall when the revolution comes...
Offline cep21

Junior Member




Java games rock!


« Reply #23 - Posted 2004-10-13 15:59:32 »

Rotation and helloworld is in both the jME and Xith3d starter guides.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #24 - Posted 2004-10-13 17:17:20 »

Quote
Rotation and helloworld is in both the jME and Xith3d starter guides.


Um...is that meant to be a joke? Huh Isn't that a bit like saying "1 + 1 looks the same in both java and C" when trying to decide which language to use?

malloc will be first against the wall when the revolution comes...
Offline cep21

Junior Member




Java games rock!


« Reply #25 - Posted 2004-10-13 19:25:36 »

It's not a joke.  They look absolutely nothing alike and is exactly like the example you gave.


" For instance, 10 minutes looking at JOGL code side-by-side with LWJGL code to do the same kind of thing is enough for a lot of people to quickly decide which one they want to use. In that case it's easier because you're only considering low-level differences, e.g. method-signatures etc. You either see C syntax and think "yes! Want that!" or you see a more OOP approach to OGL and have similar thoughts (both of those being aspects that leap out at you as soon as you get the code in front of your eyes). "
Offline cep21

Junior Member




Java games rock!


« Reply #26 - Posted 2004-10-13 19:33:18 »

They aren't exact duplicates but they are close.  I think it's a good idea blahx3 what you're proposing.  I was just saying there's already a few like that out now.

HelloWorld in the jME starter guide:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
import com.jme.app.SimpleGame;
import com.jme.scene.shape.Box;
import com.jme.math.Vector3f;

/**
 * Started Date: Jul 20, 2004<br><br>
 * Simple HelloWorld program for jME
 *
 * @author Jack Lindamood
 */

public class HelloWorld extends SimpleGame{
    public static void main(String[] args) {
        HelloWorld app=new HelloWorld();    // Create Object
       app.setDialogBehaviour(SimpleGame.ALWAYS_SHOW_PROPS_DIALOG);
        // Signal to show properties dialog
       app.start();    // Start the program
   }
    protected void simpleInitGame() {
        Box b=new Box("My box",new Vector3f(0,0,0),new Vector3f(1,1,1));    // Make a box
       rootNode.attachChild(b);    // Put it in the scene graph
   }
}


HelloWorld from Xith3d starter guide.
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  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
package org.xith3d.gsg;

import javax.vecmath.*;

// Xith3D
import com.xith3d.scenegraph.*;
import com.xith3d.test.*;

// use Jogl
import com.xith3d.render.*;
import com.xith3d.render.jogl.*;

/**
* Simple Hello-World-application, displaying a single cube.
*
* @author Jens Lehmann
*/

public class HelloXith3D
{
      /**
      * Starts the application.
      *
      * @param args command line parameters
      */

      public static void main(String[] args)
      {
            new HelloXith3D();
      }

      /**
      * Draws a cube.
      */

      public HelloXith3D()
      {
            // create the virtual univers
           VirtualUniverse universe = new VirtualUniverse();

            // add a view to the universe
           View view = new View();
            universe.addView(view);

            // add a locale
           Locale locale = new Locale(5.0f, 0.0f, 10.0f);
            universe.addLocale(locale);

            // create a BranchGroup
           BranchGroup scene = new BranchGroup();
            locale.addBranchGraph(scene);

            // let objects along this path rotate
           Transform3D rotate = new Transform3D();
            rotate.rotXYZ((float)Math.PI/4,
            (float)Math.PI/5,
            (float)Math.PI/2);
            TransformGroup objRotate = new TransformGroup(rotate);
            scene.addChild(objRotate);

            // create Cube
           Geometry geo = Cube.createCubeViaTriangles(0, 0, 0, 1, true);
            Shape3D sh = new Shape3D(geo, new Appearance());
            objRotate.addChild(sh);

            // turn the scene into a render friendly format
           scene.compile();

            // create a canvas for our graphics
           RenderPeer rp = new RenderPeerImpl();
            CanvasPeer cp = rp.makeCanvas(null, 640, 480, 32, false);
            Canvas3D canvas = new Canvas3D();
            canvas.set3DPeer(cp);

            // modify our view so we can see the cube
           view.addCanvas3D(canvas);
            view.getTransform().lookAt(
            new Vector3f(0, 0,    2f),    // location of eye
           new Vector3f( 0, 0, 0),    // center of view
           new Vector3f( 0, 1, 0));    // vector pointing up
           view.startView();
      }
}
Offline phazer

Junior Member




Come get some


« Reply #27 - Posted 2004-10-17 10:11:55 »

One big difference between Xith and jME is that jME have translation, rotation and scaling for each Spatial in the scene graph, even a TriMesh. Xith only have this data for a TransformGroup. To me it seems the jME solution would waste more resources, both memory and CPU.

Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #28 - Posted 2004-10-17 10:20:59 »

and the TransformGroup has the translation, rotation and scaling. Its no difference. Actually, Xith3D's is more momery wasteful as you need to create a furthur object (TransformGroup) rather than just 3 Vector3fs as you do in jME.

Edit: Just found out about Transform3D, even more memory wasteful!

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #29 - Posted 2004-10-17 10:56:18 »

I have a feeling Phazer was saying that JME effectively has a trasform group built into every node and has to account for each one when rendering.

Example: 5 TriMeshs in a Group. Not transformed in any way. In JME the rendering process has to at least check whether the transform components of the mesh have been used and hence need to be honoured during rendering. In Xith, there would be no transform information since there is no TransformGroup involved.

Memory usage would be higher in JME because every node would use memory for transform information even if its not used.

Kev

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 (17 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!