Best way to create an Arrow-Shape

[lithander]

An arrow is not a convex shape and so my first naive implementation by just deriving a class ArrowShape from Shape and returning the 7 points that are needed for a basic arrow didn't work out. (Outline renders okay, but filling doesn't work)

So, now I'm wondering whats the best practice to get something like this done? I want to be able to support the full range of Shape's features including LineThickness and FillColor. Should I use and render VertexArrays (but how do I set the LineThickness when rendering line primitives?) or should I use a composition of shapes? (the syncing of all the public properties that a shape typically has seems like a lot of work for such a basic goal)

What's the best practice?

I'm using SFML.Net btw

[Nexus]

In thor::Arrow and its implementation, I have composed the arrow of a rectangle and a triangle shape. But it would also be possible (and probably more efficient) to build a vertex array with 3 triangles.

There's also NetEXT, a C# port of Thor, but I'm not sure if it has an Arrow class.

[zsbzsb]

There's also NetEXT, a C# port of Thor, but I'm not sure if it has an Arrow class.

The shape module is currently a work in progress. Feel free however to try out the arrow class as that should be complete.

[lithander]

Thanks for your replies!

I've had a look at NetEXT but that particular arrow implementation wasn't exactly what I'm looking for. (I'm sure I'll have a more in depth peek later as it seems to be fountain of *other* useful stuff, though) But what I need the arrow shape to do is to render a thick outline in addition to the filled shape.

Of course I'm not expecting SFML to have everything exactly the way I need it but that's what all the build in shapes provide. So I thought I could just extend the basic Shape class like CircleShape and RectangleShape do to arrive there.

Now, seeing how much work you guys have put into extension librarys I guess the scope of SFML is just a bit narrower then what I thought. No problem. What bugs me, though, is that the shape implementation obviously has access to path rendering (e.g connected line segments with a thickness) but that usability isn't exposed to the user. 

Anyway, how to approach that problem? Thor composes concave shapes as a combination of primitive shapes (circles & rects for the edges, tris for the body) which is flexible enough to cover arbitrary polygons (except polygons with holes, right?) and would work alright if draw performance is not an issue (otherwise the fact that many drawcalls per shape-vertex are necessary will hurt a lot). Biggest issue for me however: it's not ported yet.

