blocks|key|2056219|text|我想我会去找一个镶嵌算法。诚然，在大多数使用这些的情况下，目的是减少顶点的数量以优化渲染，但在您的情况下，您可以通过参数化来保留所有细节-优化的可能性可能会很有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2056220|网络上有许多镶嵌算法和代码-几年前我在DLL中封装了一个纯C%2B%2B，用于Delphi横向渲染器，它们对于高级图形编码教程和类似的主题并不少见。|2056221|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think I'd reach for a tessellation algorithm. It's true that in most case where these are used the aim is to reduce the number of vertexes to optimise rendering, but in your case you could parameterise to retain all the detail - and the possibility of optimising may come in useful.

There are numerous tessellation algorithms and code around on the web - I wrapped up a pure C on in a DLL a few years back for use with a Delphi landscape renderer, and they are not an uncommon subject for advanced graphics coding tutorials and the like.

blocks|key|2056257|text|我对此也很感兴趣，因为我想完善我的地图应用程序(Kosmos)的道路绘制。我使用的一种解决方法是绘制两次折线，一次使用较粗的线，另一次使用较细的线，并使用不同的颜色。但这并不是真正的多边形，它只是模拟多边形的一种快速方法。请在此处查看一些示例：http://wiki.openstreetmap.org/wiki/Kosmos_Rendering_Help#Rendering_Options|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2056258|我不确定这是不是你需要的。|2056259|entityMap|0|LINK|mutability|MUTABLE|url|http://wiki.openstreetmap.org/wiki/Kosmos|1|http://wiki.openstreetmap.org/wiki/Kosmos_Rendering_Help#Rendering_Options^0|O|6|0|3E|22|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

I'm interested in this too, since I want to perfect my mapping application's (<a href="http://wiki.openstreetmap.org/wiki/Kosmos" rel="nofollow noreferrer">Kosmos</a>) drawing of roads. One workaround I used is to draw the polyline twice, once with a thicker line and once with a thinner, with a different color. But this is not really a polygon, it's just a quick way of simulating one. See some samples here: <a href="http://wiki.openstreetmap.org/wiki/Kosmos_Rendering_Help#Rendering_Options" rel="nofollow noreferrer">http://wiki.openstreetmap.org/wiki/Kosmos_Rendering_Help#Rendering_Options</a>

I'm not sure if this is what you need.

blocks|key|2056379|text|看看Delaunay+triangulation是否能帮上忙。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2056380|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Delaunay_triangulation^0|2|M|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

See if <a href="http://en.wikipedia.org/wiki/Delaunay_triangulation" rel="nofollow noreferrer">Delaunay triangulation</a> can help.

blocks|key|2056427|text|一个简单的方法从我的头顶。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2056428|将每个2d顶点的角度一分为二，这将创建一条漂亮的斜接线。然后沿着这条线向内和向外移动，你的“厚度”(或厚度除以2？)的量，你现在就有了内部和外部多边形点。移动到下一个点，重复相同的过程，在此过程中构建新的多边形点。然后应用三种语言来获得渲染准备就绪的顶点。|2056429|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A simple method off the top of my head.

Bisect the angle of each 2d Vertex, this will create a nice miter line. Then move along that line, both inward and outward, the amount of your "thickness" (or thickness divided by two?), you now have your inner and outer polygon points. Move to the next point, repeat the same process, building your new polygon points along the way. Then apply a triangualtion to get your render-ready vertexes.

blocks|key|1842442|text|哦，好吧--我试着自己解决这个问题。我在试图解决零透支问题的解决方案上浪费了两个月的时间。正如你已经发现的，你不可能处理所有退化的情况，并且同时拥有零透支。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1842443|但是，您可以使用混合方法：|1842444|自己写一个例程，检查连接是否可以从简单的几何构造而没有问题。为此，您必须检查连接角度、线的宽度和连接的线段的长度(短于其宽度的线段是皮塔)。使用一些启发式方法，你应该能够理清所有琐碎的情况。|1842445|我不知道你的平均线条数据是什么样的，但在我的例子中，超过90%25的宽线没有退化的情况。|1842446|对于所有其他行：|1842447|你很可能已经发现，如果你容忍透支，生成几何图形要容易得多。这样做，让多边形CSG算法和镶嵌细分算法来完成这项艰巨的工作。|1842448|我已经评估了大多数可用的镶嵌包，最后我使用了GLU镶嵌器。它速度快，健壮，从不崩溃(与大多数其他算法不同)。它是免费的，许可证允许我将其包含在商业程序中。细分的质量和速度都是正常的。你不会得到delaunay三角剖分的质量，但因为你只需要渲染的三角形，这不是问题。|1842449|因为我不喜欢tesselator+API，所以我从免费的SGI+OpenGL参考实现中删除了tesselation代码，重写了整个前端，并添加了内存池以减少分配数量。这花了两天的时间，但这是非常值得的(比如第五个因素的性能提升)。该解决方案最终成为一个商业OpenVG实现:-)|1842450|如果在PC上使用OpenGL进行渲染，则可能需要将镶嵌/CSG作业从中央处理器移动到图形处理器，并使用模板缓冲区或z缓冲区技巧来消除透支。这比CPU镶嵌要容易得多，甚至可能更快。|1842451|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

