I get really wiered shit going on when doing any kind of overlays. I have done this two ways with same wiered shit happening.

First one I have done with the Text2D object. I know that this causes huge overhead when changing the text so I have just had it be a static text. I have added this text to the view platform with a PlatformGeometry.

In both cases the hud works really well when within 10.000 units range of the 0 0 0 point in the coordinate system. But if I place my ship at say 50.000 units (or fly it there) range from the 0 0 0 point the overlay bounces like mad on the screen when turning or moving.

The further I am away from the 0 0 0 point the bigger the bounces on any overlay I have.

Anyone got any idea what can cause this?

The rendering is really smooth when Im close to the 0 0 0 point with virtually no gc caused skipping.

The bouncing is not relative to movement speed or to rotation speed from what I have tested just to distance from 0 0 0.

We have the same problem and have never solved it. I believe this is a problem with inaccuracies in the matrix transformation precision between the view and the image plate aligned geometry. Tiny imperfections creap into the inverse transformation used to face the hud at the camera which are not present when the camera is near the origin. we all know how sensative the screen aligned geometry is... there is no tolerance for the slightest error or else it will not align with the pixels on the screen.

Unfortunely I have never been able to figure out a way to solve this problem in java3d since the view model is non-mutable. BTW this happens whether it is platform geometry or geometry in the scene. It starts about 6,000 from the origin

Hi One *really* bad work around, add another transform group above the rest of your scene, and periodically (when the view is more than say 5000 units from 0,0,0), multiply the transform by the inverse of the view matrix, and set the view matrix back to 0,0,0, this way you will never be more than 5000 units from the origin, and the HUD/j3d.orgs overlay should work. But it is a nasty work around, rather than a solution.

Workaround manupilation of possition will be a freekin pain to do as Im doing a online game. The server is always the master for position and keeping track of player positions that have been manupilated by the client will always be a freekin pain.

My next attempt is to scale all my models down ALOT so that the region where it freeks out is deep deep deeep space. Im gonna try scale down by a factor 100 or 1000. Most likely the models will look like crap but if they dont I do move the bad region to like 5mil out this way and that would be out of range for my game to have any problems.

Why not have a grid of zones held in your central universe and then give each zone it's own co-ordinate system/Java3D environment to locate ships in it?

Wouldnt that require that each zone is its own SimpleUniverse?

Actually creating a huge world of connected zones with their own coordinate system is a very interesting thought as you virtually could create a HUGE universe that way. Wormholes/Jumpgates could move you from one zone to another somewhere totally else in the universe or you could fly there.

Though I do see two problems with this. One is just the insane ammount of memory this could use to just store all the zones. Second is fights at zone edges if they are their own SimpleUniverses, people with low ping and fast machines using these borders to lag out slower players.

Though if the client always preloaded all the bordering zones the zone transition could be made smoother.

But the zones can by no means be as small as 10000 meters so I still have to scale down alot I guess.

It will be extreamly hard to do a radar that can look into the next zone. As a radar has a fixed range and when you are say 1000 meters from the next zone the radar would be covering 39000 meters of the next zone (radar range 40000).

If I was doing this, I would probably keep the zones quite small so you can keep your current one and closest neighbours in memory at once. Everything else can be held on the disk (or server, if you are being multiplayer, or both) until needed.

The radar information doesn't have to come from the 3d view- that kind of stuff should be running off the data model anyway, surely, so that is less of an issue.

Actually creating a huge world of connected zones with their own coordinate system is a very interesting thought as you virtually could create a HUGE universe that way. Wormholes/Jumpgates could move you from one zone to another somewhere totally else in the universe or you could fly there.

If I understand it correctly everything is one branch tree but all objects within the same region are part of the same Locale. Is that correct?

Question though when I am in one locale does Java 3D still render the objects in other locales if they are within clipping range? If that is true this would actually be fantastic and exactly what I need. This way I could create a really big galaxy wich would be really cool.

Hi I'm having exactly the same thougts. When I commented on the work around I had assumed your data model and graphics where seperate enough that the server and data model see the object at one location, but you can them process that client side data to create and update the 3d scene, this way you always view from 0,0,0, and then have another transform just above the rest of the scene for the rest of the world that contains the inverse of the playres location.

If you scale down your world by 100 or 1000 you screw up the clipping, it's like setting the fronta nd back clip ration to 100 or 1000 times greater, your zbuffer will have the same problems, but at distances 100 or 1000 time smaller.

Locals are something I will look at when I'm done the current sub project and linux jinput code.

Ive done the 1000 times scale down for the moment. It works ok. I have scaled everything including physics and clipping. Though Im not happy with this solution as I cant have gigantic sectors that cover millions of kilometers but I have to chop things up into sectors that you jump between.

So if anyone will come up with a good way to use locales for this. Please post here.

Hi Having sectors of millions of kilometers isn't practicle with the z buffer depths of gaming graphics cards. There is a document floating around at http://www.starfireresearch.com/services/java3d/supplementalDocumentation.html#zbuffer that shows that for consumer graphics cards a front to back clip ratio of 3000 is the worst case, that means front clip at 1m, back clip at 3000m, which doesn't quite cover millions of kilometers, best case is probably 130km,worst case 3km, this leaves us stumped without locals and nasty work arounds. One sector of 10e6 just aint gonna happen with out some nasty code

As I understand it, FrontClip and BackClip are relative to the position you are currently in.

For instance, if you are at 0,0,0 then you can see a max of 3000 metersSo the furthest position in view is 3000,3000,3000 (note it could also be any combination of the x,y,z coordinates being -3000 and 0).

So if you move to 10,0,0 then you can see 3010,3000,3000 to 10,3000,3000

As I understand it, FrontClip and BackClip are relative to the position you are currently in.

<snip>

Quote

So if you move to 10,0,0 then you can see 3010,3000,3000 to 10,3000,3000

So having a world like Tex is talking about is feasible.

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.

Does the HUD only work with Perpsective Projection? It seems from the little I've played with it that this is the case.

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?

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).

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?

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.

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