Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Would anyone be interested in a collision DLL?

Author
Message
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 21st Apr 2012 01:31 Edited at: 28th Oct 2012 06:13
New Post 10/20/2012

I've made an update to the DBC coldet helper dll and DBC include library. You can read about it in my last post with the same date as above.

NOTE: This download doesn't contain any of the example programs. For those, you can get them from the download listed under New Post 05/14/2012 located in this post a little further down.

The new updates to the library can be found here:
Update

You can also find documentation in html format for the DBC coldet library, posted by BN2
here

Though this documentation does not included the latest update as of this writing.

New Post 05/14/2012

Well, after some encouragement from some users here on the forum, I've finally put together a release of a library that helps the compatibility of the ColDet Collision Detection Library by Amir Geva with DarkBASIC Classic. Whew! That was a mouthful.

The download includes a series of examples and media. That makes the attachment 5+ Mb in size. The ColDet archive itself is about 229k and the other files necessary to use ColDet with DBC total about 40k - both relatively small files. The media and examples aren't necessary to run ColDet but they are included in the package to help you get your collision environment(s) up and running.

Get it here

ColDet is a fast collision detection library that has been around for more than 10 years. Here's a quick recap of the capabilities.



I wasn't sure if I should post this here or WIP or the DLL board. I decided to leave it here, at least for now, since it is DBC specific.

Download the attached zip file, unzip into a directory of your choosing, and follow the instructions in Readme_setup.txt

A NOTE about example 11:

Example 11 uses an experimental built in sliding collision routine to return a predicted resulting position based on the parameters given to it. This experimental set of functions aren't perfect and may take some tweaking to get the desired result. A recently discovered nuance in this example is a jumping effect that occurs in corners when a direction key is released. This is related to acceleration and deceleration being calculated with CURVEVALUE() and a collision response generated as a result of getting very close to collision entities.

A simple adjustment for the example is to not use CURVEVALUE() for forward and lateral movement.

Lines 213 and 214 :



can be changed to



Another option might be to keep the curvevalue() portion and set forward# and strafe# equal to zero AFTER the position has been updated.

But take the examples for what they are - examples. They demonstrate most of the functions contained in inc_dbccoldet.dba . The best way to understand them is to write your own short routines and try out different things to get a feel of how to use the library.



LICENSE INFORMATION:
ColDet 3D Collision Detection Library
Copyright 2000 by Amir Geva
is released under the GNU Lesser General Public License 2.1 (LGPL). This includes the binary coldet.dll and any and all of the coldet source code. This is distributed as it's own archive.

My library, dbcwithcoldet.dll and inc_dbccoldet.dba is released under the 2-Clause BSD License (FreeBSD) as a separate archive.

Please read all of the licensing information contained in both archives so that you can understand your rights and the rights you must grant to others should you redistribute ColDet in any form. Note the file labeled "Copying."

Your rights differ for software under the FreeBSD license so please read the included licensing and understand the differentiation.


***************************************************

Original Post 20th Apr 2012
Years ago, I came across the Coldet collision library. It's a simple collision library written in C++ that is supposed to be fairly compact and pretty fast.

At the time, I got it to work with DBC, but really didn't understand it or want to be bothered to make it work consistently or well. Over the last couple of weeks I decided to take another look at it. I rewrote a helper DLL that seems to work nicely with it.

It has 3 basic types of collision:
1. Polygon
2. Sphere
3. Ray

I added a bunch of functions to my helper DLL so that you can get the normals, bounce vectors (ricochet), as well as the built in coldet functions to get collision point and intersecting triangles.

Right now I'm at a sort of a crossroads:

Do I want to continue messing around with this: make a releasable version?
Do I want to just shelve it as I know barely anyone uses DBC anymore?

I just want to gauge how much interest there might be.

If so, it would be nice if anyone had some ideas of what type of example(s) might be useful to show how to use it. If the example doesn't seem too crazy or GIANT, I could probably knock it together to include as part of the release.

If someone has a Sparky's example or a standard built in DBC example that they could post, I may be able to convert it for use with Coldet.

Let me know.

Enjoy your day.

Attachments

Login to view attachments
TDK
Retired Moderator
16
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 22nd Apr 2012 20:00
Quote: "Do I want to just shelve it as I know barely anyone uses DBC anymore?"


That's the big question!

I'm trying to figure the answer to that out myself. I've just spent the last few days rewriting part of DarkIDE so it now accurately highlights lines with errors on them (syntax or run-time) - even if they are in #Include files.

I'm enjoying doing it though I have to assume that all the work I'm putting into it is for the benefit of me and maybe just a half dozen other people max!

But with regards to your dll, I suppose the question has to be "what benefits would using it have over Sparky's"?

If there aren't any then it's difficult to justify all the work involved. If there are any benefits (like speed), I'm happy to help if I can.

TDK

http://www.computechtenerife.com
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Apr 2012 08:37 Edited at: 23rd Apr 2012 08:40
Quote: "But with regards to your dll, I suppose the question has to be "what benefits would using it have over Sparky's"?
"


Well, it has a few different features. The Sparkys dll for DBC has ray vs polygon, sphere, or box collision. The ray collision from coldet seems to be about the same speed and with coldet, you have the option to turn on or off checking for the closest triangle hit which is a bit faster than sparkys.

Coldet can detect:

* Polygon vs Polygon
* Sphere vs polygon
* Sphere vs Sphere
* Ray vs Sphere
* Ray vs Polygon

Coldet natively returns
* The coliding triangles' vertices
* The Collision point
* The index(es) of the colliding triangles

