HUD, textoverlay with Java3D and wiered stuff...

Engines, Libraries and Tools Java 3D
#1

Since Im doing a space sim I really need a HUD.

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.

The second way was using the HUD classes at http://www.newdawnsoftware.com/

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.

Hope someone has a clue, I dont atm. :frowning:

Thanks in advance.
Tex

#2

Hi
What are your front and back clip distances set to?, what depth have you placed the HUD?

Thanks

Endolf

#3

I got the hud objects within the clipping range. So if I have clipping range at 20/20000 I have the Text at 25.

Tex.

#4

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

#5

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.

HTH

Endolf

#6

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.

Tex

#7

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?

#8

[quote]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?
[/quote]
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.

Tex

#9

Another issue with the Zones. Radar.

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

Tex

#10

Wouldn’t you usually use Locale for this type of zoning.

Kev

#11

Yes, I did mean Locales I couldn’t think of the right word.

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.

#12

That’s what we’re doing (in progress) with Galactic Village… ;D

#13

This is of course exactly what the one and only true space game did, Elite.

Kev

#14

Why has no-one matched Elite yet? Every attempt just seems to be missing that essential spark, or just isn’t genuinely freeform…

#15

No, its the same with many old games, you remember them with a rose tinted thought retrievel system. The games at the time were fantastic, but by todays expectations they would be average at best.

Try playing elite plus now, it soon gets boring.

Kev

#16

Hmmm Locales.

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.

Finally does anyone have some sample code on Locales?

Thanks
Tex.

#17

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.

Cheers

Endolf

#18

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.

Thanks
Tex.

#19

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 :frowning:

Cheers

Endolf

#20

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 meters
So 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

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