Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Swifty on June 12, 2012, 04:27:38 am
-
My collision detection optimizations are finally ready for testing. I've done a couple things to the collision detection system in the Freespace Open engine.
First has been rewriting the time caching system that keeps track of all potential collision pairs in the gameplay simulation. Freespace brute forces this and ends up going through all n^2 pairs each frame in order to find valid collisions to test. This ends up becoming costly, especially when an object is deleted which results going through all n^2 pairs to find which pairs to delete.
I end up fixing this by finding potential collision pairs through applying Quicksort on all three axes to find objects that have their bounding boxes overlapping. I then use a hash table to store and keep track of the next check time for each pair that I get a positive on. The pair itself is collision tested business as usual if the next check time has been elapsed.
Second has been rewriting the collision data format for models. The internal data structure I use to store POF collision data from is much more leaner while being well formed. This means the traversal algorithm doesn't have to play with headache inducing pointer math to go down the collision data tree to find a hit on a model. The traversal algorithm is much simpler and much more readable which in the end should make it faster.
I've been playing around with multithreading the collision code. Due to the collision code becoming more efficient from my rewrites of these key portions, it's not longer necessary to multithread that section of the code.
My build with these changes are here: http://www.hard-light.net/forums/index.php?topic=81087.0 . It includes a bunch of rendering optimizations including a soft particle rendering optimization and better OpenGL state change management.
-
:shaking: [Whine] i no speak coder [/whine] *head implodes* :lol:
Nah i think i got the basic jist of this; the computer doesen't have to do so many checks for colissions each frame, so it'll free up a lot of memory?
Sounds impressive nevertheless; nice one. :yes:
-
First bug report. Game hangs on loading Tethis.pof in bp2-massivebattle with the released bp2 version. Spoon reports BP SVN seems to be working. I get one core 100% and then nothing no error etc.
-
First bug report. Game hangs on loading Tethis.pof in bp2-massivebattle with the released bp2 version. Spoon reports BP SVN seems to be working. I get one core 100% and then nothing no error etc.
its something related to pof loading iirc. i purged the data/cache and ran through rc4 build to get the caches rebuilt, worked afterwards.
-
This has the potential to be awesome. :yes:
-
Yes it has. The fact it currently seems to have a few bugs doesn't take any of the awe I have for someone who managed not only to face the collision code, survive to tell the tale and keep his sanity, but actually rewrote the damn thing.
-
i still cant get the caches to rebuild for whatever reason but just running the new build gives me about 3 fold increase in bp2 massive battle. if thats not awesome i dont know what is.
But dont do == with floats if(blown_off == 1.0) should be if(blown_off > 0.9) or you get wierd results from the vertex interpolation.
EDIT: Get some extracted shaders here for MOD's that have shaders in their VP's ( WAR IN HEAVEN IM LOOKING AT YOU!!!!)
[attachment deleted by a ninja]
-
I've been awaiting this since April 30 :yes:
Sadly multithreading didn't make it into the build :( Feature is feature. I hope I made it clear enough that I am not serious about this one.
-
I agree this is awesome, a shame multithreading didnt made it yet, but nonetheless awesome stuff will help a lot with BOE scenenarios and on my case with Dominion Battles for my ST mod.
tho i still hope you wont drop multithreading support please *-* i want moar perfomance.
-
What makes you think multi-threading will speed things up so much? Especially when a coder has told you it's not worth doing because it's not getting enough of a speed gain? :p
-
I wish people would stop thinking multithreading is some sort of magic solution to all performance problems. That's not how it works !
-
I wish people would stop thinking multithreading is some sort of magic solution to all performance problems. That's not how it works !
lalalalala I can't hear you! You sir are a liar and a ruffian.
Multi threading banzai! Huzzah, huzzah, huzzah!
-
Been looking forward to this for 6 years... yay.
Due to the new calculation method, are very thin geometry structures more apt to be hit / recognized / registered or is that a separate issue?
Got some wing tips / surfaces that are very thin on a few models, don't always register hits in those areas, and was curious....
-
I've been awaiting this since April 30 :yes:
Sadly multithreading didn't make it into the build :( Feature is feature. I hope I made it clear enough that I am not serious about this one.
I agree this is awesome, a shame multithreading didnt made it yet, but nonetheless awesome stuff will help a lot with BOE scenenarios and on my case with Dominion Battles for my ST mod.
tho i still hope you wont drop multithreading support please *-* i want moar perfomance.
Yeah let's multithread away even though it's notoriously hard to get right (http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1631937) and it doesn't even guarantee an automatic performance improvement (http://dl.acm.org/citation.cfm?id=1693489) (also see: false sharing (http://en.wikipedia.org/wiki/False_sharing)). (No offense to any SCP member's coding skills intended.)
Back on topic, though, very cool stuff, Swifty. My impression from E9's post in the release thread (http://www.hard-light.net/forums/index.php?topic=81087.msg1615643#msg1615643) was that more work was needed for OS X compatibility (although I'm using Snow Leopard and my Lion box is 3,000 miles away), so I might need to wait before trying this out. :)
Oh, and also (recolored for readability):
I hope I made it clear enough that I am not serious about this one.
Not quite clearly enough. :p
-
Is the stuff in the test build the same as the stuff in the test build you made for Diaspora? (I want to know if my feedback on the Diaspora variant is relevant in this thread).
-
Out of curiosity (I know **** about coding): On which machine will he performance gain be most recognizable? Low-End or on all machines? Will be there an overall performance gain or mostly in large battles?
-
Well, obviously, if you have a high-end machine that run 99% of the game at solid 60fps, you'll have a significant trouble noticing any performance gain...
But to be more precise, the whole thing is supposed to reduce the CPU bottleneck of collision detection, so the difference will mainly be seen on computers which have a decent graphic card compared to their CPU. For people with intelgrated, the major bottleneck isn't exactly the CPU.
-
Out of curiosity (I know **** about coding): On which machine will he performance gain be most recognizable? Low-End or on all machines? Will be there an overall performance gain or mostly in large battles?
doesnt matter. i have a i7 860 which is no slouch. bp2-massivebattle still brings the fps down to a piddly 4(or rather, seconds per frame).
the performance gain will be everywhere.
-
I hope I made it clear enough that I am not serious about this one.
Oh my gosh. I should do this from now on. Also not serious.
Collision rewrite sounds amazing! I wonder how it'll affect multiplayer.
-
:shaking: [Whine] i no speak coder [/whine] *head implodes* :lol:
Nah i think i got the basic jist of this; the computer doesen't have to do so many checks for colissions each frame, so it'll free up a lot of memory?
Sounds impressive nevertheless; nice one. :yes:
So moar dakka on the screen is possible ? :D
-
No, same amount of dakka. It's just that the dakka won't slow your framerates down as much.
-
Though, wouldn't this make increasing the object limit potentially more feasible?
-
Great to have a rewrite of the collission detection system, I wonder if it may affect what happens if two large ships bump into eachother (In a few tests during FREDing in the past I've seen that happen, quite amusing but strange nonetheless) or if it's purely the detection part.
Nonetheless, having this will help improve performance a lot during missions such as BP2-Massive Battle or my own little BoE benchmark mission. Great work Swifty!
-
Though, wouldn't this make increasing the object limit potentially more feasible?
Cart before horse. Diaspora has already increased the object limit so we need these changes before we unleash that mess on everyone else. :p
-
omg! they made it faster! double all the polycounts and all the texture resolutions!
:nono:
-
omg! they made it faster! double all the polycounts and all the texture resolutions!
:nono:
Enable shadows :P
-
well i was trying to make the point that we dont really need to use this as an excuse to go nuts on models more than we already are, thats just one aspect of the game after all. model quality isn't really too far from professional grade these days. and there are always things you can do to make the models better (and more efficient) than simply upping the poly counts. this is just coders keeping up with the abuses of modders :D
-
tho arent polies and textures mostly GPU dependend instead of CPU¿? i though we could already go nuts on those...
-
*headdesk*
Model complexity (aka polycount) has an appreciable effect on collision detection as well.
-
*headdesk*
Model complexity (aka polycount) has an appreciable effect on collision detection as well.
:shaking: i m sorry dont kill me! i forgot to think about it! :warp:
-
There are ways to implement a collision mesh though, aren't there ?
-
Yes. And doing so would yield a few more frames, I believe.
-
I don't know that anyone has successfully done collision meshes on a full, working model. Diaspora spent some time trying to make it work, and eventually gave up completely.
But yes, by default all of those polygons are going to matter for the purposes of collision. I don't know if detail box stuff is included or not.
-
omg! they made it faster! double all the polycounts and all the texture resolutions!
:nono:
Enable shadows :P
Tried it. The latest shadows patch I have doesn't play nice with the latest commits on SVN. Can't run the two together, at least with what I have.
EDIT: I did try the patch for this, and consistently higher frames were had (60-75fps vs 45-50fps when the karuna gets gutted in the WiH intro)
-
I don't know that anyone has successfully done collision meshes on a full, working model. Diaspora spent some time trying to make it work, and eventually gave up completely.
But yes, by default all of those polygons are going to matter for the purposes of collision. I don't know if detail box stuff is included or not.
Didn't Shadows of Lyat actually successfully implement them?
-
Forgive me if everything just zipped over my head, but: why can't collision be done on a lower-quality LOD? Why wouldn't that work? To my best understanding the lower LODs are basically lower-poly versions of the HQ, right?
-
Invisible walls/fly through geometry.
The lower LODs are indeed less complex versions of the model. So obviously if there is a collision that means that you'd hit one of the polys in the lower LOD model. The problem is that this poly may not be in the same place as the corresponding one in the higher LOD. So either you fly through the surface of the ship and hit the LOD or you bounce off the surface a couple of meters from it.
This is especially notable in external view.
-
any chance in creating a new pof chunk for precompiled collision models?
-
The lower LODs are indeed less complex versions of the model. So obviously if there is a collision that means that you'd hit one of the polys in the lower LOD model. The problem is that this poly may not be in the same place as the corresponding one in the higher LOD.
If that's the case, then whoever did the LOD seriously sucks at LODing.
-
Or did his job correctly. If your lod1 follows the contours of lod0 exactly, then your lod1 probably uses way more polies than necessary. This behaviour would be acceptable for a collision model though.
-
EDIT: I did try the patch for this, and consistently higher frames were had (60-75fps vs 45-50fps when the karuna gets gutted in the WiH intro)
Wow, I haven't thought that the performance gain would be that huge :eek2:
-
EDIT: I did try the patch for this, and consistently higher frames were had (60-75fps vs 45-50fps when the karuna gets gutted in the WiH intro)
Wow, I haven't thought that the performance gain would be that huge :eek2:
So far my Phenom II loves the new collision code, Props to Swifty. :yes:
However, that is only one (however popular) benchmark. Still got stuff to try. I wish I could get shadows working with it, as that would kick the FPS low enough for real testing. When you get 120 or higher anyway in most things, it's hard to see the improvement. (Note to self: Find way to unlock FPS past 120)
-
Remove VSync everywhere (including driver settings).
-
Remove VSync everywhere (including driver settings).
VSync is 60 for me, unlocked in CCC and FSO is 120, probably a reg thing.
Oh, right, before I forget: Using swifty's build, if I go to the tech room, click missions, then back to ships, FSO freezes. No debug, no CTD, just dead. I'll run debug and see if I can get a partial log sometime tomorrow, unless someone else can get the same problem. (it was consistent, 3 times in a row)
-
Remove VSync everywhere (including driver settings).
VSync is 60 for me, unlocked in CCC and FSO is 120, probably a reg thing.
Oh, right, before I forget: Using swifty's build, if I go to the tech room, click missions, then back to ships, FSO freezes. No debug, no CTD, just dead. I'll run debug and see if I can get a partial log sometime tomorrow, unless someone else can get the same problem. (it was consistent, 3 times in a row)
its something related to ibx file loading, from what i've managed to gather.
-
I am pretty sure FSO is locked at 120fps within the game engine
-
I am pretty sure FSO is locked at 120fps within the game engine
I'm pretty sure I've seen screen with 800FPS, dunno if real or forged.
-
If you disable Vsync, then it might be possible, if completely pointless. I don't know if it doesn't screw the beam damage and particle spews up though.
-
personally i prefer the collisions use the complete detailed motel actually instead of a lower end model, stuff like antennas and such are important to take onto account when colliding against stuff.
-
personally i prefer the collisions use the complete detailed motel actually instead of a lower end model, stuff like antennas and such are important to take onto account when colliding against stuff.
thing with this is the high processor demand of such a system
-
personally i prefer the collisions use the complete detailed motel actually instead of a lower end model, stuff like antennas and such are important to take onto account when colliding against stuff.
You're not making sense. What prevents you to keep the antenae on your collision mesh.
-
personally i prefer the collisions use the complete detailed motel actually instead of a lower end model, stuff like antennas and such are important to take onto account when colliding against stuff.
You're not making sense. What prevents you to keep the antenae on your collision mesh.
I think what assasing123 is on about is using the detail0 to calculate collisions rather than a lesser detail level or a radius detection
-
What headdie said.
-
Using detail0 for collision detection is just a tiny bit inefficient, since you've got a whole bunch of poly's on the model. What's wrong with making a collision box that encompass the antennae/ detail geometry?
-
having a stand alone collision mesh would be optimal so you have control over what collides and what doesnt. using lod0 it collides with everything, and using lod1 it collides with places that would be open on the main lod and miss other points of detail like the antennae structures mentioned above which have been ommitted. even then you can cull a huge number of polygons from the collision mesh. surely your 12 sided cylender your using as an antennea can be a simple 4 sided shape in the collision mesh, a small structure like that after all wont show much error in where the collision happens neither would most shallow greebles reduced to less complicated shapes. curved surfaces can be reduced by large amounts too.
really all you need to do is take the diaspora concept, and make the engine consider that arrangement when doing collision tests. what exactly where the issues with the diaspora method? it looked good on paper, its sad that it didnt pan out as intended. figure out why that didnt work, what issues they had, call em bugs and fix them. way id set it up is add a submodel prop to define a model as an explicit collision model, and add another prop to reference that model in the subobject it represents.
collision meshes would be given a named reference (granted it can use the submodel name or number, ommitting everything to the right of the :)
$colision model: somename
and on objects that use collision meshes they would use the named reference
$use collision model: somename
it would be considered an error to attempt to use a collision model as a sybsystem or any other kind of model or to attempt to render it.
-or- you could do this
$collision use lod: 1
for people who think that lod1 is enough and use that
i would allow both, for convenience.
or you can just use the diaspora conventions, but they are kind of cryptic and collision detection was not their intended function (such as colide_this_only was intended for objects you did not want to be collideable at all, not for redirecting collision detection to another model).
-
I don't see a need to mess with submodel props and stuff, really. Just have it work like this: if submodel A has a child submodel B named "collision" (or whatever), then use B as the collision mesh for A. Simple as pie.
-
Ideally, when making your ship, you'd just model LOD1 in such a way that it makes a good collision mesh. All problems solved.
-
I don't see a need to mess with submodel props and stuff, really. Just have it work like this: if submodel A has a child submodel B named "collision" (or whatever), then use B as the collision mesh for A. Simple as pie.
that also works i guess. my solution is probibly overkill.
-
Well, my idea does have the drawback that you couldn't recycle your LOD1 models (for example) as collision meshes but would have to add separate copies of those submodels. So, I think that an additional submodel prop with which you can tell which submodel to use as the collision mesh would still be needed.
-
I tried the new exe for the collision detection rewrite and did n't notice any change in frame rate, in fact it seemed to go down. But after looking at it, it seems it is due to the limitations in my video card (Nvidia GT120). I noticed how ever that the burden on the processor went down. I had been getting a lot of alerts saying I had high usage on the processor in the range of 99 to 100%. While using the new exe, I got one alert for 86%.
-
I don't see a need to mess with submodel props and stuff, really. Just have it work like this: if submodel A has a child submodel B named "collision" (or whatever), then use B as the collision mesh for A. Simple as pie.
that also works i guess. my solution is probibly overkill.
That's more or less what we tried. There were some code issues we never got resolved, and in addition it turns out to be difficult from a modeling point of view to get a collision mesh that really works well.
Eventually, Swifty got fed up and decided to just try improving collision detection altogether. Which leads to this thread. :)
-
This is amazing, I had no idea collision detection was such a bottleneck. +30-50% Framerates? Yum. Massive Kudos, Swifty.
If this is released as part of 3.6.16 along with all the HTL awesomesauce of the next FSU version, I shall hurt myself with delight.
-
so... sorry to ask, but has anyone succeded on mixing this with VA shadows and shinies?
-
Given that the last public shadows patch is quite old at this point, no.