kneeride wrote:betajaen you rock!! This is very cool.
I've been reluctant to integrate a physics engine because it would have been overkill for what I need. I also thought the memory would be overkill because there needs to be 2 scene managers (1 for phsyics and 1 for ogre).
I've been using MOC for ray to mesh but I'm really hanging out for this one:
I'm just working on changing the "node" system a bit. I want it to be more like Ogre's where you can attach multiple objects, and of different types. My system just assumes you want a mesh and does it automatically. I'll probably get to boxes and spheres then.
I'm also aiming for speed. Every microsecond counts.
kneeride wrote:betajaen you rock!! This is very cool.
I've been reluctant to integrate a physics engine because it would have been overkill for what I need. I also thought the memory would be overkill because there needs to be 2 scene managers (1 for phsyics and 1 for ogre).
I've been using MOC for ray to mesh but I'm really hanging out for this one:
I'm just working on changing the "node" system a bit. I want it to be more like Ogre's where you can attach multiple objects, and of different types. My system just assumes you want a mesh and does it automatically. I'll probably get to boxes and spheres then.
I'm also aiming for speed. Every microsecond counts.
Yes I remember reading that article god knows how many years ago I was developing with Geforce 2 and 3 was just out?? I never implemented it in my collision engine at the time it was the last thing on my list but I split from the team I was working with
There are 10 types of people in the world: Those who understand binary, and those who don't...
doing a box -> sphere check is only a matter of checking to see if a points distance from the center of the sphere is below it's radius
No, it takes more than that.
It's possible for the sphere to intersect the sides of the box without ever going near a box corner.
Looks cool, maybe I won't have to modify Moc now to be more efficient (it transforms every triangle into world space, instead of transforming the ray into local space like beastie does).
Any news or updates on this project, or is it elapsed? If so, any recommendation for an alternative? Or is it work stable and simply didn't need any further update?
doing a box -> sphere check is only a matter of checking to see if a points distance from the center of the sphere is below it's radius
No, it takes more than that.
It's possible for the sphere to intersect the sides of the box without ever going near a box corner.
Looks cool, maybe I won't have to modify Moc now to be more efficient (it transforms every triangle into world space, instead of transforming the ray into local space like beastie does).
I'm pretty sure taking all faces from the box and doing face<->center_of_sphere distance is enough: if a point of the box is inside the sphere, then a point of a face must be; then if a point of a face is inside the sphere, then the face's point closest to the center of the sphere must be as well.
Doing face<->point distance is a matter of projecting the point to the plane of the face; then if it's inside it, do center<->plane distance (easy), and if it's outside, you can do point<->edge with the edges of the face.
Of course that's probably not the fastest way to do it though.
Hi,
I have a question about beasty. I'm looking to it because I need to detect a simple collision between meshs and I though I would be able to use it in my scene but at first sight I haven't find any function to move my node in my tree so my question is, do I need to have all my objects static to compute any raytracing with beasty or do I miss in the code ??
Very nice work but is there any mesh scaling function? It seems like the mesh is not scaled properly and the collision is detecting the unscaled mesh...
Maybe some parts of your library are interesting for the sensor simulation of my underwater application. So I can learn from it.
Help to add information to the wiki. Also tiny edits will let it grow ... Add your country to your profile ... it's interesting to know from where of the world you are.
It's because I've literally twisted and turned C++ in a way, it may as well be BASIC. Visual Studio is a bit of a pushover, where as G++ is more hardened against my "style" of programming.
I don't have quick and easy idea of fixing it for you though. The long alternative would be to create a cpp file and declare all the functions in that and remove all the templates; just like proper C++ code.
betajaen wrote:It's because I've literally twisted and turned C++ in a way, it may as well be BASIC. Visual Studio is a bit of a pushover, where as G++ is more hardened against my "style" of programming.
I don't have quick and easy idea of fixing it for you though. The long alternative would be to create a cpp file and declare all the functions in that and remove all the templates; just like proper C++ code.
Darn, I was hoping to write some Python bindings for this. Do you know if I'll run into the same issue with Gorilla? I've got time to kill and need a break from my normal project.
No, Gorilla doesn't use templates at all. As far as I'm aware, Gorilla is multiplatform.
I only used templates like that, so I could reference functions to classes that haven't been declared yet. Like I said; creating a cpp file, with all of the functions defined in it, would be the most appropriate way to go, but at the time I just wanted a single header file.
betajaen wrote:No, Gorilla doesn't use templates at all. As far as I'm aware, Gorilla is multiplatform.
I only used templates like that, so I could reference functions to classes that haven't been declared yet. Like I said; creating a cpp file, with all of the functions defined in it, would be the most appropriate way to go, but at the time I just wanted a single header file.
Awesome! I'll hit Gorilla first and then move back to beastie, as I need a GUI* just as much as I need collision.
I just found something interesting recently. The collision detection become unstable when the mesh uses multiple materials. Do anyone encounter the same problem or is it just me?
Hi !
I'm using Beastie in a little project, and I'm wondering if this library is still under developement.
More specifically, the integration of Paul Nettle work (ellipsoid character controller), which is the only really missing feature in my opinion.
Thanks again for this work,
S.
doing a box -> sphere check is only a matter of checking to see if a points distance from the center of the sphere is below it's radius
No, it takes more than that.
It's possible for the sphere to intersect the sides of the box without ever going near a box corner.
Looks cool, maybe I won't have to modify Moc now to be more efficient (it transforms every triangle into world space, instead of transforming the ray into local space like beastie does).
I'm pretty sure taking all faces from the box and doing face<->center_of_sphere distance is enough: if a point of the box is inside the sphere, then a point of a face must be; then if a point of a face is inside the sphere, then the face's point closest to the center of the sphere must be as well.
Doing face<->point distance is a matter of projecting the point to the plane of the face; then if it's inside it, do center<->plane distance (easy), and if it's outside, you can do point<->edge with the edges of the face.
Of course that's probably not the fastest way to do it though.
i never answered this I realised. You can just use the center of the box and the distance to it's side and the radius of the sphere for the intersect.
There are 10 types of people in the world: Those who understand binary, and those who don't...
I just found something interesting recently. The collision detection become unstable when the mesh uses multiple materials. Do anyone encounter the same problem or is it just me?
I'm experiencing the same problem. I'm thinking that beastie can't properly test collisions on more than 2 sub-meshes...
If someone knows how to modify this behavior, don't hesitate to post the solution !
S.