Intersections a line with collision polygons in a tile.
by Hans Sjunnesson · in Torque Game Builder · 09/05/2005 (3:58 am) · 5 replies
This is in regard to [url="http://www.garagegames.com/mg/forums/result.thread.php?qt=34106"]this[/url] thread I started on the scripting forum.
Basically, the way I see it, the collision polygons on tiles aren't exposed to anything but the physics part of Torque. What I'd want is a method which returned all the intersections an arbitrary line has with the collision polygons of a fxTileLayer2D.
The example I had in my previous thread was this picture:
The rather crude solution I'm using now is to use Bresenham line drawing algorithm to step through the square tiles to see if there are any tiles with collision polygons in between the two agents. However, this works only fairly well, since the agents are free to roam around the tiles, and don't keep to the center of the tiles, so there will be some overlap at times. Also, it only works for square tiles which are completely filled with collision polygons.
Fixing this in script would mean stepping through each square tile, calculting line intersection with the collision polygon in that square, and then rinse and repeat. T'wouldn't be much trouble if my algorithms weren't so unoptimised.
--
Hans
Basically, the way I see it, the collision polygons on tiles aren't exposed to anything but the physics part of Torque. What I'd want is a method which returned all the intersections an arbitrary line has with the collision polygons of a fxTileLayer2D.
The example I had in my previous thread was this picture:
The rather crude solution I'm using now is to use Bresenham line drawing algorithm to step through the square tiles to see if there are any tiles with collision polygons in between the two agents. However, this works only fairly well, since the agents are free to roam around the tiles, and don't keep to the center of the tiles, so there will be some overlap at times. Also, it only works for square tiles which are completely filled with collision polygons.
Fixing this in script would mean stepping through each square tile, calculting line intersection with the collision polygon in that square, and then rinse and repeat. T'wouldn't be much trouble if my algorithms weren't so unoptimised.
--
Hans
#2
--
Hans
09/05/2005 (11:46 pm)
Ideally, a list of logical tile-coordinates along with the world-coordinates of the intersections.--
Hans
#3
Also, what intersection details would you want? Presumably, polygon entry-point only?
This would make it a verbose sequence ... "tileX1 tileY1 colX1 colY1 tileX2 tileY2 colX2 colY2..."
- Melv.
09/06/2005 (12:11 am)
It's a minor point but if it were to return intersection details, it wouldn't technically be a pick-command as that wouldn't flow with existing pick functionality that returns the objects in question only. This would become something like "castLine()", as trivial as that may sound. ;)Also, what intersection details would you want? Presumably, polygon entry-point only?
This would make it a verbose sequence ... "tileX1 tileY1 colX1 colY1 tileX2 tileY2 colX2 colY2..."
- Melv.
#4
09/06/2005 (12:43 am)
For my game, polygon entry point works fine. In fact, I only need to check if we get any intersections at all, because this is a simple occlusion check. But I guess them other lot wants a more useful feature than that :)
#5
I've been away from T2D for a bit, and I was wondering if we've seen anything like this yet, of there's an engine-side solution to this, or of an established scripted way of solving line-of-sight issues with blocking tiles.
--
Hans
08/21/2006 (4:09 pm)
I'd like to work some black magic here and resurrect this thread.I've been away from T2D for a bit, and I was wondering if we've seen anything like this yet, of there's an engine-side solution to this, or of an established scripted way of solving line-of-sight issues with blocking tiles.
--
Hans
Associate Melv May
Something like...
- Melv.