Opcode collider errata.

Find any bugs in Vega Strike? See if someone has already found it, or report them here!
Coragem
Bounty Hunter
Bounty Hunter
Posts: 169
Joined: Sun Jan 20, 2008 8:38 pm
Location: Rio de Janeiro, Brazil

Opcode collider errata.

Post by Coragem »

EDITED: As Safemode asked to, I moved this post from Developers Focus forum. I read Safemode post on dev blog, after i posted this there.

Safemode,
i just download and compiled with the new opcode. and made a quick test.
Just dont be surprised if it segfaults.
Yes it did Segfaulted while i was shooting at a base defense ship. Well i did damage to the ship, so the laser is colliding.
And also, it's buggy.
I flown though the station several times and didn't crashed. so i guess the above is true :)
My laser and dumbfires hit the station 100% of the time. thats how i got into the above situation.
For now it seems to be working better for guns and missiles. maybe fast traveling stuff.
I played for like 5 minutes so still going to test it for real tonight.
Again, thank you for the effort. hope we catch all those bugs soon.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

make sure you've updated to the latest svn revision, i made some changes after 11816. you should be using at least 11818 svn head.

I've been able to hit bases and bounce off them with 11818. As well as shoot. Though, it seems my conversion from bsp_polygon is still somewhat buggy (perhaps also the way we check collision pairs is not right either) since VS assumes static collision pairs, yet opcode doesn't use static vars for checking it's collisions at all.

The only places i've been having trouble with bouncing off bases is when i try colliding into the side of a "docking bay". I end up getting inside and then hitting the internal walls.


Hitting of shields seems to be working for me anyway. I tested it for about 15 minutes last night at 3am and didn't segfault... but obviously that was just by happenstance.

I need some extra eyes on my bsp_polygon -> triangles conversion in CSopcodecollider.cpp and anything else in there seen as wrong.

opcode doesn't contain copies of the mesh it's colliding, to save memory, it uses a single copy held in csOPCODECollider. this is different from the Rapid collider, and i wonder if that's an issue or not.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

One more thing. I changed how opcode is built and such so you'll want to clean out your .o's and libcollide2.a files. make clean wont do the job because it's not looking for the old libcollide_.o's. It shouldn't affect your build, but it clutters things up.

I need some people more experienced with the whole bsp polygons and such to help me out with my geometry initialize function in CSopcodecollider.cpp, i know there are still issues in 11818, because i fired some missiles in an asteroid field and even though the asteroid i hit was damaged correctly, a ship exploded for no good reason in another part of the field. Then i was attacked for killing him.

That's actually one of the only complaints i can make with my limited testing. Collisions against bases with my ship were excellent. Shield damage and such happens exactly where it should be. Weapons hit their targets and etc etc. Just that asteroid field weirdness makes me sure that other people's problems are real, and i'm just getting lucky.



A good report would be
1. svn rev #
2. successful collisions (with what and reaction observed)
3. unsuccessful collisions (with what and what happened)
4. if segfault give back trace if possible (run with gdb (do not install bin))
5. any other weirdness related to collisions observed.

As always after doing a svn update with updates relating to the Makefile.am and configure.ac, redo your bootstrap.sh and make distclean and then test.

And make sure you test with external view on. for physical contacts.
Coragem
Bounty Hunter
Bounty Hunter
Posts: 169
Joined: Sun Jan 20, 2008 8:38 pm
Location: Rio de Janeiro, Brazil

Post by Coragem »

Safemode,

Sorry i cant post more detailed information right now (At work). One thing happened to me this morning right after i updated to svn rev: 11820 and enabled the collider.

I was playing normally until i was shooting this plowshare (and hitting) then suddenly it started to wildly teleport on the screen, stop for a sec and teleport again. never saw that happen before. maybe not a collider bug tho.

Another thing, i killed like 3 ships close to each other using 1 dumbfire... cant tell if its the collider or just the big blast radius those things have. (i killed myself lots of times shooting one too close to a target)

I did record linux terminal output to a text file (at home) so i'll try parsing where that teleport happened and post it.

No seg faults during play until now.
bgaskey
Elite Venturer
Elite Venturer
Posts: 718
Joined: Wed Mar 07, 2007 9:05 pm
Location: Rimward of Eden

Post by bgaskey »

