new collision code

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

new collision code

Post by safemode »

I'm currently in the process of porting over CS 1.2's opcode collider.

This should bring us up to legal status with the GPL.


I'm going through the code and stripping out stuff that just doesn't belong in VS and removing all the virtual functions and inheritance, and plugin arch and such. When that's done we'll have a backwards compatible collision system that is way more flexible and faster for various types of collides.

Right now i got most of the inheritance gone, the files in place, functions where they should be in the collider class.

What still has to be done:
0. Convert collider object name references to new object name. (function names are the same)
1. Removal of extraneous classes/data (this is important because it causes extra headers and classes to be included, complicating things)
2. conversion of non-backwards compatible arguments to 2 functions discovered thus-far.
3. compile test to see if everything is kosher
4. commit to svn as a secondary collision system.
5. then removal of the RAPID collider.


sounds like a lot but it's not. The longest step is the compile test. I hope to have this all done early this week though. And the removal of the RAPID collider from the SVN head by the end of the week.

then i can get back to playing with Unit :) woot.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

safemode or safecode? ;)
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

the new collision system will have a special collider for rays

The api will be like this

csOPCODECollider::CollideRaySegment(csReversibleTransform *trans, csVector3& start, csVector3& end, bool use_ray);

Seems pretty straight forward to me, 2 points,the transform, and a boolean flag for some reason i've yet to discover :)

The regular Collide function will retain the syntax it currently has.

Basically as i've learned how the CS colliders work... we'll have a "Collider" class that is the overall api for working with the actual collider algorithms. The way their regular opcode collider works, is if you send it a triangle mesh or so, it uses the regular TreeCollider class, which i believe uses an un-optimized aabb tree. There is code for an optimized one, but i'd like to get this thing to work with the regular stuff, substituting other "collider" algo classes will be a peace of cake once this is all done.

the ray collision is done using a RayCollider class, so these two classes will be data members of the opcode class. I dont know exactly how VS sets up their collision system, but besides some name changes, and any future changes to take advantage of the new ray collider, i dont think much else will need to be altered, in VS land. Maybe someone can run down the steps from creating the collider to executing the check for collisions, that would be helpful. to ensure api compatibility.


Still not ready for a commit yet, but i'm getting there. Stripping off all of the abstractness in CS is what's making this so hard..and it has to be done or we'll be compiling in half of CS due to their plugin system. Fun stuff.
()Alf
Mercenary
Mercenary
Posts: 105
Joined: Fri Dec 28, 2007 4:55 pm
Location: im Schwabenländle

Post by ()Alf »

Think about the possibility in the future of seamless flight and (hopefully ;)) walking on bases/planets. Stripping everything out might be ending in pushing some of it in again at some point later in developement (although i'm not sure what you're talking about ;)) ;)
Enjoy the Tri p :shock:
__________________________________
My Box:: Board: Fujitsu-Siemens D2156S; CPU: Pentium 4 - 3.4GHz Core²Duo; GraCa: ATI Radeon X1600Pro (PCIe); RAM: 3GB; Sound: Creative SB Audigy 1; 2xHD(ntfs): Pri_120GB,Sec_250GB; OS: Win-XP-Pro-SP2_32bit
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

adding colliders for terrains is easy enough once everything else is in place..




currently i'm in the compile/recompile phase. once i can build an object of the collider, i'll be ready to splice it into VS and see if i can hack the VS code to use it and test it. May sound like a lot, but once the recompile phase is done, the rest should be fairly easy, assuming there aren't huge issues with the class actually working (shouldn't be cuz i think i was pretty careful in fixing it).
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Well, i spent a few hours tonight trying to get somewhere with this. I'm stick trying to cull all the dependencies. It's really pissing me off too. It's like CS has created it's own data type for _everything_ under the sun and they've made their functions so templated and virtual and all-encompassing that it ends up having to include 80% of the low-end infrastructure of CS just to get this collider to compile.


If i knew exactly how the collider currently works and how the CS collider works, this would go much quicker, but as it is, i'm learning it as I'm hacking on it. So it's frustrating that code-wise it's pretty much done...but getting it to compile is only 50% done because i got too much cruft still attached to the stuff we need, and it's making compiling the thing impossible.

