What i have learned from Xith3D.....

Engines, Libraries and Tools Xith3D Forums
#1

I have ported a bigger program from java3d to xith3d.
Almost what i can do in java3d, i can do with xith3d.
Absence behaviors in xith3d was not a trouble.
Working with overlays in java3d is a nightmare
(synchronisation problems), not in xith3d (mostly).
A bigger disadvantage in xith3d is the missing
‘Text2D-’ and ‘Text3D-’ classes in the core API.
But the main disadvantage from xith3d is, it is
complete useless for simulations. Why that???
Xith3d calculates all with floating points.
My program is a solar system simulator with real
datas that must calculate with big and small datas.
The precesion from floating points is to low for such
a program, i must say.
(Look at a sum from a floating point value greater than 2048.0f
and a floating point value lower than 0.0001f and you know what i mean.
In doubles, the sum is correct!).
My conclusion is, xith3d is a good API for games, but
a bootleneck for simulations.
That is, what a have learned.

Bye Adi

#2

[quote]My conclusion is, xith3d is a good API for games, but
a bootleneck for simulations.
[/quote]
Then it has succeeded where it wanted to. The focus of Xith is to target game development specifically.

#3

Why not seperate your visualisation from your simulation. Then you could keep your simulation in precise doubles and visualise in Xith’s floats (which is probably all your graphics card support unless you’ve got a really nice one ;)). What I’m suggesting is the problem isn’t with Xith.

Kev

#4

Hello Kev

I think my card is ok.(I have a NVIDIA GeForce FX 5700 Ultra with 128 MB).

Alas, i already have minimized all my distances with
a scaled factor of 0.000016f .
(Because, alone the distance from sun to pluto is
in reality 5869660000.0 km (kilometers).)
This results in a distance, in my system, to
~93914.0f.
Now, when my (constant) speed is e.g. 1500.0f km/second (very fast), the way that i make in a second underlies also this scaled factor, so i got ~0.024 km in my system.
Further on, i must divide this value with my framerate
e.g 64. I got now 0.000375f km per frame.

Now, i have the problem to add 93914.0f + 0.000375f.
Adding this as double is simple, i always get the correct sum.
But this (double) sum i can’t put as 93914.000375f in a float.
Also, i must work with a realistic acceleration, so it
takes a long time until i have reached such a speed,
that an addition takes effect.

Or have i overseen something??
What do you mean about that??

Bye Adi

#5

I think what Kev is saying is to use Xith3D only to display your universe and keep the actual calculations separate. This stops the rounding erros compounding.

For example, in my game - I am using ODE (which you can compile to use doubles, not that I have as I don’t need that level of precision and they slow the calculations down) for the physics calculations. Periodicaly, Xith3D reads the values from the ODE simulation and moves the 3D representations of the objects accordingly in the scene.

In the original design doc, David decided that it was a waste of time to support both floats and doubles when the underlying graphics hardware primarily uses floats.

Will.

#6

Exactly, the 3D graphics can be an interpretation of the actual (superbly accurate) data model.

Incidently, I believe your card (as with most consumer cards) only has float accuracy in OpenGL.

Kev

#7

Even if Xith were using doubles, that wouldn’t really help you.
Just step from your solar system sim to a universe sim and you’ll get the same problems with doubles again.

The dynamic range of floatingpoint number is limited. Regardless how many bits they take.

And this is not an issue simulation vs. game, bc. large dynamic ranges may appear in games as well as low-dynamic ranges may show in simulations.

#8

[quote]The dynamic range of floatingpoint number is limited. Regardless how many bits they take.
[/quote]
That’s very true. It’s the reason why in banks and bookkeeping etc computer software usually uses BCD for computing: Binary Coded Decimal. (For example each digit of a numer is being stored in a nibble.)

Take a look at the java.math package please which provides BCD like math:[quote]Provides classes for performing arbitrary-precision integer arithmetic (BigInteger) and arbitrary-precision decimal arithmetic
[/quote]
Slower than floats/double of course, but precise.

Aside all this, I would always separate the model and view, like the good old MVC (Model View Controller) pattern suggests to and Kev etc did so, too. So even if your model used BCD arithmetic (just an example) your (Xith 3d) view is just a relative view on this, and rounding errors are delayed to the last step: the view.

PS: I’m still wondering how current 3d APIs with their floats only (which is standard in gaming space) will migrate to double one day when 64 bit CPUs (Athlon64 etc.) will be standard?

#9

They will likely remain floats for at least another decade. Double-precision is entirely unnecessary for visualization on the screen. Visualization itself is a whole slew of hacks and tricks to fool the eye.

Cas :slight_smile:

#10

[quote]They will likely remain floats for at least another decade.
[/quote]
Floats have enough advantages over doubles that you can argue that doubles ought to be removed from the language (or else downplayed).

/me ducks and runs for cover

Seriously, using floats forces programmers to discover, confront, understand, and learn how to deal with the fundamental problem of floating point arithmetic: the ease with which 0 != 0 and X+Y != X+Y. (EDIT: that’s a gross over-simplification of the problem, but it’s a neat way of illustrating to the uninitiated the seriousness of what they’re dealing with - floats are a showstopping-bug waiting to happen for them :frowning: )

And…in most cases as soon as you understand the problem you can trivially easily implement arithmetic to whatever arbitrary precision you need.

OTOH (before I get flamed ;)) this is something you’d really want to enforce on programmers with < 4 years experience (assuming most do not learn all about FP for quite a few years) rather than upon all java programmers. So it’s a silly and impractical idea. Yes, I’m playing Devil’s Advocate here - but at the same time for most (all?) games-development situations you NEVER need doubles and you are BETTER using floats - save that when you know the limits of the algebra you’ll be doing, there may be guaranteeably no need to use anything more than simply doubles.

Still, I’m always hearing more stories from games devs about how that assumption was valid when the game was started, but by release (or in an expansion pack) it became invalid, wasted huge amounts of time tracing the bugs, and then had to be upgraded to a scheme that would have worked equally well with floats :(. (EDIT: FYI almost always from people having this problem in C++, not java, but it’s the same issue - number of bits used in FP datatype thought to be sufficient AND safe, but ending up not being safe)

#11

EDIT: Please not this post isn’t intended at the original author rather at the world in general

Hmm, just because someone is inexperienced doesn’t mean you should pander to their lack of understanding. One thing I’ve loved about java (and the APIs around it) is the amount it teaches me everytime I use it…

The number of times I’ve come up against a problem, starting swearing and accusing the API developer of being an idiot and then realised that infact I’m wrong and they’re doing it for a damn good reason.

So, yes, yes we should force developers down the right roads and yes developers should have minds open minds to accept that they don’t know everything (especially me :)) IMO, this isn’t only true of language syntax but of design and documentation standards.

No one learns or understands anything if everyone just goes around saying hey man, let everyone do it their own way, don’t cramp my style. :slight_smile:

Now, I’m going back to my lemsip, cough

Kev

#12

Hello Kev

Your Question :
<<“Why not seperate your visualisation from your simulation?”>> i have tried, and it works.
Good, i have not an 1:1 representation between
simulation- and visualisation-datas, but it works.

However, i think it was not the worst, if someone
could compile xith3d for floats or doubles.
(It makes migration to xith faster, i think).

Thanks for your advice and also to all
others.

Adi

#13

I think the problem is that even if Xith3D had doubles - it wouldn’t be a 1:1 representation between Xith3D and the visualisation data anyway (being that the graphics cards only use floats).

Glad you got it working :slight_smile:

Will.