With my helper DLL
* Normals of the colliding triangles
* Bounce Vector for ray collision
* Ability to add and delete collision objects
* Have as many collision objects as you want (limited by the size of a DWORD and memory) that can or do not have to correspond to the object numbers in DBC. A use for this might be to reserve a whole series of numbers just for limbs for collision with animated objects
* The Sliding collision predicted return position (experimental at this point)

There is also box collision burried in the workings of coldet. I'm not quite sure how to "dig it out" and make it available as a callable function. I could implement it myself, but I'd rather use coldet's version, but then again, besides having fun playing with this stuff, I'm not sure if it's worth the effort.

In total, there are about 30 functions available right now in my helper dll. In most cases, one would probably use 4 to 10 of them:

initialize the dll
setup collision
update position and rotation
check for collision
return collision point (3 functions for x,y,z)
return normals (3 functions for x,y,z)

Enjoy your day.
Silverman
12
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 23rd Apr 2012 13:13
(Google translation)
hello latch,

it is possible with your dll to show the limits(bounds) collisions of objects? and also detect multiple collisions (the ray that pierces several objects)?

DirectX 9.0c (February 2010)/ DBClassic v1.13
seppgirty
FPSC Developer
10
Years of Service
User Offline
Joined: 3rd Jul 2009
Location: pittsburgh, pa.
Posted: 23rd Apr 2012 18:45
@ latch
i think it doesn't matter if 1 person our 1 million people find it useful. the experience you get from making something work is priceless for you. gaining knowledge is never a waste of time. i say work on it in your spare time and make the collision DLL the best you can.

@TDK
if you enjoy it, do it.

who knows guys, maybe DBC will make a little comeback.

just my opinion guys

gamer, lover, filmmaker
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 24th Apr 2012 00:31 Edited at: 24th Apr 2012 00:35
@seppgirty
I agree. But it can be motivating when there is interest from others in the work one is doing. It can be incentive to actually get something done.

@Silverman
Quote: "it is possible with your dll to show the limits(bounds) collisions of objects? "


Well, this isn't something built in to the DLL, but it's easy to get. If you know the radius of your sphere for sphere collision, you could just create a sphere object of that size, and ghost it or make it wire frame. For a polygon collision object, you could query the x,y and z size and construct a box using built in commands.

If a bounding box functionality is desired, I suppose I could have a function to return the bounds.

