Archived

This topic is now archived and is closed to further replies.

nuclearglory

C++ Collision Plugin - Now available!

Recommended Posts

Saves you a LOT of time, work, and energy. Get pro grade collision without re-inventing the wheel. Go to our website for full details: http://www.nuclearglory.com/ngc.php (will open in a new window) If you have any questions please feel free to ask here or email us at: admin@nuclearglory.com [edited by - nuclearglory on April 20, 2004 4:48:53 PM]

Share this post


Link to post
Share on other sites
I have a few questions,this sounds something like i might be interested in.If it does what i need for my projects,i''ll buy it first thing tommorow.

(1): My project is a c++/DirectX 9 project,not directX8/8.1
will this collision system work with it? or at least be able to port any of the code(if included) to DirectX9 myself?

(2): Do i get c++ source code or at least a static lib for my cash,and not just a .dll file named what this product is called?

(3): Will i get any c++(DirectX)based examples on how to use this product?

(4):I''m more interested in the ray cast/intersection (as shown in that demo)on your website,are there a couple of c++ examples on using this
stuff?

(5):finally,does this work with only standard static .x file meshes,or would it be fairly easy to get animated meshes(e.g using the standard way of using skeletal animation as in the tiny x sdk demo)working with
this?

Cheers!

Share this post


Link to post
Share on other sites
Greetings,

(1): My project is a c++/DirectX 9 project,not directX8/8.1 will this collision system work with it?

Yes, DirectX is backwards compatible. The DLL calls DirectX from within itself and will work properly if DirectX 8.1 or higher is installed on the target computer. This holds true even if your application is working with higher versions like DirectX 9.

(2): Do i get c++ source code or at least a static lib for my cash, and not just a .dll file named what this product is called?

Currently, the collision system is provided as a .dll file and a .h file. The .h file handles all of the interfacing with the DLL to make the commands easy to call from your application. It's provided as a .dll file to prevent the library from being compiled into the working program in an attempt to bypass our license agreement. However, if you really want a static .lib, just let me know and we'll go ahead and put it in the public package.

(3): Will i get any c++(DirectX)based examples on how to use this product?

The library doesn't require DirectX knowledge or commands to use. So an OpenGL based program (for instance) could make use of the library. In the manual, however, is a chunk of C++ code to pass a DirectX mesh to the library for collision. Also, there is an example framework.h file providing an example setup in C++. If you have any specific questions just feel free to ask.

(4): I'm more interested in the ray cast/intersection (as shown in that demo)on your website,are there a couple of c++ examples on using this stuff?

The usage for all of the commands are covered in the manual. All of the commands are similar in design, so once you learn a few then using the rest of the commands are fairly easy. The tough part is covered in the framework.h file.

(5):finally,does this work with only standard static .x file meshes,or would it be fairly easy to get animated meshes(e.g using the standard way of using skeletal animation as in the tiny x sdk demo)working with this?

The current C++ version only supports static meshes. We do, however, (as a future addition) plan to allow the developer to pass a pointer of a mesh buffer to the collision system. This would allow you to pass the buffer of an animated mesh to the system every frame as the object animates. So, essentially, the collision system would be getting a new static mesh each
time you animated your object. This sounds slow, but, in the realm of passing a pointer, the DLL could just immediately access the buffer information from your program directly, and it should be quite fast.

---

The demo on our website is identical to the version you purchase EXCEPT it times out after a bit each time you start it up. That lets you know exactly what you're getting before you get it.

If you have any other questions feel free to contact me or post.


[edited by - nuclearglory on April 22, 2004 8:19:00 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Why is it Windows/DirectX only? Couldn''t it be just working with a basic mesh definition? Also, what space partitioning method are you using? Can it be fed with a 250000 faces object and still be very fast? You should make a demo colliding against polygon soup. Imho gravity has nothing to do with a collision engine.

Share this post


Link to post
Share on other sites
-Why is it Windows/DirectX only? Couldn''t it be just working with a basic mesh definition?

At the time it was being developed, getting the product released in an expedited timeframe (among other things) was important. The answer to that was DX and Windows. It was being put together as a plugin library for other game engines that used DirectX, so it wasn''t a problem. That was done for the major release version 2.00. So... we will have to rewrite it completely to dump DX and Windows. That will (more then likely) happen for the next major release. (version 3.00)


-Also, what space partitioning method are you using?

I''d say none, but that would make it sound like there were no optimizations. If you were to load up a polygon soup of 100,000 polygons in a single mesh it''s going to slow down considerably. The engine is designed to skip meshes that are out of range. This means that the world would be a composed of chunks of meshes. As those meshes are loaded their bounding boxes are computed. If the moving ellipsoids do not come into range of the mesh then the entire mesh is skipped. There is also a command "DeActivateObjCPP" to completely deactivate loaded objects in the collision system. Along with "ActivateObjCPP" to activate the object. These commands were designed with custom-built optimization and visibility sets in mind. You simply "shut-off" objects out of range to get the speed boost.

We are planning for BSP support in the next major release. Along with a custom-designed "on-the-fly" partitioning system that should save you the work of breaking down your level.

-Imho gravity has nothing to do with a collision engine.

I know. It was a request of a user and one of the co-developers decided to put it in just to meet the request. That was done in version 1.00 --- I actually removed the command in version 2.00 and was almost immediately bombarded with complaints from the BASIC users. So... it was put back in so they had nothing to complain about.

Share this post


Link to post
Share on other sites
I''m working on updated help documents and preparing a static .lib file so you can build the collision system into your project.

On a larger note, we''re soon to be making our in-house game engine to be open source! It is the game-engine we used to build the example for the collision system. So... you will be able to see the full working source of the engine and how the C++ collision plugin has been integrated into it.

The documents I''m working on thouroughly cover where each part of the collision code is in the engine and steps you through each and every collision command as the engine calls them. This will be very useful for understanding how integration works if you want to build your own implementation. And, because it''s integrated into an already working engine, you can copy and paste into your own work. Heck, you can even use our engine if you want.

More info to come as the packages are released.

Share this post


Link to post
Share on other sites