From my noobs point of view I think that SFML would really benefit from build-in path rendering with arbitrary thickness. (If not more vector graphics features ala http://en.wikipedia.org/wiki/OpenVG) Has this allready been proposed as a feature request? Or is there an extension that does that? If I started to write my own code in that area that would feel like a full-featured side-project instead of something I could justify to do at work. ;/

P.S.: I'm not trying to step on anyones toes. Just trying to figure out how SFML want's to be used!

[zsbzsb]

I've had a look at NetEXT but that particular arrow implementation wasn't exactly what I'm looking for. But what I need the arrow shape to do is to render a thick outline in addition to the filled shape.

Can you explain more of what you are after? Because there is an outline in the arrow class. 

What bugs me, though, is that the shape implementation obviously has access to path rendering (e.g connected line segments with a thickness) but that usability isn't exposed to the user.

Huh? No it doesn't, why don't you look at the implementation and you will see all it does is use vertex arrays that are exposed through the public API.

otherwise the fact that many drawcalls per shape-vertex are necessary will hurt a lot

Again, it is implemented via vertex arrays which means 1 draw call per array.

Biggest issue for me however: it's not ported yet.

Feel free to contribute, you know where the repo is 

SFML would really benefit from build-in path rendering with arbitrary thickness

Well to me this seems to be a very specific high level feature request. SFML aims to provide all the building blocks to do just about anything you want. Also the current mind set is to not implement something in SFML that can be handled outside the library. However, feel free to open a thread in the suggestions forums - just remember my previous sentence. 

[Nexus]

With performance, I think lithander means thor::ConcaveShape, which internally uses sf::ConvexShapes for rendering. The reason for this is mostly historic: I wrote this class before sf::VertexArray existed, it has already been part of the very first Thor version back in 2011. This might change in the future, together with the rendering of thor::Arrow, but for Thor 2.0 I have higher priorities.

I'm not sure if porting concave shapes as-is to C# is a good idea. If you look behind the scenes, you'll see that the implementation is far from trivial. In order to decompose a concave shape into convex shapes, a Delaunay triangulation algorithm is used... I implemented it myself, and I'd probably not do it right again, it was a rather tedious debugging experience You might consider alternatives, like a simpler decomposition algorithm, or an existing implementation.

[lithander]

Can you explain more of what you are after? Because there is an outline in the arrow class. 

Maybe I was looking at an old version?
https://bitbucket.org/zsbzsb/netext/src/5f3d9f38b34d7a6738bcac259160650e75c62f5c/NetEXT/Shapes/Arrow.cs?at=feature/shapes
The arrow rendered here consists of a stem ("Line") and a tip ("Triangle") rendered in a given color. But the shapes build into SFML support an outline that traces the silhoutte of the shape in a second color.

What I'm looking for is like this:

No code here that would do that, or am I missing something? 

What bugs me, though, is that the shape implementation obviously has access to path rendering (e.g connected line segments with a thickness) but that usability isn't exposed to the user.

Huh? No it doesn't, why don't you look at the implementation and you will see all it does is use vertex arrays that are exposed through the public API.

otherwise the fact that many drawcalls per shape-vertex are necessary will hurt a lot

Again, it is implemented via vertex arrays which means 1 draw call per array.

SFML Shape is fine. I'm talking about the ConvexShape in Thor.
https://github.com/Bromeon/Thor/blob/master/src/ConcaveShape.cpp

Look at formOutline and draw methods. There's one shape, per tesselated tri. 2 shapes per edge. So some arbitrary polygon that consists of 10 edges and tesselates into say 10 triangles will need ~30 drawcalls. Am I right?

SFML would really benefit from build-in path rendering with arbitrary thickness

Well to me this seems to be a very specific high level feature request. SFML aims to provide all the building blocks to do just about anything you want. Also the current mind set is to not implement something in SFML that can be handled outside the library. However, feel free to open a thread in the suggestions forums - just remember my previous sentence. 

It's probably true that this kind of feature could be implemented outside SFML just not by a layman and not quickly. I can see that what you describe as the "current mindset" makes sense for a hardware abstraction layer that has "simple" in his name. I'm just spoiled from e.g. the flash API or the Cinder framework, I guess.

[zsbzsb]

Maybe I was looking at an old version?

Ooops  my bad, I haven't looked at the code in a while (and had a long day playing card games with family) and mistook 'thickness' for 'outline thickness'.

No code here that would do that, or am I missing something?

Yes, you are right.

Look at formOutline and draw methods. There's one shape, per tesselated tri. 2 shapes per edge. So some arbitrary polygon that consists of 10 edges and tesselates into say 10 triangles will need ~30 drawcalls. Am I right?

That very well looks like it may be the case, remember I haven't gotten this far into the port yet - however I don't see why it couldn't be implemented with a single draw call. Maybe Nexus should be answering this and not me.

[FRex]

In theory sf::ConvexShape can represent an arrow (and other non convex shapes) just like it can represent a star.
If there is line from middle of bounds to each vertex then it can be done.
In practice, a lot of nice looking arrows will break that rule, but you can write own triangle fan (or strip or list) that does the same easily.

That very well looks like it may be the case, remember I haven't gotten this far into the port yet - however I don't see why it couldn't be implemented with a single draw call. Maybe Nexus should be answering this and not me.

I'm not Nexus, but it can be done with triangles and triangle strip (obviously harder) but not with triangle fan.
sf::Shape is two calls BTW: one triangle fan and one triangle strip, because one of them (the shape fan) may be textured, but it could be made with a single strip if someone really wants to and doesn't care for the texturing.

[Nexus]

Seems like some of you have missed my answer

[zsbzsb]

Seems like some of you have missed my answer

I was totally out of it last night, I guess I did miss it 

you'll see that the implementation is far from trivial.

I don't see why a complicated implementation should stop it from being ported. Either way, finding another implementation or porting the Thor version will take time and will still need to be maintained.

[Nexus]

I don't see why a complicated implementation should stop it from being ported.

I'm not sure if it would be possible to just rewrite the C++ code 1:1 to its C# equivalents. I could imagine that some parts might need to be handled differently, which would require a detailed understanding of the algorithm's functionality. It's not impossible, but needs some effort. Anyway, I assume you know that; my post was rather directed to lithander as an explanation why the concave shape has not been ported yet

Either way, finding another implementation or porting the Thor version will take time and will still need to be maintained.

Yes... If I change something or fix a bug in Thor, that would have to be carried over -- that is, unless you directly use the underlying C++ code for the triangulation and write a C# API on top of it.

[shadowmouse]

This might be a stupid suggestion, but is there any reason not to just make a sprite and texture using that arrow image you posted earlier or another one if you wanted a different style?

[lithander]

Thanks for the discussion. I've learned a lot about SFML through it.

Shadowmouse, that's not a stupid suggestion. I'll probably just do that. But first I wanted to make sure that there isn't some easy way to generate one procedurally. That wasn't obvious to me from the beginning.

I'm tempted to mess with triangulation of paths and other primitive shapes and maybe make something worthy of contributing to the community. But for now I'm swamped with work so this'll have to wait.