However, it is possible to get the actual colliding triangles positions. You could use that information to draw lines to show the colliding triangles (something I'd include in the examples), or you could even construct a triangle mesh, or manipulate the points through a memblock (that sounds like a good example to include!).

Quote: "and also detect multiple collisions (the ray that pierces several objects)?"

Part of getting a good speed response is returning immediately after a collision is detected. I have a function right now that works like the DBC's OBJECT COLLISION(num,0) that will search through all objects to find collision with object num . I suppose I could rig up a similar function that keeps checking even after the first hit.

The trick here is that to return a varying number of objects from a single DLL function call to dbc, the information would have to be returned in a dynamic memblock (or one sized to hold all possible collision objects). The user would have to be comfortable getting the information out of the memblock OR the memory usage could be doubled by having the memblock write to a global array that the user queries (I'm thinking as I'm typing). It's possible to manage. I could see it being useful for a long range or sniper rifle piercing several targets.

These are some good ideas! They help to clear some of the cobwebs out of the old coconut!

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 24th Apr 2012 07:59 Edited at: 24th Apr 2012 08:02
@Latch-

My answer is a resounding YES. The description you give makes it sound absolutely excellent. So, would this be possible (perhaps as an example):

A landscape is animated by swapping the mesh every frame, out of a large dataset of meshes, using the same index number of the object. A player model collides with the environment with a bounding sphere. There are also other objects in the environment that the player can interact with or shoot or something, using ray collision. At some point, the entire environment is cleared (all objects except for the player are deleted) and an alternate environment is loaded in with a clean slate. This would be incredibly useful for Dark Survival 2 because sliding collision meshes can be swapped, scaled and changed. These things happen with each new level.

EDIT: Just to make myself clear, what Dark Survival 2 does is load in all data ahead of time, then with each level everything is deleted and new objects are put in. Simple stuff like this is beyond the scope of Sparky's DLL without hacks. So, many thanks for what you're doing with this library.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 25th Apr 2012 00:48
@Fluffy

Every separate mesh would have to be setup as a collision object. if you animated your terrain with 150 different meshes, then you would need 150 collision objects for the terrain alone.

The collision is based on the world positions and rotations of the individual triangles that make up an object. You could, for example, have 100 different objects - trees, houses, terrain, etc. And as long as they are static (they don't move around and aren't changed) they could be combined as a single object with limbs - and that can be made into a single collision object. That is called a "triangle soup". This single object could be moved and rotated as a whole once combined, but the individual pieces could no longer be changed.

In the case you mention, you could initialize the collision to reserve 100,000 collision objects. For your swapping meshes, you could keep track of the terrain by assigning collision object numbers 80,000 to 81,000 (or whatever) to be terrain specific. I have the values set so high just so we know the meshes aren't necessarily corresponding to the DBC object numbers (1 - 65535). It may not be necessary to set them that high, it depends on your needs. The more collision objects reserved and especially used, the more memory is used. But you can delete objects as you need.

Right now, the way I have the functions written, the code might look like



Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 25th Apr 2012 23:32
@Latch-

That sounds no different from Sparky's. Why would I use it if I can't reinitialize objects? Perhaps I'm reading your code wrong.

After coldetDeleteCollisionModel is used, can coldetSetupObject be used again on the same object number to define a new mesh?
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th Apr 2012 01:23
Quote: "That sounds no different from Sparky's. Why would I use it if I can't reinitialize objects? Perhaps I'm reading your code wrong."

The main difference between Sparky's for DBC and coldet is that there are more collision detection options. Unlike Sparkys, you can detect collision between 2 objects from any angle without casting rays in multiple directions.

Quote: "After coldetDeleteCollisionModel is used, can coldetSetupObject be used again on the same object number to define a new mesh?"

Yes. Though I haven't timed deleting and recreating collision objects in rapid succession, entire terrains tend to be quite high in polygons. And one of the main bottle necks is the MAKE MEMBLOCK FROM MESH for every mesh that has to change. I tried it in sparky's for a simple animated object and performance was killed. I think it would be similar in coldet.

It sounds like I need to do a test or two!

In general, height on a terrain is calculated based on what tile you want to get the height of. It's not usually done by going through a collision detection routine where objects and or triangles are tested one at a time. You usually know exactly what tile you are over based on the 3d position. Then you use the dot product based on the positions and height od the triangles in the cell.

Anyway, a cheat you may want to try, which may not be much different than setting up a collision DLL, would be to create a matrix off screen that is the same size as your mesh terrains. You have an offset to the location of the offscreen matrix and you use GET GROUND HEIGHT from there but reposition your object or camera on your mesh. Just a thought. You change the heights of the off screen matrix by using an array with values of your mesh heights.

Enjoy your day.
Silverman
12
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 26th Apr 2012 16:09
Latch, you can announce a date for release an alpha version of your dll?

DirectX 9.0c (February 2010)/ DBClassic v1.13
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th Apr 2012 19:45
@Silverman
I keep tweaking it and trying different things... I have a tendency to always keep things in an "experimental" state. I think I could reasonably release something this weekend - maybe by Sunday or Monday.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 28th Apr 2012 06:09
@Latch-

Quote: "Though I haven't timed deleting and recreating collision objects in rapid succession, entire terrains tend to be quite high in polygons. And one of the main bottle necks is the MAKE MEMBLOCK FROM MESH for every mesh that has to change. I tried it in sparky's for a simple animated object and performance was killed."


Well, at least it's possible. Just make sure this is an easily accessible feature. Loading new levels usually depends on this principal.

Quote: "It sounds like I need to do a test or two! "


I can't wait!

Quote: "Anyway, a cheat you may want to try, which may not be much different than setting up a collision DLL, would be to create a matrix off screen that is the same size as your mesh terrains. You have an offset to the location of the offscreen matrix and you use GET GROUND HEIGHT from there but reposition your object or camera on your mesh. Just a thought. You change the heights of the off screen matrix by using an array with values of your mesh heights."


That is a very interesting suggestion, although it wouldn't work for stairs, large and complicated environments, or certain 90 degree slants.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 30th Apr 2012 10:21
@all
I'm going to have to push the first release forward a day or two as I haven't had any time this weekend to do anything on it.

@Fluffy
Are you trying to animate a terrain by swapping meshes each frame, or are you trying to reuse the same collision object numbers for each level reset/reload of objects?

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 1st May 2012 01:18
@Latch-

The second thing. The first thing might be cool just as a demo, though, like for volumetric fluids and stuff (baked in Blender as a series of meshes).

Anyhow, why not try to make a physics library with this? You would only need a few variables.

You would need arrays holding the angular velocity, directional velocity, mass and other stuff for each object, then compare object positions to one another and modify their angular and directional velocities based on their position relative to one another, and of course you would have to assume that an object's origin is its center of mass.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd May 2012 03:45
Quote: "The second thing. The first thing might be cool just as a demo, though..."


Ah! Then I misunderstood you. I thought you were trying to animate the entire terrain in real time by swapping meshes frame by frame in which case you would need to have a collision object setup for each different mesh/frame in order for the collision triangles to be registered.

If it's at level changes, you could reuse the collision object numbers, just delete the collision object before setting it up as something new.

Quote: "Anyhow, why not try to make a physics library with this? You would only need a few variables.

You would need arrays holding the angular velocity, directional velocity, mass and other stuff for each object, then compare object positions to one another and modify their angular and directional velocities based on their position relative to one another, and of course you would have to assume that an object's origin is its center of mass."


For now, I'll just stick to making sure the collision is working.

What I'm stuck on at the moment is building a sliding collision function so that you automatically get the updated position you want. There's a problem with the objects going through the "cracks" at the edge where two triangles meet - or collision with one triangle pushing the destination through a nearby triangle or object.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 2nd May 2012 20:26
@Latch-

Quote: "If it's at level changes, you could reuse the collision object numbers, just delete the collision object before setting it up as something new."


Great!

Quote: "What I'm stuck on at the moment is building a sliding collision function so that you automatically get the updated position you want. There's a problem with the objects going through the "cracks" at the edge where two triangles meet - or collision with one triangle pushing the destination through a nearby triangle or object."


That sounds like trouble. I was having the same problem with Sparky's, where the downward ray could easily fall between two polygons and the player would fall through the level. I hope you can take care of the problem.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 3rd May 2012 15:08
To : Anyone interested in where I am with the DLL in general and the built in sliding collision function I'm attempting to add...

Well, after racking my brain trying to come up with the "perfect" sliding collision function, perfect meaning a function that would work with any 3D model, I've given up on that quest. I've been forced to face what I was hoping to be able to get around: THE COLLISION MODEL MATTERS ABSOLUTELY!

In a nut shell, if the geometry of your model doesn't flow, then your collision response may suffer. When I say geometry, I mean how the triangles are put together and laid out and make up your model.

There were two angles I approached the problem from: simple and complex.

Simple, is very similar to the sliding collision example that comes with the DBC help files. Basically you check in the X direction for collision, then the Z direction. If there is collision on that particular axis then you don't update that axis' movement or return it to it's previous position. This almost always works - especially well when everything is at 90 degree angles - but when the angle of collision is not 90 degrees, you'll get a hopping or jogging effect.

Complex. This can take many forms. The basic idea is to change the vector of motion to become parallel to the wall(face) you collide with.

But what happens when there are holes or cracks in the geometry? Weird stuff! Lets say you had a fence. You modeled it to be made up of slats. It looks real nice in 3D. Let's say you used a ray or a sphere to test for collision with the fence. The ray may miss all the triangles completely and you could slip right through spaces between boards. The sphere could collide with the edge of a slat instead of hitting clean with the outward face and return a normal that points in a very wrong direction, not to mention a collision point that may not be where you would expect. And there's always the chance of moving faster than the width of the fence. If you were using sphere collision or polygon collision, you may miss the fence altogether or collide with a face on the other side that points the rebound in the wrong direction.

And how about a crate that isn't quite next to a wall. If you "kinda" try to go behind it, the collision may hit the back of the crate and adjust the resulting movement vector to be through the wall.

What does all of this mean? You have to carefully plan the method of collision detection and likely Build two models. The first model is your fancy 3d model made however you want with all kinds of intricate spaces and objects. The second model should be your dull and drab collision model. It's meant to keep your camera and or characters from going where they shouldn't. A fence becomes a long angled box. A group of crates becomes one big impassable cube. Make sure there are no gaps or cracks to slip through. Link the geometry together solidly. Don't overlap triangles that may confuse the collision response. This collision model will be hidden or, in the case of coldet, made into a collision object and the actual object gets deleted. Anyway, I thought I'd post this while I was thinking about it. You may not need a separate collision model if you build your main model(s) very carefully. If you do use a separate collision model, you should make it as simple as possible. The fewer triangles that have to be checked, the faster your collision checks will be.

As I keep rediscovering, DESIGN is extremely important. If you don't design your 3D worlds well, there's something bad waiting around the corner to slow your progress down.

Anyway, now that I've pretty much decided that sliding collision is dependent on a well designed collision model and my function can't apply to every scenario, I can start cleaning up the code a bit and finish putting together some examples. I'm sorry for saying I'd release this by May 1, but it looks like it may be more likely to happen this upcoming weekend. I'll try and hurry up as I get little pockets of time to do stuff.

Enjoy your day.
seppgirty
FPSC Developer
10
Years of Service
User Offline
Joined: 3rd Jul 2009
Location: pittsburgh, pa.
Posted: 3rd May 2012 18:57
sounds great latch. i'm sure people will find this useful. i think the more info and tutorials you do. the more people will want to use this. keep up the good work.........

gamer, lover, filmmaker
chafari
Valued Member
13
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 4th May 2012 16:23
Hi there
@Latch I use Sparky's like most people ...but I like the idea ...good luck with your dll .

Cheers.

I'm not a grumpy grandpa
Silverman
12
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 4th May 2012 18:00
@chafari,

sparky is only a raycaster, collisions built in DB Classic are slow and imprecise (see buggy sometimes). So the dll "coldet" is welcome. See the first post for the feature of "coldet".

DirectX 9.0c (February 2010)/ DBClassic v1.13
chafari
Valued Member
13
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 4th May 2012 19:43
@Silverman perhaps you are right...I use it a lot in Dbpro, but for Db clasic ,I just have the sample that came with the sparkys's for DBC...any way the Dll will be welcome .

Cheers.

I'm not a grumpy grandpa
Fluffy Rabbit
User Banned
Posted: 4th May 2012 21:43
@Latch-

I am thrilled by your honesty. If it worked perfectly, it would be too good to be true or too complex. I do ask that you retain the "simple" collision function alongside your others. I'm OK with the hopping.

Thanks.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th May 2012 23:17
@All

Hey, thanks for the encouragement, people! It actually has me a bit motivated. I may actually get this finished instead of playing with it and changing it endlessly.

Yes, coldet does offer a couple of more options than sparkys for DBC, but I wouldn't say it is better or worse. It is, after all, only a collision library. The user still has to build their game and make sure everything works as they want!

Quote: "I do ask that you retain the "simple" collision function alongside your others. I'm OK with the hopping."


I'll put in a flag in the sliding collision call that will allow the selection of either method. Or should I just make TWO separate functions?

Either way, I'll still consider the built in sliding collision as experimental.

@silverman
You wondered if there would be a way to query for bounding area. While I haven't built this into the helper DLL yet, I'm not sure if I will because I'd have to keep track of the bounding boxes and I'm not sure how to pull this out of coldet itself without rewriting the code, I will include an example of how to display the colliding triangle(s) and bounding spheres.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 5th May 2012 00:36
Quote: "I'll put in a flag in the sliding collision call that will allow the selection of either method. Or should I just make TWO separate functions?"


Probably two different functions, but only because I'm assuming that's faster to make. To me, it doesn't matter.

Ooh, I can't wait!
Silverman
12
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 6th May 2012 14:21
@Latch

for object bound, I'll try to do what you described in your previous post. However I want to know if "coldet" can return the type of collision for each object (box, sphere, or poly), and the radius of collision in each direction (X, Y or Z)?

DirectX 9.0c (February 2010)/ DBClassic v1.13
Fluffy Rabbit
User Banned
Posted: 6th May 2012 19:32 Edited at: 6th May 2012 19:33
@Silverman-

To determine the axial collision radius, simply subtract the point of collision from the object's current position (after collision).
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th May 2012 00:10 Edited at: 7th May 2012 00:36
@All
The first release (is that an alpha?) will be soon... I'm still doing some code cleaning and bug hunting. Found a couple small bugs that were show stoppers in my code so far! It's amazing how you can stare at something for days and not see anything wrong and keep yelling at the computer "why aren't you working?" - though the computer says nothing! Anyway, some code had A-A when it should've been A-B . What a difference that made!

@Silverman
Quote: "However I want to know if "coldet" can return the type of collision for each object"

The collision type isn't controlled by a flag. You call the collision type directly when you check for collision. You'll understand when you see the library. For example, you can test for collision with the following calls:



Quote: "...and the radius of collision in each direction"

You control the radius within which to check for collision. The actual collision points are returned but may be less than the radius you are checking ( if you are 4 units away from a wall but are testing sphere collision within 6 units - you'll get detection at 4 units).

If you are doing polygon collision, the collision is Face vs Face so the bounding areas are formed by the points that make up the intersecting triangles. Internally, coldet uses box and radius testing before it breaks down the result to points or triangles, but these functions aren't exposed to the DLL.

You don't have to create a collision object to use collision detection with coldet. For example, you could load a humanoid object into DBC and use sphere collision for it. To find out what the collision radius would be that DBC would use for it's own collision detection, you can use the built in command:



Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 7th May 2012 00:19
@Latch-

Quote: "The collision type isn't controlled by a flag. You call the collision type directly when you check for collision. You'll understand when you see the library. For example, you can test for collision with the following calls..."


So much power! I can't wait for the release of this library. Do you have a new estimate for a release date? Maybe like tomorrow?
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th May 2012 00:42
Quote: "Do you have a new estimate for a release date? Maybe like tomorrow?"

I was hoping to get it done today but I have to go out shortly. Keep your fingers crossed for tomorrow! I don't know where the time goes... I thought I was done with this a month ago! But there's always some little something that keeps getting in the way - mostly not having a consistent amount of time.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 7th May 2012 02:18
@Latch-

I completely know what you mean. This will be awesome when it comes out. I think I have a free schedule tomorrow, so I'll be waiting around.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 11th May 2012 01:53
I'm still slugging along. All I can say is release will be soon.

I ran into a snag of sorts. If you have an object with lots of polygons, I'm not sure of the count limit - maybe 10,000 or more - and it has no limbs or very few limbs, all/most of the polygons belong to one mesh, it may load into DBC, but it won't be able to be converted to a mesh (and the object size functions won't work) and thus the triangles can't be set up in coldet.

However, it seems that if the object is divided into many limbs and the limbs share the burden of the polygon count, then the object can be converted to a mesh.

FPS wise, you get better performance without limbs in DBC in general. So there is a trade-off.

I was wondering if anyone has written a direct x file to memblock converter. What this would do is "rip" the meshes out of a direct x file and save them in memblock mesh format. If you have the code laying around somewhere, it may be useful in getting around the limb situation described above. I've got code that does some aspects of this, but it's not this specific and I don't have the time now to tweak or write another x file parser. So if anybody has code like this sitting somewhere, that'd be cool if it could be incorporated into the project. But, this issue isn't a show stopper - just an inconvenience at this point.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 11th May 2012 19:41 Edited at: 13th May 2012 20:44
@Latch-

With regards to Dark Survival 2, you could release an alpha version of your collision library now. Setting up the meshes at load time would be a bit of a nuisance. That's not how the Dark Survival 2 engine works. Also, a level is made up of a bunch of different meshes. So, the X-to-memblock converter is unnecessary.

EDIT: Also, imagine all of the disk access.

1) level.3ds is loaded by DarkBASIC (read)
2) level.3ds is converted to DirectX format (read, write)
3) level.x is loaded by Coldet (read)

