Havok for Torque
by Kyle \"DV\" · in Torque Game Engine · 07/02/2008 (11:44 am) · 25 replies
Now that the Havok Physics and Animation engines are available free for non-commefical independant use, there is a way to incorperate this winning technology into TGE correct?
About the author
#2
07/02/2008 (11:50 am)
Just wanted to check and make sure :) thanks for the speedy reply!
#3
07/02/2008 (12:00 pm)
And reading through the voluminous documentation provided by Havok.
#4
07/02/2008 (12:06 pm)
Judging by the documentation I've been reading, it looks like it is easier to integrate than PhysX. Of course, I haven't made it past the 500 page mark...I'll let you know after I've read the full 900 pages of the docs =)
#5
What I'm doing, is using the PhysX resource, and replacing all the PhysX stuff with Havok's, but leaving the code that connects PhysX to Torque in place.
07/02/2008 (12:09 pm)
That's because Havok is better! ;-)What I'm doing, is using the PhysX resource, and replacing all the PhysX stuff with Havok's, but leaving the code that connects PhysX to Torque in place.
#6
Havok needs to be integrated at a low level, and also at an asset level. Using Animation and Physics requires a much deeper integration. Just replacing the PhysX resource with Havok code is going to make your head spin.
Start from scratch...that's my suggestion.
07/02/2008 (12:11 pm)
@Nathan - I'm going on record and stating that your approach is a "bad idea." Trust me on this. Start from scratch with Havok. While I love the PhysX resource, after looking through Havok's docs and demos, the resource you are replacing is more of a "tacked on physics as an after thought."Havok needs to be integrated at a low level, and also at an asset level. Using Animation and Physics requires a much deeper integration. Just replacing the PhysX resource with Havok code is going to make your head spin.
Start from scratch...that's my suggestion.
#7
07/02/2008 (1:47 pm)
That's what I was planning on, but I'm not sure I'll be able to do that without breaking the engine. I guess I could give it a try though, the PhysX resource doesn't have all the stuff that Havok can do anyway.
#8
@Nathan - Read through as much of the docs as you can before your head explodes. Read over the code from the demos. Code your own simple Havok application. Then integrate Havok into Torque.
This is one of the safest ways to implement a 3rd party lib into Torque without breaking the engine. It may not be the fastest, but nothing in game development should be rushed. Especially an implementation of this magnitude.
07/02/2008 (1:50 pm)
If anyone is sick of seeing me post the following...tough!Quote:Read. Read Code. Code
@Nathan - Read through as much of the docs as you can before your head explodes. Read over the code from the demos. Code your own simple Havok application. Then integrate Havok into Torque.
This is one of the safest ways to implement a 3rd party lib into Torque without breaking the engine. It may not be the fastest, but nothing in game development should be rushed. Especially an implementation of this magnitude.
#9
Any URL? just to get a look, I'm too scared to even think getting a look into the needed changes for it.
07/02/2008 (2:04 pm)
Ok, who finished porting it? ;-)Any URL? just to get a look, I'm too scared to even think getting a look into the needed changes for it.
#10
07/02/2008 (2:05 pm)
I agree with Michael, Havok is such a powerful tool, that it will save you alot of headaches to build on a Havok enabled Torgue engine. Plus it means you are less likely to forget to add havok functions to things as your port them.
#11
On a serious note, I have a good idea of what major systems have to be modified. I'm not exactly sure where I would start, but I have a pretty good idea of progression at least.
07/02/2008 (2:07 pm)
I finished porting it my head...does that count? =)On a serious note, I have a good idea of what major systems have to be modified. I'm not exactly sure where I would start, but I have a pretty good idea of progression at least.
#12
It'd be an invaluable resource for independant devs and teams like ours who dont actually have a dedicated coder. This implementation is something ill be doing myself so a guide would prove enormously useful, but i at least have a background in various script langauges like AS/Javascript/Java/PHP and languages like LUA, and ive even dabbled in C++ before. So im sure someone like me would be able to follow along :)
07/02/2008 (6:59 pm)
If it wouldnt be too much trouble to ask, could maybe someone post up documentation of the steps they took to do this sort of thing? It'd be an invaluable resource for independant devs and teams like ours who dont actually have a dedicated coder. This implementation is something ill be doing myself so a guide would prove enormously useful, but i at least have a background in various script langauges like AS/Javascript/Java/PHP and languages like LUA, and ive even dabbled in C++ before. So im sure someone like me would be able to follow along :)
#13
07/02/2008 (7:11 pm)
I second that request. Now that havok is free for independant developers someone should document this process.
#14
07/02/2008 (7:33 pm)
@Kyle and Edward - No one has claimed they have integrated Havok yet. Currently, most everyone is in the same boat.
#15
07/02/2008 (8:12 pm)
@Michael, yeah i was afraid of that, however, some are more proficient in programming than others, and one can only hope, wish, and request, so one can learn :)
#16
07/02/2008 (8:16 pm)
Its that or we hunt shrubberys
#17
07/24/2008 (3:51 pm)
...And after we find the shrubbery, we need to cut down the largest tree in the forest with a herring. =P
#18
The resource that's there for PhysX isn't really the "right" way to go about doing it. For one thing, it's only creating one simulation world, so will only really work for local server games. Secondly, there are some rather crazy hacks in there (the whole sNxActor struct is entirely unnecessary and was a hackish way to get around the deletion of PhysX objects when the simulation is writelocked. Either a queue or simply calling releaseWritelock() gets around this issue in the proper way), and the coupling between PhysX objects and datablocks is a little crazy(a better method is serialization, which PhysX has support for with the NXUStreams). This is merely a list of a couple of small things wrong with the PhysX resource as it exists (not to say that I don't appreciate the resource, as it's a very good starting point for a better integration scheme).
I also wouldn't personally relish separating out Havok's animation system from the physics side of things, since Torque already has an animation system.
I've been meaning to write up a plan post (ala James Ford's post about the AI work he did) about the work I and Tom did on the PhysX integration in BeTheDinosaur, but it'd be a rather massive amount of writing if done right, and combined with work and home life being busy, haven't had time.
* - I'm relatively sure that PhysX also has more features in general than that of Havok (fluids, soft bodies, etc.), and I've seen the same sort of instability problems with complex jointed multibodies in either engine in various games.
07/24/2008 (4:15 pm)
If you're using the PhysX resource as an indication of how "good" PhysX is, you're kind of missing the point. I looked over the Havok docs, and I really don't see anything there that would qualify it as being "better" than PhysX*. I definitely think the PhysX license is superior, though.The resource that's there for PhysX isn't really the "right" way to go about doing it. For one thing, it's only creating one simulation world, so will only really work for local server games. Secondly, there are some rather crazy hacks in there (the whole sNxActor struct is entirely unnecessary and was a hackish way to get around the deletion of PhysX objects when the simulation is writelocked. Either a queue or simply calling releaseWritelock() gets around this issue in the proper way), and the coupling between PhysX objects and datablocks is a little crazy(a better method is serialization, which PhysX has support for with the NXUStreams). This is merely a list of a couple of small things wrong with the PhysX resource as it exists (not to say that I don't appreciate the resource, as it's a very good starting point for a better integration scheme).
I also wouldn't personally relish separating out Havok's animation system from the physics side of things, since Torque already has an animation system.
I've been meaning to write up a plan post (ala James Ford's post about the AI work he did) about the work I and Tom did on the PhysX integration in BeTheDinosaur, but it'd be a rather massive amount of writing if done right, and combined with work and home life being busy, haven't had time.
* - I'm relatively sure that PhysX also has more features in general than that of Havok (fluids, soft bodies, etc.), and I've seen the same sort of instability problems with complex jointed multibodies in either engine in various games.
#19
07/24/2008 (5:47 pm)
At this point I really don't care which physics engine I use just as long as it works on Windows and MAC. PhysX and Havoc are currently Windows only.......I think. We need a physics engine that supports multiple platforms.....any ideas?
Associate Scott Burns
GG Alumni