So, With the latest checkin of the JBullet integration, it's kinda become clear to me that I'm in a bit of a 'hurry up and wait' mode with JBullet. There's still a few bugs I know of (odd force/torque application problems, materials properties un-mapped) but there's also a bunch of features that JBullet just doesn't have at the moment, and may not for quite some time. (Joint motors, certain joint types, breakable joints, ContinuousDynamicsWorld and a few other key features that make the Bullet Physics library so nifty.) So, I kinda forsee the pace of development on this JBullet integration slowing significantly, since it will continue to have some big gaps for the forseeable future. Don't get me wrong. You guys pipe up with bugs, questions and/or problems, I'll gladly help out, but I'm convinced that this JBullet implementation is going to be a bit ugly for a while. That said, I'm kinda chomping at the bit to really get into another physics implementation, though it'll likely require native bindings. Shudder I do better when I'm multi-tasking and can switch my attention from one set of problems to another when I need a break.
- The bridge demo was nice as a 'cut scene' more for cinematic effects but I want to drop a building on somebody. OpenCL is scheduled to be introduced in Mac OS X v10.6 ('Snow Leopard'). Havok showed FAR more impressive stuff themselves. This isn't about PhysX versus Havok, in that demo the physics sucked- we have already seen that Havok.
- The xtras folder is located in Macintosh HD>Library>Application Support>Adobe>Shockwave 11>Xtras I don't know where you'll find the xtra.
Havok Vision Engine is a cross-platform game engine that provides a powerful and versatile multi-platform runtime technology ideally suited for all types of games and capable of rendering extremely complex scenes at smooth frame rates.
Given that situation and my short attention span, I guess my question is. Which engine do people want to see implemented? And does anybody care if I take a stab at it while I'm cleaning up the JBullet integration? PhysX - Looks incredibly solid and robust, but software support is questionable, and hardware support is NVidia-only. Havok Physics - Looks good, and is likely quite solid, but with several of the features present in PhysX sharded off into other products and potentially evil licensing restrictions. (though integration into JME is free) Also, no hardware support.
Bullet Physics - Again, looks good, but still under pretty heavy development if I'm reading the forums right. OTOH, the similarities to JBullet make the idea of a native integration a bit easier to stomach. Other libraries? Anybody wanna do a Java physics library from scratch? I vote for PhysX, because of the reasons you already mentioned.
It is a great thing, that NVidia is behind PhysX and perhaps there will be support for ATI-chips in the future. I mean: ATI cards have a lot more gpu power than NVidia cards and will rock the future.
They would be even better suited for expensive physics calculations than the NVidia cards. NVidia has to change the architecture to be competitive and then perhaps both chipsets will be more similar, and a PhysX support for both chipsets will be possible. NVidia will not like to do this, but perhaps they have to because of pressure by the game developers. But even without gpu-physics: Multi-core processors are standard today. Have you ever heard that PhysX makes any problems without GPU-support? I can't imagine that, because some many commercial games are using it.
I think what you're seeing is the same wall that a lot of commercial game houses have been seeing. Nvidia's the closest to having it 'nailed down', but companies are wary of shutting out consumers based on their GPU vendor. What Turborilla used for Mad Skills Motocross I thought turned out very well, and they wrote it from scratch. They based it off of this guy.I've not done much with physics programming, but have been following the technology since AGEIA popped up on the scene. You definitely aren't alone in this boat. I personally think Intel and AMD will come out on top since they're offering cross platform opportunities and in the economic climate that physics is gaining ground in, market penetration is everything with high end computers/components being sold less and underpowered netbooks coming up more.
There's a shrinking market for PC physics when you factor in the rise of the consoles and global domination via netbook. That all said, I've said it before, I'll say it again, and Momoko will come in here and yell at me :-@, but OpenCL needs to get up and going on Java so accelerated physics isn't shut away from LWJGL, JME, and other visualization applications. What is the licensing situation like for PhysX and Havok? Say I want to make a game with JME, and JME happens to feature an integration with PhysX. In this case, what does that actually entail?
Can I as an independent developer harvest the full power of PhysX without spending a dime? Btw guys, are you familiar with? Pretty exciting stuff that Skye linked me to a couple days back:) Personally I would just feel a lot more at home sticking to the leading open source solution that is Bullet. Other major OSS like Blender has also integrated it with their game engine.
It is a lot easier to connect with and collaborate with fellow OS projects, so by using Bullet, my job would be a lot easier. If I shoot the bullet guys an e-mail or drop an inquiry on their forum, I'm sure I'll hear back from them.
However if I try to get in touch with someone who truly calls the shots with PhysX or Havok, I'd reckon my chances are rather slim. Maybe the port is not the way to go though, and we would be better off going for a binding. It's a bigger hassle when you just compare the work directly to integrating JBullet, but what about the big picture? When integrating JBullet we greatly rely on a third party to keep up. Unfortunately, it seems the port was not as far ahead as I thought it was, which makes me feel bad for encouraging Falken to continue work that might have not been the right way to go in the first place.
There is a last option though; we could find someone to continue the port, either in collaboration with the current developer or more like a branch for JME if a collaboration proves difficult. Not something to bet on though I suppose. How viable are ports anyways? They are sort of destined to always be a couple steps behind. I always felt like making headway with ever more efficient compatible hooks and bindings was the way to go, just that in this case I was of the impression that we had a fairly complete and accessible solution at hand already, which would be great as 'the first of many'. Edit: Falken224 said: (.)Anybody wanna do a Java physics library from scratch?
Sbook said: What Turborilla used for Mad Skills Motocross I thought turned out very well, and they wrote it from scratch. The based it off of this guy The thought of 'our own' physics library (well in Java anways and hopefully developed in 'close vicinity' of the JME community) is certainly enticing. Thing is, with just basic collision detection and some more, you've already met the needs of many projects. And I've been playing around with the idea for a while. I looked at a couple older abandoned projects, and I was thinking maybe some day soon I'd send out a couple mails in hopes of finding a developer actually willing to make the true 'JMonkey Physics'. I don't know if this is the right time though. Maybe developing it for a shiny 3.0 version would seem more inviting.
Erlendsh said: Unfortunately, it seems the port was not as far ahead as I thought it was, which makes me feel bad for encouraging Falken to continue work that might have not been the right way to go in the first place. Chuckle Don't even worry about it.
It's good ground-breaking work and seemed like the right thing to do at the time. And it's gotten me MUCH more familiar with the concepts you have to deal with in physics engines, which I think is an INCREDIBLY important part of this whole process. You don't complicate things with JNI, or having to deal with the nitty-gritty of actual physics calculations. That said, here's what I wanna do and why: 1) I want to do something useful.
Hardware accellerated physics could REALLY step up the quality for some hardcore physics-heavy type games (racing sims or the like) Thus, I vote for PhysX, even with it's limitations. Otherwise, it's 'Just another binding' 2) But, if hardware accelerated is not a big deal, I fall back to the argument that bindings are ALWAYS going to cause some interesting problems, both in development and in distribution. I'd REEEEEALLLLY want to try coding up a physics engine, despite the incredibly high learning curve. Right now, kinda leaning toward starting up a physics engine from scratch. Might as well do it right, eh?:) That way we KNOW how far along the physics implementation is, and we're not waiting for ports and we're not having to deal with various OS incompatibilities.
I think that's the right way to go, but it'll take a while, and prolly never be as powerful as one of the big libraries. But hey, it'll be pure JME.:) -Falken. With all this talk of OpenCL, I went and checked it out. I guess the Bullet Physics guys are looking at having a preliminatry OpenCL implementation ready by late September. Maybe that's a bit optimistic, but hell.
That's starting to change my mind. Forget PhysX and Havok. I think maybe a straight Bullet Pysics JNI binding is the way to go. Let them do all the hard OpenCL work.
We'll just call their API.:) Hardware (of all sorts) accelerated (eventually) AND open source. Seems like an easy sell to me. Sounds good and well to me At least playing more with proven systems should prove useful before we want to start anything of our own. I still really like the idea of having a native library available, which could be really lightweight, but probably now is not the best time. Falken224 said: I guess the Bullet Physics guys are looking at having a preliminatry OpenCL implementation ready by late September. Where are you getting this from? Playing the wait-and-see game is risky business, so we better not be idling with our hopes up for too long.
I wanted to pop this question earlier though: What about 2D physics? Is this something JME could benefit from? After all, we do also seem to produce some 2D games that require physics, namely Tobias' MSM. There are some nice ports around, like. Contrary to JBullet, this one is actively developed and pretty much on par with the original. I believe there are also a couple java based 2D libraries around, like.
Erlendsh said: Falken224 said: I guess the Bullet Physics guys are looking at having a preliminatry OpenCL implementation ready by late September. Where are you getting this from? Well, right and:) And it wouldn't really be WAITING. Bullet is a perfectly fine physics library to integrate with, whether they move to openCL or not. It'd just be a SPECTACULAR benefit if they did, and since they're the only library that's looking at adopting anything even LIKE universal hardware support, I say go for it.:) -Falken. I vote for a straight bullet integration because of the above mentioned reasons: it's open source, a very active community (so the development of integration can have tough questions answered quickly), a free licence, and it has hardware acceleration CUDA already, but OpenCl is soon to come.
Also because Bullet is perpetually having features added which will be easy to integrate instead of one developer who probably won't be here forever, no offense Falken. Also creating a physics engine from scratch will probably be somewhat lacking features necessary by today's standards (like CCD, hardware acceleration, multiple broadphase, and narrowphase algorithms).
Xtra Havok Physics Scene For Mac
To download XTRA HAVOK PHYSICS SCENEFOR MAC, click on the Download button A Havok cast member is linked to a shockwave 3D cast member. Get the xtra havok physics scenefor mac Firefox browser with Yahoo.
Where do I put it on the Mac? Complete task 'command+option+escape' to force quit open applications. The more substeps, the more accurate the simulation but the slower the performance will be. Xtra havok physics scenefor mac Xtra havok physics scenefor mac Xtra havok physics scenefor mac Havok cast members can be created through Director or external programs like Plasma or 3DS MAX 4-5 with the Reactor plugin.
The first option links the shockwave 3D world to the Havok cast member we just created. Clicked on a application which requires Havok xtra, the error says 'This application requires an Xtra Havok Xtra havok physics scenefor mac Scene xgra either does not exist or failed to initialize properly. I believe Nvidia GPU software updates support game physic's.
The more substeps, the more accurate the simulation havlk the slower xtra havok physics scenefor mac performance will be. Place the shockwave 3D cast into channel 1 in your Score.
Xtra havok physics scenefor mac The Xtra havoo with a library of behaviors to simplify this process. Oh, with the instructions above, where do I get to run Shockwave above all other layers? Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. I've never had to bootcamp yet, so this is out of my expertise. The has a range of resources including demos, downloads, documentation, tutorials, and FAQ.
Xtra havok physics scenefor mac Yes I do play games with my MBP, on some games I get this NOTE: This applicaction requires an Xtra Havok Physics Scene that either does xtra havok physics scenefor mac exist or faliled to initialiize properly. Javascript Disabled Detected You currently have javascript disabled. When finished, click and expand the Animation and Export rollout.
Havok Physics Scene Xtra For Mac 2
Downloaded the Full Installer Mac OSX 10. EDIT: OK, I found a couple possible solutions, but I can't test any without a site that's not working, and I don't know the URL of the site that didn't work for me.