286
Devs / Re: EXIT: Unleashing monsters
« on: August 06, 2020, 10:48:21 AM »
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Continuing to update via patches, this patch fixes a twitch when bending over in front of walls I introduced in a recent patch and fixes a bug that had let projectiles pass between level geometry polygons when aimed at the seams, and upgrades the wall clipping math.
The last detail is significant, but first I must add there are some files changed that require using SVN Update. These are upper arm sections for two arm equipment items and a new MHM clip model for the tile that is like half of a column embedded into a wall, and changes to their PRT files.
After I made the change to this MHM model (the old one modeled the column with just a slab) they revealed the clipping issue I sought to address in the past days. After I finished that yesterday I looked into the projectile bug which I've been aware of for a least a couple years, and I discovered the MHM hit detection code there was particularly bad (SOM's code is not the work of geniuses, in case anyone is wondering) so I just rewrote it all and managed to fix the bug along the way.
As for the new wall clipping logic, it uses a significantly different approach that is much more accurate with the goal of being able to pass through any opening that will accommodate the clipping radius (developers should be able to assume if there is a 1 meter opening players will be able to pass through it.)
I'm pretty confident I implemented this correctly, but it's new. Because it's more accurate a problem arises because if you consider a corner, if you approach it, you might hit both walls, in which case whichever side happens to be first in the model data will predominate. If the code is very accurate it will make it impossible to touch the other wall. I might change this by adding some reflection logic, but the end of result of this change is the model is more "sticky" so to remedy this the best I could think of was to reverse the order that the polygons are considered every other time. That way the other wall in the corner can exert an influence in the case of a draw. In this way the stickiness mostly goes away, but it's a short order fix to a brand new system. I just have to get it off my work stack right now.
The old system was sticky too, so I guess very possibly this new system is better, but the top priority is removing those instances where the old model resulted in invisible barriers. I guess I never noticed since as long as they don't create a passage narrower than the clip radius usually you wouldn't notice them.
The technical differences is I used the section of the clipping circle (on the ground) and the wall's plane (upright) as the clipping radius for testing 2D penetration of the polygon outline. Usually this is much smaller than the fixed radius that was being used. But in one case at least, it can be a problem, so I resorted to a hybrid system that maxes out at a half radius, which was the old system's way. That problem case is if you find yourself right on the wall's plane, which can happen if you approach it from beneath an archway.
Another step lessens how far the clip shape is ejected from the wall so that if it's on the wall's lip instead of being ejected all the way out, it just ejects to where the clip shape (column) would be stopped by its own geometry. Like if you pushed a cylinder against the edge of a wall forming an exterior corner then depending on how far the cylinder is from the corner, more of the cylinder can pass behind the plane of that wall before actually coming into contact with it.
I think the old system dealt with this by using half the radius for the 2D geometry penetration test and using the full radius for the plane test. I think that's an interesting hack but leads to the problems this change addresses. In other words it had pretended like the walls were inset by half the radius. But only for some of its math. Part of me wonders if this is actually smart, but I think it's not something that can work with the new system since its radius isn't a fixed value.
Also for this second step (ejection) the code could be a lot better. Instead for time sake I've just treated every polygon like it's an upright rectangle. It can be improved (later when I have time) by clipping the top and bottom to the base and height of the clip shape and finding the point on the diagonal where the clip shape touches the polygon if it's not a rectangle polygon. Most clip geometry is rectangular, so this is good enough in the meantime.
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Continuing to update via patches, this patch fixes a twitch when bending over in front of walls I introduced in a recent patch and fixes a bug that had let projectiles pass between level geometry polygons when aimed at the seams, and upgrades the wall clipping math.
The last detail is significant, but first I must add there are some files changed that require using SVN Update. These are upper arm sections for two arm equipment items and a new MHM clip model for the tile that is like half of a column embedded into a wall, and changes to their PRT files.
After I made the change to this MHM model (the old one modeled the column with just a slab) they revealed the clipping issue I sought to address in the past days. After I finished that yesterday I looked into the projectile bug which I've been aware of for a least a couple years, and I discovered the MHM hit detection code there was particularly bad (SOM's code is not the work of geniuses, in case anyone is wondering) so I just rewrote it all and managed to fix the bug along the way.
As for the new wall clipping logic, it uses a significantly different approach that is much more accurate with the goal of being able to pass through any opening that will accommodate the clipping radius (developers should be able to assume if there is a 1 meter opening players will be able to pass through it.)
I'm pretty confident I implemented this correctly, but it's new. Because it's more accurate a problem arises because if you consider a corner, if you approach it, you might hit both walls, in which case whichever side happens to be first in the model data will predominate. If the code is very accurate it will make it impossible to touch the other wall. I might change this by adding some reflection logic, but the end of result of this change is the model is more "sticky" so to remedy this the best I could think of was to reverse the order that the polygons are considered every other time. That way the other wall in the corner can exert an influence in the case of a draw. In this way the stickiness mostly goes away, but it's a short order fix to a brand new system. I just have to get it off my work stack right now.
The old system was sticky too, so I guess very possibly this new system is better, but the top priority is removing those instances where the old model resulted in invisible barriers. I guess I never noticed since as long as they don't create a passage narrower than the clip radius usually you wouldn't notice them.
The technical differences is I used the section of the clipping circle (on the ground) and the wall's plane (upright) as the clipping radius for testing 2D penetration of the polygon outline. Usually this is much smaller than the fixed radius that was being used. But in one case at least, it can be a problem, so I resorted to a hybrid system that maxes out at a half radius, which was the old system's way. That problem case is if you find yourself right on the wall's plane, which can happen if you approach it from beneath an archway.
Another step lessens how far the clip shape is ejected from the wall so that if it's on the wall's lip instead of being ejected all the way out, it just ejects to where the clip shape (column) would be stopped by its own geometry. Like if you pushed a cylinder against the edge of a wall forming an exterior corner then depending on how far the cylinder is from the corner, more of the cylinder can pass behind the plane of that wall before actually coming into contact with it.
I think the old system dealt with this by using half the radius for the 2D geometry penetration test and using the full radius for the plane test. I think that's an interesting hack but leads to the problems this change addresses. In other words it had pretended like the walls were inset by half the radius. But only for some of its math. Part of me wonders if this is actually smart, but I think it's not something that can work with the new system since its radius isn't a fixed value.
Also for this second step (ejection) the code could be a lot better. Instead for time sake I've just treated every polygon like it's an upright rectangle. It can be improved (later when I have time) by clipping the top and bottom to the base and height of the clip shape and finding the point on the diagonal where the clip shape touches the polygon if it's not a rectangle polygon. Most clip geometry is rectangular, so this is good enough in the meantime.