dumbfires do have a huge radius (too big imho) and give no warning if ur too close to the target :(

As for teleporting plowshares, i havn't seen this, but it doesn't really sound like a collider problem, but what do i know :?
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

it seems like with opcode, the "collision" appears to be a much stronger magnitude than with the rapid collider


Perhaps we make values based on the penetration of the meshes after we get a collision and with the opcode collider, those penetration values are different, thus throwing off our calculations for how strong a collision it was.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

The whole jumping around thing needs to be verified by compiling with the rapid collider and retracing your steps. See if it happens then. If so, then we got a separate problem.
bgaskey
Elite Venturer
Elite Venturer
Posts: 718
Joined: Wed Mar 07, 2007 9:05 pm
Location: Rimward of Eden

Post by bgaskey »

It seemed to compile and start fine on my iMac G5. No time to test gameplay yet, hopefully this weekend :)
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 keep dying every time I so much as scrape the edge of a base. Indeed, the base itself gets about 20% of its hull damaged each time I crash into it.

I see the amount of damage is something on the order of 10^9 so really big.

Good news: haven't died when I'm not touching anything (haven't been able to test inner passageways or other important places since I keep dying).

I saw Jack committed a change so maybe that fixes the damage problem.
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:I keep dying every time I so much as scrape the edge of a base. Indeed, the base itself gets about 20% of its hull damaged each time I crash into it.

I see the amount of damage is something on the order of 10^9 so really big.

Good news: haven't died when I'm not touching anything (haven't been able to test inner passageways or other important places since I keep dying).

I saw Jack committed a change so maybe that fixes the damage problem.
The change I committed shouldn't significantly affect damage unless you're in a very large ship and cartwheeling into the station. I spent a couple hours ramming a Dostoevsky repeatedly into a Confed factory (custom testing mission) and didn't notice anything untoward with the damage levels. What vessel were you colliding into which station, and how fast were you going? Perhaps just as importantly, was this in a handgenerated system, a mission, or a normal system? I wouldn't be surprised to see something odd when interacting with an orbiting station with non-trivial velocity, given the way their apparent velocity looks to jump around.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Please specify what revision you are using when reporting.

As of 11836, Collisions are acting correctly in all cases i could come up with in 10 minutes. That includes, edge hits, face hits, going inside "docking bays" and soft collisions and hard collisions on the first base in the "n" key list in the Sol system using my llama.

Damage however, was much stronger than it should have been, though I believe it was applied in the correct areas. I have not had a chance to test jacks commit.
Coragem
Bounty Hunter
Bounty Hunter
Posts: 169
Joined: Sun Jan 20, 2008 8:38 pm
Location: Rio de Janeiro, Brazil

Post by Coragem »

Ace said:
I keep dying every time I so much as scrape the edge of a base.
I have to agree i barely touched the inside of the docking bay when i was launching, and i blew up.
I am gonna play this all afternoon so what ever i find i ll post.

EDIT: Used latest Rev 11837
You do not have the required permissions to view the files attached to this post.
Last edited by Coragem on Wed Feb 13, 2008 6:21 pm, edited 1 time in total.
My System: Arch Linux x86_64 Bits CPU: AMD Phenom II X4 995 RAM: Kingston DDR2 800Mhz 8 GB GPU: Dual ATI Radeon HD 4830 512 MB Opensource ATI-Git Drivers. HD: SATA 500 Gb WindowManager: KDE4 Joystick: Thustmaster T.Flight Stick X USB
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Again, not sure if you missed my last post. But all this is meaningless without the revision number you used to do the testing.


It seems rather obvious that well have to ifdef the code that's related to computing the damage based on the vectors that you get from computing force based on overlap distance (elasticity and such).

Visually, i've seen nothing to illustrate that the opcode is allowing me inside the other mesh, but value wise, it may be more than the rapid collider, and thus throw off our calculations of force which are based on that. If it turns out that it's just wrong, opcode has numerous other colliders that may make better sense and perform better in a space sim, than the aabbtreeCollider that crystalspace 3d uses. Since crystalspace 3d seems mostly geared to terrain/fps type games and not the massively huge environments of space.

There is even an obb and obbHybridCollider, though, without an example of it being used correctly, it's not a high priority for me to use it. (our rapid collider used a similar collider) though, the obb collider uses aabbTrees in it's back end.
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 »

sorry about that. My testing was done with 11836/11837.
I was still able to end up inside other objects, but only when going out of my way trying to do so -- namely, repeatedly bouncing myself off of non-convex areas of the base that tossed me back into the base, or, somewhat more difficult to achieve, bouncing around in a strut-rich area of the factory model until the ship ended up impaled on one of the struts. As I said, however, this required fairly pathological persistence. I was not, in my testing, ever able to end up inside another object based on my first collision with said object. I'm sufficiently satisfied with the above statement that I wouldn't spend too much time worrying (at least at this juncture) about handling any remaining corner cases (unless there's a demolition-derby mod, the sort of behavior required to cause the undesired effects would result in player termination anyway, so I don't think it'll be a big deal).

Collision detection is noticeably improved over the old RAPID collider. I saw neither spurious collision detections when not colliding nor was I able, as with the RAPID collider, to often put 10-15% of my ship through the side of a base before it registered a collision :-P. As far as I can tell, the new collider is in every way superior to the old one.

I'd be very surprised if the above reports of damage are different when using the old collider, as the damage portion of collision resolution hasn't changed in ages. I seem to recall dying with some frequency when attempting to dock to the Ataraxia fighter barracks, but if someone else can regress and confirm this, that'd be appreciated :). Magnitude of damage can be affected by changes to the collision detection, but only to the degree that the normal returned from the collider is more or less aligned with the relative motion of the objects than the normal returned before (roughly, how glancing the blow is). While it is possible that the new collision algorithm is picking faces that better represent the actual angle of impact, and thus changing the resulting damage, I'd be surprised if the magnitudes were significantly different than before. But -- we don't need to suppose, because we can test :) If no one else gets around to it, I can do it later this week.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Awesome. glad to hear that.

I think people are really complaining about damage being too great for a wide variety of things, even stuff not opcode based, like missile blast waves. I'm not sure if a recent change in the python code has altered things or not. But it definitely seems we could improve things by reducing the ease of ship destruction :)
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 don't remember collisions being quite so damaging before.

But I am now using version 11837.

I'm on Windows. Flying a Llama.begin, in Crucible/Cephid 17

I can go right through turrets on the relay.
I can collide with the ring on the outside of the relay, and it feels I am drawn in closer to the relay, but I don't die very quickly (a reasonable amount of damage)

Touching any point of the fighter barracks will cause me to instantly die, however I can dock in the bays without any problem if I am extremely careful about where I am (using the pan camera)

There are too many ships around so I can't easily set a breakpoint, but I might try disabling python so I am the only person.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

I'm not sure how the win32 version builds

The regular /cmd/collide dir shouldn't be linked in at all.

the compiler needs to set a define for each file in the project, OPCODE_COLLIDER

If that's true, and your'e actually using opcode, This would be the first instance of being able to fly through something with 11837.

I really dont know why damage is so much greater, I was told the difference in elasticity due to the collider would not impact the calculations for damage much at all. maybe it does. But I also notice a lot of damage from missile blasts, and i dont think that uses opcode at all.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

It would be interesting to determine if all turrets can be flown through. Perhaps the older collider gave the perception you could by colliding further away from the parent unit than Opcode does. just a guess. Anyway, it would be very telling if you could fly through all turrets on other bases and even the same base. Either the turret doesn't have a collider associated with it or the collider isn't being setup correctly for it.

First, test fly through other turrets using opcode. Then test with the old rapid collider (same svn rev though) and see if it behaves differently.

If it behaves the same, then it's not a show stopper. If the rapid collider is correctly mapping the turret by opcode isn't, that is a show stopper and i'll have to figure out why. If it's not every turret, then we should see what's going on in that particular case, but it likely isn't collider related.
Finally, if the rapid collider's behavior gave the impression of a collision with a turret, but really wasn't, then we have to find out why turrets aren't being correctly collided with and fix it, that wouldn't be a collider problem though.
Coragem
Bounty Hunter
Bounty Hunter
Posts: 169
Joined: Sun Jan 20, 2008 8:38 pm
Location: Rio de Janeiro, Brazil

Post by Coragem »

Safemode, sorry about the lack of details in the last post. I have the habit of making svn update, make clean and make every time i play so, if i miss revision assume its the latest one.
Another report.
I have played during the afternoon so far...
1. svn rev:
11837
2. successful collisions:
missile hits and beam shots, getting hit. no problems so far.
3. unsuccessful collisions:
Was about to dock with a Rlaan Ruizong was going too fast 200 m/s and turned the ship, i got into the Destroyer and stayed there, taking almost no hull dmg (maybe shield dmg). did managed to get unstuck and get shoot :? soon after.
4. if segfault give back trace if possible (run with gdb (do not install bin))
No seg falts since the update.
5. any other weirdness related to collisions observed.
I see computer ships go right into some stations when they try to dock. i think they used to blow up more doing this on the rapid collider.

I will be keeping a separate copy of VS compiled with -disable-opcode tomorrow so i can fast test both colliders when i find something odd.
My System: Arch Linux x86_64 Bits CPU: AMD Phenom II X4 995 RAM: Kingston DDR2 800Mhz 8 GB GPU: Dual ATI Radeon HD 4830 512 MB Opensource ATI-Git Drivers. HD: SATA 500 Gb WindowManager: KDE4 Joystick: Thustmaster T.Flight Stick X USB
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

make sure you make distclean There were a lot of build related changes that may be sneaking it's way into your build. Probably not though.

That's very weird, other people aren't experiencing that behavior.

Are you using a 64bit machine? Linux? x86?
There are some hardcoded defines in opcodetypes.h that should be delegated to configure.ac

#define CS_HAVE_STDINT_H 1
#define CS_HAVE_INTTYPES_H 1
#define CS_COMPILER_GCC 1
#define CS_PROCESSOR_SIZE 64
#define CS_HAVE_INTPTR_T 1
#define CS_HAVE_WCHAR_H 1
#define CS_HAVE_WCTYPE_H 1

I can think of two of those that will be immediately a problem for non linux, non 64bit setups.
Coragem
Bounty Hunter
Bounty Hunter
Posts: 169
Joined: Sun Jan 20, 2008 8:38 pm
Location: Rio de Janeiro, Brazil

Post by Coragem »

i would have PM you this but i think more people could get lost reading the post too.
Safemode said:
make sure you make distclean There were a lot of build related changes that may be sneaking it's way into your build. Probably not though.
Ok, just read the man for make distclean, didnt know that command, but can you give me some more info on the diference from make clean?
That's very weird, other people aren't experiencing that behavior.
Sorry, didnt get you there... :? which one?
Are you using a 64bit machine? Linux? x86?
Linux Debian Stable 32Bit. AMD Atlhon XP, x86, yes.
There are some hardcoded defines in opcodetypes.h that should be delegated to configure.ac

#define CS_HAVE_STDINT_H 1
#define CS_HAVE_INTTYPES_H 1
#define CS_COMPILER_GCC 1
#define CS_PROCESSOR_SIZE 64
#define CS_HAVE_INTPTR_T 1
#define CS_HAVE_WCHAR_H 1
#define CS_HAVE_WCTYPE_H 1

I can think of two of those that will be immediately a problem for non linux, non 64bit setups.
Should i add these into configure.ac? my compiling knowledge is limited to instaling libs and giving configure some arguments...
Sorry about so many doubts.
My System: Arch Linux x86_64 Bits CPU: AMD Phenom II X4 995 RAM: Kingston DDR2 800Mhz 8 GB GPU: Dual ATI Radeon HD 4830 512 MB Opensource ATI-Git Drivers. HD: SATA 500 Gb WindowManager: KDE4 Joystick: Thustmaster T.Flight Stick X USB
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

Coragem wrote:i would have PM you this but i think more people could get lost reading the post too.
Safemode said:
make sure you make distclean There were a lot of build related changes that may be sneaking it's way into your build. Probably not though.
Ok, just read the man for make distclean, didnt know that command, but can you give me some more info on the diference from make clean?
make distclean removes all build generated helper files that configure generates and make generates, such as dep files and such.
That's very weird, other people aren't experiencing that behavior.
Sorry, didnt get you there... :? which one?


being able to slip inside another mesh via running into it.
Are you using a 64bit machine? Linux? x86?
Linux Debian Stable 32Bit. AMD Atlhon XP, x86, yes.
There are some hardcoded defines in opcodetypes.h that should be delegated to configure.ac

#define CS_HAVE_STDINT_H 1
#define CS_HAVE_INTTYPES_H 1
#define CS_COMPILER_GCC 1
#define CS_PROCESSOR_SIZE 64
#define CS_HAVE_INTPTR_T 1
#define CS_HAVE_WCHAR_H 1
#define CS_HAVE_WCTYPE_H 1

I can think of two of those that will be immediately a problem for non linux, non 64bit setups.
Should i add these into configure.ac? my compiling knowledge is limited to instaling libs and giving configure some arguments...
Sorry about so many doubts.
no, you would set CS_PROCESSOR_SIZE to 32 not 64 for now, and recompile. Ill be incorporating the setting or not setting of these defines into VS's configure.ac and thus it's config.h that it generates. Then I'll have to include that file in those files that use these types of defines.

For now just set it to 32 and do a full recompile.

Then retest.
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 »

That define is supposed to be big enough to hold a pointer...
so setting it to 64 will waste space if intptr_t does not exist, which is not common in this day and age.

Yes, I happen to be on windows. It includes collide2 stuff and sets OPCODE_COLLIDER.
I only changed the COMPILER_GCC line to MSVC.

I'm going to reboot and try the same thing in 64-bit Linux.
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 »

@Coragem re: point #5 -- I seem to recall something some while back being mentioned by one of the other devels about disabling collision detection for AIs during the final approach for docking procedures, so that may be a "feature" if you're seeing traffic head toward the base, and wander toward a docking port, ignoring some of the station between them and the docking port. Eventually, we should replace individual docking ports with a sequence of points in space, the first of which is trivially navigable to even for AIs, and then we can just have ships follow the pre-computed flightplan in the rest of the way, but I digress :)
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 can confirm it happens on 64-bit linux with the fighter barracks... and this time I didn't actually touch anything, I got close to the overhang in one of the bays.
But I blow up immediately as soon as there is a collision.

I'm going to try without opcode collider in a few hours when I get back.
Post Reply