next »

[ahealingman]

1st - thanks to the developers/maintainers for xith3D. After using for awhile I found it to be excellent and more importantly, to be extremely stable. Compared to jME, whose 'stable' release threw exceptions with their test apps on the first two computers I loaded it on.

My main problem actually has to do with jagatoo not xith3d. How do I get keys to repeat? Do I have to code a complete InputStatesManager or is there an easier way? I only need the cursur keys to repeat. I saw a mention of a KeyboardQueue somewhere but none of the test apps, which I've been using as my primary source for docs/examples, makes use of this queue so I'm lost as to how its setup or used.

Next, I am about to start getting into pickable items, etc and java3d set everything up through capability bits, if I remember right. Is this setup the same in xith3d? I ask because in all the test/example apps I've looked through I don't recall seeing any capability bits being set. Are these used/not implemented/ or setup a different way?

Another problem (not with xith) is a math problem (either I wasn't paying attention in school or so much time has gone by my memory is gone). Does anyone know the equation for determining a location on a sphere? Specifically, I want the camera to move around an avatar at a set radius so that it can be positioned (almost) anywhere in the top half of an (imaginary) sphere around the avatar. Basically the same as any typical third person game would do. Getting the camera to move in a full circle around the avatar was easy enough and I thought I could find the answer on the internet but 4 hours of google'ing hasn't gotten me anywhere. Everybody seems to give the equation with spherical coordinates but I can't find one for cartesian coordinates

thanks

[ChrisE]

Hola!

I can't really speak for the first two questions, but maybe I can help with the third.

So, handling that in absolute spherical coordinates is the correct thing to do. You have one angle, say lambda, for the left/right (or, alternately, east/west) and another, say phi, for up/down (north/south) on a sphere. You calculate each frame from these your position.

To find this, you place a point on the sphere (in our case, at {0,0,radius}). This would be a point at the equator of the sphere. We then rotate this point "north" however much the angle phi is, and then spin about the world's vertical axis (the Y axis, here) by the angle lambda.

The way of doing this in code would be something like:

Code:

Point3f getPointOnSphere(float lambda, float phi, float radius)
{
Point3f ret = new Point3f(0,0,radius);
Matrix4f lambdaRot = (new Matrix4f()).rotY(lambda);
Matrix4f phiRot =  (new Matrix4f()).rotX(phi);
phiRot.transform(ret);
lambdaRot.transform(ret);
return ret;
}

The idea here is that you have other code to check the lambda and phi and update them according to mouse movements or whatever, and constrain them to your sphere. The reason we don't just do relative updates to a direction vector (say, each frame rotate the vector a bit) is that numerical problems can creep in and ruin things. Recalculating each frame is easier. Also note that there are probably some issues around the poles of that sphere; also note that first we move the point up north/south, and then move it east/west.

That will get you a point on the sphere. Now, to build a full camera, you need to have a vector facing forward (in this case, just the vector from the point on the sphere to its origin), and a vector facing "up" from the direction the eye is looking (here, a vector parallel to the surface of the sphere at the eye point).

Does that help at all?

[badboyboogey]

Create a class to handle the inputs which extends 'InputAdapter'
Here's a simple example of one way to do it.. I'm sure someone will tell you there are better ways, there are also ready made InputHandlers like the FirstPersonInputHandler

Code:

eg:-
public class MyInput extends InputAdapter{
    private boolean keyDown[]=new boolean[256];

    public MyInput(){
        for(int i=0;i<256;i++){
            keyDown[i]=false;
        }
    }
    public void onKeyPressed( KeyPressedEvent e,Key key ){
        keyDown[key.getKeyCode()]=true;
    }

    public void onKeyReleased( KeyReleasedEvent e, Key key ){
        keyDown[key.getKeyCode()]=false;
    }
}

then register the keyboard and mouse in your setup/init code as such....
InputSystem.getInstance().registerNewKeyboardAndMouse(env.getCanvas().getPeer());

and as ChrisE says thats is the correct way of doing it, but if you need to use cartesian coordinates then you could just work out the angle from the center of the sphere to your point  in cartesian space using standard trig .. ie:- use x and z coordinates to work out the angle required for the Y Axis, y and z coordinates for the X Axis Angle.
then use the method ChrisE posted above to position the camera using those angles...

[Marvin Fröhlich]

My main problem actually has to do with jagatoo not xith3d. How do I get keys to repeat? Do I have to code a complete InputStatesManager or is there an easier way? I only need the cursur keys to repeat. I saw a mention of a KeyboardQueue somewhere but none of the test apps, which I've been using as my primary source for docs/examples, makes use of this queue so I'm lost as to how its setup or used.

The question is: What do you need the repeated keys for? If it is for a HUD, then the Xith HUD should handle that for you. If it is to move things around while some key is pressed, then you could use something like boogey posted. Though his suggestion is a bit incomplete.

First you shouldn't use a hardcoded 256 for the array. Better use Keys.getNumKeys(). On a side note Java ensures, that a byte array is initialized with all elements to false. So the initialization code is not necessary. Though I can understand, why he uses it.

His suggestion only shows, how to record key states, but doesn't demonstrate, how to use them to move objects around. One way would be to implement the Updatable interface in some class, add an instance to Xith's updater (Xith3DEnvironment.getUpdater()) and increment a float value, that influences the position, and recalculate the position as long as the desired key is down.

Of course this is only the do-it-all-by-yourself approach. If you can live with hardcoded key mappings, this is just fine. But if you want your users to be able to define key (or button) mappings for moving things around, you can either code this all on your own or use the InputHandler class. Extend it, equip the attached InputBindingsManager and use action states instead of key states. Have a look at the input testcases in xith-tk. They should givbe you a good overview.

Next, I am about to start getting into pickable items, etc and java3d set everything up through capability bits, if I remember right. Is this setup the same in xith3d? I ask because in all the test/example apps I've looked through I don't recall seeing any capability bits being set. Are these used/not implemented/ or setup a different way?

Not having to deal with all these capability bits in xith3d is one of the major benefits of xith3d over java3d. They add a lot too much bullshit to the scenegraph. Though a Node has get/setPickable(), if this is, what you're looking for. I guess, you know the PickingLibrary and have had a look at the picking testcases in xith-tk, have you?

Marvin

[ahealingman]

Capability bits: They were bull, the reason I ask is because if you forgot to set one properly you may spend hours trying to debug code that looks like it should work.

Repeat keys: Thanks, thats what I'm looking for. Sometime down the road I may change it but for now hard-coding the keys purpose works for me.

Sphere: Looks/sounds easy but I'm not quite getting it. What are the angles relative to? The only thing I know is the player/avatar position, radius and current camera position.

I want the camera to move with the player/avatar but also be independent, controllable via the cursur keys. Press left/right and the camera moves in a circle to the left/right. Press up/down, camera moves up or down but only a quarter of a full circle, stopping short of being directly north. The same movement that any normal game, showing a player model in the middle of the screen would have.

Right now I keep track of where the camera should be by dividing a circle into 32 sides and just calc the x,z coordinate.

Wait, I think I realize which angles now.

Marvin, HUD for repeating keys? I haven't gotten into the HUD yet, I assumed it was just for painting one screen over another which I hadn't planned on getting into till the scene and movement were complete, but I will check it out.

[ahealingman]

For the keys thats not what I am looking for, I already tried overriding onKeyPressed but it only fires once per key press, the key has to be released then pressed again. I'll ask the question a different way.

How do I keep firing the onKeyPressed event until the key is released? I've tried      InputSystem.getInstance().getKeyboard().isKeyPressed(key) but this always returns true (while inside onKeyPressed()) whether the key is pressed or not. I imagine its true until all the listeners are done running their code

[Marvin Fröhlich]

This behavior is explicitly wanted. isKeyPressed() will return true as long as the key is actually pressed and has nothing to do with a key repeat.

Please answer this question first: What do you need to key repeat for?

Marvin

[ahealingman]

I have a player/avatar. I want the camera to rotate around the player using the cursur keys left/right/up/down at a set radius. I don't want to have to keep hitting a key to move the camera, just hold the key down and the camera keeps moving. Technically, moving in a hemisphere around the player.

Thanks to everyone's help I have everything working except for being able to hold the key down.

I think this is the same kind of camera movement runescape has. I haven't checked them out in the last few years but I am fairly certain their camera moves in about the same way that I am describing.

Shooter Demo is another example except I'm not doing first person. Hold a key and the scene pans in a direction, which is the same thing I want except I'm just moving the camera instead of panning the scene.

[Marvin Fröhlich]

Ok, then it is as I expected. Read my first posting in this topic again.

You want the camera to rotate around the avatar at a set speed (angular rotation speed). Let's say, you want it to rotate by 10° per second. Let your KeyboardListener also implement Updatable and add the instance to the RenderLoop's Updater. In the update() method you would do something like this.

Code:

private static final float ROTATION_SPEED = FastMath.toRad( 10f ); // 10° per second
private static final long ROTATION_UPDATE_STEP = 10L; // rotation will be updated all 10 ms (optimization, play with this)
private long nextRotationUpdate = -1L;
private long rotationStartTime = -1L;
private boolean isRotationKeyDown = false;
private float startRotaiton = 0f;
private float currRotation = 0f;

public void onKeyStateChanged( KeyStateEvent e, Key key, boolean state )
{
    if ( key == Keys.R )
    {
        isRotationKeyDown = state;
        rotationStartTime = e.getWhen();
        startRotation = currRotation;
    }
}

public void update( long gameTime, long frameTime, TimingMode timingMode )
{
    if ( isRotationKeyDown && ( gameTime >= nextRotationUpdate )
    {
        currRotation = startRotation + ROTATION_SPEED * timingMode.getSecondsAsFloat( gameTime - rotationStartTime );
        nextRotationUpdate = gameTime + ROTATION_UPDATE_STEP;
       
        // apply the rotation to your camera
    }
}

If you would do this by utilizing key repeat, your movement would be anything but smooth. Play with the ROTATION_UPDATE_STEP constant. If this constant is missing, the rotation would be recalculated and updated every single frame, even if the step is so small, that you don't see any change. This can lead to unnecessary FPS drops. Choose this value as small as possible to keep a good frame rate while the movement is still smooth. You possibly also want to limit this by a rotational amount additionally to the time limit to keep the movement smooth with good FPS on different systems.

Marvin

[ahealingman]

Works perfectly. Thanks. Sorry I missed it on your first post, I got sidetracked by the calculation of the sphere. I don't think fps will be a major issue with this app, not fast paced, but I did see a huge drop when one model was in the scene. I can live/work with that though. Thanks

[ChrisE]

Got the camera orbiting satisfactorily yet?

Pics?

[ahealingman]

Yes, camera orbiting works perfectly thanks to your code. Pics? That would be too embarrassing. Took me 7 days to model one square building with inside walls. My avatar is a block with a sphere for a head, sorry no pics

[ChrisE]

Glad to hear it. Don't worry about just having walls and a sphere--took me a couple weeks to get to the same point in my work.