the guys over at CS really really really love to make abstract inherited classes (everywhere, the more multiple inheritance they can do the better). Then they love to wrap those in namespaces. Then they love to wrap those in macros to export the classes for runtime plugin archs (probably home-grown). Then they love to sprinkle the entire source tree with macros from everything to defining FALSE and TRUE and null to "new" and "delete" and inline and whatever else you can think of. And lets not forget peppering the entire thing with #if's. They mix their classes up so much that the heirarchy of objects is so convoluted that they dont include inherited data types in the derived classes, for anything, it's all forward declared because they depend on eachother, all of the headers in the entire thing are included at once in a single header in a specific order that I'm willing to bet, is the same order the cpp files need to be compiled in or goat blood will pour from the walls and you'll go deaf from the screams of a thousand dead babies.



In any case, i'm making headway, but it'll be another day or so until i can get something up for everyone to look at and start playing with.
()Alf
Mercenary
Mercenary
Posts: 105
Joined: Fri Dec 28, 2007 4:55 pm
Location: im Schwabenländle

Post by ()Alf »

I understand enough of coding to laugh through what you wrote, but not enough that i can ask:: why not doing that collision thing from scratch as orginal VS contributed selfmade :?: ;)
And forgive my packed english, read too much of lokies (and still hes the masterpacker :)) ;)
Enjoy the Tri p :shock:
__________________________________
My Box:: Board: Fujitsu-Siemens D2156S; CPU: Pentium 4 - 3.4GHz Core²Duo; GraCa: ATI Radeon X1600Pro (PCIe); RAM: 3GB; Sound: Creative SB Audigy 1; 2xHD(ntfs): Pri_120GB,Sec_250GB; OS: Win-XP-Pro-SP2_32bit
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

the guy who wrote the collider for CS knows a CRAP load more about colliders than i think the majority of people do. Strip out the nitty gritty of this opcode collider, without the need to have it be pluggable and abstract, and we'll have one hell of a fast and flexible collider in VS.


I dont like to give up just because i dont understand anything i'm working with at the moment. It'll just take me a bit longer than I originally thought.. I dont forsee it taking past the week though unless i just dont get any time at all to work on it.
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 »

Sounds like you're making progress on stripping down the CS code!

I hate that feeling of trying to get a small piece out of a complicated program. Hopefully you don't spend too long getting it to compile.

As safemode says, we need an advanced collision system. Vegastrike has already tried the route of a hand-made collision with BSP trees. It works good enough for firing guns (which is just lines), but the collision system was too terrible for flying around and having two objects collide with each other.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

well at the end of last night, I resorted to basically adding all the files necessary for my hacked of collider class. This got me far, all the way to some actual g++ errors and not preprocessor crap.

I'm wondering now though if it would just be better to replace the collide function code in the Rapid class we currently use, and the constructors, removing the rapid helper functions and compile. This will give me errors about undefined variables and missing functions. I can then add those missing functions and variables only and I should be able to avoid adding unessary data types and all the mess that entails.

I'll have to think about that, as that may be the best way to do this as all the work of linking in and compiling the CS collider code has been done with the current collider, and I'd have to do that all over again by using all these additional cs geom and tool and util and such files.

So, I think I may copy my current work to a new directory, then pull out the necessary public functions from the collider that we use to do all our work, then add functions and classes as the compiler errors demand until it compiles successfully. If that work is successful, it at least wouldn't mean i wasted the last couple days, had to learn how the colliders worked anyway.


EDIT: found this while i'm at work right now. http://www.crystalspace3d.org/docs/onli ... ion.html#0

It really re-inforces my second idea of just taking the collide function and constructor/createCollider function and replacing the current rapid ones but keep the class and such the same, then add what the compiler complains about.

EDIT again: http://www.gamedev.net/community/forums ... 1&#1793117
That is also a pretty good example of use. Apparently we're not the first to adopt OPCODE. Everyone uses it. I'll be looking at a few of those other projects to see what they've done.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

http://www.codercorner.com/Opcode.htm

I'm so stupid. Needless to say i'll be downloading that and using the examples of it's use, proceed from there. Without the cruft of CS to further complicate an already complicated system.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

Opcode is quite old. I've heard better things about Bullet:
http://www.continuousphysics.com/Bullet/

