raycollider work

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:

raycollider work

Post by safemode »

That was easier than i thought it would be. I got rid of the bspTree and bspShields, no more bsp files generated and sheilds still work, since they use opcode's mesh collider.


Now i just have to tell Beam and Bolt's Collide function to call Raycollider against my Mesh colliders and it's pretty much just pretty-ing things up.

and as far as pretty-ing things up go, there's a lot of relic dead code sitting around, lots of incorrect names and what not.

I ask that nobody bother playing with trying to fix any collider related files or functions as i'm likely going to step all over it and i dont want to waste your time.

The files that are going to get heavily touched are as follows ..
collide.cpp, collide.h, unit_bsp.cpp, unit_bsp.h , unit_collide.h , unit_collide.cpp, collide_map.cpp, collide_map.h, beam*, bolt*, unit_csv.cpp and unit_xml.cpp

To what degree, not sure yet, but those are all heavily collider oriented and i'm probably gonna be in them all to some degree.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: raycollider work

Post by klauss »

Cool.

Is it worthwhile trying to cache Opcode's collider tree in optimized form?
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: raycollider work

Post by chuck_starchaser »

safemode wrote:I ask that nobody bother playing with trying to fix any collider related files or functions as i'm likely going to step all over it and i dont want to waste your time.

The files that are going to get heavily touched are as follows ..
collide.cpp, collide.h, unit_bsp.cpp, unit_bsp.h , unit_collide.h , unit_collide.cpp, collide_map.cpp, collide_map.h, beam*, bolt*, unit_csv.cpp and unit_xml.cpp.
Acknowledged.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

klauss wrote:Cool.

Is it worthwhile trying to cache Opcode's collider tree in optimized form?

nah. generation is fast and we're talking maybe a couple dozen types of units. plus you'd need a way to determine if the mesh you loaded is updated from the cached collider you have saved. seems like more trouble than it's worth.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

I have rays and beams operating under the ray collider now. just a minor bug with beams not terminating at the point of collision.



While that sounds like it's done, it's not. There's still likely a good deal more that can be optimized for use with opcode now that bsp-isms aren't being used.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

I committed an initial and very hackish raycollider setup. I haven't profiled things yet. If you want to try it out, pull my branch and build like normal. It's going to be a while before this code hits trunk.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: raycollider work

Post by klauss »

Will do once I get oprofile working on my rig.
It's really tricky.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

Right now i'm prepping to remove all remaining bsp code and profiling the code.

Once that's done, i'll start working on debugging any remaining issues with the raycollider work.

after that, I want to tidy the code up and do the usual renaming and documenting

Finally, Once all the bugs are worked out and everthing is back to normal, I want to look into the sphere collider.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: raycollider work

Post by chuck_starchaser »

This is cool stuff :D
For bug hunts, don't forget I found a few bugs, while squashing warnings, that are still un-fixed. Actually, the out of bounds bug you just fixed was one of them. They are summarized here:
http://vegastrike.wcjunction.com/trac/ticket/28
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

I also want to correct what i said earlier to klauss and in the other thread about not having LOD's for physics colliders... We do. 8 apparently, though i may have edited it earlier to now have 16. I'll put it back to the regular 8 soon.

ColTree is basically an array of prescaled colliders that every unit with a mesh gets.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

Another major commit today, removing bsp and obsolete helper functions. Renamed queryBSP to rbCollide , which stands for ray - bolt collide. It is mostly similar in function to Collide, but uses the ray collider.

The only thing really remaining for the ray collider is to modify the end and distance vector and float value that is sent to rbCollide from the caller. This should theoretically fix beams passing through and continuing to be drawn after a collision is detected.

I'll likely have that done tomorrow.

Also, for those playing with my branch while this is going on, VS.py in data is in need of a minor edit to change it's reference to queryBSP to rbCollide ... it's not used in any other python files though.



I'm also probably going to modify my unitcollection class to inline certain functions so that they're better optimized.
Ed Sweetman endorses this message.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: raycollider work

Post by charlieg »

safemode wrote:Renamed queryBSP to rbCollide , which stands for ray - bolt collide. It is mostly similar in function to Collide, but uses the ray collider.
Why not call it RayBoltCollide? Why shorten it by 5 characters just to make it another class that has a slightly obscure name? :roll:

Sterling work other than that tiny minor gripe. ;)
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: raycollider work

Post by chuck_starchaser »

Or just RayCollide, since it will end up getting used for lots of things other than bolts, I suspect, (e.g.: tractor beams, and plain ray queries such as when you click on a 3D cockpit instrument or 3D base computer, to figure which button you clicked on).
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: raycollider work

Post by klauss »

rayCollide, so it doesn't get mistaken for a class :P

