Pure Java Port of ODE - planning/feasibility

Game Mechanics
#61

[quote]Will it affect the speed significantly
[/quote]
I would preffer to use doubles. Much less problems with bad rounding.

If Java would compile floats, and doubles optimally there would be 2x decrease in speed for doubles,if you don’t think about other isues in CPU pipeline. I consider advantage of doubles as worthy to that 2x possible slowdown. Note that 2x difference was measured in a test that attempted to maximalize amount of instructions per second (sciencemark float/double SSE2 matrix multiply on celeron presscott core.). I expect that in real life it would be more like 1.4 difference.
Also I encountered a code that used floats, and was 10x SLOWER than code with doubles (highly likely a bug in JIT, or not.).

Few other notes.

I would be against abreviation in name. Too similar to JOGL, JOAL, and so on. A some more nicely sounding name would be more fitting.

Also isn’t one of reasons for this undertaking to avoid mistakes present in ODE? And to have Java standards more abiding interface? Class names needn’t be exactly copied from ODE.
Note that a code that believes into some documentation of other code that was ported from, often ends with poor documentation, if any documentation at all.

I don’t think a class like.

public class ODEstore {
public double data
public double data2
}

Would be against any Java’s conventions. Who is spreading that rummor? (This was actually asked by Lina Inverse…) Public variables are confy, and less error prone in a lots of situations. The speed difference between public access and a inline of get(set( is at most 2x on server after considerable running time. It’s a quite opposite situation on the client (Or at least was on first JVM in 5.0 series.).

If you really need some implementation of matrix, I have one nearly ready, It could do multiply, inverse, and determinant. It looks like all what is needed. Actually it could do also perpetualization of itself.

YUDITH is a very nicely looking text editor on the Linux, with UTF support on top of that.

#62

[quote]I would preffer to use doubles. Much less problems with bad rounding.
[/quote]
Okay, but I think people have been quite happy for some time using floats in odejava. This is a gaming engine and I really don’t think you need the precision that a double gives. Especially if it means you physics runs 2x as slow (and physics can often be the bottleneck)

[quote]Who is spreading that rummor?
[/quote]
I was the one spreading the rumour that public attributes are against java conventions. Maybe I should of said good practice. Java is all about good OO principles and data hiding is an important OO principle. I did not really think there was any real difference in speed with public variables these days. Anyhoo, you don’t mind public attributes and I want public attributes for different reasons (easy code comparison to C code) so we are not in disagreement.

The real Java convention I want to break that I know will be contravertial is giving some class names lowercase first letters so they have exactly the same names as their ODE counterparts. Thats still up for discussion at the moment. I think I will probably lose that one :slight_smile:

We do not need an implementation of a Matrix. Our discussion was actually whether we should copy ODE’s or reuse the much more complete Matrix implementation in the vecmath package distributed with java3D. I think the team is in agreement now that we will reuse the vecmath one.

One of the main annoying bugs in ODE was a stack overflow in the LCP algorithm. Switching to java shoudl solve it. In the event it doesn’t I think any of us could fix it. The other main buggy part of ODE is the collision system. I don’t think there is really an immediate plan on how to fix that, other than maybe not to port the broken bits so people won’t be dissapointed when using the engine. I have a idea on what to do with the collision system but I refuse to commit to implementing it (it involves calculating eigenvectors if your matrix class can do that, the vecmath one can’t).

#63

How much time do you guys someone to devote their time to this effort?

#64

Yes… but Ithink that is in the conext of hiding the data structures used for a particular implementation of an algorithm. I think the type of structs that would be simpler with public member data are things similar in concept to what Java already does this with, like Point, Dimension, Insets, etc. They are still ‘simple’ types in a sense. Usually manipulated by other classes, not member methods of their own class.

I think JOODE (“Judy”) is a cool name for the project too :slight_smile:

#65

I think data hiding is really an important OO design principles. You are right stating that in some very special cases public attributes fit well but I think that this is for very special cases like Point, Vector, Color,… i.e. classes that are so stable that they are highly unlikely to see these attributes ever change. This is not the case for most classes and one of the major problem with not hiding data is that, if you want to abstract your class later in the development process, you won’t be able to replace it with an interface. From my experience getter / setter have a near 0 footprint.

On the subject of float versus double, I have no idea of what is the best but there have been a couple of posts in the forum stating that doubles are actually faster than floats. This has to be checked since we could benefit of using doubles both in speed and in precision.

            Vincent
#66

The real Java convention I want to break that I know will be contravertial is giving some class names lowercase first letters so they have exactly the same names as their ODE counterparts. Thats still up for discussion at the moment. I think I will probably lose that one :slight_smile:
[/quote]
Hey, when we simply remove the first Letter (that’s always a ‘d’, if not prove me wrong), we get upper letter class names. So what’s the problem there, we could simply write then:
For documentation see 'd'+ClassName in the ODE specification

About float/double:
I only know that Xith3D is using floats, because the graphic cards use floats. But we don’t use the hardware of the graphics card here. But because Xith uses floats it would be much easier for the user, when we use floats, because else Vector3d would have to be transformed into Vector3f and this could get time expensive. So we would have to put another layer around or ODE port and then we could also use our own Matrix and Tuple classes. Another drawback for javax.vecmath just occured to me: For the Math stuff it’ll probably pretty bad, if we’ll always have to convert between e.g. Point3x and Vector3x, because we need methods from Point as from Vector (This happens pretty often if you do crude, fast math). On the other hand Java3D uses also Vector3d.

So I think we have two options here:

  1. use doubles, which have more prcision andmight be faster, and add a layer around the ODE port, which could cost some performance.
  2. use floats, which have not that much precision, and have direct acess to the ODE port, which makes it faster.

Arne

#67

I don’t understand these two options. A double warapper around a float based port will not work. There will be no benifits. We could design the system so that both are supported but this is not preferable as it means design changes. Really a hard decision has to be made upfront. ODE is preprocessed to either use floats of doubles (effectively).
Double do require slightly less effort to code becuase you do not need to suffix f to everything. I spose it does not really matter, it is not a big deal to transform the system from one to the other with skilled use of replaceAll function.

I think this thread (with a sun engineer invloved) does resolve the issue
http://192.18.37.44/forums/index.php?topic=8234.0

Floats are now faster, becuase they are used properly.

#68

I meant it the other way round- using doubles inside and floats on the outside (cos maybe in the internal stuff has to be more exact)

[quote]I think this thread (with a sun engineer invloved) does resolve the issue
http://192.18.37.44/forums/index.php?topic=8234.0

Floats are now faster, becuase they are used properly.
[/quote]
Ok floats then. Cos this will be faster than doubles and we won’t have to make another layer for 3D-API.

#69

This may be too soon to answer, but will the transition for applications that are now using OdeJava be smooth transition to JOODE?

#70

Yes. Unless you are using the unsupported functions of Odejava (which are documented as such) you won’t have to change a thing.

Will.

#71

So how are you continuing? Did team assembled? Did you looked into ODE internals and properly analised pipeline? Like: pointer A, B… A++ = (something++) *(*B)

ODE has a lot of code where assembly syntax like mov eax, [eax] rules over C one.

I tried a little benchmark of floats and doubles I used 4MB + arrays to prevent any locality. Floats were faster only if you didn’t use ((float) Math.sqrt(float)) * … If there was any need of retyping into a float, speed was worse than 6 multiplications and one division tried with double data type.

Of course there is also question if ODE problems are not caused by low precision. Did anyone tested ODE recompiled into doubles, and compared it with float based ODE?

As for data hiding. Don’t overdo it, game library needs to be able to work in close cooperation with itself. If people abstract every layer inside library, library could be slower, and possibly harder to maintain.

#72

[quote]As for data hiding. Don’t overdo it, game library needs to be able to work in close cooperation with itself. If people abstract every layer inside library, library could be slower, and possibly harder to maintain.
[/quote]
There won’t be any datahiding. Almost everything will be public attributes.

The project request has been sent off now. It was delayed unfortunatly becuase the system was closed for maintanece when I tried to do it Thurs. I am suprised they did not put up the project up though in the forums anyway though, becuase I did send an email to the dev people. Oh well. I hope this does not delay us too long.

So floats are decided. I am gonna gonna preprocess the C and see if I can build a more complete UML diagram (it was ignoring PP instructions so was probably losing information). Woo!

#73

For what it’s worth, I don’t see JOODE as “Judy”. After all, the English name Cooke is not pronounced Cooky", nor is the word code pronounced “cody”. I can’t think of any words ending with ‘e’ off the top of my head where the e is promounced ‘y’. I read JOODE as in “Hey, Jude”.

#74

[quote]I read JOODE as in “Hey, Jude”
[/quote]
Hmmm. Yeah. You might be right. Either is cool though. We will swap pronounciations to whatever is most unpopular at the current time to keep people on their toes.

I have managed to construct a fairly comprehensive set of Java classes based on the ODE source using bouml. There are 304 classes in total, though most of these need to be deleted and alot are just typedefs. In doing this I had to alter the ODE source to give the enums names, becuase currently they are anonymous. Hence I will be including a copy of the ODE project so that we have a project copy that we can keep in sync. I will also put in the latest verion of the ODE in the javaode project, and the required .dll and .so so tests can be written to compare functionality and check things are working.

#75

Only a side thingi, but you said, that we first should only allow Boxes and Sphere’s as collideable objects. But we also should keep in mind to be able to extend the number of objects.
We e.g. should be able to have something like a GeomTerrain, that’s not implemented over a GeomTriMesh (because as we know GeomTriMesh sucks). GeomCylinder and in the end GeomTriMesh (even if it sucks - it’s needed) should be added later on, too.

I don’t know how collisions are implemented in ODE, but we sure should try to have a working solution, where we don’t have to code extra stuff for all different pairs of Geoms. (I believe this is the case in ODE, if not, the rest of this post is garbage, because it deals with generalizing collisions between two objects)

I’ve got an idea of how do get the collision point between two objects (independent of the type of the objects), but as an idea it’s pretty good I think, but it’s close to impossible to implement (without a huge performance reduction). I’ll post it anyways:

I explain it with a 2D example, because I think then it’s eaier to understand.
We always probably start with a situation like in collision1.jpg (attachment) To find the closest intersection point we can transform it into collision2.jpg (simply rotate) Now we can represent the Objects as mathematically functions, so we can solve the problem with analysis. We got an equation like this:

a(x) = d-b(x)

=> a(x)+b(x) = d

To find the first collision point, we have to find the absolute maximum of a(x)+b(x).
To do this we have to calculate:
(a(x)+b(x))’ = 0
<=> a’(x)+b’(x) = 0
From all the x that we get as a result, we have to use the one with maximum distance.

Problem’s with this algorithm:

  • The algorithm would automatically have to be able to solve a’(x)+b’(x), in 3D this would be even more complicated, so we would need a Math API that can solve equations and for 3D also derivate.
  • For rotating Body’s ( which pretty often happens) it would also get more complicated.

It’s crap right? Some self critics has to be ::slight_smile:

Nah, If such a Math API exists (than can solve this stuff pretty fast) I could imagine this to be an option. Ode specifies collision cases between all different Geoms (I am right here, right?), so we could do like wise (faster) and only use this method, if no such collision got specified.

Arne

#76

Bounding box? It works on any geometry. Sphere test works as well. Even plane ray test needs just 12? multiplication and one division in 3D space.

#77

JOODE sounds like a great initative. Please post a link to the project when you get the website set up. I’d like to sign on as an observer, or maybe even contribute code (although there’s now way I could commit to giving time to the project).

If it’s going to be a straight port of the ODE code, hopefully that will mean few surprises. I’ve implemented my own physics engine in Java, and did not find it an easy task. (Although is did get a ball to roll down a corkscrew spiral and then bounce on the ground, which was fun).

Mark McKay

#78

Arne. The problem with collision detection is not detecting a collision, but quickly detecting that there hasn’t been a collision. The reason why I suggested we only implement boxes and shperes at first is just for simplicity. We can’t port the ODE trimesh code so we need a fresh approach to arbitary geometries. This may mean a whole rethink of how the collision systema ctually works, so I don’t think we should faithfully port all the collision code we can think of (like CCylinders and rays etc). Anyway I really don’t want to think about the next step yet. So just spheres and boxes for now.

Kitfox. We are jsut waiting for the project to wind its way through the admin. Should be going soon.

#79

Yeah, but we should keep in mind, that it should be able to get extended later on.

#80

In the end it’s just the same.