Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 9
1  Java Game APIs & Engines / Xith3D Forums / Re: Project owner on: 2006-12-02 19:11:17
Just curious... why the move away from java.net?
2  Java Game APIs & Engines / Xith3D Forums / Project owner on: 2006-12-02 17:43:31
A Mr. mkbluesky has requested project ownership of Xith3d on Java.net.  I am not sure who that is.  I am not at all opposed at moving the project owner to someone else, but I would like this board to make the decision.

Please let me know.

Dave Yazel
3  Java Game APIs & Engines / Xith3D Forums / Re: TimerInterface / JavaTimer on: 2006-07-21 12:18:50
At one point the System.getCurrentMilis() has a resolution of 55 ms on the PC, which is why most people bind to the hi-res timer to get the time to pass into each frame render.  Because java did not support a better timer we added the interface so people could plug-in the JNDI binding to the PC multi-media hires timer, but felt that the implementation should not be added to the codebase.

If System.getCurrentMillis is still at a 55 ms resolution then it is no good for 3d interpolation.
4  Java Game APIs & Engines / Xith3D Forums / Re: How goes Xith3D? on: 2006-07-20 19:25:48
After working on Magicosm for 5 years, and developing Xith3D along the way we hit a crisis point where we ran out of money, energy and people.  It was the first big failure of my life (Magicosm) and it was a huge blow to me when it failed.  I had persevered for a long time after other similar projects failed and had never really accepted the possibility of failure.  We got all the way to beta test with about 15 people and finally realized that even with all the technology finished and working we were never going to be ready for production, not without a staff of paid modellers, artists, voice people and writers.  Even the production costs like hardware, bandwidth, customer support, etc was going to be beyond us.  We had always thought a grass roots, word of mouth product could boostrap itself into existance.  About this time World of Warcraft came out, Guildwars and EverQuest II.  All you have to do is spent 10 min in WoW to realize how much *more* that world had to offer from what we were building... and dispair set in.  I retired from Magicosm and in an effort to deal with the pain of that, also pulled myself out of the whole world of game programming.  I will never attempt such an ambitious effort again. 

But I still love 3D, and the wonderful creative process of turning math into something visually appealing.  So after a couple of years of distance between myself and Magicosm I am testing the waters again.

Dave
5  Java Game APIs & Engines / Xith3D Forums / How goes Xith3D? on: 2006-07-20 18:37:59
Hey guys... it has been a while I know since I last stopped by.  I continue to be amazed by the interest and loyalty to Xith3D from the java gaming community.  Some projects have cleared up for me and I am looking forward to pulling down the latest code and trying it out.  I may have written the original version and the first year of enhancements, but the real work has been done by all of you.  Without your work this would have been one more API littering the cutting room floor.  I hope no one bears any resentment to my retirement from the project, life took a turn and I had to change my focus for a long while.

So tell me,  how have things been around here?  Any idea on an estimate on how many people are using the libraries?  Did many companies ever adopt it for their commercial usages?

What are the current weaknesses of Xith3D in comparison with other java 3D libraries?  Did anyone ever add shader support, volumentric fog, bezier patches?  Was there ever a decision to add physics, springs, etc?

Has the evolution been toward low level optimization / card feature support, or higher level architectural additions?

Anyway.. just curious... and it is great to see familar names around here!
6  Java Game APIs & Engines / Xith3D Forums / Re: UIWindows using Swing Containers... on: 2004-07-17 15:02:11
The biggest issue you are going to run into is that you cannot put a heavy weight component inside the 3d window.  That is why the gui system does not go below JComponent.  Even then we cheat by painting the changes of the component into the 3d window on each frame.  I completely understand why you want to do what you are asking for, but there is no way to integrate any 3d library with heavyweight components because they have underneath them their own window, which is a OS specific implementation incompatible with OpenGL and DirectX.
7  Java Game APIs & Engines / Xith3D Forums / Love you guys on: 2004-02-12 23:02:34
Here is my semi-monthly thanks for all of you who are helping to make Xith3D better and better!  It is super nice to be able to work Magicosm for a couple of weeks and see everything running here smoothly without my even having to worry about it!
8  Java Game APIs & Engines / Xith3D Forums / Re: Texture loading time on: 2004-02-12 22:59:57
We dont currently support a compressed texture format, but there is no reason except no one has implemented it yet.  OpenGL supports compressed formats.  In addition I suspect a bit of your time is spent calculating mipmaps.  Opengl can calc mipmaps for you (i think) so there is another point where we can optimize.
9  Java Game APIs & Engines / Xith3D Forums / Re: Bug in shadows rendering on: 2004-02-12 22:57:47
JCD:

I wrote the shadow code and I know I did not handle the "shadow in view" problem, mostly because I could never figure it out!  According to the papers I have read you need to clip the volume to the view, stitch the clipped edges and render a "cap".

I would just *love* someone to fix it!
10  Java Game APIs & Engines / Xith3D Forums / Re: Need help understanding the Peer system on: 2004-02-12 22:53:51
Thanks Yuri... could not have explained it any better!
11  Java Game APIs & Engines / Xith3D Forums / Re: Introducing Pixel and Vertex Shaders on: 2004-01-26 13:50:53
Very cool work!  So would this work on only a subset of cards or driver versions or manufacterers?  It sounds like the application would need to know if was going to use the vertex program (if available) or fall back to more traditional methods.  Perhaps we need to expose the capabilities of the card to the application?
12  Java Game APIs & Engines / Xith3D Forums / Re: GUI for understanding Appearance attributes on: 2004-01-26 13:46:01
Very cool!  I will try this out tonight.
13  Java Game APIs & Engines / Xith3D Forums / Re: Quake 3 demo released on: 2004-01-24 11:35:29
The performance issues are entirely due to the overhead of the scenegraph.  A Quake level is about as un-scenegraph freindly as you can possibly get since it is divided up into thousands of little chunks of just a few triangles.  Only 15 percent of the time is spent actually rendering the geometry accoring to my profiling.  I will be introducing a few enhancements to the API to allow you to specify the shader execution list inside an atom, this will allow things like the quake levels to rendered more quickly since the programmer can optimize where it is necessary.
14  Java Game APIs & Engines / Xith3D Forums / Re: Possible bugs or at least omissions on: 2004-01-23 22:35:03
The offset factor works, I use it in magicosm.  I will have to check the other two.
15  Java Game APIs & Engines / Xith3D Forums / Re: How far does the Collision code go? on: 2004-01-23 22:31:27

Next step is to define a dummy node for your avatar and attach to the collision system and your scene:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
// build a dummy node to represent the avatar for collision and movement
// purposes.  we do this by creating a branch group with set bounds around an
// avatar of 1.83 meters high.  Then we make a collider node of an ellipsoid which is
// half as wide as it is tall.

        MovementForce force = new MovementForce();
        TransformGroup aTG = new TransformGroup();
        Node n = new BranchGroup();
        n.setBoundsAutoCompute(false);
        n.setBounds(new BoundingSphere(new Point3f(0, 0.915f, 0), 0.915f));
        aTG.addChild(n);
        converter.getRoot().addChild(aTG);
        avatarNode = new ColliderNode(n, ColliderNode.CT_ELLIPSOID, ColliderNode.CT_ELLIPSOID, true, new Coord3f(0.5f, 1, 0.5f));
        cs.addCollider(avatarNode);

// now make a force for the collider which controlls movement

        avatarNode.addForce(force);