Of course, I don't know much about these things, that's just what I hear.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Bullet is currently slower. And there are some other less major drawbacks to opcode, that may be overshadowed by the advantages. Right now, we're setup for an opcode-like collider, a persistant type collider like bullet may require even more reworking than this upgrade to opcode is. In the end, after i've worked out the new opcode collider, changing it again or adding the option of both wont be as hard.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Another Update on the progress: Didn't have a lot of time today

I got Ice to compile fully. Using the "stand-alone" opcode, i'm also able to get most of the opcode OPC files to compile, with some issues with assembly in headers that i'm sure is due to some define not being set or set wrong somewhere or a header not being included. They use a *SURPRISE* macro to set asm lines so it can be swapped between VC++ and gcc and such.

What sucks is that all these hoops have to be jumped through just to get the opcode "library" in order. I haven't even been able to test how compiling the class that will link opcode to VS so that it acts like the old collider will work. Still making progress though. Once I get the opcode compilation squared away, getting it spliced into a class we can use shouldn't be hard at all, since it functions in the same way already... just all the backend stuff has changed.

I'm hoping the fact that the backend stuff has changed doesn't affect the physics of the game....since the collider uses a different type of tree and such.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

ok, finally getting somewhere. Right now i'm using opcode 1.2, which is much smaller and less hooked into CS. the standalone opcode 1.3 is really too much of a pain to get to compile. So my plan is to get 1.2 working, and then patch in 1.3....which should be relatively easy.

Right now, i'm in the process of getting the class that links opcode to CS working under our fake CS compatibility layer. It's fair to say that process is 50% done at least. What i plan on doing tomorrow is getting the current build over to VS's build system. It shouldn't be too hard. Then i can commit the changes and can start working on debugging the code so it actually functions with our system. That really shouldn't be too hard either since it's api is nearly exactly the same.

The plan at the moment is to make the collision systems compile time configurable (at least for now) until it's been trouble shot enough for 0.5 ...then the old one is gone so we can distribute VS freely as intended.

opcode supports a lot of shapes, a lot of colliders to collide against those shapes. I have no problem with supporting that stuff, but it involves importing a lot of files that are interdependent on a lot of other files and various macros in CS. I'm primarily concerned with replacing the rapid collider so VS is GPL compliant, once that's done, the work of porting over the other shapes and colliders we currently dont use can be done.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

by now some of you may have noticed some svn commits from me.

I maintain my own tree so my screwups in svn land dont hit the trunk first. I can mangle my own tree and when it's all squared up, merge over cleanly to the trunk. Also, every now and then i prefer to test out things on other people's boxes outside of trunk if i think it's probably gonna break it...

Anyways, i've merged over my work for the new collider. Really, all that's left to be done is wrap the code in the game that creates the current Rapid collider with ifdef's and put the csOPCODECollider name in it's place. The API is completely backwards compatible (should be) so it should be a basic drop-in replacement for our current collider.

As the code is now, no actual opcode collider is created in the game. This just compiles and links the code to vegastrike. Tomorrow or so i'll do the ifdef'ing to allow --enable-opcode to swap the actual collider in the game so we'll actually be using the opcode collider for collisions. Once this testing phase is over, the old collider will be removed from svn.

Also, as the code is now, opcode only provides the same functionality that the old collider provided. The raycollider isn't "functional" to the compatibility class (I left the calling functions out for simplicity sake now). And making use of all the other additional features would require changing the code that actually uses the collider to make use of them. All we need to do to make use of the raycollider is add in the code to call it in the game when appropriate and make a minor addition to our compatibility class and viola, ray collider.


The big question is: Will this work?
You'll just have to wait until i get the time to modify the calling code in the game ...either tomorrow or monday ..unless someone beats me to it. The api is 99.9% similar in functionality, so it should function the same despite the backend being all different.

The only thing i can think of that would make it not work is if a variable i thought was insignificant and thus commented out was in fact very significant or the calling code in the game makes assumptions about the collider that is soley dependent on the old Rapid Collider algorithms.



anyways, happy svn updating. We're getting very close.
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 »

Awesome work.

