Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (511)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 6
  ignore  |  Print  
  Java port of Bullet Physics Library  (Read 103053 times)
0 Members and 1 Guest are viewing this topic.
Offline jezek2
« Posted 2008-01-11 14:47:46 »

Hello,

I've ported Bullet Physics Library to Java. See:

http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=1827

UPDATE 2008/02/07:
More information and latest versions can be found on JBullet homepage.
Offline darkprophet

Senior Duke




Go Go Gadget Arms


« Reply #1 - Posted 2008-01-11 16:00:15 »

Hey, thank for that. Just wondering if this is an actual port or a binding?

If its a port, how come the webstart wants to run without permissions?

DP Smiley

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline jezek2
« Reply #2 - Posted 2008-01-11 16:22:22 »

Hey, thank for that. Just wondering if this is an actual port or a binding?

It's actual port. Smiley

If its a port, how come the webstart wants to run without permissions?

The demo uses OpenGL (LWJGL), I'll later add support for some software 3D renderer (probably jPCT or something like that).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline irrisor

Junior Duke





« Reply #3 - Posted 2008-01-11 19:57:21 »

Having a complete physics engine in Java would be awesome. JOODE never got finished, unfortunately. Any estimates for release dates or a road map? How large is your team? (first posts reads like size==1)
Offline jezek2
« Reply #4 - Posted 2008-01-13 22:01:45 »

Having a complete physics engine in Java would be awesome. JOODE never got finished, unfortunately. Any estimates for release dates or a road map? How large is your team? (first posts reads like size==1)

I'm working on it alone. No dates are set, but I would like to have it usable for my project in this month, but that's not fixed date either.
Offline jezek2
« Reply #5 - Posted 2008-01-16 02:19:22 »

I've uploaded new version: http://jezek2.advel.cz/tmp/jbullet-20080116.zip

Webstart: http://jezek2.advel.cz/tmp/jbullet/jbullet-test.jnlp

Changes:
- Moved all push/popProfile to try/finally blocks
- Added final for Vectors/Transforms/etc fields where applicable, and fixed some discovered bugs
- Fixed bug with non-functional removeOverlappingPair
- Enabled ground BoxShape in BasicDemo
- Implemented drawing of BoxShape
- Fixed VectorUtil.maxAxis

Known issues:
- collision of boxes has some bug
Offline Herko_ter_Horst

Senior Newbie




Java games rock!


« Reply #6 - Posted 2008-01-16 19:05:58 »

I'm afraid I am unable at this point to offer more than moral support, but I just wanted to say: keep up the good work! Smiley
Offline jezek2
« Reply #7 - Posted 2008-01-18 06:37:50 »

I'm afraid I am unable at this point to offer more than moral support, but I just wanted to say: keep up the good work! Smiley

Thanks, it's nice to see it useful for other people Smiley
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #8 - Posted 2008-01-21 19:03:13 »

hi

I've just tried your webstart demo above. Does it do anything else than changing the spheres' colors? I can rotate the scene with the arrow keys, toggle wireframe mode with w and change the color with space. Is there anything else? (No offense of course)

It's very cool, that you're porting bullet to Java. Even if I like JOODE, it isn't currently developed anymore. So we need other options.

I saw, that you're using Sun's crappy vecmath lib. You shouldn't. It's extremely GC expensive. May I kindly suggest to use OpenMaLi? A current build can be optained here. OpenMaLi contains a package called org.openmali.vecmath2. It provides about the same (float-based) classes as Sun's vecmath but without the GC issues plus soe additional ones. And these classes are more feature-rich. The main difference is, that no public instance fields are used, but only getters/setters (which are inlined by the JIT-compiler). This gives you the opportunity to check for modifications through the isDirty() getter. There are built-in instance-pools for all the classes, that you can use to avoid insance-creation related GC issues. Well, there are a lot of other additional features in OpenMaLi. Maybe you even want to contribute some additional physical math to OpenMaLi Wink. You'd be welcome.