Then you need to capture your AWT events and use them to modify your force:

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  
  class KeyboardEventListener implements AWTEventListener {
            public void eventDispatched(AWTEvent event) {
                if (event instanceof KeyEvent) {
                    KeyEvent e = (KeyEvent) event;

                    if ((e.getID() == KeyEvent.KEY_TYPED) && (e.getKeyChar() == '-')) {
                        takeScreenshot=true;
                    }
                    if ((e.getID() == KeyEvent.KEY_TYPED) && (e.getKeyChar() == 27)) {
                        System.exit(0);
                        e.consume();
                    }

                    // turning right

                    else if ((e.getID() == KeyEvent.KEY_PRESSED) && (e.getKeyCode() == KeyEvent.VK_RIGHT)) {
                        force.turnRight();
                        e.consume();
                    } else if ((e.getID() == KeyEvent.KEY_RELEASED) && (e.getKeyCode() == KeyEvent.VK_RIGHT)) {
                        force.turnStop();
                        e.consume();
                    }

                    // turning left

                    else if ((e.getID() == KeyEvent.KEY_PRESSED) && (e.getKeyCode() == KeyEvent.VK_LEFT)) {
                        force.turnLeft();
                        e.consume();
                    } else if ((e.getID() == KeyEvent.KEY_RELEASED) && (e.getKeyCode() == KeyEvent.VK_LEFT)) {
                        force.turnStop();
                        e.consume();
                    }

                    // turning forward

                    else if ((e.getID() == KeyEvent.KEY_PRESSED) && (e.getKeyCode() == KeyEvent.VK_UP)) {
                        force.setSpeed(4f);
                        e.consume();
                    } else if ((e.getID() == KeyEvent.KEY_RELEASED) && (e.getKeyCode() == KeyEvent.VK_UP)) {
                        force.setSpeed(0);
                        e.consume();
                    }

                    else if ((e.getID() == KeyEvent.KEY_PRESSED) && (e.getKeyCode() == KeyEvent.VK_DOWN)) {
                        force.setSpeed(-4f);
                        e.consume();
                    } else if ((e.getID() == KeyEvent.KEY_RELEASED) && (e.getKeyCode() == KeyEvent.VK_DOWN)) {
                        force.setSpeed(0);
                        e.consume();
                    }

                    // go down

                    else if ((e.getID() == KeyEvent.KEY_PRESSED) && (e.getKeyCode() == KeyEvent.VK_DELETE)) {
                        force.fallDown();
                        e.consume();
                    } else if ((e.getID() == KeyEvent.KEY_RELEASED) && (e.getKeyCode() == KeyEvent.VK_DELETE)) {
                        force.fallNone();
                        e.consume();
                    }

                    // go up

                    else if ((e.getID() == KeyEvent.KEY_PRESSED) && (e.getKeyCode() == KeyEvent.VK_INSERT)) {
                        force.fallUp();
                        e.consume();
                    } else if ((e.getID() == KeyEvent.KEY_RELEASED) && (e.getKeyCode() == KeyEvent.VK_INSERT)) {
                        force.fallNone();
                        e.consume();
                    }

                    // gravity

                    else if ((e.getID() == KeyEvent.KEY_TYPED) && (e.getKeyChar()=='g')) {
                        force.toggleGravity();
                        e.consume();
                    }

                    else if ((e.getID() == KeyEvent.KEY_TYPED) && (e.getKeyChar()==' ')) {
                        force.jump();
                        e.consume();
                    }

                }
            }
        }

        Toolkit.getDefaultToolkit().addAWTEventListener(
                new KeyboardEventListener(),
                AWTEvent.KEY_EVENT_MASK);


Then in your renderer loop you let the collision system handle the avatar and then sync the view.

1  
2  
3  
            cs.newFrame(deltaTime);
            force.updateView(avatarNode, view, deltaTime);
            view.renderOnce();


Thats it!

You can check out the Quake 3 demo I just posted to see this work and to study the complete source code.
16  Java Game APIs & Engines / Xith3D Forums / Re: How far does the Collision code go? on: 2004-01-23 22:31:12
Ok step by step instructions.

The basic technique is to create a dummy node which represents your avatar, then build a collider for it.  Then create a Force which is used to move the avatar around.  Then once the dummy collision node has been updated, you sync the view with the location of the node.

