http://3dboxing.com/ob3d/download/
You can't do a whole lot yet but punch a heavybag with different punches.
Still working on the rest.
Edit:
Video
http://www.youtube.com/watch?v=v3piQTMeZDw&feature=player_embedded
Very nice. :) I look forward to seeing it with multi player so I can beat up some of the people (primarily the other devs) on this board. 
darkfrog said:
Very nice. :) I look forward to seeing it with multi player so I can beat up some of the people (primarily the other devs) on this board. ;)
Im looking forward to fight you }:-@
Never play against the developer of a game…they always have cheats. 
…but I could still beat you.
I was actually trying to get the punching bag to knock me over, but just couldn't make it happen…thought it would make for an awesome screenshot.
Got a few questions for ya, how hard was it for you to get physx to work with java, and jme? also why not use jme-physics?
It was pretty hard getting it to work the binding to C++ was the most difficult . I don't use JME physics because
I already have my own little abstraction layer for the 6-7 physics objects I use which is sufficient for now.
How about some videos/screenshots for us non-windows users? 
mojomonk said:
How about some videos/screenshots for us non-windows users? :)
Here is a picture
Cool!
And a video
darkfrog said:
Very nice. :) I look forward to seeing it with multi player so I can beat up some of the people (primarily the other devs) on this board. ;)
Well I'll be using your library (JGN) for networking so now is the time to implement a Trojan Horse :) ..it will be interesting how it will work (JGN).
Baune said:
Well I'll be using your library (JGN) for networking so now is the time to implement a Trojan Horse :) ..it will be interesting how it will work (JGN).
Awesome! Multiplayer in this game is where the fun is really at. Maybe you should make it so like five people can be in the ring at once....sort of a deathmatch boxing experience. 8)
You'll need to write a custom implementation of the synchronization system for your PhysX API, but since I've already written an implementation for jME-Physics it should be really easy and a total of maybe 10 lines of code. :P
I'll check the JME physics to see how it's done. I was thinking about only sending commands from client to client and each client would then run it's own physics sim.
Problem is of course that the simulations would maybe slowly drift apart…and cheating would be easy…I'm not really sure of the implementation yet but I if you synchronized with each packet and each sync packet would be around 5-10kb wouldnt that cause alot of lag ?
Why in the world would you ever need to send 5-10kb per message? That's a LOT and means you're very likely doing something wrong if you're sending that much information per sync message. To give you an example, the standard physics synchronization message in JGN is around 50 bytes which I would consider pretty large. :o
Alright. Curious on how you can sync the entire world with only 50b but I'll look at the JME code. If that is possible it would help alot.
Not the whole world, but each object. However, that would be a bit more for a boxing game as there are additional things to take into consideration, but you should be talking a maximum of 100bytes per player per synchronization message.
But each boxer is made out of approx. 17 bones each one is a physics body.
You would probably sync these properties on each bone :
Rotation (9 floats)
Position (3 floats)
Speed (3 floats)
Force (3 floats)
And I wouldn't be surprised to find a few more.
It takes nine bytes to transfer a float (I think).
So that would be ((17*(9+3+3+3))*9) * 2 =5508 bytes. Then comes all the game logic, like how much health they have etc…
This would be peanuts in a LAN game of course…
A float is made up of 4 bytes and 4 * 18 = 72 bytes, you'd need a short (2 bytes) to reference the "boxer", which gives you 74. You would not want to include things like health and other game logic in synchronization as that would be a waste. You should only send that information as it changes and for anti-cheat you should probably have the information always coming from the server to the clients.
However, each bone would not need that many. A standard physics synchronization message (which even if you needed one per bone) is made up of position (3 floats), rotation (4 floats), linear velocity (3 floats), and angular velocity (3 floats), which gives you a total of 13 floats totalling 52 bytes. You would likely want to create your own custom synchronization message that would synchronize the entire boxer in a single message and I'm assuming you wouldn't have to worry about every bone would you? I'm assuming most of the bones positions and velocities are based on other bones and velocities?
darkfrog said:
A float is made up of 4 bytes and 4 * 18 = 72 bytes, you'd need a short (2 bytes) to reference the "boxer", which gives you 74. You would not want to include things like health and other game logic in synchronization as that would be a waste. You should only send that information as it changes and for anti-cheat you should probably have the information always coming from the server to the clients.
However, each bone would not need that many. A standard physics synchronization message (which even if you needed one per bone) is made up of position (3 floats), rotation (4 floats), linear velocity (3 floats), and angular velocity (3 floats), which gives you a total of 13 floats totalling 52 bytes. You would likely want to create your own custom synchronization message that would synchronize the entire boxer in a single message and I'm assuming you wouldn't have to worry about every bone would you? I'm assuming most of the bones positions and velocities are based on other bones and velocities?
Thanks for your input Darkfrog..
Each bone are connected to two or one other bone through joints. I don't know if you can calculate a bones sync data based on other bones.
There's no such thing as a boxer he is just a pile of bones kept together by joints, a cliassic ragdoll really. So the question must be how to sync a ragdoll.
What I found out about PhysX is that it is pretty deterministic..if two identical sims receives the same input they will behave identically even over longer time.
So if I just send commands from client to client they would maybe behave the same..I could also send a checksum (example, the sum of all velocities). if the
checksum differs then the sims are out of sync..and you could send the megasized syncpacket. What one could hope for is that it wont happen too much.
If every player has a real good connection, like a 2mb connection and a ping <50 , it would probably still be pretty fast even with constant megasync packets but it would cost a lot of $ in bandwidth.
You could also tell players that this game is only for LAN, but that would be kind of a downer.
Right now these are the only ways I see..or I could wait 5 years for the 10000gb connection everybody will have at that time.
52 * 17 bones is still only 884 bytes and for two boxers you're only talking about 1768 bytes. That's really not bad. If you're sending updates 10 times per second (a pretty good update rate) then the server is only sending 18kb/s which is really light. The clients are talking about 9kb/s. These are larger packet sizes then I would want, but since you only have to worry about two players in a boxing game bandwidth is going to be a non-issue I think. I think this could definitely be optimized as I'm sure not all 17 bones are really moving around much. My assumption is that some bones are static in the body (otherwise the player would just fall down into a blob) and are really unimportant to sync. You could probably do some tweaking and get it down to at least like 10 bones that have to be sync'd and then you'd end up with messages 520 bytes instead.
Worst case scenario it's still not going to have that great of a bandwidth restriction on you.
Try synchronizing hundreds of objects in a game for hundreds of players and then you'll see true bandwidth issues.