Marvin
Offline jezek2
« Reply #9 - Posted 2008-01-21 21:14:05 »

hi

I've just tried your webstart demo above. Does it do anything else than changing the spheres' colors? I can rotate the scene with the arrow keys, toggle wireframe mode with w and change the color with space. Is there anything else? (No offense of course)

You can grab spheres by mouse and throw them, shoot boxes with '.' or right mouse, or apply impulse with middle button. I'll add text overlay with help in next version Smiley

It's very cool, that you're porting bullet to Java. Even if I like JOODE, it isn't currently developed anymore. So we need other options.

I saw, that you're using Sun's crappy vecmath lib. You shouldn't. It's extremely GC expensive. May I kindly suggest to use OpenMaLi? A current build can be optained here. OpenMaLi contains a package called org.openmali.vecmath2. It provides about the same (float-based) classes as Sun's vecmath but without the GC issues plus soe additional ones. And these classes are more feature-rich. The main difference is, that no public instance fields are used, but only getters/setters (which are inlined by the JIT-compiler). This gives you the opportunity to check for modifications through the isDirty() getter. There are built-in instance-pools for all the classes, that you can use to avoid insance-creation related GC issues. Well, there are a lot of other additional features in OpenMaLi. Maybe you even want to contribute some additional physical math to OpenMaLi Wink. You'd be welcome.

I'll examine it. But I don't think the Sun's vecmath are crappy, yes sure, there are some allocations, but in somewhat rare situations, the most visible is Matrix*.invert(), which is practically not used in Bullet btw. I actually like the raw approach of fields. I don't think that vector lib should track dirty status or something, as it's extra work which is not needed in most cases. I would also need to change all my projects where I want to use Bullet, or have nasty conversions code when it meets other parts. But anyway, I might be wrong, I'll check it in detail for sure.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #10 - Posted 2008-01-21 21:30:27 »

You can grab spheres by mouse and throw them, shoot boxes with '.' or right mouse, or apply impulse with middle button. I'll add text overlay with help in next version Smiley

Thanks. I will run it once more.

I'll examine it. But I don't think the Sun's vecmath are crappy, yes sure, there are some allocations, but in somewhat rare situations, the most visible is Matrix*.invert(), which is practically not used in Bullet btw.

Sun's vecmath was the main reason for GC issues, that we once had in Xith3D. Replacing it with a GC-free version solved most of these nasty hick-ups. Would be a pity, if using your cool physics lib was a new reason for them.

I actually like the raw approach of fields.

I am sure, you're talking about the possibility to do things like this:
1  
vec.x += 10f;

In OpenMaLi's vecmath2 this can be done like this:
1  
vec.addX(10f);


There are a lot of these convenience methods to ensure, people don't start to dislike the lib just because they have longer lines of code Wink.

And it is really hard to track, when a public field is accessed for writing or reading at design- and runtime. For getters/setters it's fairly easy.

I don't think that vector lib should track dirty status or something, as it's extra work which is not needed in most cases.

I did some deep benchmarks when I created vecmath2 and keeping these dirty bits up to date really didn't do anything at the performance. So it's purely extra feature with no loss of performance Smiley.

I would also need to change all my projects where I want to use Bullet, or have nasty conversions code when it meets other parts. But anyway, I might be wrong, I'll check it in detail for sure.

Well, that's a bit of work indeed. Though most of it can be automated through text-replaces.

I'll check it in detail for sure.

Cool Smiley.

btw. OpenMaLi was meant to become a standard math lib for all engines, etc. I hate, that everyone is creating an own math lib, which might be specialized. Sun's vecmath could be this one lib, but it is not an option because of the GC issues. OpenMali is designed to be as general as possible and is already used by Xith3D and Odejava. It was also planned for JOODE, but unfortunately the devs didn't have time to help me with the port of the more tricky parts of the simulation code.

Marvin
Offline Jackal von ÖRF

Junior Duke





« Reply #11 - Posted 2008-01-21 21:56:23 »

Well, that's a bit of work indeed. Though most of it can be automated through text-replaces.

