Direct access to draw data outside of callback. about im3d HOT 4 CLOSED

Hi - thanks for clarifying the issue! I think I understand better now: all you really want is to know the total number of vertices that will be drawn before the callbacks happen, so that you can (re)allocate your vertex buffer up front.

Actually this is already possible but it's a sort of 'backdoor' in the API and looks hacky:

U32 totalVertices  = 0;
totalVertices += GetContext().getPrimitiveCount(DrawPrimitive_Triangles) * 3;
totalVertices += GetContext().getPrimitiveCount(DrawPrimitive_Lines)     * 2;
totalVertices += GetContext().getPrimitiveCount(DrawPrimitive_Points)    * 1;

U32 allocationSize = totalVertices * sizeof(VertexData);

Of course, this information is only accurate at the time you call Draw() - if you do any Im3d:: calls between allocating the buffer and calling Draw() (or MergeContexts() for a multi-context setup), your buffer will be the wrong size!

I'm thinking about ways to enforce this ordering constraint via the API. The best solution I can think of is to have the callback called only once, so that the app can consume all of the pending draw lists at once and have global info about the frame, e.g.:

void Im3d_Draw(const Im3d::DrawList _drawList[], int _drawListCount)
{
 // loop over all the draw lists and count vertices
 // (re)allocate resources
 // issue draw calls

Right now I don't see any negative implications of doing it this way (I can still support the old-style callback) and it maintains the single point of contact between the app and the draw data (which I think simplifies things a lot).

Any additional thoughts or ideas are appreciated!

from im3d.

Ok, so having 'direct' access to the draw data is possible but will require a couple of changes to the API. Right now, calling Draw() finalizes the draw data internally (really this just means doing the sorting), and then calls the app callback. So this finalization step would still need to happen, however I'd probably move it to an EndFrame() function - after calling this the draw lists would be available until you call NewFrame() again.

I think I'm happy with doing it this way, rather than adding a new type of callback. I'll therefore mark this issue as 'todo' and put it at the top of my list. Thanks again for your input!

from im3d.

The new API is now available in version v1.13. The examples have been updated to use the new API (draw callback is marked deprecated but I'll probably not remove it any time soon).

Thanks again for your valuable input!

from im3d.

Thank you very much for the response and recommendation on a workaround.

The callback with a list of commands seems like a much better way to approach it.

If I may bring in another library for an example for a moment, ImGui has made the render callback function obsolete (still available by default though) and instead recommends the user call a function GetDrawData() when they need access to draw lists from the library.

In the case where the users might want to distribute the draw call recording/buffer management payload between threads this method of direct access would be the best way to do it, only requiring the threads to all sync with the get list function. Instead of having to be invoked or wrangled by a callback.

from im3d.