walrus said:
The Idea:
Its fairly straight forward. Basically its just a combination of R-Trees and Oct-Trees optimizes collision detection for highly complex objects.
hi, I'm evaluating java based physics engines for my company. I downloaded all available files from sourceforge (jinngine-0.5.0.jar and jinngine-docs-0.5.tar.gz), but I didn't wether a source code nor a license.
Unfortunately I need to cofirmation of our legal department before I can start testing each engine 
Please can you add a license to the project?
When comes source code available?
thx.
Hi
I'm really sorry i didn't see this post before now, guess I forgot to turn on email notifications for the thread. In case it could still be relevant or somebody else is having the same questions, Jinngine is published under GPL. You can browse the details on either sourceforge.net or the google code page. The source code is available from the google code svn service.
go to
http://code.google.com/p/jinngine/
and for more stuff goto
http://apps.sourceforge.net/wordpress/jinngine/
Can I ask do u add the jmejinngine to your project,s build path or still just jMEphysics 2 because the jinngine physics Space is in the jme folder would i actually need it or no? or can i only import the jinngine library by itself not jmejinnegine?
Hi people, I know this threat is pretty old, but I'll use it for a little update on jinngine. During the last year or so I've been pinned down by studies, so not much time has been available to develop either jinngine or the jme plugin. I did have some time to update http://jinngine.sourceforge.net. I think my first attempt on creating a JME plugin ended in a big mess. I simply lost track of how I was supposed to implement the interface. Right now my focus is on finishing my studies, and hopefully releasing Jinngine 1.0 by late summer 2010. It will be a minimal release, but only containing stable/testet code and documentation. After that, I think I will give the JME plugin a try again. During 2008/2009 i did some attempts to recruit additional developers, but it is very difficult to find qualified people. Please let me know you want to help. (MSc level in math/computer science required) .
By version 1.0, it might also be easier for other people to actually implement the JME plugin, since Jinngine is/will be pretty much a light-weight framework for doing game-physics with Java.
On the science side, there is now an experimental solver included in Jinngine, which is based on a Newton type solver. It is (sometimes :) able to handle very large mass ratios at interactive framerates. However, its far too unstable to be usable most applications. This stuff resulted in a paper published at the 2009 VRIPHYS conference. Have a look in the SVN repository if you are interested in such stuff.
-silcowitz
EDIT:
hehe, yeah i meant to have a 1.0 release by summer 2010, not 2009 
Cool! I ran through your demos and they were smooth and enjoyable. Can't believe I haven't come by this project until now.
I would advise you to check out Falken's latest development with JMEPhysics, which is mainly JBullet and native bullet integration.
There was also an extended discussion about various physics integrations to choose between. You'll see that there was considerable interest in a native Java library made from scratch, but no expertise around to really do anything about it.
Lastly, Ogli might also be able to help, but for the time being he's got other priorities. Definitely worth getting in touch though.
Irrisor on the other hand is unfortunately unable to work on JMEP any longer and has been fairly inactive lately along with the rest of the old JME staff. Maybe with all the cool stuff happening lately he'll eventually feel the pull again though 
silcowitz said:Well, we now have at least one or more (Falken) people doing the exact same thing, with fair success I think, so this might be more straight forward now
I think my first attempt on creating a JME plugin ended in a big mess. I simply lost track of how I was supposed to implement the interface.
silcowitz,
I get the basics of the math, but as far as the qualifications you're looking for . . . I'm a bit short.
I AM, however, quite strong at integration. I'm a bit pressed for time right now, as my company's in the process of attracting some venture capital, but I'm trying to stick around and help out where I can. If you need any advice with JME integration, I've done the JBullet integration and most of the native Bullet Physics binding, and I don't mind sharing my expertise.
Just holler!
That sounds really great, I will definitely need assistance in creating the pluging integration, last time I tried I didn't have much success… I found it pretty hard to find my way around in the API. I think the stuff about qualifications is just guidelines, the are really no requirements… Of course, gamephysics is pretty tough on math and cs. But I'd really appreciate any help I can get. For one thing, the jinngine API is not really "tested" in a real application… that means that there is a lot of missing features that needs to be created. This will properly quickly show up when attempting the jme plugin. My focus is now to make jinngine as robust and testet for simple 3d java gamephysics, so I would rather have one good feature than 2 shaky ones. But certainly there is a minimum level that must be achieved in order for the library to be useful.
But I will be in touch as soon as I think jinngine is ready for a first try
Well that minimum would certainly be: trimesh support, mass and collision calculation and resting to safe cpu power.
even constraints are not needed for every game
Yes i think that sounds very reasonable. What are you guys primarily using trimesh for, for models or more for landscape/environment? (speaking of physics shapes that is, not rendering) I think I would personally go for having moving models approximated by compositions of primitives, and mesh for landscapes/environment etc. But I never did a real full-scale game, so I would like to know what other people prefer…
One strategy for non-convex stuff such as a trimesh, is to do convex decomposition of it off-line, and then organize the resulting convex compounds in some BVH. Without having given it much thought, that would be my first angle on the problem. Doing robust collision detection/contact generation is perhaps the most important thing for animation stability and quality, so I often focus a lot on that…
Well I usually have for nearly everything in game a low poly physics model, wich I use for collisions
Making a space game, that is why I cannot often use primitives as a replacement.
(So an intresting feature would be to merge nodes on the fly (aka two boxes next to each other, eleminate the 2 sides that are blocked by the other to reduce faces for collision calculation, but i guess it's wore work than it's worth)
I didn't hear about any updates for a long while, but I noticed that the google project seems to have been receiving updates up until late January, so I assume it is still alive and well. What a great surprise that is
Whenever you have any worthwhile updates to share, do please remember to share them here and we'll see about putting it on a 'bigger poster' 
hi all
Jinngine is still alive, and I am still pursuing my ambition of making a stable release in late summer 2010. But i'll try to put up a new update soon, because it has been quite silent for a while. I'm currently working on my master thesis, which is about doing physics based animation fast and accurately. As always, I'm trying to make all my study efforts end up in improvements for jinngine. So, besides the thesis, i'm currently working on
It's so cool that you manage to make most of your work in parallel with your free time passion. That should make for some worthy working hours: and judging by the repo updates I'd say you're achieving just that
At the time of writing, this engine isn't related to JME in any other way than being written in Java, is that right? But I expect you're planning an integration down the line? If you need any help with that, I'm sure Normen and Falken on this forum could be of great help. Also, you might want to consider skipping JME2 and go straight for JME3, as the alpha is coming out and the code is finally stabilizing a little. Be on the lookout for progress updates.
True, there is no relation except the language, and the application to game physics. I did try to do JME integration at some point back in 2008, but the project consumed too much time and stole focus from what I really should be doing. I think the best strategy is to have someone into JME do the integration part, as you kind of suggest.
Obviously, a lot of stuff will turn up when attempting integration, and it must certainly isn't just going to be missing getters and setters :) The biggest hurtles properly comes from having abstractions on the client side, that doesn't really exist inside the physics library. This could be joint modeling for instance. But i'm sure its possible to do it. I think I should focus on making a new release that has some very basic but robust features in place. Then, it should be easy for someone in the JME team to do a functionally limited integration ( with a lot of "feature not supported" exceptions thrown :). When that integration is stable, we can move on from there.
Hope that sounds reasonable.
Some of the most "missing" things in jinngine right now would be