BTW: VS.py is kind of a mockup module that holds an example of all functions exported by VS, AFAIK. And, AFAIK again, it's not really used, it merely sits there as (very bad) documentation.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

it doesn't matter to me what it's called. Though, rayCollide might confuse it with the actual RayCollider class in opcode.

I was trying to think of something common to ray and bolts to call it, but couldn't come up with anything at 4am yesterday :)

Whatever you guys decide, i'll name it. It's only a couple edits

Once i get the thing finished, it's going to take every ounce of strength not to merge it to trunk.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

Well, I'm really starting to think that rays impact lengths are being ignored by Draw, and whatever other graphics related functions actually construct and draw the beams.

I have to test out a trunk compile and see if i get similar functionality. if so, at least there's no regression. then it's just a graphics issue that can be troubleshot
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: raycollider work

Post by chuck_starchaser »

No confusion at all; RayCollider sounds like a thing; rayCollide() like an action.
If there's any confusion it's for all the right reasons: Why should there be a RayCollider class in opcode in the first place? Not saying there shouldn't be; just that the purpose of the class is not self-evident, as the need for state in computing ray collisions is not self-evident.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: raycollider work

Post by chuck_starchaser »

No confusion at all; RayCollider sounds like a thing; rayCollide() like an action.
If there's any confusion it's for all the right reasons: Why should there be a RayCollider class in opcode in the first place? Not saying there shouldn't be; just that the purpose of the class is not self-evident, as the need for state in computing ray collisions is not self-evident.
Well, I'm really starting to think that rays impact lengths are being ignored by Draw, and whatever other graphics related functions actually construct and draw the beams.
Impact lengths?
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

when a beam hits you in VS, it just keeps going . This happens in the current BSP collision setup, and in mine.

This means that Draw for beams is probably being executed before the collision and updatePhysisics is being executed. Either that or neither collider is updating the correct data member that Draw uses to create the beam onscreen.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: raycollider work

Post by klauss »

@chuck: state is needed for time-coherent caching, an opcode optimization that speeds up subsequent collision tests in time-coherent simulations (ie: if two consecutive tests are likely to return the same).

Anyway, it's very java of it: read Execution in the kingdom of nouns.

It's hilarious and rather enlightening. I've been spreading it all over, so you may have seen it twice or thrice already ;)

@safemode: I've seen that bug before. It's related to the slower simulation frequency of "unimportant" units, the beam's length isn't capped until the collision is actually detected in the physics step, but the physics step may take a long time to be scheduled. You usually see a flash of the beam going through the object right before it's snapped to its shield hit location. If your branch doesn't snap it ever, then it's a bug. If it only takes time to do it, it's a pre-existent bug. I don't think that bug is easily fixable without a serious refactoring of the physics scheduler.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: raycollider work

Post by safemode »

nah, it doesn't snap in any version.

Go to the military barracks base or whatever it's called in Cephid_17. Fly up till you're about Shield length from it (firing lasers causes your whole screen to flash white (cuz you're near the shields).

Now, goto an external view, number 3 or 4 or something, where you're far enough away to see your entire ship.

Shoot your lasers costantly at the base, it will eventually start shooting beams at you.

Now watch as every beam passes straight through your center without stopping. The entire time.

Beams are not recieving data of where to stop, or Draw is not using the data.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: raycollider work

Post by klauss »

Then I guess it got broken some time before you started de-bsping.

It once worked, I can vouch for that.

So, anyway, even if you fix it in physics code, you'll be left with that bug I mentioned.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: raycollider work

Post by chuck_starchaser »

I understand the motivation for "SIMULATION_ATOM" (time_step); but shouldn't a collision detection override the scheduling and result in a physics update as soon as the next frame? --if not immediately?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: raycollider work

Post by klauss »

It should, but

1) collision detection only happens at physics steps (each unit handles collisions against smaller units in its physics cycle - I'm not exactly sure where beams fit in though)
2) it's not easy to re-schedule, given how things are structured. Even removing the unit from its scheduled simulation bin (a linked list of all units to be simulated at that simulation atom) isn't trivial to implement atm. It's been done, though, for asteroids IIRC. Asteroids had an insanely long simulation atom, so re-scheduling was a must and eventually I tackled that. I don't remember the details, but it could be reused I bet. Still, you have point 1 to solve.

I think the whole implementation is wrong, even if the concept isn't. Problem is, I don't have neither a better implementation nor time to come up with one.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: raycollider work

Post by chuck_starchaser »

Ouch! Sounds horrible. Re-scheduling should be fluid; otherwise what's the point?
Anyways, what we could do, at the very least, is force bolts to be simulated at every physics step. They got no physics to compute, except position; and ray collision is probably the simplest collision; so it shouldn't be too expensive.
And don't worry about refactoring the scheduler; I got it nailed (on paper, at least).
Post Reply