So step one, define a Force for moving an avatar around:

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  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
136  
137  
138  
139  
140  
141  
142  
143  
144  
145  
146  
  /**
     * Movement force used for the renderer walkthrough
     */

    public static class MovementForce implements Force {

        public static final int TURN_RIGHT = 1;
        public static final int TURN_LEFT = 2;
        public static final int TURN_STOP = 0;

        public static final int FALL_NONE = 0;
        public static final int FALL_UP = 1;
        public static final int JUMP_UP = 3;
        public static final int FALL_DOWN = 2;

        AngleInterpolater turnAngle;
        AngleInterpolater lookudAngle;
        float turnSpeed;
        float lookudSpeed;
        float speed;
        long totalTime = 0;
        Coord3f movement = new Coord3f();
        Vector3f eulers = new Vector3f();
        Vector3f firstPersonEulers = new Vector3f();
        Transform3D firstPersonTransform = new Transform3D();
        Vector3f curpos = new Vector3f();
        int turnDirection = TURN_STOP;
        boolean applyGravity = false;
        int fallDirection = FALL_NONE;

        public MovementForce() {
            // set other speeds
            turnSpeed = 180f; // 180 degrees per second
            turnAngle = new AngleInterpolater((float) Math.toRadians(206.65),
                    (float) Math.toRadians(turnSpeed), 0,
                    (float) Math.toRadians(360), true);
            lookudSpeed = 40f;

            // set up the look up and down interpolater
            lookudAngle = new AngleInterpolater((float) Math.toRadians(0),
                    (float) Math.toRadians(45), (float) Math.toRadians(-30),
                    (float) Math.toRadians(40), false);

        }

        public synchronized void setSpeed(float speed) {
            this.speed = speed;
        }

        public void turnLeft() {
            turnDirection = TURN_LEFT;
        }

        public void turnRight() {
            turnDirection = TURN_RIGHT;
        }

        public void turnStop() {
            turnDirection = TURN_STOP;
        }

        public void fallDown() {
            fallDirection = FALL_DOWN;
        }

        public void fallUp() {
            fallDirection = FALL_UP;
        }

        public void jump() {
            fallDirection = JUMP_UP;
        }

        public void fallNone() {
            fallDirection = FALL_NONE;
        }

        public void toggleGravity() {
            applyGravity = !applyGravity;
        }

        public synchronized void updateView(ColliderNode node, View view, long time) {

            totalTime += time;

            // adjust the interpolaters

            switch (turnDirection) {
            case TURN_STOP:
                turnAngle.stop();
                break;
            case TURN_RIGHT:
                turnAngle.startDecreasing(totalTime);
                break;
            case TURN_LEFT:
                turnAngle.startIncreasing(totalTime);
                break;
            }

            firstPersonEulers.y = turnAngle.getValue(totalTime);
            firstPersonEulers.x = lookudAngle.getValue(totalTime);
            firstPersonEulers.z = 0;
            firstPersonTransform.setEuler(firstPersonEulers);
            Transform3D viewTransform = view.getTransform();
            viewTransform.setEuler(firstPersonEulers);
            node.getNode().getTransformGroup().getTransform().getTranslation(curpos);
            curpos.y += 1.6f;
            viewTransform.setTranslation(curpos);
            view.setTransform(viewTransform);

        }

        public synchronized boolean apply(ColliderNode node, long time, Coord3f velocity) {

            firstPersonEulers.y = turnAngle.getValue(totalTime);
            firstPersonEulers.x = 0;
            firstPersonEulers.z = 0;
            firstPersonTransform.setEuler(firstPersonEulers);

            float seconds = (float) time / 1000f;
            velocity.x = 0;
            velocity.z = -speed;
            firstPersonTransform.transform(velocity);

            if (!applyGravity) {
                switch (fallDirection) {
                case FALL_NONE: velocity.y = 0; break;
                case FALL_UP: velocity.y = 0.5f; break;
                case JUMP_UP:
                    applyGravity=true;
                    break;
                case FALL_DOWN: velocity.y = -0.5f; break;
                }
            } else {
                if (fallDirection==JUMP_UP) {
                    velocity.y = 12;
                    fallDirection=FALL_NONE;
                }

                if (velocity.y >= -5) velocity.y -= 9.8 * seconds;
                else velocity.y = -5;
            }

            return false;
        }

    }

17  Java Game APIs & Engines / Xith3D Forums / Quake 3 demo released on: 2004-01-23 22:23:47
I have uploaded a quake 3 demo to the xith3d project files section.

https://xith3d.dev.java.net/servlets/ProjectDocumentList?folderID=0

This demo demonstrates walking through a quake level.  The source code is included.  Everything is included  that is needed to run it on windows.  If you want to  run it on Linux or Mac you will need to download the appropriate installation and jigger the rundemo script.

