You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working on writing some python binding code for an algorithm that relies on Embree. I ran into an issue when I found I needed to be able to efficiently add geometries to the Embree scene that the algorithm processes. When wrapping the Embree objects for Python, I found that many attributes are settable but not gettable through the API. This gets in the way of providing an object oriented binding for object oriented languages. The frustrating part is that I can see that most of these missing functions are exposed methods on the internal Embree objects that the C API wraps.
While making this I noticed the pyembree branch that @dopitz has been working on. Personally, I'm disappointed that it is a transliteration rather than a Pythonic API. But I suspect he has run into the issues I've had with getting data back out of Embree, and doing something more user friendly is difficult.
I went through the v4.3 C API and made a list of functions that, in my opinion, should be added to the API:
One larger change that I listed was adding an RTCAccessor struct based on the glTF Accessor so that the buffer binding parameters could be returned as a single structure. I would suggest returning a zero initialized structure for unpopulated but assignable slots on a geometry.
As a side note, what I mean by // like vulkan is that it returns a vector by two successive calls. The first call with the output pointer set to nullptr just gets the size of the resulting array. The user then allocates that memory, and calls the function again with the allocated pointer to get the array values. The default value would need to be wrapped in a macro controlled by EMBREE_API_NAMESPACE.
I'd also like to see a C++ header with compile time information. Some good information would be the buffer types attached to each geometry type, the number of slots for each buffer type, and the buffer formats allowed for each buffer type. But this is not necessary.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
I've been working on writing some python binding code for an algorithm that relies on Embree. I ran into an issue when I found I needed to be able to efficiently add geometries to the Embree scene that the algorithm processes. When wrapping the Embree objects for Python, I found that many attributes are settable but not gettable through the API. This gets in the way of providing an object oriented binding for object oriented languages. The frustrating part is that I can see that most of these missing functions are exposed methods on the internal Embree objects that the C API wraps.
While making this I noticed the pyembree branch that @dopitz has been working on. Personally, I'm disappointed that it is a transliteration rather than a Pythonic API. But I suspect he has run into the issues I've had with getting data back out of Embree, and doing something more user friendly is difficult.
I went through the v4.3 C API and made a list of functions that, in my opinion, should be added to the API:
One larger change that I listed was adding an RTCAccessor struct based on the glTF Accessor so that the buffer binding parameters could be returned as a single structure. I would suggest returning a zero initialized structure for unpopulated but assignable slots on a geometry.
As a side note, what I mean by
// like vulkan
is that it returns a vector by two successive calls. The first call with the output pointer set tonullptr
just gets the size of the resulting array. The user then allocates that memory, and calls the function again with the allocated pointer to get the array values. The default value would need to be wrapped in a macro controlled byEMBREE_API_NAMESPACE
.I'd also like to see a C++ header with compile time information. Some good information would be the buffer types attached to each geometry type, the number of slots for each buffer type, and the buffer formats allowed for each buffer type. But this is not necessary.
The text was updated successfully, but these errors were encountered: