new collision code

Development directions, tasks, and features being actively implemented or pursued by the development team.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I've got 99% of the work done to use csOPCODEcollider in the game. Then my bleeding edge kernel caused disk corruption on my boot partition. Luckily my source is not on that partition, though i'm not sure where in the journal it left me at. Hopefully all the way done.

I'll continue work today and hopefully none of what i've gotten done so far has been lost.

EDIT:

None of the source work was lost. So i'm still on track for that. I've almost got it compiled, just missing a function or two that no longer exists in CS's Model class. I dont think i'll have a problem with creating them, but i'm looking at our code that uses the colliders and i'm starting to think that VS uses it's collider assuming some basic internal structure of the collider. Like how it makes use of it's meshes and such, and thus may make the debugging phase that much more longer. Maybe i'm wrong though. I havn't run it yet obviously. I've also been told that most of the "special" handling of the collider has to do with hacking together the functionality of the Ray Collider. Opcode should render all that obscolete.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I've been going over a lot of the "user" code in VS of the collider. the opcode collider doesn't use some functions that are present for use in the rapid collider we currently use. I'm at a toss up for trying to emulate those functions in the opcode collider or figure out if the user code has to be more drastically altered to make use of how opcode handles things.

It's going to take a little while for me to figure out what is required of the user code and what is stuff that is maybe redundent to features found in the opcode collider.

I'm hoping now to get the thing in a "testable" state before this weekend. Then maybe some of the developers with more experience in the collider area can help with culling all the hacks and workarounds specific to the rapid collider that we no longer need and any other gotcha's that turn up.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

the thing that's holding me up is the mixture of collidesystem and collider that we do. I'm not sure why it was done, but opcode's distinction between the two is making it frustrating to make as a drop in replacement. I've got to basically make csOPCODECollider a collidesystem even though it was originally intended to be something else. The addition of multiple colliders (treecollider, terrain collider, ray collider, sphere collider) etc, makes it hard to transcribe api's from the Rapid Collider to the opcode collider. I'm still learning how these classes work internally and how they interact with VS .. so it's taking longer than it should, sorry.

In any case, i gotta add some more missing functions to csOPCODECollider and edit them to make use of the fact that they'll be member functions of the collider, and not part of another class.

I'm currently using the little time i've had this week to track down undefined functions during final linking. It's fun. trust me.

If anyone would like to outline what code that uses the collider is related to colliding rays, that would be cool, since once this collider works "emulating" the rapid collider we'll put the ray collider in and add in #ifdef's for using the raycollider to collide rays. This will then be the configure option set instead of --enable-opcode that you'll be able to set to test and compare to regular tree collider.

And of course when the ray collider is great, we'll remove the workaround code and configure setting and use the ray collider exclusively for ray collisions.

Another thing. Is there any good use in VS for the terrain collider? or perhaps the sphere collider or maybe of the other permutations of the tree collider. They would all require some more files to be brought in and etc etc. Right now i think all we need is the tree collider and ray collider.
sfx
Atmospheric Pilot
Atmospheric Pilot
Posts: 1
Joined: Fri Feb 08, 2008 2:35 pm

ray collider

Post by sfx »

Hi,
I am new to VegaStrike, peeking into code atm.
safemode did you have a look at the Beam class, but to be more exact at Unit::queryBSP(...) which is used in Beam::Collide(...)?

##beam.h
class Beam {
private:
...
float speed;//lite speed
QVector center;//in world coordinates as of last physics frame...
...
public:
bool Collide (class Unit * target, Unit * firer, Unit * superunit/*for cargo*/);
}

##beam_generic.cpp
void Beam::Init (const Transformation & trans, const weapon_info &cln , void * own, Unit * firer) {
...
curlength = SIMULATION_ATOM*speed;
...
}
bool Beam::Collide (Unit * target, Unit * firer, Unit * superunit) {
...
float distance;
Vector normal;//apply shields
QVector direction(this->direction.Cast());
QVector end (center+direction.Scale(curlength));
...
Unit * colidee;
if ((colidee = target->queryBSP(center,end,normal,distance)))
...
}

##unit_generic.h
class Unit
{
...
// Queries the BSP tree with a world space st and end point. Returns the normal and distance on the line of the intersection
Unit * queryBSP (const QVector &st, const QVector & end, Vector & normal, float &distance, bool ShieldBSP=true);
...
}

Definition of Unit::queryBsp(...) is in unit_collide.cpp line:689
Last edited by sfx on Fri Feb 08, 2008 5:31 pm, edited 1 time in total.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Welcome sfx nice to see another coder about :wink:

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

the collider functions in the beam class would likely just call ray collider functions in csOPCODECollider. so the beam.h/cpp files will have to be edited.

I'm really almost done with getting it working, i just have had no time to work on it this week, despite my intentions to have it done before the weekend. I'm hoping that my break from looking at it yesterday lets me get in fresh today and this weekend. Really, all i have to do is incorporate some functions from the collidesystem class into our collider like we did with the rapid collider. This may mean adding some geometry, as opcode uses some different geometry than the rapid collider used.

Also, i'm working on dealing with a lot of undefined functions and such during linking now that i'm actually using the collider. Probably stupid errors, since linking without making any actual use of it compiles fine.

I commented out some things in the collider that would mean including some more files that i'm probably going to have to include.

basically the game sends an array of vectors that form a triangle to the collider.
the game then resets the collide pair (a static growing array in the collider class, indicating colliding meshes).
The game then calls for collide()
if true, it gets the colliding pairs and does things with them

repeat. That's how i understand it anyway, correct me if i'm wrong.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

I'm not sure, but I think that ray collisions were done with BSP since it was faster than the old CS collider.

If we could combine everything into the new collider and get rid of BSP that would be nice.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

well, what opcode wants to use is the trimesh class for mesh containers into the collider.
As far as rays, as far as i remember (im at work) all you need to give csOPCODECollider is a vector and it uses it's ray collider to check for collisions along that ray segment against any meshes.

So unless i'm mistaken, to check a collision against a ray it would work the same as checking against any mesh, only the function calls would be slightly different.

something to that effect. All the ray functionality dealing with colliding is internal to opcode, so you shouldn't need anything special in VS anymore.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

had some time to work on opcode today... finally.

got a clean compile and tested it out. Of course, without the emulated functions needed for returning the collision pairs correctly, collisions dont work.

So next fixing that issue (mostly adding in missing collide system functions)

I'm hoping to get that stuff done this weekend still.

Part of the issue with converting this over is that there are quite a few features that the rapid collider used that just dont exist in the opcode collider anymore....like static functions for retrieving collided pairs. I'm not sure if we added those or if that's how CS worked before...but it doesn't use it in opcode.

Basically i need to convert all the user code over to the following api.

first we create a collider with the mesh as an argument (this is done the same as the rapid collider)

then we ask if we collided (this is also done the same as the rapid collider)

Then if we collided we get the collided pairs with csOPCODECollider::GetCollisions(); // Not static


Nothing is static, in that setup. So I have to figure out how to fix the VS code to not expect to use static variables.


I could make a commit this weekend to my tree, but i dont think it's worthwhile to commit yet to the HEAD unless i make some progress with actually colliding with something.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

EDITED re-read if you read the pre-edited post :

I couldn't help myself. Had to keep workin on it.

I have collisions working. Although there is a lot of additional work needed. Things are fairly slow for some reason (probably a mistake on my part somewhere)

It's somewhat buggy. I think my vertex info is off. But it's confusing because i had to convert our bsp_polygon into what opcode wants, and I'm not sure i did that correctly, and the same goes for converting back to "getVertex" for the particle gfx in halo_system.cpp. If someone can help me out with the initial inputting of the bsp_polygon ...that would be great. Hell, it would be even better if someone could help me get bsp_polygon converted into a trimesh, so i didn't have to make all these workarounds in opcode to fudge around bsp_polygon. I get confused when bsp_polygon is made up of vectors (how many?) and trimesh has vertex's and indexes to those vertexes ...etc etc. I need help in that area