when running the demo, use the arrow keys to move around, G will toggle gravity and spacebar jumps.

Dave
18  Java Game APIs & Engines / Xith3D Forums / Re: Code explanation on: 2004-01-23 21:32:37
That feature is designed to sacrifice disk space for faster texture loading.  If it turned on then the first time the texture is read it is stored in uncompressed form on the disk.  The second time you run it maps the file into memory using NIO and just copies the data directly into the bytebuffer of the image, which is in turn passed directly to OpenGL
19  Java Game APIs & Engines / Xith3D Forums / Re: Node bounds changes on: 2004-01-17 18:39:46
Ah that could be, hard to keep track sometimes Smiley
20  Java Game APIs & Engines / Xith3D Forums / Node bounds changes on: 2004-01-17 16:11:44
Someone changed some code to handle cached bounds in Node.  There were two changes and the second change broke some things.  

The lines:

1  
2  
   vworldBounds.set(childrenVBounds);
                bounds.set(childrenBounds);


were changed to:

1  
2  
vworldBounds.set(childrenBounds);
                bounds.set(vworldBounds);


As far as I can tell, this change does not work and in fact breaks things pretty bad.  I can't be sure what was trying to be done here, but I have to change it back for now.

21  Java Game APIs & Engines / Xith3D Forums / New commit on: 2004-01-17 14:25:43
I tagged the current repository as XITH3D-ALPHA-10 and then committed a bunch of code changes, then tagged that as XITH3D-ALPHA-11.

I have vastly improved the texture state changes, including support for efficient multitexture units.  The attributes and the texture themselves have been seperated into two shader peers so that we do not re-issue the opengl commands for one when we need to change the other.  No longer is the ShapePeer calling the texture peer, the new code ensures that the texture units are correct before the shape peer is invoked.  I am also sorting the state based on multiple texture units so that we can minimize texture swapping.  There were also a boatload of tweaks to different things to improve performance.  I regression tested it, but let me know if any of your projects break and I will jump on the fixes.

In addition I am working on the ability to bypass the scenegraph if you want to in order to get more speed out certain things.  Basically you will be able to construct a list of shaders and pass them into the engine to be processed in the order you specify.  This would assume that your code would handle the culling and it would technically be possible for you to "mess things up" by not handling a state change.  For for things like rendering a Quake level it would vastly speed thinsg up to not have the scenegraph looping through 500 shapes of 10 triangles each and sorting all the atoms and checking the state on each atom, which is where a lot of time is being spent right now.  So basically, this is just one stap above OpenGL, you would basically be saying, set the polygone attributes to X, set the texture attributes to Y, render this shape, etc.  This would co-exist with the view rendering and in fact would be a special type of scene node with a callback to have you adjust the render list before it was added to the frame list.
22  Java Game APIs & Engines / Xith3D Forums / Re: TextureAttribute's combine mode on: 2004-01-16 23:16:00
I will check... I may not have done that mode.  If not, it will be easy to add.
23  Java Game APIs & Engines / Xith3D Forums / Re: Quake3 Renderer progress on: 2004-01-11 02:18:22
Some screenshots of a quake3 level being rendered through xith3d.   I can walk through the level with full collision detection / sliding along surfaces with gravity.  All running very smoothly.

http://www.magicosm.net/xith3d/snapshot4.jpg

http://www.magicosm.net/xith3d/snapshot2.jpg

