是否可以制作多边形边界框？
（首先，为了确定，六边形是一个有 6 个点的多边形，想想蜂巢或文明 5）
我正在制作一个使用六边形网格的游戏，但我似乎无法获得正确的边界框，Javas API 只告诉我关于矩形“BB”（getBounds 和 getBounds2D）。
我已经绘制了形状并按应有的方式将它们对齐，但我希望单元格彼此完全相邻，要么边缘彼此相连，要么它们紧挨着彼此，但它们之间永远不会有 1 个像素。当 BB 是矩形时，这是不可能的。
如果这是完全不可能的，也许有一种方法可以减小组件的大小，但仍然绘制完整的东西？这样你就可以得到一个跨越六边形中间的规则矩形，尽管它使两个“点”无用，这不好。
谢谢<3
(first off, just to be sure, a hexagon is a polygon with 6 points, think honey-comb or Civilisation 5)
I'm making a game that uses a hexagonal grid, but I can't seem to get the bounding box right, Javas API only tells me about rectangular "BB" (getBounds and getBounds2D).
I've drawn the shapes and aligned them as they should be, but I want the cells to be exactly adjacent to eachother, either that the edges go into eachother or that they are right next to eachother, but never even 1 pixel between them. This is impossible to do right now when the BB is rectangular.
If this is completely impossible, maybe there's a way to reduce the components size but still draw the full thing? That way you could have a regular rectangle that spans in the middle of the hexagonal, although it leaves the two "points" useless, which is not good.
Thanks <3
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据定义，边界框是一个盒子（也称为矩形）。所以不，不可能制作非矩形边界框。
可以制作一个非矩形窗口、剪切区域……但限制此类事物的框将始终是一个“框”。这是因为许多例程会对边界框进行初步检查（重叠等），然后对实际形状进行细粒度检查。细粒度检查的计算成本很高，因此快速检查（这些矩形是否重叠？）可以充当过滤器，确定哪些候选者值得额外的时钟周期。
也就是说，您要对边界框执行的操作是完全不同的事情：
如果您要使用边界框的坐标来确定是否需要将某些内容绘制到屏幕上，则绘制它如果边界框的一部分可见。然后使用裁剪例程（可以裁剪为任何形状）来确保只显示您想要可见的位。
如果您要使用边界框的坐标来指定单击侦听器，请这样做。在六角形侦听器中实现额外的代码，以确定单击是在六角形内还是仅在边界框内。如果它在十六进制之外，则丢弃。
基本上，如果不进一步了解您要实现的目标，就不可能提供合理的解决方案；然而，许多例程首先进行边界框检查，作为减少调用次数的快速而肮脏的方法，然后进行更详细的检查以查看边界框解决方案是否误报（认为是对象碰撞）。
A bounding box is by definition, a box (aka rectangle). So no, it is not possible to make a non-rectangle bounding box.
It is possible to make a non-rectangle window, clipping area, ... but the box that bounds such a thing will always be a "box". This is because a lot of routines do peliminary checks (overlapping, etc) on the bounding box, and then do fine grained checks on the actual shapes. Fine grained checks are computationally expensive, so a quick check (do these rectangles overlap?) can act as a filter for which candidates deserve the extra clock cycles.
That said, what you're going to do with a bounding box is an entirely different thing:
If you are going to use the coordinates of the bounding box to determine if something needs to be drawn to the screen, then draw it if even part of the bounding box is visible. Then use the clipping routines (which can clip to any shape) to ensure that just the bits you want visible are shown.
If you are going to use the coordinates of the bounding box to designate a click listener, then do so. Implement within the hexagon listener the extra code to determine if the click was within the hex or just within the bounding box. If it's outside the hex, then discard.
Basically without knowing a bit more about what you are trying to accomplish, it's not possible to offer a reasonable solution; however, many routines do bounding box checks first as a quick and dirty means of reducing the number of calls, and then do more detailed checks to see if the bounding box solution was a false positive (think object collision).