Or through a creative use of a couple of refactorings, such as explained here: http://blogs.jetbrains.com/idea/2006/08/switching-between-api/

(Migrating direct field access might be harder, though... might need some manual find-and-replace.)

Offline jezek2
« Reply #12 - Posted 2008-01-21 22:14:28 »

Sun's vecmath was the main reason for GC issues, that we once had in Xith3D. Replacing it with a GC-free version solved most of these nasty hick-ups. Would be a pity, if using your cool physics lib was a new reason for them.

I have own BulletStack object for Vectors, Matrices, Transforms and Quats. And there is BulletPool for some other things. The invert() method is practically not used, so I think there is no problem with it Smiley

I am sure, you're talking about the possibility to do things like this:
1  
vec.x += 10f;

In OpenMaLi's vecmath2 this can be done like this:
1  
vec.addX(10f);


There are a lot of these convenience methods to ensure, people don't start to dislike the lib just because they have longer lines of code Wink.

This and that it's using less memory and indirection when it's stored directly in fields. In vecmath2 you have float[] array and few others fields for each instance.

And it is really hard to track, when a public field is accessed for writing or reading at design- and runtime. For getters/setters it's fairly easy

I use code like this in objects that have Vector fields:

1  
2  
void getSomething(Vector3f out);
void setSomething(Vector3f vec);

(both are doing a copy)

So there is no problem of tracking for me Smiley

I did some deep benchmarks when I created vecmath2 and keeping these dirty bits up to date really didn't do anything at the performance. So it's purely extra feature with no loss of performance Smiley.

Good to hear Smiley

btw. OpenMaLi was meant to become a standard math lib for all engines, etc. I hate, that everyone is creating an own math lib, which might be specialized. Sun's vecmath could be this one lib, but it is not an option because of the GC issues. OpenMali is designed to be as general as possible and is already used by Xith3D and Odejava. It was also planned for JOODE, but unfortunately the devs didn't have time to help me with the port of the more tricky parts of the simulation code.

Yeah, standard vecmath is really good thing for interoperability between apps/libraries. Sun's "javax.vecmath" is standard, but probably not sufficient.

What about automatic creation of builds (either by source modification or on bytecode level) that support either the lib? I already thought about it some time ago, to allow having version that uses doubles instead of floats.
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #13 - Posted 2008-01-21 23:39:31 »

I have own BulletStack object for Vectors, Matrices, Transforms and Quats. And there is BulletPool for some other things.

That's what I was talking about. There should be no need to reinvent thewheel and create all this on your own, if the math-lib already provides it Wink.

This and that it's using less memory and indirection when it's stored directly in fields. In vecmath2 you have float[] array and few others fields for each instance.

I didn't profile the memory usage. So I cannot comment this in detail. Though I guess, the overhead is not too big and should not be a problem, since it should be only a few additional bytes per instance. I would not worry about it.

I use code like this in objects that have Vector fields:

1  
2  
void getSomething(Vector3f out);
void setSomething(Vector3f vec);

(both are doing a copy)

So there is no problem of tracking for me Smiley

I assume, you don't have those methods for all accesses to vectors, which would make the direct field approach quite useless Wink. So in case you will have this problem Wink.

Yeah, standard vecmath is really good thing for interoperability between apps/libraries. Sun's "javax.vecmath" is standard, but probably not sufficient.

Sun's vecmath is designed specifically for Java3D. And Sun won't care about other opinions, what should be better to be integrated into it. I always try to keep it as general as possible and the influence of JOODE (by Arne) to OpenMaLi was quite big, which made it even more general.

Plus: If you need something in the math lib, it can be added to OpenMaLi. You will never get Sun to add or modify anything in their vecmath Wink.

What about automatic creation of builds (either by source modification or on bytecode level) that support either the lib? I already thought about it some time ago, to allow having version that uses doubles instead of floats.

Hmm... never tried that. But I guess, it should work to simply do a text-replace of "float" -> "double".

