Improving Python/C/C++ and general development process

Archive Blender Development
82

They mandate you use a single and only that one single outdated compiler to target their software to sidestep the binary issues. That’s not something I would call that ‘solving the problem’

A better solution was offered by MS with the COM infrastructure but that was/is notoriously complex (it is said it was designed by the team at MS who put the com in complexity) and is not supported on other operating systems (although the core fundamentals could carry over, if you want a better insight in the actual problems and how they solved them, essential com by don box is an interesting read)

The C++ people had a stab at this with N4028 but that seemingly never went anywhere.

This is a complex problem for which seemingly no ‘simple’ solution exists, any solution will generally be more of a compromise (like forcing everyone onto a single compiler) rather than an actual solution.

That being said, no reason you can’t layer a c++ client library on top of a well designed C based API… once more a compromise but one with more freedom than what autodesk chose to do.

The idea of ‘Why don’t you guys just have an C++ API and all problems will vanish, it’s that simple!’ is somewhat at odds with reality.

5 Likes
84

I think it’s much simpler to keep the problems indefinitely than to accept the C++ API just to prove to yourself that a program can work without basic addons while no other program does. And to be listening to the community complain for a decade because we would like to have what any other software had 15 years ago.

85

A few years ago, I made an add-on (actually there were several …) with the XSI C++ API … the same add-on that other developers were doing for Blender … with the Python API.
The difference between the two addons was quite large.
I can only say that the add-on made for XSI, had even shading nodes, when PyNodes didn’t exist in Blender yet.
If we add that the XSI add-on was one of my first projects in C++ it gives an idea of ​​the ease and flexibility that the XSI C++ API offered to developers. Now when I hear here and there, that having a C++ API for Blender is something ‘very bad’ for the addons system, I can only smile (or maybe I should cry …)
Only my two cents…
Greetings…

1 Like
86

I was torn on whether I should post this in here or as its own separate topic but I think it fits in with the general API performance discussion here. Does bmesh.update_edit_mesh() have poor performance on mid-to-high poly meshes? There’s been a lot of talk about a data I/O bottleneck when python interacts with Blender and I’m not asking for python help so much as seeking to understand if what I have run into is that bottleneck or something else.

I’m writing an add-on to handle certain types of component selections on a mesh in Edit mode. I have noticed that after my script is done and returns finished there is a 1-second lag before the 3D viewport updates to reflect the new selection when I’m testing on a mesh that has 333,000 faces.

The last few lines of the script are as follows:

    time_start = time.perf_counter()
    bm.select_history.add(active_face)
    bm.select_flush_mode()
    bmesh.update_edit_mesh(me)
    time_end = time.perf_counter()
    print("Time to Flush and update_edit_mesh: %.4f sec" % (time_end - time_start))
    return {'FINISHED'}

The very last thing that the script does is run a print statement before returning finished. If I watch the system console (top right in the video) next to the Blender window there is very clearly a delay after the print but before the viewport updates and I’m able to navigate the scene again.

Using VLC I can move the video forward 1 frame at a time so I can measure the delay with the stopwatch. The print to console happens at 00:02.96 and the viewport updates at 00:04.09 which is a difference of 1.13 seconds. But according to the performance timer it only takes 0.03 seconds to flush selection and update the edit mesh. If I delete the bmesh.update_edit_mesh() entirely then I’m able to navigate the viewport immediately after the print to console and the script ends (but then the mesh never updates, obviously).

So does that mean the update actually takes longer and the print statement happens before the update finishes and the 0.03s time is actually incomplete/wrong? Or is there something else happening afterward that causes the viewport to not refresh for a full second and this isn’t an api performance issues at all? (Reminder: the mesh is 333,000 faces)

For comparison if I run a loop_multi_select from the menu/hotkey (which is internal so there’s no data I/O) the update is instantaneous on the same 333k mesh.

image
image699×439 98.2 KB

Edit:
It occurs to me that this might be a different performance issue related to Edit-mesh to GPU Conversion or the total mesh data sent to the GPU (instead of selection changes only) mentioned in this task rather than a bottleneck at the Python interface itself. https://developer.blender.org/T74186

2 Likes