Oh well - I've tried to solve that problem myself. I wasted two month on a solution that tried to solve the zero overdraw problem. As you've already found out you can't deal with all degenerated cases and have zero overdraw at the same time.

You can however use a hybrid approach:

Write yourself a routine that checks if the joins can be constructed from simple geometry without problems. To do so you have to check the join-angle, the width of the line and the length of the joined line-segments (line-segments that are shorter than their width are a PITA). With some heuristics you should be able to sort out all the trivial cases.

I don't know how your average line-data looks like, but in my case more than 90% of the wide lines had no degenerated cases.

For all other lines:

You've most probably already found out that if you tolerate overdraw, generating the geometry is a lot easier. Do so, and let a polygon CSG algorithm and a tesselation algorithm do the hard job. 

I've evaluated most of the available tesselation packages, and I ended up with the GLU tesselator. It was fast, robust, never crashed (unlike most other algorithms). It was free and the license allowed me to include it in a commercial program. The quality and speed of the tesselation is okay. You will not get delaunay triangulation quality, but since you just need the triangles for rendering that's not a problem. 

Since I disliked the tesselator API I lifted the tesselation code from the free SGI OpenGL reference implementation, rewrote the entire front-end and added memory pools to get the number of allocations down. It took two days to do this, but it was well worth it (like factor five performance improvement). The solution ended up in a commercial OpenVG implementation btw :-)

If you're rendering with OpenGL on a PC, you may want to move the tesselation/CSG-job from the CPU to the GPU and use stencil-buffer or z-buffer tricks to remove the overdraw. That's a lot easier and may be even faster than CPU tesselation.

blocks|key|1842502|text|在我的情况下，我可以透支。我只是将半径=+width/2的圆放在折线的每个顶点的中心。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1842503|工件以这种方式被屏蔽，如果你能忍受“圆角”和一些透支，那么它很容易实现。|1842504|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In my case I could afford to overdraw. I just drow circles with radius = width/2 centered on each of the polyline's vertices.

Artifacts are masked this way, and it is very easy to implement, if you can live with "rounded" corners and some overdrawing.

blocks|key|2056705|text|从你的图像看起来，你正在用填充和橙色在线段周围绘制方框。这样做肯定会造成糟糕的透支。所以首先要做的是不要渲染黑色边框和填充颜色可以是不透明的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2056706|为什么你不能使用GL_LINES原语来做你想做的事情呢？你可以指定宽度，过滤，平滑度，纹理任何东西。可以使用glDrawArrays()渲染所有顶点。我知道这不是你想要的东西，但当你专注于2D绘图时，这可能是更容易的方法。(搜索纹理线条等)|2056707|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

From your image it looks like that you are drawing box around line segments with FILL on and using orange color. Doing so is going to create bad overdraws for sure. So first thing to do would be not render black border and fill color can be opaque. 

Why can't you use GL_LINES primitive to do what you intent to do? You can specify width, filtering, smoothness, texture anything. You can render all vertices using glDrawArrays(). I know this is not something you have in mind but as you are focusing on 2D drawing, this might be easier approach. (search for Textured lines etc.)

blocks|key|1843113|text|我最终不得不亲自动手，写了一个小的ribbonizer来解决类似的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1843114|对我来说，问题是我希望OpenGL中的粗行没有我在iPhone上使用OpenGL时看到的那种工件。在研究了各种解决方案后，我决定自己制作可能是最简单的解决方案。有几种不同的方法。|1843115|一种方法是找到两个线段之间的相交角度，然后沿该相交线移动到离曲面一定距离处，并将其视为带状顶点。我试过了，它看起来并不直观；丝带的宽度可能会有所不同。|1843116|另一种方法是实际计算线段表面的法线，并使用该法线计算该线段的理想带状边，并进行带状线段之间的实际相交测试。这工作得很好，除了对于尖锐的角落，带状线段的交点太远(如果段间角度接近180‘)。|1843117|我用两种方法解决了锐角问题。Paul+Bourke直线相交算法(我以一种未优化的方式使用)建议检测相交是否在线段内部。由于两个线段是相同的，我只需要测试其中一个线段的交集。然后我可以仲裁如何解决这个问题；要么在两端之间伪造一个最佳点，要么戴上一个端盖-这两种方法看起来都很好-端盖方法可能会抛弃opengl的多边形前向/后向排序。|1843118|请参阅http://paulbourke.net/geometry/lineline2d/|offset|length|1843119|请在此处查看我的源代码：https://gist.github.com/1474156|1843120|entityMap|0|LINK|mutability|MUTABLE|url|http://paulbourke.net/geometry/lineline2d/|1|https://gist.github.com/1474156^0|0|0|0|0|0|3|16|0|0|C|V|1|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@$L|15|M|16|1|17]]|A|$]]|$1|N|3|O|5|6|7|18|8|@]|9|@$L|19|M|1A|1|1B]]|A|$]]|$1|P|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]|X|$5|S|T|U|A|$V|Y]]]]

