Yes…I know it sounds stupid but I can't seem to get around it for my game. ODE won't scale to what I want and doesn't provide some of the things I want and I really don't need that complicated of physics for my game except for some rewinding features and such so I've decided to write my own basic physics implementation.
If anyone would be interested in helping with this I would appreciate the assistance but I will happily make this available in my public repository for anyone that wants it. I'm doing a lot of reading about the math necessary to do this and it might be a while before I get back with anything. This is for my space game so it will not include gravity at this point and I'm working this to have good support for JGN as well so I can provide better physics-networking.
Just wanted to post a message just in case someone thinks this is a dumb idea and wants to try to talk me out of it, or is interested in helping. 
…if anyone has a better idea or another API that would provide what I need please let me know. :o
darkfrog said:
.....if anyone has a better idea or another API that would provide what I need please let me know. :o
What exactly is it that you need?
"rewinding features"? What features is jMEphysics2/ODE missing that you need?
I'm pretty sure it doesn't do any 'planetary' gravity. I wanted 'la grange points' and tidal forces… Tidal forces are neat because they can rip a ship apart perpendicular to the planet but perhaps not parallel, the tidal force decreases to the power of 3 instead of power of 2 like gravity. This means small ships can escape into the protection of the tidal forces of a gas giant when fleeing large ships. So you saying you won't need gravity kinda makes me a 'sad panda'.
But I assume I can extend these features easily enough into Java and still use ODE, especially since they will not need to be calculated often.
Could you maybe join the ODE project and add the features you need?
And like I said about the Launch program, aren't you spreading yourself a little too thin to "re-invent the wheel"? Extending ODE would be better than starting from scratch.
Though true in premise there is many aspects of ODE that just won't work for me. I don't need a full physics system, I really only need physics collision handling.
I can't use ODE because of the scaling issues…I have a massive universe and ODE just won't handle it. Further, ODE doesn't handle (at least not well) "rewinding" in time to apply events in the past and get their outcome now.
I would love it if I could use something else…I'm considering taking some ideas from JOODE to build what I need.
err, maybe I got something wrong, but it does not seem to me that you thought a lot about the drawbacks of ode: the scaling problem with ODE in your case would be the collision detection! As you most probably won't have much contacts the constraint solver should not be the issue. It's not the 'full physics' that limits performance but the collision detection of many objects. Or do you talk about something else than performance? If not you will hardly solve your problem with writing a new physics library.
To speed up collision detection you can use spheres only. In a space game you could approximate most objects with a sphere, e.g. because they have a shield. This should speed up collision detection quite a lot. Additionally you should not put everything into the same collision space (currently not supported by jME Physics 2, but would be easy). Furthermore don't use bodies for bullets/lasers. Compute paths yourself and add rays to a separate space that does not collide with itself. Have you tried all this? I think it should scale pretty well.
Note, you may need to use ODE in double precision when you want to simulate more than what one player can see. But it would be better to split simulation up into local areas and use single precision.
Regarding the 'rewinding': ODEs data structures can be altered quickly, so resetting them to a state from some frames before should not be an issue. Why do you think it'd be a problem with ODE?
I'd love it if I could do it with ODE but based on previous testing I've done it just won't scale for all the objects in the scene and it's always seemed to have issues with adding and removing objects to the collision system dynamically. How writing my own will help with this is that I'm not planning to write a system to the degree that ODE is, but rather work with jME's collision system and just have it process the effects of specific collisions. This way I can invoke it for specific objects and ignore other objects. It could be as simple as a method:
public static void processCollision(PhysicsNode node1, PhysicsNode node2)
It would then look at how the two nodes are colliding, the direction and velocity of each, and then process the effect of the collision by changing position, velocity, and direction based on it. This way I can be more selective in the game of who should process what. For example, the server will need to handle collisions between non-player objects, but player to non-player objects can be handled in the client. player to player collisions can be handled on both clients but also get authoritative adjustments from the server if there's a conflict. I will probably handle basic collisions near the player in the client as well, but ignore anything that is further away since it's too far away to see small adjustment lag from the server.
ahem, jME bounding collisions are a whole lot slower than ODEs collision detection. All three available collision detection systems (interal+OPCODE / Bullet / Gimpact) should perform better. If you want to get any usable speed from the bounding collision system you have to organize your scenegraph very well (e.g. Nodes as BSP etc.) - ODE already does that internally.
If you apply the optimizations you mentioned to your ODE test (using ODE collision spaces and probably a custom near callback) it should perform fine. I'd bet it's faster than using jME collision detection.
Does jME-Phsycsi support this? My testing was with jME-Physics 1 and my biggest problem was it could take around one second to remove or add a DynamicPhysicsObject, so it didn't really make it feasible to do that kind of thing on the fly.
Any suggestions are appreciated and if you believe jME-Physics can handle all of this I'm happy to give it a try.
darkfrog said:
Does jME-Phsycsi support this?
no :roll:
But the ODE space part should require a lot less work than reinventing the wheel :wink:
I was already thinking about adding collision groups to the API for this. Each PhysicsNode would get a reference to PhysicsGroup. PhysicsGroup gets a directed 'collidesWith' association to itself. By default all objects would be in the default group and collide with each other.
In ODE implementation this can be mapped to spaces.
I will definitely implement this one day... can't guarantee any particular time frame, though. If you want it now, you'll have to implement it yourself (I'd estimate about 300LOC in 4 Classes).
Well, we're really not talking about a whole lot of work for what I need, but if ODE will be faster (performance and implementation) then I'd rather go that route.
Okay, so if I understand what you're suggesting I could write the implementation in jME-Physics for PhysicsGroup and essentially create a PhysicsSpace per group that could be manually created instead of generated?
Then I could just add and remove DynamicPhysicsNodes to this PhysicsGroup (is adding and removing not going to be a performance hinderence anymore?) for the specific DPNs that I want physics calculations for.
I'm trying to figure out the best way to handle the networking aspects of this as well. The problem I had with jME-Physics-Networking in Roll-A-Rama was that two balls would hit and one of the clients would handle the collision first and bounce off but the other ball hadn't really detected the hit yet, so it would just keep going (because as far as it was concerned the other ball would be rolling towards it and then when it was about to hit it, it would simply bounce back). I'm trying to figure out a way to handle this situation. You have any ideas?
If I could have the clients process the collision but just stop instead of bounce then the server could detect the hit and send information back to them telling them to bounce back…this would also resolve some cheating issues on the client.
Ok, do that then 
is adding and removing not going to be a performance hinderence anymore?
Still left a big question unanswered. :P
darkfrog said:
is adding and removing not going to be a performance hinderence anymore?
adding and removing should be fine, if not we can certainly improve that
Okay, I'll see if I can't do something with this sometime this week.
Honestly I'd much rather let a physics engine handle a lot of this than bother with it in my own code.
Thanks!
irrisor said:
ahem, jME bounding collisions are a whole lot slower than ODEs collision detection. All three available collision detection systems (interal+OPCODE / Bullet / Gimpact) should perform better. If you want to get any usable speed from the bounding collision system you have to organize your scenegraph very well (e.g. Nodes as BSP etc.) - ODE already does that internally.
If you apply the optimizations you mentioned to your ODE test (using ODE collision spaces and probably a custom near callback) it should perform fine. I'd bet it's faster than using jME collision detection.
After reading this thread, I think I'm going to re-eval JmePhysics2. My game is very simple and current I have Controllers doing simple physics and collision detection using the built-in JME stuff. What I'm wondering is how ODE scales. Since you've used ODE a lot, do you have any estimates on a higher-end number of objects you've simulated with ODE in a game environment? A quick guess on how well ODE scales with object triangle counts would be very useful too if you can estimate off the top of your head.
The next game I have in the design phase could potentially have 1000's of simple (< 20 tri's) objects which are added and removed by the players dynamically in-game. I have some object coordinate/map info that I was going to use to significantly reduce the calls to JME's calculateCollisions. Is there any way for me to assist ODE with reducing collision checks or is it just so fast it's not worth it? I know I need to RTFS with JmePhysics2 :P (and I will once my dev machine is up again) all I'm really looking for is a yes/no/maybe answer.
Another question, is there a standard ODE/JmePhysics way of preventing missed collisions due to objects moving too fast related to the physics stepping? IIRC most people suggest adjusting ODE's physics stepping to make it more fine grained, but doesn't the speed of the physics system have to be in tune with fps and system resources? I had planned on using JME's collision code and comparing a node's position delta against it's bounding sphere size. If the node moved too fast, I would sub-divide the move and process collisions multiple times. This is for larger object movement and client/server issues, I plan on using rays instead of collisions for projectile objects.
Thanks!
The majority of my concerns have been due to ODE not scaling well. However, I think that's really the case with all physics engines.
If I can do what Irrisor suggests and add and remove objects from the physics environment on the fly without taking a performance hit then I can simply manage objects within a certain range of the client and the server can maintain the larger scale scene but will just use collision detection to keep things from flying through each other for most of the universe.
Well anytime you need 'fine' detail collision detection I always recommend a separate thread that does path prediction collision detection. I also think all collision detection should be sphere based up until a sphere collision is detected, then a finer polygon/ray/etc collision detection should run. This is more for a space game though where collisions are easier to predict and spherical collision detecting fits nicely most game models well.
When I first learned OpenGL in school we used glut, and I made a damn fine collision detection system for a "3D curling" game, normal curling is this game where you slide rock down ice and try to get your rocks near the center of this circle (mainly a Canadian game). Teams take turns, you can knock others out of the circle etc. Well its pretty boring but I thought a 3D version would kick ass. So i made 3 collision systems,
:a real-time spherical collision (errors sometimes, fastest & simple)
:a real-time polygon collision system (lots of errors, slow, complex)
: and then my threaded prediction algorithm that used spherical up until that collision was detected, then it switched to polygon detection for a bit (very complex, fast, no errors!).
So thats how I'll be making my collision detection system again using jMEphysics2… hope that helps someone.
I'll try to comment on some of the points:
- number of tris
should not matter! Usually you shouldn't use triangle accuracy for physics collision. If you do the physics collisions with triangles (number of tris does matter), there should be fewer triangle for collision than the displayed triangles, if possible.
- number of objects
Using up to hundred objects which often collide with each other (probably most of them permanently) is possible. Using a few thousand objects which can collide with each other but do so seldom is ok, also. If you have thousands of objects (e.g. bullets) which do not collide with each other but do collide with other few objects (e.g. ships) you can use a lot more objects (currently not supported via jME Physics 2 - see above).
- coordinate/map info to reduce collision checks
ODE already does that, depending on the kind of space you are using (jME Physics 2 ODE binding uses hash space).
- preventing missed collisions
In ODEs internal collision detection (used by jME Physics 2, currently) you would usually circumvent this by either adding rays from the last position to the new one, or by extending the collision geometries (e.g. replacing a sphere with a capsule from old sphere position to new sphere position). Another possibility is to replace the collision detection with a continuous library (e.g. bullet), these don't use steps.
- separate thread
using a separate thread for collision detection can improve calculation speed on multi-core systems, but cannot buy you accuracy
- using approximations
this is usual, but it does gain speed only, not accuracy