Source Code Project Mantis - FSSCP
View Issue Details
0002664FSSCPmath-relatedpublic2012-06-09 23:532012-11-23 21:14
Assigned Toniffiwan 
PlatformOSOS Version
Product Version3.6.14 RC6 
Target Version3.6.16Fixed in Version3.6.15 
Summary0002664: shockwaves uses target objects radius to calculate damage
DescriptionWhen calculating the distance at which shockwaves will do damage to a given target, the target of the shockwave is treated as being a sphere. For any model with a shape that is not perfect sphere, this method will have inaccuracies. It's particularly noticeable with the Karuna from Blueplanet2 as the one of the Karunas primary weapons is the Apocalyse missile (which has a shockwave), and the Karuna model is long and thin. Any target of the Karuna that is close and not directly fore/aft of the ship will cause the Karuna to take damage from it's own weapons, even though "logically" the ship is outside the shockwave outer radius.
Steps To ReproduceSome discussion has occurred in this forum post.

I've attached a mission from qwadtep which showcases the issue. In theory none of the Karunas should take damage from their own missiles, however either 2 or 3 do, depending on which Karuna model is in use.
Additional InformationThe obvious solution is to be to be more accurate with the distance calculation. My concern is how this will affect performance, as I believe that collision detection is the current bottleneck in FSO.

One idea would be to calculate a cylinder for shockwave distance calculations - which is still an approximation but could be accurate enough for most cases. I think this would require two more pieces of information, radius & world position we have, we'd need length and orientation of the cylinder. I think I came across a existing function somewhere which will calculate the closest point on a cylinder to a given world position? (of course I can't find said function now...)

Another idea would be to use something similar to the weapon impact calculations, i.e. use the lod0 model with all its polygons. Obviously this gives the most accurate results, but is it too computationally expensive?
TagsNo tags attached.
Attached Files? test-range.fs2 (14,882) 2012-06-09 23:53
patch mantis_2664.patch (6,003) 2012-11-19 04:11
patch mantis_2664_puresvn.patch (5,481) 2012-11-23 04:11

2012-06-10 17:18   
Why not use the rotated model bounding box?Seems to me that that would be a good first place to start, instead of going straight to full-on ray collisions with LOD0.
2012-06-10 22:27   
The bounding box sounds like a good idea, I'm ashamed to admit it but I didn't know they existed when I logged the ticket :-) Since then I've been doing some wiki reading about the .pof format. Just to further expose my knowledge deficiencies in this area - what's the "rotated" model bbox? I presume that the "normal" bbox is described in the OBJ chunks, by these three values?

vector geometric_center
vector bounding_box_min_point
vector bounding_box_max_point
2012-06-11 05:08   
Rotated just means that you have to rotate the bbox coords into world coordinates by using vec_rotate with the objects current orientation matrix.
2012-06-27 23:10   
I found a function in the aicode for getting the nearest point on a bounding box so I moved that around and reused it for the shockwaves check. My testing with the attached mission now has only the 400m Karuna taking some self damage, and only some of the time, probably from missile impacts on the nearest engine section of the Deimos.

Could someone please review the patch and provide comments? Thanks
2012-11-11 00:18   
The patch looks okay, but I want to look at it in context with the code, and unfortunately the patch can no longer be cleanly applied. Can you make a new patch against latest trunk?
2012-11-19 04:22   
Oops - old patch was in git format, not svn format. Does this one apply cleanly? You might need the tortoise equivalent of "patch -p1" to ignore the leading fs2_open directory in the patch paths.
2012-11-22 22:10   
Unfortunately no. Is it diff'd against current trunk?
2012-11-22 22:20   
Gah! It was created vs the current trunk on the day it was attached. I've had a problem like this before, I'll redo the patch again not using git at all this time...
2012-11-23 04:13   
OK - try mantis_2664_puresvn.patch :)
2012-11-23 13:04   
Looks good. :yes: Both the math and the logic. I say go ahead and commit it.
2012-11-23 21:14   
Thanks - committed in r9371

Issue History
2012-06-09 23:53niffiwanNew Issue
2012-06-09 23:53niffiwanFile Added: test-range.fs2
2012-06-10 17:18The_ENote Added: 0013652
2012-06-10 22:27niffiwanNote Added: 0013653
2012-06-11 05:08The_ENote Added: 0013660
2012-06-27 23:07niffiwanAssigned To => niffiwan
2012-06-27 23:07niffiwanStatusnew => assigned
2012-06-27 23:07niffiwanFile Added: mantis_2664.patch
2012-06-27 23:08niffiwanProduct Version3.6.14 RC5 => 3.6.14 RC6
2012-06-27 23:10niffiwanNote Added: 0013731
2012-06-27 23:10niffiwanStatusassigned => code review
2012-11-11 00:18Goober5000Note Added: 0014020
2012-11-16 00:56Goober5000Target Version3.7.2 => 3.6.16
2012-11-19 04:11niffiwanFile Deleted: mantis_2664.patch
2012-11-19 04:11niffiwanFile Added: mantis_2664.patch
2012-11-19 04:22niffiwanNote Added: 0014069
2012-11-22 22:10Goober5000Note Added: 0014152
2012-11-22 22:20niffiwanNote Added: 0014153
2012-11-23 04:11niffiwanFile Added: mantis_2664_puresvn.patch
2012-11-23 04:13niffiwanNote Added: 0014160
2012-11-23 13:04Goober5000Note Added: 0014165
2012-11-23 21:14niffiwanNote Added: 0014169
2012-11-23 21:14niffiwanStatuscode review => resolved
2012-11-23 21:14niffiwanFixed in Version => 3.6.15
2012-11-23 21:14niffiwanResolutionopen => fixed