JiglibFlash is a open source Actionscript 3D Physics Engine. It’s ported by muzerly from the c++ open source physics engine jiglib and uses a part of jiglibX. The SVN source of JiglibFlash can be found here.
The current state of the library is in early alpha and there is no documentation nor tutorials yet. First we will work on some extra ‘features’, like a heightmap and car physics.
The current JiglibFlash demo (click in the screen and use arrow keys and the space bar to ‘jump’) uses PaperVision 3D as render engine. However we will do some architecture changes so that it will work on every 3D open source render engine out there.
The good news is that it’s already available for other 3d physics engines then PaperVision 3D, see Sandy 3D example and Away 3D example. Thanks for that guys!
Since we all have full time+ jobs it’s hard to tell how fast we will advance but we (muzerly mostly atm 
) do our best.
We are also looking for people to join the project team, so if you have some spare time contact me that would be great.
You can reach us at the irc server freenode at channel #jiglibflash or mail me at speedok at gmail dott com.
“One day, one day, full GPU support?”
6 Responses to JiglibFlash 3D Physics engine for AS3
Theo
January 20th, 2009 at 2:23 pm
I love the library!
One question though: How does the Integrate() method’s parameter do? Could it be used to ’skip’ simulation steps?
My reasoning is: could you get away with calling Integrate() every other frame and then interpolate the motion of the scene objects during the in-between frames in some hacky but less expensive way?
I had a go at this but it seems to mess up. Obviously it won’t be a realistic sim but if you have allot of objects it might be just-good-enough.
admin
January 20th, 2009 at 7:16 pm
Aloha Theo,
At the moment we are looking for a propper way to do the ‘timesteps’. This aside, i doubt you will get good results when you skip a frame. If you can join irc server freenode #jiglibflash then we can talk about it in greater detail.
Here’s a little demo of a bit more objects: stresstest demo.
Theo
January 21st, 2009 at 11:06 am
Impressive
I think sacrificing realism and missing a few collisions would be worth it in certain scenarios. Imagine a ball hitting a big enough wall of blocks, as soon as it does, the frame rate will suffer and the game plan changes to keeping the fps up rather than doing good physics.
Another possibility is turning off collision checking on certain frames (might have to keep it on for some objects to prevent half the wall falling through the ground). Are there any other resource hungry checks I could mess with?
I tried the skipping idea out on your first demo, will post some code and try to get on IRC sometime (UAE time-zone). One problem of course is that flash has no threading so when it does do a physics step it will still freeze until completion and thus renders my whole suggestion useless
richard
January 21st, 2009 at 7:01 pm
Hey Theo, look forward to chatting with you too!
I was thinking we really need to separate all the PV stuff out of the core classes. Better usage for all engines and use cases later. I think we need better control of what gets mapped and how depending on use case. For example I might want to use a sphere in the physics engine, but map the position and rotation to a colloda later with more shape detail, but the sphere is close enough for calculations. Can we plan to work this in?
Petit
January 24th, 2009 at 12:31 am
Hi!
Truly amazing stuff!
I’m working on the Sandy team, and I like what I see when using your engine together with Sandy.
How can we join forces? Would it be hard to create interfaces or proxies between the engines?
How about licensing?
Cheers!
/Petit
Milan S.
April 29th, 2009 at 5:49 pm
Hello guys, your Jiglib framework is amazing. Thank you !!
I’ve played a little with that and here is the result:
http://blog.3datweb.com/post/Balanced-ball-game.aspx