Dave
24  Java Game APIs & Engines / Xith3D Forums / Re: xith sound on: 2004-01-08 17:34:37
OpenGL does not allow distance attenuation with anything but mono sounds.  I have that from the Gerin, the OpenGL main dev.  It makes sense when you think about it since it needs both channels to attenuate spatially.
25  Java Game APIs & Engines / Xith3D Forums / Re: Quake3 Renderer progress on: 2004-01-08 17:29:00
The first version of the Quake renderer ran at 0.5 FPS due to the fact that I was not using the cluster visibility provided with the BSP.  I integrated the VIS stuff now and brought the FPS up to 24 FPS.  After doing a bunch of profiling and found a few bottlenecks in Xith3D and removed them and now am running at 110-220 FPS depending on the location and view inside the level.  I don't know if you guys are familiar with the way FPS levels are stored, but the faces (which are really Shapes, a whole bezier patch is considered one face) in leaves are referenced if there is a non-zero intersection with the leaf bounds, which means one face can often be shared by multiple leaves.  So when you do your VIS by cluster you need to assemble a list of faces which are non duplicate in the potential visibility cluster information.  This list is then culled per frame and rendered.  So I created a huge switch with an entry for each face.  I created some optimized code in View so that it could handle large switches more quickly (using bitSet.nextSet() - very cool feature).  Now 99 percent of the time is spent texture switching and rendering all those itsy bitsy faces.  The really wierd thing is that by the time you do all this PVS and FOV culling you are leff with very little triangles... sometimes 300-500.  I would have expected the framerate to be much higher.  

There are a couple of current ineffiencies in the current Xith3D.  One is that multi-tetxure geometry is not getting sorted very well.  In the case of Quake you have large lightmaps which are shared for many faces, so you really want to sort first by the second texture unit and second by the main texture unit.  Discovering this automatically might be extremely difficult, so perhaps we should create a shape hint or sort policy which can guide the renderer on how to sort the shapes.  

The next problem is that currently multi-textured is not good about handling state changes as well as non-multitextured geometry is.   So for example when redering quake faces the geometry continues to enable unit 1, bind lightmap, render and then disable unit 1 which is incredibly expensive.  The same is also true of unit 0.  So I will have to improve that radically.  I think that we should also add some optimization into the state sorter so it can basically say "all other things being equal, render all these geometries with the same exact state."  Which is a bit like combining shapes into one shape dynamically, but at a lower level than the scenegraph.

any other ideas or thoughts would be welcome.
26  Java Game APIs & Engines / Xith3D Forums / Re: xith sound on: 2004-01-06 16:38:49
The xith3d design supports streaming sources, but the ogg and wav loaders do not support it yet... if that makes sense.  I will add it to the long list of things to do Smiley
27  Java Game APIs & Engines / Xith3D Forums / Quake3 Renderer progress on: 2004-01-06 09:52:56
I have finished writing a Quake3 map loader.  I was able to load and display several maps last night without issue.  I am working on a walkthrough demo with collision to be available hopefully this weekend for you to try.  I will be checking this code in to the xith-toolkit project.
28  Java Game APIs & Engines / Xith3D Forums / Re: Collision Demo on: 2003-12-26 03:49:48
Just commited another set of fixes which provided massive performance improvements.  

Just sitting here watching the demo and smoking a nice cigar...

it's hypnotic... tell me if you don't agree!
29  Java Game APIs & Engines / Xith3D Forums / Re: Collision Demo on: 2003-12-25 22:34:43
I commited a fix which addresses some performance problems.  The calculation for the list of potential colliders is now much more constrained.
30  Java Game APIs & Engines / Xith3D Forums / Re: Point/Vector/Tuple/Coord3f mess on: 2003-12-25 16:47:04
Yes it is dangerous, but perhaps necessary.

I would prefer the transformAsPoint or transformAsVector methods.

I personally prefer a unified solution.  The collision code really brought it home as I was constantly switching back and forth from vectors to points, making extra copies for no good reason.  Unfortunately all the methods in the Vecmath library are declared final, so we cannot alter the behavior whatsoever.

Basically is there some reason why we would not want to calculate the distance between two vector endpoints?  Well Vector3f does not have this method.  Is there any reason why we would apply a transform with a translation component to a vector and not have it apply the translation part?  I think it is non-intiutive that transform of a vector will only effect rotation and scale, but ignores the translation.

I personally would prefer that Xith3d used a single unified Coord which did away with the distinction of point and vector except that would introduce too much incompatiibility with older code.

I will revert the Transform3D back to using the Matrix4f and will introduce the two transformAs methods.  I do think having the Coord3f as a unified Tuple for use in subsystems like collision should be allowed.
Pages: [1] 2 3 ... 9
 

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

The first screenshot will be displayed as a thumbnail.

rwatson462 (37 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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