Marvin
Offline jezek2
« Reply #14 - Posted 2008-01-22 04:32:30 »

That's what I was talking about. There should be no need to reinvent thewheel and create all this on your own, if the math-lib already provides it Wink.

Oh, I should have explained more. It's "special" pool designed to match JBullet needs, that has push() and pop() operations (called in try/finally block), so it automatically reuses objects when they leave the scope. An example:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
protected final BulletStack stack = BulletStack.get();
// per-instance, obtains it from ThreadLocal to allow having multiple distinct simulations in different threads
// the instance has usually many fields, so it doesn't matter to add one :)

void someFunc() {
   stack.pushCommonMath();
   try {
      Vector3f vec = stack.vectors.get();
      // etc
   }
   finally {
      stack.popCommonMath();
   }
}


pushCommonMath pushes vectors, matrices and transforms. You can also push/pop individual stack pools like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
stack.vectors.push();
stack.quats.push();
try {
   // some code
}
finally {
   stack.vectors.pop();
   stack.quats.pop();
}


I assume, you don't have those methods for all accesses to vectors, which would make the direct field approach quite useless Wink. So in case you will have this problem Wink.

Most accesses using public final Vector3f fields.

Sun's vecmath is designed specifically for Java3D. And Sun won't care about other opinions, what should be better to be integrated into it. I always try to keep it as general as possible and the influence of JOODE (by Arne) to OpenMaLi was quite big, which made it even more general.

Plus: If you need something in the math lib, it can be added to OpenMaLi. You will never get Sun to add or modify anything in their vecmath Wink.

Hm yes true. Btw do you have any statistics what libraries actually developers use? vecmath, vecmath2, or do the majority use their own vecmath libs? or are there any other general purpose libs available? Smiley
Offline jezek2
« Reply #15 - Posted 2008-01-22 07:56:09 »

