Vector drawing support.

[Mel]

I don't know if this is kind of too artisan or a really good idea, but i came with this it yesterday. Currently, Irrlicht supports some basic line drawing, i.e. you want to draw a 3D line: you provide start point, the end point and call the routine, end of it. Simple, and yet, useful... Until you hit the moment in which you want to draw thousands, namely outlining polygons (not a wireframe representation) a GUI artifact, an editor grid, vectorial numbers on the scene, or any other thing anyone can come up with (fancy space-ship HUDs? ). This has, ironicall, a much higher cost than a model done of thousands of triangles because the triangles can be stored on the video card, while, simple sets of line segments can't and my question is: is it possible to make something similar with segments? for instance a sort of drawing buffer which stores vertices and lists of indices so the engine was capable of drawing many lines at a time with a single draw call?. In due time, it could be even possible to provide spline lines, diferent drawing styles via stencil ops and so on.

How about it?

[CuteAlien]

I checked that in over easter :-) You can now set the primitive type on meshbuffers and use them for example to draw lines. Example here: https://bitbucket.org/mzeilfelder/irr-p ... ew-default
Only working in svn trunk (in a few hours the ogl-es branch should also work, just have to adapt the drivers there).

edit: Just noticed this only works for 3D stuff so far. Because Irrlicht drivers always set the 3d material mode for meshbuffers. Well - will try to work on this as well (I need those things myself right now).

[Mel]

I think it is okay to leave some option for 3D "drawings" as well, for instance to draw paths in space, or wireframes that aren't necesarily triangular (this could speed up the rendering of the bounding boxes, for example), or the like, also, with the thickness option, i think it would provide additional flexibility

[hendu]

That's another one of my patches, IIRC. I made it to have a meshbuffer of point sprites in VRAM.

[CuteAlien]

@hendu: Sorry man. I did even go over patches on the tracker before starting this in the hope to find some. But didn't see it (which one is that?). I found only some patch in forum about it (not from you and that patch was partly lost and the parts posted turned out to be rather buggy).

I've given up on the 2d meshbuffers for now. Pretty hard to implement that in a way which is useful to me without breaking interfaces (setting 2d render-mode always sets further variables, so I can't just say set 2d or 3d render mode and pass that variable through in the meshbuffer). I'm currently hacking around that for the stuff I need (with an internal lock in the driver preventing renderstate changes).

[chronologicaldot]

Bringing up the topic again...
I would think you would just pick some optimal distance to the near plane for rendering and set all the points to that z-depth. Sure, you'd have to set the world transformation and material before drawing (like any other mesh), but it's all still 3D. I'm not sure what you mean by the issues you hit though as I haven't tried it.
I don't mess around with lines much, although I seem to recall that was one of the features taken out of Burnings until the vertex cache could be fixed.

[CuteAlien]

It's not quite the same as 3D - the 2D mode has some special handling like own materials and other driver settings. And yes - you could probably use real 3d lines and draw them at a certain depth (and maybe specific z-buffer settings). If I remember right one of the biggest differences in 2D mode is that it doesn't even send the depth-coordinates, but it wouldn't matter that much doing that (but likely thare are some more differences).

Having 2D lines in buffers would still be good - just not something we can add easily for 1.9 like it was possible for the 3D lines.

[Mel]

Well, i wasn't speaking about 2D drawing only, i was speaking about optimizing a bit the drawing of lines in general, i.e. using GL_LINES, and such

[CuteAlien]

We use GL_LINES when you use the the corresponding primitve in drawing (also now in the new meshbuffers). We can't use them in the UI because OpenGL is the only platform which supports stuff like thick lines. For D3D we would have to simulate that first.