But at least it's at the point where other developers can start helping me.

Just dont be surprised if it segfaults.

I'll be making a commit tonight to the head.


you can compare against the original collider by not giving the --enable-opcode option to ./configure.
It'll probably be slow because i dont have any optimizations setup (we dont use the hybrid model which might be better for our types of collisions) and there's probably plenty of other code cleanups and unecessary stuff going on. Plus, we are using opcode as if it was rapid collider, and that's probably not the most efficient way.

Also, i dont currently use raycollider for those types of collisions.

And also, it's buggy. :) but it does work somewhat.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I think today i'll make opcode the default collider for svn, and change the configure option for opcode to --disable-opcode, so you can test against the rapid collider.

We need people to give feedback and so we'll be more likely to get that if this is on by default.

I want to get my bugs in this worked out asap, because i'm eager to get ray colliding put into opcode and remove all that bsp collider stuff we currently do. Removing all that should have the added benefit of speeding up the physics frame a bit too. But the ray collider will likely be post-0.5.0 Since it's not necessary.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I've been studying the ray collision code that will be needed to be added into the collider and I think that will be fairly easy to add. I'm not sure what the terraformer stuff in there refers to, but it sounds like ground stuff so i'm ignoring it for now. I'll probably add in the ray collider code as soon as possible.

Before i do that though, I'm assuming that CS's choice of mesh/mesh collider is the best one for VS. I'd like to get some feedback on if that is true or not. Opcode provides for quite a few other types of colliders.

It'd be helpful if someone can document a sort of general step by step as far as collide related function calls a unit takes from creation to checking for a collision. Same for "beams/rays" and any other special case. That will help me out when culling all non-opcode collider code later.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Well, I guess this post is a good news bad news kind of post.

Good news :

I dont think the opcode collider is bugging out as bad as I had originally thought when it allowed me to go inside some of the bases in the sol system.

Bad News:

I got the old Rapid collider to do the same exact thing.


Basically, take your ship, go as slow and as close to the same velocity as the first base that you "n" to to make your target. It's got a large disc type underbelly. Pretty much land on the underbelly and sit there. Your ship wont bounce off and you have a good chance of then accelerating inside the ship. It's almost like the game gets confused as to what side to push you to, and it pushes you inside.

I got this to occur with both colliders, which makes me think it's a bug in the code that handles the physics after getting the collided vertexes.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

I remember something similar from quite a while back got caught in the mesh of a pirate corvette so i blasted my way out i believe i posted a screen shot at that time it has happened to me a few times.

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

From what I recall, the collision resolution code assumes that the normal vectors it is passed (for the two colliding faces) correspond to an external collision. However, due to discretization of time, the collision may not be detected until part of one colliding object is already partially or fully inside the other object. If what is returned corresponds to a collision between internal faces, it's going to resolve the collision with a bounce inwards :-/. I don't think it's so much a question of "becoming confused" as not being able to differentiate in the first place :-/.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

It would be nice if we could change the way we do collisions.

It feels to me like a normal force should be enough, but there should never be a reason to go through a mesh no matter what the reason is.

If we collide how hard would it be to basically apply the appropriate forces to keep conservation of energy and momentum, but in addition basically push your ship out so that it is touching the mesh of the ship it collided with.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

dont we save the center for each mesh? Couldn't we just guarantee that the force vector of the "bounce" has the z component in the direction of the center ? assuming x and y components are along the face of the collided triangle.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

I was looking at the Win32 scripts, and I wanted to know if there is a list of files that need to be compiled, or any specific #defines or libraries that are needed?

Is it just all the cpp files in src/cmd/collide2? Do I need to take out the old collide folder?