I ended up having to get my hands dirty and write a small ribbonizer to solve a similar problem.

For me the issue was that I wanted fat lines in OpenGL that did not have the kinds of artifacts that I was seeing with OpenGL on the iPhone. After looking at various solutions; bezier curves and the like - I decided it was probably easiest to just make my own. There are a couple of different approaches.

One approach is to find the angle of intersection between two segments and then move along that intersection line a certain distance away from the surface and treat that as a ribbon vertex. I tried that and it did not look intuitive; the ribbon width would vary.

Another approach is to actually compute a normal to the surface of the line segments and use that to compute the ideal ribbon edge for that segment and to do actual intersection tests between ribbon segments. This worked well except that for sharp corners the ribbon line segment intersections were too far away ( if the inter-segment angle approached 180' ).

I worked around the sharp angle issue with two approaches. The Paul Bourke line intersection algorithm ( which I used in an unoptimized way ) suggested detecting if the intersection was inside of the segments. Since both segments are identical I only needed to test one of the segments for intersection. I could then arbitrate how to resolve this; either by fudging a best point between the two ends or by putting on an end cap - both approaches look good - the end cap approach may throw off the polygon front/back facing ordering for opengl.

See <a href="http://paulbourke.net/geometry/lineline2d/" rel="nofollow">http://paulbourke.net/geometry/lineline2d/</a>

See my source code here : <a href="https://gist.github.com/1474156" rel="nofollow">https://gist.github.com/1474156</a>

blocks|key|2057511|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2057512|http://www.codeproject.com/Articles/226569/Drawing-polylines-by-tessellation|offset|length|2057513|它看起来完全是你想要的，它的许可证甚至允许在商业应用中使用它。我可能会在某一时刻尝试用它来替换我自己的不太完美的实现。|2057514|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|24|0|0|0^^$0|@$1|2|3|-4|4|5|6|N|7|@]|8|@]|9|$]]|$1|A|3|B|4|5|6|O|7|@]|8|@$C|P|D|Q|1|R]]|9|$]]|$1|E|3|F|4|5|6|S|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|T|7|@]|8|@]|9|$]]]|H|$I|$4|J|K|L|9|$M|B]]]]

I just found this amazing work:

<a href="http://www.codeproject.com/Articles/226569/Drawing-polylines-by-tessellation" rel="nofollow">http://www.codeproject.com/Articles/226569/Drawing-polylines-by-tessellation</a>

It seems to do exactly what you want, and its licence allows to use it even in commercial applications. Plus, the author did a truly great job to detail his method. I'll probably give it a shot at some point to replace my own not-nearly-as-perfect implementation.

I have a path made up of a list of 2D points. I want to turn these into a strip of triangles in order to render a textured line with a specified thickness (and other such things). So essentially the list of 2D points need to become a list of vertices specifying the outline of a polygon that if rendered would render the line. The problem is handling the corner joins, miters, caps etc. The resulting polygon needs to be &quot;perfect&quot; in the sense of no overdraw, clean joins, etc. so that it could feasibly be extruded or otherwise toyed with.
Are there any simple resources around that can provide algorithm insight, code or any more information on doing this efficiently?
I absolutely DO NOT want a full fledged 2D vector library (cairo, antigrain, OpenVG, etc.) with curves, arcs, dashes and all the bells and whistles. I've been digging in multiple source trees for OpenVG implementations and other things to find some insight, but it's all terribly convoluted.
I'm definitely willing to code it myself, but there are many degenerate cases (small segments + thick widths + sharp corners) that create all kinds of join issues. Even a little help would save me hours of trying to deal with them all.
EDIT: Here's an example of one of those degenerate cases that causes ugliness if you were simply to go from vertex to vertex. Red is the original path. The orange blocks are rectangles drawn at a specified width aligned and centered on each segment.
<a href="https://i.stack.imgur.com/MfYJs.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/MfYJs.png" alt="" /></a>

How do I render thick 2D lines as polygons?

我有一个由二维点列表组成的路径。我想把它们变成一个三角形的条带，以便渲染一条具有指定粗细的纹理线条(以及其他类似的东西)。因此，从本质上讲，2D点的列表需要成为指定多边形轮廓的顶点列表，如果进行渲染，多边形的轮廓将呈现该线。问题是处理角连接、斜接、封口等。生成的多边形需要在没有透支、干净连接等意义上是“完美的”，以便可...

问如何将粗2D线渲染为多边形？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何将粗2D线渲染为多边形？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何将粗2D线渲染为多边形？
EN