Ok, I looked more into it, read forums, etc. And I start to like it Smiley I'll continue to use Sun's vecmath for awhile to have more finished port, and then (if I don't change my mind of course) I'll port it to Vecmath2 (and gradually the other projects).

I really prefer the standard way (be it official or de facto) for such thing as a Vecmath library. I hoped that "javax.vecmath" is the solution to this, but seems it's missing features, and what's worse the API is set in stone, it can't evolve. I like your approach (if I'm not wrong) and I apply it too, when things needs to be fixed, it should be fixed regardles of backward compatibility (I don't mean huge rewritting but small iterative changes).

There is some stuff missing for me though. Most notably I need the double versions of (at least) Matrix3d/4d, Vector3d and Point3d.
EDIT: I don't need that now though, when I will need it I can contribute a patch.

There are some methods that seems duplicate to me, like scaleAdd() could be replaced with mul().add(), which is more universal (there are few places where I needed scaleSub() for example). Have that any reason (like performance) besides having compatible methods with Sun's vecmath? Or scale(float) vs mul(float). Also the clamp() etc methods returns TupleNf<T> instead of T (I know that would be probably problem to solve Smiley ), so you can concatenate operations only from base TupleNf.

I don't know if it's really useful, but I have an idea of XXX.asReadOnly() method, which would create a new XXX readonly instance with shared float[] array. The instances should be cached in WeakHashMap (EDIT: or better own cache that uses SoftReference, should be pretty straightforward to create), so you could simply write code like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
protected final Point3f position = new Point3f();

public Point3f getPosition() {
   return position.asReadOnly();
}

public void setPosition(Point3f pos) {
   this.position.set(pos);
}
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #16 - Posted 2008-01-22 13:20:43 »

Oh, I should have explained more. It's "special" pool designed to match JBullet needs, that has push() and pop() operations (called in try/finally block), so it automatically reuses objects when they leave the scope. An example:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
protected final BulletStack stack = BulletStack.get();
// per-instance, obtains it from ThreadLocal to allow having multiple distinct simulations in different threads
// the instance has usually many fields, so it doesn't matter to add one :)

void someFunc() {
   stack.pushCommonMath();
   try {
      Vector3f vec = stack.vectors.get();
      // etc
   }
   finally {
      stack.popCommonMath();
   }
}


pushCommonMath pushes vectors, matrices and transforms. You can also push/pop individual stack pools like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
stack.vectors.push();
stack.quats.push();
try {
   // some code
}
finally {
   stack.vectors.pop();
   stack.quats.pop();
}


Most accesses using public final Vector3f fields.

Hmm... don't know, if this suit your needs. But in vecmath2 there's an abstract ObjectPool class, that all concrete pools extend from. So you could implement a specialized pool for other class instances than the vecmath2 internal ones with only a few lines.
But maybe your more global pool approach has to be implemented on a higher level. Though might be useful for general use and should therefore be in OpenMaLi.

Using the vecmath2 internal pools would be like this for the above code example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
Vector3f vec = Vector3f.fromPool();
try
{
    ...
}
catch ( BlahException e )
{
}
finally
{
    Vector3f.toPool( vec );
}


It doesn't matter, how many instances currently are in the pool. Additional instances are created on demand.

Hm yes true. Btw do you have any statistics what libraries actually developers use? vecmath, vecmath2, or do the majority use their own vecmath libs? or are there any other general purpose libs available? Smiley

No, I'm afraid I have no statistics. I only know, that Java3D uses Sun'S vecmath (and will always use), jMonkeyEngine uses their own internal math. Though I will try to ask them somewhere in the future, if they maybe want to move to vecmath2, since JAGaToo uses vecmath2, which is a gaming-tools lib, that jME might find useful to base on like Xith3D does. (Just another (meant to be) standard lib to share code). Xith3D uses vecmath2, Odejava uses vecmath2, JOODE will use vecmath2.
That's all I know of.

Ok, I looked more into it, read forums, etc. And I start to like it Smiley I'll continue to use Sun's vecmath for awhile to have more finished port, and then (if I don't change my mind of course) I'll port it to Vecmath2 (and gradually the other projects).

Great to hear that Smiley.

I really prefer the standard way (be it official or de facto) for such thing as a Vecmath library. I hoped that "javax.vecmath" is the solution to this, but seems it's missing features, and what's worse the API is set in stone, it can't evolve. I like your approach (if I'm not wrong) and I apply it too, when things needs to be fixed, it should be fixed regardles of backward compatibility (I don't mean huge rewritting but small iterative changes).

Exactly my opinion Smiley.

There is some stuff missing for me though. Most notably I need the double versions of (at least) Matrix3d/4d, Vector3d and Point3d.
EDIT: I don't need that now though, when I will need it I can contribute a patch.

I didn't implement the double versions, since I didn't see a need for them. If there someone (like you Wink), who has a need for them, you would give a really great contribution to the project Smiley.

There are some methods that seems duplicate to me, like scaleAdd() could be replaced with mul().add(), which is more universal (there are few places where I needed scaleSub() for example). Have that any reason (like performance) besides having compatible methods with Sun's vecmath?

It is relatively new, that most of the methods return the instance back again. And the scaleAdd() method was there from the beginning on. So if this isn't slower because of the two method calls and therefore two for-loops, the scaleAdd() method couldbe removed. Otherwise we should add a scaleSub() method for you.

Or scale(float) vs mul(float).

Well, the basic reason for keeping both methods is the logic of the code when you read/write it. It is the same reason, why I kept both PointXf and VectorXf classes even, if they only differ in a handful of methods and of course the way they are transformed by a Matrix4f. A point is a point and a vector is a vector. They might be very similar and even related, but they are not the same from a mathematical point of view.
Sometimes you might find it more logical to multiply a point's values, that to scale it.

Also the clamp() etc methods returns TupleNf<T> instead of T (I know that would be probably problem to solve Smiley ), so you can concatenate operations only from base TupleNf.

That simply wouldn't compile. Otherwise I would have done it. If you see a way to make this working, we can happily change it.

I don't know if it's really useful, but I have an idea of XXX.asReadOnly() method, which would create a new XXX readonly instance with shared float[] array. The instances should be cached in WeakHashMap (EDIT: or better own cache that uses SoftReference, should be pretty straightforward to create), so you could simply write code like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
protected final Point3f position = new Point3f();

public Point3f getPosition() {
   return position.asReadOnly();
}

public void setPosition(Point3f pos) {
   this.position.set(pos);
}


I really like this idea. I think, I will add this feature soon Smiley.

Thanks for the feedback. And thanks for deciding to (maybe) use OpenMaLi.

Marvin
Offline jezek2
« Reply #17 - Posted 2008-01-22 16:27:41 »

New version: http://jezek2.advel.cz/tmp/jbullet-20080122.zip

Webstart demos:
BasicDemo
GenericJointDemo

Changes:
- Fixed convex/plane collision detection
- Added GLDebugDrawer and fixed some bugs
- Added CapsuleShape
- Added ConeTwistConstraint, HingeConstraint and Generic6DofConstraint
- Added GenericJointDemo
- Optimized drawing of spheres and cylinders using display lists
- Fixed collision of boxes
- Added text overlay

Enjoy Smiley
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #18 - Posted 2008-01-22 16:41:13 »

This is truly impressive. Great work, man.

It's a lot of fun to toss the poor guy around grabbing his head Grin. What's the gravity setting? It looks like it's lower then 1g.

Marvin
Offline darkprophet

Senior Duke




Go Go Gadget Arms


« Reply #19 - Posted 2008-01-22 23:26:57 »

I am building a game engine that uses vecmath and profiling with both yourkit and the netbeans profiler shows that with correct usages, the GC is fine with it since most allocations are in the young generation.

Im afraid you might constrict the people who use your API if you got down the route of supporting one rendering library with its own customised math lib.

DP Smiley

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline jezek2
« Reply #20 - Posted 2008-01-23 08:13:37 »

This is truly impressive. Great work, man.

It's a lot of fun to toss the poor guy around grabbing his head Grin. What's the gravity setting? It looks like it's lower then 1g.

Thanks, it's just a simple testing scene (from original Bullet), you can check the sources for details and play with adjustments Smiley

Im afraid you might constrict the people who use your API if you got down the route of supporting one rendering library with its own customised math lib.

I'm leaning towards the idea of automatic Ant-based source translation to vecmath2 (the original would be still using Sun's vecmath), so I could support both of libraries at once to satisfy all parties Smiley There might be also builds with doubles instead of floats in future.

Though I think you're not quite fair to the Vecmath2 effort, it's really independent of Xith3D, and have interesting features, and could be extended more, whereas with Sun's vecmath we're stuck in time Smiley
Offline bienator

Senior Duke




OutOfCoffeeException


« Reply #21 - Posted 2008-01-23 10:56:22 »

Though I think you're not quite fair to the Vecmath2 effort, it's really independent of Xith3D, and have interesting features, and could be extended more, whereas with Sun's vecmath we're stuck in time Smiley
anyone tried to contribute changes back? In best case the vecmath2 lib could be a extension of Sun's improved vecmath package instead of a fork.

EDIT: added improved before vecmath to make it clearer

Offline kevglass

JGO Kernel


Medals: 186
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #22 - Posted 2008-01-23 11:02:16 »

Where are you getting that vecmath is closed source, or not accepting contributions - looks pretty open to me?

https://vecmath.dev.java.net/

It's a sub-project of:

https://java3d.dev.java.net/

Where most of the mangement get's handled. I'm sure they'd be excited about a whole bunch of contributions that reduce GC and improve performance!

EDIT: Infact:

Quote
The API specification will continue to evolve as part of the Java Community Process (JCP). We welcome community participation, and encourage developers to contribute both bug fixes and new implementation code to the API.

Kev

Offline darkprophet

Senior Duke




Go Go Gadget Arms


« Reply #23 - Posted 2008-01-23 12:07:40 »

Why not have method that take floats and you translate them into whatever libs you want?

so maybe: position(float x, float y, float z); It might break the API, but then atleast your math lib neutral, much like ODE.

DP Smiley

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline CommanderKeith
« Reply #24 - Posted 2008-01-23 12:09:04 »


Holy cow, that's amazing!!  Cheesy

pressing e for more people and . for bombs loads of times doesn't ware it out - it's still stable, nice job with the port.

Offline jezek2
« Reply #25 - Posted 2008-01-23 12:56:24 »

Why not have method that take floats and you translate them into whatever libs you want?

so maybe: position(float x, float y, float z); It might break the API, but then atleast your math lib neutral, much like ODE.

That's not an option, Bullet doesn't have clearly seperation between public API and "internal" things. In fact, Bullet is pretty modular and you can happily use any internal stuff when you need just that. ODE on the other hand has C frontend API that hides all internal stuff.
Offline jezek2
« Reply #26 - Posted 2008-01-23 13:10:09 »

Where are you getting that vecmath is closed source, or not accepting contributions - looks pretty open to me?

JDL is not classic opensource license, for example it requires that modified versions passes TCK. To obtain it I must do some paperwork, which I don't want. To change things I must become member of JCP, another thing that is barrier for me.

With truly opensource I have much lower barrier to contribute or even make own changes for my own usage (none barrier).

I'll provide builds of JBullet for both vecmath libs and let decide developer what he likes/needs. This issue is pretty closed for me by this.
Offline Marvin Fröhlich

Senior Duke




May the 4th, be with you...


« Reply #27 - Posted 2008-01-23 19:42:22 »

OpenMaLi is certainly not specialized especially the vecmath2 package. There may be some packages or classes, that would not be there, if I wouldn't use it in Xith3D as well as there are some changes or additional classes, that came from influences from the JOODE project. But these specific classes are all written in a way, that make them usable for other purposes, too. And this is, what should be applied to everything committed to the project.

So it is perfectly independent from Xith3D or any other project.

Marvin
Offline jezek2
« Reply #28 - Posted 2008-01-27 09:11:19 »

I've been thinking a lot about Vecmath libraries lately. I've come to the conclusion that it simply can't be done "nicely" in Java. For example, supporting read-only Vector3f would need "const" support in Java, but that's horrible thing as it pollutes entire code bases. It can be done somewhat by interfaces, but that's not good for performance and is not ideal either.

I've come to similar conclusion with properties in Java (instead using getters and setters). I thinked and tried few approaches (and searched web for ideas), all had major drawbacks, I then realized that getter/setters are simply the best option, their only drawback is that you have to type more, but that's not much issue because we have powerful IDEs.

Also, with physics library, you have to already somewhat translate between graphics and physics layers, so wrapping between different Vecmath libraries is not much problem. Maybe I can add "float x,y,z" versions to some "public" and supposedly to be widely used methods to ease this, as darkprophet suggested.

So my conclusion is, that I will stick with official "javax.vecmath" library, and everything that is not included can be added through utility static methods, we as Java developers are using them a lot already, so no issue Smiley

Marvin I'm sorry about it, but I think that Vecmath2 don't add much value (at least in current version) to switch from official Vecmath (or developers' own implementations).
Offline bienator

Senior Duke




OutOfCoffeeException


« Reply #29 - Posted 2008-01-27 11:24:29 »

JDL is not classic opensource license, for example it requires that modified versions passes TCK. To obtain it I must do some paperwork, which I don't want. To change things I must become member of JCP, another thing that is barrier for me.

With truly opensource I have much lower barrier to contribute or even make own changes for my own usage (none barrier).
just for a note: the next version of Java3d (and vecmath) will also have GPLv2+CP ex as license (1.5.2). The 1.6 release is planed to be the "big changes" release but I am pretty sure that this release won't happen this year.
1.6 is probably the release with the best chance to get a contribution approved.

Pages: [1] 2 3 ... 6
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (50 views)
2014-10-17 03:59:02

Norakomi (39 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (36 views)
2014-10-15 16:18:58

TehJavaDev (66 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!