Are you going to commit your basic opcode code to SVN trunk soon?
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Makefile.am contains all the files (minus a couple headers i got lazy and didn't include"

Look under the tag libcollide2

The only build define you need to worry about is OPCODE_COLLIDER

That has to be defined for building the entire project, since i'm using that as a macro conditional for including either the rapid collider or the opcode collider.


In the configure script we have an option to set OPCODE (an automake conditional used in Makefile.am to select libcollide2 instead of LIBCOLLIDE to build and link) and it sets the OPCODE_COLLIDER gcc define to be used for all source compiles (it's in CXXFLAGS).

Other than that, you might want to look in opcodetypes.h
also opcodeqsqrt.h contains some assembly that is GCC specific, so it wont compile for non gcc compilers, but it may not build right without looking for the alternative qsqrt functions (since the NO_QSQRT define isn't set).
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I just made some rather significant changes to the filesystem structure of opcode. I had to resolve some name conflicts with the old collider. Normally this wouldn't be a problem since you wouldn't have two but the way we compile VS and the fact that i had some files with the same name as those in the old collider combines to make keeping things separate very annoying. So i just changed the name to something unique in the collide2 directory. Also, I was missing some ifndef wrappers around some include's for the rapcol.h file directly. This was causing some headers to get included that shouldn't have been, usurping the ones in my directory as well.

So after fixing both of those issues, and doing some minor cleanups in the collide2 dir i also made opcode the default collider for HEAD. You can compare against the old with --disable-opcode in ./configure.

The only main issue i've noticed is that damage is of a higher magnitude for collisions with opcode. not sure why yet, though i suspect it has something to do with how we determine the magnitude of the collision. Perhaps it used some behavior of the old collider to base it's numbers off of.

Also, at least on my computer, i notice a significantly larger stutter when panning around close to an object. I dont know if that's a video driver thing on my box or a physics frame thing. I haven't had time yet to profile it.


anyways, happy testing. please use at least -r 11826
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

ace123 wrote: If we collide how hard would it be to basically apply the appropriate forces to keep conservation of energy and momentum, but in addition basically push your ship out so that it is touching the mesh of the ship it collided with.
Well, we already do conservation of momentum (energy isn't conserved except in completely elastic collisions, and the degree to which energy is not conserved is used to calculate damage).
I think the problem with positioning was generally one of figuring out where exactly the two meshes would first have collided such that they could be moved appropriately prior to the application of force. I don't recall exactly what we ended up with in that regard in the current code.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

The old code didn't seem to do that properly a lot of the time.
For example I would kind of bounce out, but parts of my ship would be inside the other ship if you viewed with Pan Camera.

I'm about to commit a lot of changes to get things compiling on windows and Unix'es.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

Okay I have committed my changes, and the new collider is enabled for all operating systems.

Now it's just up to waiting for bug reports to come in.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I cant wait for those bug reports. heh.

Like i said, on my system the only real annoyance i have is that damage is greater for collisions with opcode enabled.

In the meantime of waiting for the bug reports to flood in, I'm gonna get ray collider setup and "available" in opcode. The sooner that bsp collider stuff is out of here the better. I want to get everything down to UnitType::Collide() wrapping a call to csOPCODECollide::Collide() or something to that affect. Beam::Collide can wrap csOPCODECollide.RayCollide()






on another note:
Edit: Removed note, we pretty much do all of what i was suggesting anyway.
Last edited by safemode on Tue Feb 12, 2008 7:12 pm, edited 1 time in total.
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

ace123 wrote:The old code didn't seem to do that properly a lot of the time.
For example I would kind of bounce out, but parts of my ship would be inside the other ship if you viewed with Pan Camera.

I'm about to commit a lot of changes to get things compiling on windows and Unix'es.
Given my understanding of the nature of our collision detection, I'm not surprised that the initial repositioning wasn't at all consistent (To be honest I can't even recall if we attempt to do any repositioning at all -- I'd check now, but I'm running a bit late for heading in to work). Please correct me if I'm wrong, but I have long been under the impression that there is no element of time passed into the collision detection algorithm - that it is comparing two meshes at particular positions and orientations and returning some arbitrary pair of intersecting triangles (if any exist). Short of running a binary search (once a collision is detected) over the positions (and rotations) each mesh occupied during the last timeslice, I don't see how the location, both in time and space and on the respective models, of the initial collision could be properly computed without an element of time.
Post Reply