Messages

1

Feature requests / Re: Support drawing multiple arrays of same OpenGl mode within one call

« on: April 08, 2015, 05:16:57 am »

You have to remember, OpenGL is a pipeline. Pipelines don't like to stop and if you force them to they will annoy you with bad performance. You will get much better performance by shaping your geometry into "pipeline friendly" geometry instead of thinking of how to save draw calls through secondary data structures. Saving draw calls only benefits you if you are driver-bottlenecked, which to be honest almost never happens in a typical SFML application. When dealing with large amounts of geometry in SFML, it will probably be the memory bandwidth that kills performance, since all the data has to be transferred again and again every single frame.

Those are all really good and worthwhile points worth considering. I don't necessarily see why the two functions I referenced would particularly interrupt the OpenGL pipeline but I don't have a tremendous amount of experience with the inner workings of OpenGL so I'm more than willing to concede that point. Memory constraints are also obviously a big concern however for my particular needs in this project, which again may be strictly specific to me, my solution seemed to make stricter use of memory compared to the basic implementation. Mainly I found that with the way things currently are I would either be forced to add a large number of unnecessary vertices to describe more generic primitives rather than use OpenGL's abstractions such as triangle strip etc; or alternatively require additional instances of VertexArray, which as a C++ class with several functions and members such as std vector, does come with its own overhead that could add up depending on how many calls need to be made. In my particular case, this solution allows me to make the most of my memory and use only one instance of a (modified) VertexArray while still using only the lowest number of vertices as needed to describe my geometry (and some additional book keeping variables to make the new OpenGL calls work but those are trivial in comparison).

2

Feature requests / Re: Support drawing multiple arrays of same OpenGl mode within one call

« on: April 08, 2015, 04:55:47 am »

Yeah just to be clear I was merely speaking from a performance angle, it wouldn't necessarily add any new functionality. I also agree that for a typical 2d game focused user, which may be who SFML is currently focusing on I don't know, I imagine the program wouldn't require too much more than several disconnected quads with textures mapped to them, in which case this work could easily be seen as overkill. Again what originally led me down this path was SVG and 2d vector rendering in general where something like groups of disparate paths of bezier curves and other complex geometry could result in either a very large number of calls to OpenGL or a large number of unnecessary vertices under the current implementation.

I totally understand if you don't feel that the large majority of users would benefit from this kind of minutia, I might just be approaching it from an atypical perspective. I was more just curious if you guys thought the work I've done for my particular case would be helpful to the community at large. I'm completely fine with withdrawing my motion from the table however

3

Feature requests / Re: Support drawing multiple arrays of same OpenGl mode within one call

« on: April 08, 2015, 12:55:37 am »

Not exactly sure what you're asking here...

You can easily put multiple primitives of the same type into an sf::VertexArray (or std::vector<sf::Vertex> and draw it in one call. That's one of the main advantage of using vertex array over arrays of sprites.

Are you asking for something else then?

For primitive modes such as points, lines, triangles, and quads you are absolutely correct; I'm speaking in regards of the others: linestrip, triangle strip, and triangle fan, where each new vertex is related to the last. For instance, if I want to draw multiple triangle fans I would specify the first vertex as the center point and subsequent vertices as points radiating from that center origin, however in the current implementation, to the best of my knowledge, there is no way to define a *new* center point completely unrelated to that original triangle fan and draw them both with one call. The same way it is not possible to start a new triangle strip at a location different than the last vertex. The methods I outlined would allow this functionality.

4

Feature requests / Support drawing multiple arrays of same OpenGl mode within one call

« on: April 07, 2015, 07:56:51 pm »

Hey guys! I'm not sure what the general protocol here but this isn't so much a "request", more just bringing a feature possibility up for discussion. So I've been messing around with a little SVG renderer using SFML and, as tends to happen with mindless hobby projects, am waisting a lot of time with premature optimization. Mainly, I was interested in drawing multiple, unconnected, paths within the same OpenGL call. So basically, one TrianglesStrip vertex array to hold multiple OpenGL primitives.

Now there are a couple of ways to go about this in OpenGL and I've been spending sometime trying to plug them into RenderTarget's draw method. I started off rigging up something using glPrimitiveRestartIndex however it's a, relatively, newer call (introduced in 3.1 if I recall correctly) and while I got it working on my Windows PC the call was completely unsupported on my MacBook Pro (and I have no clue how it would work with OpenGL ES, which appears to be slowly becoming part of SFML's targets). So it looked like glPrimitiveRestartIndex​ wouldn't work with SFML's cross-platform purposes.

I've more recently moved onto implementing and alternative, glMultiDrawArrays, with some degree of success (Purely hacky proof of concept stuff, nothing close to being generally usable yet). glMultiDrawArrays appears to have much wider support and looks like it might play nicer than primitiveRestart in regards to how RenderTarget is structured. However I suppose the trade off is that from what I can tell it might not be as performant as primtiveRestart, basically coming down to how particular GPU's and drivers handle it.

So I guess this has all been a long winded way of putting a feature up for review and to provide some preliminary research I've done in regards to it. Do you think that being able to draw multiple primitives of the same mode within a single call is a valuable enough feature to be worth trying to implement? Or do you think it's something that would be unnecessary and not very rewarding to the common user?