Does the HUD only work with Perpsective Projection? It seems from the little I’ve played with it that this is the case.
I need Parallel projection for the project I’m working on. Is is possible to configure the NewDawn code to work in this mode?
Thanks,
Mike
[quote]As I understand it, FrontClip and BackClip are relative to the position you are currently in.
[/quote]
yes. but for some reason java3d does something weird, and once you move too far it all goes strange (depth buffer errors creap in). Also, anything more than 3km away will be clipped so you can’t see it, ok for small ships, no good for planet sized objects :). So you end up rendering those objects offscreen, then pasting them in as part ofthe background, ick. Just pointing out that waht ever you do there will be some nasty work arounds. This (Java 3d, directX or opengl) is a real time rendering engine, not a renderer, so there will always have to be some tricks to get it to look like what we want.
Cheers
Endolf
[quote]Does the HUD only work with Perpsective Projection?
[/quote]
It should work, although I’ve not tried it, I’ll take a look.
Cheers
Endolf
[quote]Does the HUD only work with Perpsective Projection? It seems from the little I’ve played with it that this is the case.
[/quote]
Yea, it works but it looks really funky if you used perspective. Also, you get the same effect as you did with perspective so I don’t think there is any gain moving to Parrallel Per (at least in my case I can’t think of a reason but you guys might).
Oh yea, I tried this but it didn’t work:
At the root of your graph, I added a TransformGroup and then added all the other components beneith that (excpet for your HUD/view). Then when you move, you modify this root transform and I was thinking that would make like the player was moving but really the entire environment would move. Your view would stay at (0,0,0).
I guess the problem with this is if you add a BranchGroup under that, then the transform information stops ??? What do you guys think?
[quote]I guess the problem with this is if you add a BranchGroup under that, then the transform information stops What do you guys think?
[/quote]
If you have a transformgroup, and place a branchgroup under it, the transform will effect everything under it, including anything in the branchgroup. My code is full of such things.
HTH
Endolf
P.S. Looking at parallel projection in the HUD is still on my list of things to do, but it’s a long list atm.
Opps. I correct myself. What I described in the above post works!!! I messed up the implementation of it (I added the view to the root transform group w/ everything else so my view was moving when everything else was moving). All I did was add the view to the root branch group instead of the transform and it worked.
[quote] At the root of your graph, I added a TransformGroup and then added all the other components beneith that (excpet for your HUD/view). Then when you move, you modify this root transform and I was thinking that would make like the player was moving but really the entire environment would move. Your view would stay at (0,0,0).
[/quote]
So what I have mentioned above takes care of your HUD shacking but it does introduce a new problem. That problem is figuring out how the rest of the world should move relative to you. Rotation seems like it would be hard to do but that can be taken care of for you easily depending on how you setup your TransformGroup structure. This is what I did.
Below shows how each TransformGroup is connected so trans is a child of rotZ, ect.
rotX -> rotY -> rotZ -> trans
So if you do this, the world rotates properly. The next question, and the one I have been stuck on for a couple of days is, how do you figure out what to set the trans to be each time say you move forward (once you have rotated)?
Better stated, when you rotate, we want to be able to go in that direction. Any suggestions on how to cacluate the Transform for that?
Create a vector that goes into the z axis. Use your transforms to .transform() the vector. It will then point in the direction of your camera… move using this vector?
Kev
do you mean:
Vector3f vec = new Vector3f();
vec.z = (value you want to travel);
rotX.transform(vec);
rotY.transform(vec);
rotZ.transform(vec);
trans.set(vec);
If so, then this doesn’t do it for me either. Maybe i’m not thinking about this correctly ???
Once you have your rotated vector so that it is aligned with the direction the camera is facing you add it to your camera/player position and you are done. Movement in the direction of the camera relative to the world. You won’t be changing the rotation transform as a result of moving forward.
[quote]Once you have your rotated vector so that it is aligned with the direction the camera is facing you add it to your camera/player position and you are done.
[/quote]
If you do this, then you will still get the camera jitter problem when you move about 3km away from the origin.
To get away from the camera jitter, we must leave the camera at the origin and move everything around the camera. This solution is a hack to an obvious bug.
j3d.org has something in their FAQ about camera jitter but I don’t think they address the problem we are talking about or maybe I’m not understanding their solution.
http://www.j3d.org/faq/speed.html#jitter
http://www.parl.clemson.edu/~mspeth/images/cameraviewproblem.png
Ok, so here is the current problem. In the picture above, we have the world rotating around our camera (which is always facing in the -z direction). No matter how far the world gets away from the camera, it will always rotate around the camera in circles.
When we update the worlds position, (right now) we normalize the translation back to the origin. We need to figure out how to normalize it to the direction of the camera is pointing I think ???
//variables
Transform3D tmpTrans, positionHolder, posTrans, rotatorX, rotatorY, rotatorZ;
Vector3f position, vec;
// method for calculating translation component for world
tmpTrans.set(position);
positionHolder.mul(tmpTrans);
positionHolder.mul(rotatorX);
positionHolder.mul(rotatorY);
positionHolder.mul(rotatorZ);
positionHolder.get(vec);
vec.x = -vec.x;
vec.y = -vec.y;
posTrans.set(vec);
trans.set(posTrans);
Ok, the above code works; well sort-of. After moving around a bit I get a wierd behavior (such as moving in the up instead of moving forward).
Well, I gotta go see Bad Boys II (at my friends request) so I’ll try to figure out this wierd behavior tomorrow.
Hi
Unless i’m missing something, if you store a transform 3d (or a 4x4 float/double matrix) as your current location, and update just like you were originally doing, then you get the transform for your top world transformgroup, you can just take the inverse of the location matrix.
This is how I implemented a camera in native GL.
HTH
Endolf
tmpTrans.set(position);
positionHolder.mul(tmpTrans);
positionHolder.mul(rotatorX);
positionHolder.mul(rotatorY);
positionHolder.mul(rotatorZ);
//This takes the translation found in the above code
//And inverts it to apply to world translation & rotation
posTrans.set(positionHolder);
posTrans.invert();
wT.set(posTrans);
Ok, so this finally works. Thanks endolf for your help. Your method was soo much easier then mine. A big note, with the above method you only need to update 1 TransformGroup to move the scene (instead of 4 like I posted before) since the rotation & translation information are calculated w/ 1 Transform3D.
Well, if anyone wants the full source, I can code up a Class that handles this behavior.
[quote]Ok, so this finally works. Thanks endolf for your help.
[/quote]
No problem, just glad it’s all working.
Cheers
Endolf