Hi there,

I'm playing around with primitive render hooks and having some trouble where my generated GR_Primitive gets deleted unexpectedly. I'm setting the GUI_HOOK_FLAG_COLLECT_PRIMS flag and deletion occurs whenever my GR collection primitive has a mix of primitives, some that do and some that don't meet the criteria (type) for the hook. I would expect the GR_Prim to be kept if it had at least on primitive that DID meet the criteria.

I'm looking at the docs re: this:
http://www.sidefx.com/docs/hdk13.0/hdk_viewport.html [sidefx.com]

Can you explain the 4th potential reason for deletion?
“If primitives were reordered in the detail such that a match between a primitive and its GR primitive could not be made.”

Thanks for your help!

If you had a GU_Detail with the following primitives:

Primitive Sphere
PolySoup
Volume

and on the next cook, it changed to

PolySoup
Primitive Sphere
Volume

the GR prim for the primtiive sphere would be deleting as it no longer matches PolySoup. Houdini doesn't try to match forward in the list as that can led to very slow situations. It's also a relatively uncommon case.

Once the GR_Primitive is deleted what is the expected draw behavior? We get a reliable segfault soon after the GR_Primitive is deleted and I'm wondering if that's a problem on our end or simply due to the absence of the primitive.

AP_Interface::coreDumpChaser(UTsignalHandlerArg) <libHoudiniUI.so>
AP_Interface::si_CrashHandler::chaser(UTsignalHandlerArg) <libHoudiniUI.so>
signalCallback(UTsignalHandlerArg) <libHoudiniUT.so>
UT_Signal::UT_ComboSignalHandler:perator()(int, siginfo*, void*) const <libHoudiniUT.so>
UT_Signal::processSignal(int, siginfo*, void*) <libHoudiniUT.so>
_L_unlock_16 <libpthread.so.0>
RE_OGLBuffer::setLabel(RE_Render*, char const*) <libHoudiniUI.so>
restartCollection(UT_Thing&, UT_Hash const&, void*) <libHoudiniAPPS3.so>
UT_ThingList::traverse(int (*)(UT_Thing&, UT_Hash const&, void*), void*) const <libHoudiniUT.so>
UT_HashTable::traverseConst(int (*)(UT_Thing&, UT_Hash const&, void*), void*) const <libHoudiniUT.so>
GUI_GeoRender::update(RE_Render*, GR_DisplayOption*, GUI_SetupResult, GR_DecorationOverride, char const*, bool&) <libHoudiniAP
PS3.so>
GUI_DetailLook::updateForRender(RE_Render*, GUI_DisplayOption&, RE_LightList*, GR_DecorationOverride, char const*, bool&) <lib
HoudiniAPPS3.so>
DM_VPortAgent3D::setupGeometry(RE_Render*) <libHoudiniAPPS3.so>
DM_VPortAgent3D::renderViewport(RE_Render*, int, int, bool, bool) <libHoudiniAPPS3.so>
DM_VPortAgent3D::doRender(RE_Render*, int, int) <libHoudiniAPPS3.so>
DM_Viewport::doRender(RE_Render*, int, int) <libHoudiniAPPS3.so>
UI_Feel::renderMe(RE_Render*, int, int) <libHoudiniUI.so>
UI_Feel::doRenderKids(RE_Render*, int, int) <libHoudiniUI.so>
UI_Feel::doRender(RE_Render*, int, int) <libHoudiniUI.so>
UI_Feel::renderMe(RE_Render*, int, int) <libHoudiniUI.so>
UI_Feel::doRenderKids(RE_Render*, int, int) <libHoudiniUI.so>
UI_Feel::doRender(RE_Render*, int, int) <libHoudiniUI.so>
UI_Viewport::reRender(RE_Render*, bool) <libHoudiniUI.so>
UI_Window::renderChildViews(RE_Render*) <libHoudiniUI.so>
UI_Window::doRedraw() <libHoudiniUI.so>
UI_Queue::doWindowRedraws() <libHoudiniUI.so>
UI_Timer::handleEvent(UI_Event*) <libHoudiniUI.so>
UI_Manager::handleEvent(UI_Event*) <libHoudiniUI.so>
UI_Queue::processNextEvent() <libHoudiniUI.so>
UI_Queue::drain() <libHoudiniUI.so>
UI_Queue::eventLoop() <libHoudiniUI.so>
main_part2(int, char const* const*) <libHoudiniUI.so>
main <libHoudiniUI.so>
__libc_start_main <libc.so.6>
_start <houdini-bin>

Any thoughts?

I should add that our use case is simply overriding bezier curves. If some of the input curves change from bezier to linear/nurbs and then back to bezier (which happens in our networks quite often) we get a crash.

It appears to be a bug in the hook code. I will see if it can be fixed for the next production build.

twod
It appears to be a bug in the hook code. I will see if it can be fixed for the next production build.

\

Much appreciated. Thanks!