I think a new configure option won't be necessary. As soon as at least 90% of collisions work properly (you can get close to a unit without crashing) that new code should be turned on by default so that everyone who checks out svn can bugtest.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I wanted the ability to compare and contrast to the current collider as we bugtest the new one until release ...at which point the old collider will be removed and the simple configure option will be removed too
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Oh, and i'll still need to add some configure checks to set the defines that opcode uses to determine if say, a processor is 64bit or not, what version of gcc we're using, etc etc. Right now that stuff is hard-coded in a couple headers.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Post by charlieg »

That would make a good dev blog post (they don't all have to be as long as the last one!)

Edit: referring to this one:
safemode wrote:by now some of you may have noticed some svn commits from me...
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Coragem
Bounty Hunter
Bounty Hunter
Posts: 169
Joined: Sun Jan 20, 2008 8:38 pm
Location: Rio de Janeiro, Brazil

Post by Coragem »

Safemode, hi.

Just download svn updates and compiled with the --enable-opcode option.
So far everything seems normal, i did have some problems docking into bases inner docking bays... but i think that might be a older problem?
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

unfortunately, i didn't get any time yet to actually USE the opcode collider. it's all set and ready to be dropped in place of the current one used in our engine, but right now it's just compiled and linked.

So you're still using the old collider even with --enable-opcode. What is possible right now in the meantime is if anyone has a compiler error, they could post it and i'll know ahead of time what i need to setup in the ./configure.ac file to set the defines correctly, instead of just hardcoded like it is now.

basically, i just wanna know if it compiles successfully for people and with any luck i'll have time monday evening to actually make use of opcode in the game, and do some testing with it.

At that point, i'll make a blog post about it because it'll need some heavy testing prior to 0.5.


I just want to make it clear, --enable-opcode right now just compiles and links opcode, it doesn't mean the game will actually use it. I still have to code that. When i do that, then --enable-opcode will mean you'll be "Using" the opcode colider.

And 0.5 will not have any --enable-opcode option at all, as it will be the only collider. Unless someone wants to code in libode support and we could have two backends :)
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 »

Yeah definitely not perfect yet.
I was playing around with docking, and I noticed some places where I crashed without even touching the base, and other places where my ship was just going directly through.

I can't seem to properly crash into a relay at all... I've just been flying through it. I do seem to crash into its turrets however.

The old one might have been more lenient with crashes. I'm also having problems with the mining base, and there are times when I have rocketed away at huge velocities. I haven't noticed any of this before but maybe it's just that I'm being cautious now.

Also, where are these #defines for different CPU's?
I think the only thing I saw in OPC_Settings.h was whether it could use X86 assembly or not. I defined it to true and it still works on amd64, since it's compatible with x86.

I think the question is whether it's x86-based or a completely different architecture.
Coragem
Bounty Hunter
Bounty Hunter
Posts: 169
Joined: Sun Jan 20, 2008 8:38 pm
Location: Rio de Janeiro, Brazil

Post by Coragem »

So you're still using the old collider even with --enable-opcode.
:(
basically, i just wanna know if it compiles successfully for people and with any luck i'll have time monday evening to actually make use of opcode in the game, and do some testing with it.
As far as i can tell compiling was flawless on my system.
As soon as it is enabled in the game engine let me know, i can't wait to crash onto things to test it out.
And Thank You a lot for the effort Safemode, It will be awesome to see VS into Debian and other distros.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

ace123 wrote:Yeah definitely not perfect yet.
I was playing around with docking, and I noticed some places where I crashed without even touching the base, and other places where my ship was just going directly through.

I can't seem to properly crash into a relay at all... I've just been flying through it. I do seem to crash into its turrets however.

The old one might have been more lenient with crashes. I'm also having problems with the mining base, and there are times when I have rocketed away at huge velocities. I haven't noticed any of this before but maybe it's just that I'm being cautious now.

Also, where are these #defines for different CPU's?
I think the only thing I saw in OPC_Settings.h was whether it could use X86 assembly or not. I defined it to true and it still works on amd64, since it's compatible with x86.

I think the question is whether it's x86-based or a completely different architecture.
whether or not the assembly is actually in the files that those defines would have enabled is another story. I'd have to look again. It might just be a useless define. Most of the assembly was geared toward win32 only.


Unless you patched in the collider into the game to actually create an OPCODE collider instead of the old Rapid one, you were still using the old one when you had your issues with the base.

Right now as far as svn goes. The opcode collider is never used in game, no matter what.
Post Reply