5 minutes and a head crash later, the object is loaded in. I suppose a little bit of disk access could be saved by doing this:

1) level.3ds is converted to DirectX format (read, write)
2) level.x is loaded by Coldet (read)
3) Coldet's memblock is converted to a DarkBASIC mesh

However, the biggest problem I see is a logistical one. DarkBASIC's built-in primitives are not DirectX meshes. So, logically, whenever they are used, Coldet would generate a memblock from a primitive object. This differs from loading a mesh from the HDD, doesn't it? I don't know where I'm going with this, but it just seems like you don't need those new features and I'd just like to see a preliminary release now, as the wrapper is.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th May 2012 21:11
The first release is in the top post.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 14th May 2012 21:46 Edited at: 14th May 2012 22:44
@Latch-

This is a dream! I will post my results as soon as I've tested out the examples.

EDIT:

Example 1 (no-frills polygon collision detection) - 23-100 FPS, and with quite a few objects I must say

Exampe 2 (adapted sparky's example) - unconditional maximum monitor FPS of 100. Wow!

Example 3 (laser reflection) - like a similar example in Sparky's, it runs smoothly

Example 4 (factory) - relatively complex environment, constant 33 FPS (possibly not accurate)

Example 5 (landscape) - complex and beautiful environment, same performance as last example

Example 6 (bouncing bals) - possibly the most amazing example I've ever seen with DBC, again with a constant (and possibly false) 33 FPS

Example 7 (object picker) - seems to work OK, smooth performance

Example 8 (matrix editor) - a matrix editor! Smooth performance, but the mouse doesn't always seem to line up

Example 9 (running gobin) - constant 50 FPS (possibly inaccurate). Incredible! Absolutely incredible. It's just so far out there, and it may very well take me days to figure out how it works.

Example 10 (factory FPS) - same performance as landscape, and a solid example. Also quite jittery on some angles, but never do you pass through any objects. Very solid.

Example 11 (factory FPS with built-in collision) - same performance, less jitter, but when I push into a corner and release, I get rebounded to the end of the polygon. I would trust the ray-only method instead.

Overall, this is a damn good collision library. It beats Sparky's in any area. I will definitely try to implement this into my game engine ASAP, and possibly a large number of my other games. The potential here is very high.
29 games
13
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 15th May 2012 00:34 Edited at: 15th May 2012 00:35
This is an awesome effort. The demos are really good and the code is easy to follow with lots of helpful commenting.

In terms of performance, all the demos restricted to 40 fps I get a constant 40 fps on my four year old lap top (which is always good). The first demo did anything from 30 to 60, although was constantly over 40 when I remmed out the "_show_triangles" sub-routine. I think the lower frame rate, compated to the other demos, was the shear number of objects on screen rather than just the collision detection.

I'll have a bit of a play in the next couple of weeks and see if I can come up with something fun.

Once again, awesome effort.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 15th May 2012 05:18
Thanks for testing it out, people!


@All
One thing I didn't do to uncap the FPS limit in DBC was to load and play an mp3 file at the beginning of each demo. This will allow the FPS to go beyond the monitor sync limit. Don't worry, this won't redraw the screen faster than your monitor can, but it will allow your loops with SYNC in them to run as fast as possible.

@Fluffy Rabbit
Most if not all performance issues are due to "taxing" DBC a bit in some of the demos. I use a lot of lighting, layering, ghosting, polygons and such not to mention drawing the collision triangles and/or the impact point.

The Goblin Demo has some menu options where you can switch on and off different options. Try turning the goblin shadow off, set the trees to static, set fps to 0, make sure fog is off, and turn off the sky. This will run that demo at about as fast as it can go. The lesson being that the design of the environment is really what will drive performance.

For the factory sliding collision demo 2, I'm curious about where that rebound is occurring. I chose the factory model for 2 reasons:

1. I like how it looks
2. It has a very difficult environment to test within the limits of ColDet becuase it has so many gaps between polygons and so many individually separated meshes. In Coldet, there is no elliptic collision detection and it's hard to predict how collision with the edges of polygons will react- the collision point changes a bit and the normals may be from an adjacent face pointing in the wrong direction - causing jumping to the end of a face for example.

You may try increasing the radius# variable to something like 4 and see if that makes a difference. It definitely takes tweaking to get the built in sliding collision to work. The best way, as I mentioned in a post above, is to create a special collision model that is very basic and use that for collision detection while displaying your detailed model.

Quote: "...a matrix editor! Smooth performance, but the mouse doesn't always seem to line up..."

There's a "snap to" distance equal to the radius of each sphere assigned to a matrix point. So if the mouse is close enough, the red cross will appear at the nearest vertex. You can increase or decrease this radius. If the radius is too big, it'll be harder to select points further away from camera. If it's too small, you'll have to have the mouse positioned precisely in order to select a vertex.

@29 games
Quote: "This is an awesome effort. The demos are really good and the code is easy to follow with lots of helpful commenting."

Thank you.

Quote: "In terms of performance, all the demos restricted to 40 fps I get a constant 40 fps on my four year old lap top (which is always good)"

The 40 fps limit is just to show that a reasonable FPS can be maintained even when DBC is pushed. The ColDet library really has a pretty low impact. I'm still surprised at how fast it is.

Quote: "...when I remmed out the "_show_triangles..." "

The triangles in that particular demo were drawn with the LINE command which is notoriously slow in DBC. It's definitely not a reflection on the speed of the collision dll.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 15th May 2012 06:34
@Latch-

It sure sounds like there are a lot of variables, which brings me to a bit of a problem in fact.

Well, I've tried to implement your Coldet wrapper into the Dark Survival 2 engine, but as far as I know so far, my absolutely 100% perfect code seems to be having some kind of allergic reaction to the library, and the player can pass through everything. Consider it a kind of game. I call it, "find the singular bug that is causing my program to not work". Attached is the complete project, with source and a compiled binary.

Thanks in advance.

Attachments

Login to view attachments
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 15th May 2012 22:14 Edited at: 15th May 2012 22:21
@Fluffy
Your code doesn't seem to work beyond collision detection. A selection from the menu stops the game. I noticed a couple of CLEAR RENDER VIEW commands that are undocumented commands and may be iffy (running your program crashed my computer every time) - I think the crashing is also related to a DELETE SPRITE command.

Delete Sprite can cause problems under circumstances I can't quite remember, but I think those circumstances exist in your code - cause I can avoid the crashing by commenting out the delete sprite and the clear render view.

There are no comments in your source so I don't know what the program is trying to do. You have no error checking with the collision code so you are not checking if your collision objects are being set properly or at all.

Overall, there are too many small challenges in the code itself to decipher a solution without spending hours/days pouring over it. One place to start would be commenting the heck out of it. You'll thank yourself later for doing that because you won't remember what is what when you shelve the program and then come back to it some time in the future.

On another note relating to sliding collision example 11:
Quote: "... but when I push into a corner and release, I get rebounded to the end of the polygon."


This seems to be related to me having used curvevalue() for the forward movement and strafing. The movement keeps creeping at such small increments after you release the key, the camera gets just close enough to invoke a collision response - and that response keeps happening until the object moves beyond the event horizon - so to speak. So the repositioning seems to happen along the edge of a triangle.

It's easy to correct in DB code - when there's a collision, after updating the sliding position, set forward and strafe to 0 to stop any additional movement. This will slow the sliding down along objects but will prevent the jumping on release and also seems to stop jitter.

Another way is to not use curvevalue() for the movement from the start.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 16th May 2012 00:22
@Latch-

Fine, I'll work on fixing my code, but I hope that you can post an example of your wrapper working without the use of curvevalue(), or perhaps with those mathemagical fixes. It is important for people to see that it works. By the way, I examined your bouncing ball routine, and was extremely disappointed with the physically inaccurate code, despite the convincing illusion. I guess I'll have to work on a physics engine myself. It amazes me how ambitious all of this code turns out to be, and it kind of bugs me when there are professional game studios employing dozens of people to overcome little problems like this.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 16th May 2012 04:21
Quote: "Fine, I'll work on fixing my code"

Not sure of the tone of your statement, but I read it as you being annoyed. Why wouldn't you want to make your own code more manageable for yourself and anyone else that may decide to try and help you?

Quote: "but I hope that you can post an example of your wrapper working without the use of curvevalue()"

Good idea.

Quote: "By the way, I examined your bouncing ball routine, and was extremely disappointed with the physically inaccurate code, despite the convincing illusion."

Again, I'm not sure of the tone - sounds like you're taking a shot at me for my critique of your source code. But at any rate, many, if not most, physics type things happening in games are done without physics. If there's no need for the computational overhead, avoid putting it in. In a nutshell, look for the simplest solution.

Quote: "It amazes me how ambitious all of this code turns out to be..."

Don't know what this means.

Enjoy your day.
Silverman
12
Years of Service
User Offline
Joined: 18th Jan 2007
Location: France
Posted: 16th May 2012 16:25
Wow, this dll and examples are amazing, congratulation Latch.

in another post, you said: "There's still lot to do in DBC!"
I agree with you, and you just prove it with your dll, just extend the possibilities of DBC.
And also thank you to you to share the source code of coldet, it will be helpful for people who want to make dll for DBC.

DirectX 9.0c (February 2010)/ DBClassic v1.20
Fluffy Rabbit
User Banned
Posted: 16th May 2012 21:36
@Latch-

Quote: "Not sure of the tone of your statement, but I read it as you being annoyed. Why wouldn't you want to make your own code more manageable for yourself and anyone else that may decide to try and help you?"


I code how I code. I never intended to involve other people with DS2, but if I can get the library working you'll definitely be in the credits whether you help me out directly or not.

Quote: ""but I hope that you can post an example of your wrapper working without the use of curvevalue()"
Good idea."


I assume you're going to work on that. May I suggest something without acceleration or deceleration? It would be a great demonstration on the actual functionality of the library.

Quote: "Again, I'm not sure of the tone - sounds like you're taking a shot at me for my critique of your source code."

That was the overall tone of my post.

Quote: "But at any rate, many, if not most, physics type things happening in games are done without physics. If there's no need for the computational overhead, avoid putting it in. In a nutshell, look for the simplest solution."

That's a disappointment. Nonetheless, you mentioned in the source of the bouncing balls example that you haven't yet tested doing the same thing with the balls set up as collision objects. That sounds like a very interesting proposition. I've been working on doing that, but haven't figured it out. Perhaps you could?

Quote: ""It amazes me how ambitious all of this code turns out to be..."
Don't know what this means."

By ambitious I also meant complicated.
29 games
13
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 17th May 2012 00:53
@Fluffy Rabbit

Just change this:



to this:



and that'll remove the acceleration effect.

I've had a bit more of a play with example 11 and tested it a lot more thoroughly. Yes, there are issues of jittering when pressed on into some corners, especially against complex geometery like the crossed-braced columns or, my particular favourite, going between the crates on the right (from where the camera starts). The mod to the code I mentioned above doesn't really sort this out. Pushing into a right angle corner of the room and I didn't notice any problems.

Having done my own collision and using Sparky's in both DBC and DBP, I would say it's impossible to make a collision detection system that's a hundred per cent perfect. You will always encounter problems with complex geometery or, as in the case of the crates, geometery that is close together. When you start adding in a walk/run function, crouching, jumping, cover systems, moving scenery, it gets complicated and things are bound to go wrong. The trick is to design the levels so these issues don't arise or at the very least minimised. If I was using the level as in the examples I would either push the crates together so the player can't go through them or push them further apart and I'd probably replaced the crossed braced columns with solid columns. It's just a question of working within the limitations of the system.

If I remember DS2 correctly, the geometery of the levels was quite simple so there really shouldn't be much of a problem.


My own experiment with coldet has been a little more modest, just my own version of example 1 just to get the hang of things. I might have something fun in a couple of days.
chafari
Valued Member
13
Years of Service
User Offline
Joined: 2nd May 2006
Location: Canary Islands
Posted: 17th May 2012 02:49
Hi you all
@Latch This dll is a great contribution to the community of Darkbasic Classic...great job

Cheers.

I'm not a grumpy grandpa
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 17th May 2012 03:13 Edited at: 17th May 2012 13:17
@Silverman
Thanks!

@Chafari
Thanks Chafari!

@29 games
Quote: "My own experiment with coldet has been a little more modest, just my own version of example 1 just to get the hang of things."

That's the way to do it. After all, it's a whole new command set.

Quote: "The trick is to design the levels so these issues don't arise or at the very least minimized"

Absolutely! And to reiterate on a tangent I went off on earlier in this thread:

@All
Quote: "...But what happens when there are holes or cracks in the geometry? Weird stuff! Lets say you had a fence. You modeled it to be made up of slats. It looks real nice in 3D. Let's say you used a ray or a sphere to test for collision with the fence. The ray may miss all the triangles completely and you could slip right through spaces between boards. The sphere could collide with the edge of a slat instead of hitting clean with the outward face and return a normal that points in a very wrong direction, not to mention a collision point that may not be where you would expect. And there's always the chance of moving faster than the width of the fence. If you were using sphere collision or polygon collision, you may miss the fence altogether or collide with a face on the other side that points the rebound in the wrong direction.

And how about a crate that isn't quite next to a wall. If you "kinda" try to go behind it, the collision may hit the back of the crate and adjust the resulting movement vector to be through the wall.

What does all of this mean? You have to carefully plan the method of collision detection and likely Build two models. The first model is your fancy 3d model made however you want with all kinds of intricate spaces and objects. The second model should be your dull and drab collision model. It's meant to keep your camera and or characters from going where they shouldn't. A fence becomes a long angled box. A group of crates becomes one big impassable cube. Make sure there are no gaps or cracks to slip through. Link the geometry together solidly. Don't overlap triangles that may confuse the collision response. This collision model will be hidden or, in the case of coldet, made into a collision object and the actual object gets deleted. Anyway, I thought I'd post this while I was thinking about it. You may not need a separate collision model if you build your main model(s) very carefully. If you do use a separate collision model, you should make it as simple as possible. The fewer triangles that have to be checked, the faster your collision checks will be.

As I keep rediscovering, DESIGN is extremely important. If you don't design your 3D worlds well, there's something bad waiting around the corner to slow your progress down."


I chose the warehouse model for it's design. It has a lot of holes and gaps and is tough to work out a generic sliding collision routine that works with it and it's cracks. I wanted to be sure that the sliding would work "good enough" out of the box for this model.

The built in sliding collision routine is meant to be "vanilla" for testing against any model - so the results may vary on a per-model basis.

The built in function is there to use if one wishes. You may have to tweak the parameters and also design a separate collision model to use for complex geometry - or figure out your own method of sliding collision.

Enjoy your day.
Fluffy Rabbit
User Banned
Posted: 18th May 2012 19:47 Edited at: 18th May 2012 20:03
@29 games-

I will work on implementing your solution.

EDIT: So, I finally got it running and anylized it, and found something remarkable. When going straight forwards or backwards, it works perfectly! However, when the strafing routines are called, weird things can happen. That's the problem! All that has to be done is make it so movement in all directions is the same, with no regard to strafing or otherwise. That's what I've done in all of my games so far, and they've never acted up. On a related note, Delta Force: Black Hawk Down behaves much the same way example 11 does with collisions, and it has strange glitches when the player goes to the left or right relative to the camera. All that has to be done is calculate movement in all directions the same way, so:

Step 1: Based on combinations of keys, figure out which way relative to the camera the player wants to go.
Step 2: Move the player in that direction using the MOVE OBJECT command.
Step 3: Check for collisions the normal way.

@Latch-

I agree that the warehouse is a complex model, but perhaps there are significantly worse models to work with. You see, that warehouse model was inspired by the design of a warehouse that actual humans walk through, so it is supposed to be navigatable, but what about in a natural environment, with trees and the like? I've actually found that a lot of games don't handle this too well. Morrowind has terrible collision, Jak 3 uses collision boxes, and Halo has well designed simplistic environments. As far as arbitrary geometry collision with a player in Coldet is concerned, why not just have a collision mesh that represents the bounding box of the player? That's what you suggested in an earlier post.

By the way, I am working on getting the library to work in DS2. Through the use of debugging routines, I found that all of the geometry is being loaded in correctly. Now it's a question of whether there's something wrong with my sliding collision function or the objects are not being placed correctly.
Libervurto
13
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 24th May 2012 16:29 Edited at: 24th May 2012 17:01
I made number six a bit more musical.

This is quite a significant addition to DBC mate! (Your DLL not my plinky-plonky noises )
You should get a mention in the newsletter for this.

WARNING: The above comment may contain sarcasm.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 28th May 2012 20:28
@OBese87
Quote: "I made number six a bit more musical."

That's pretty cool! I like that - well done.

Quote: "This is quite a significant addition to DBC mate!"

Thank you!

Enjoy your day.
Latch
13
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 18th Jun 2012 22:29 Edited at: 18th Jun 2012 22:35
@Fluffy Rabbit
I tried your new version of ds2. No more crashing (which is great). I was having similar problems with this new version that I was having with the old until I tried something... I turned off the analog joystick that was plugged into the computer. There are separate analog commands in DBC for joysticks and I think that the use of joysitck up, down etc. wasn't jiving with the code. Until I figured it out, I was getting really weird behaviour from the camera - non stop spinning, constant going backwards, uncontrollable keyboard responses.

So, you may want to include a routine where the user sets up the type of input device or keyboard keys that they want to use. Others might run into the same problem as me. The analog controls are
JOYSTICK X()
JOYSTICK Y()
JOYSTICK Z()

Enjoy your day.

Login to post a reply

Server time is: 2019-09-17 05:41:32
Your offset time is: 2019-09-17 05:41:32