Just wondering if everyone else is still having trouble with the built-in help pane? It seems that after switching to QT, back in the day, it's always needed the browser env var work-around and I was hoping that by now it would be fixed.
The main issues are that it goes blank after searching, say for ‘motion path’ and clicking on the first topic http://127.0.0.1:48626/basics/motionpath, [127.0.0.1] or it's incredibly slow after a few link clicks.
Let us know your thoughts!
Ubuntu 18.04.1, H17.5.229, Nvidia.
built in help pane misbehaving
934 1 1-
- anon_user_37409885
- Member
- 4189 posts
- Joined: June 2012
- Offline
-
- David Sarma
- Member
- 1 posts
- Joined: Oct. 2013
- Offline
I was experimenting with the help browser a few years ago as a potential means to get Houdini to interoperate with Javascript. The idea is that this would open the door to all manner of browser visualization options (e.g. D3, P5.js, Plotly), input via WebMidi, camera and sensor input, or any other options that come from interoperation with the web. Particularly with GLTF export, and new possibilities coming along with WASM and WebGPU, it would seem that this might become more relevant.
The initial issue I had was that there's not an apparent way to open the help browser devtools to debug Javascript or display issues (If there is and I just missed it, I'd really appreciate hearing how to do that). The other issue, as you mentioned, is the apparent sluggishness. I'm not quite sure the different issues, being unfamiliar with QT, but I found a link at least explaining some of how the Javascript communication works (https://retifrav.github.io/blog/2018/07/14/html-from-qml-over-webchannel-websockets/). In my experience so far, trying to load a sample page with a GLTF file in the help browser (for example this one: https://reon90.github.io/redcube/) doesn't display correctly.
While using an external browser helps to address the speed of display issue, at the moment, the “Scripting Houdini from web pages” help page (https://www.sidefx.com/docs/houdini/hom/browserpython.html) states that communication to Houdini only works with the embedded browser.
This does seem like a longstanding issue that's persisted for a while, so I was wondering if a different direction might help to address the issue. If the help were instead included as an Electron application, with the ability to send commands back to Houdini, then that would gain the benefit of continuous upgrades as browsers update, and have immediate access to familiar browser devtools. Speaking about things that I don't really know much about, going by the above link, my guess is that if the WebSocketTransport were enabled in addition to the WebChannelTransport, that's what would allow the external browser to have equivalent functionality to the embedded browser, of executing Houdini commands. Of course, then a user could roll their own Electron application to have file system access, control Houdini to respond to data streams delivered via web pages, or any other possibilities that the web allows.
The initial issue I had was that there's not an apparent way to open the help browser devtools to debug Javascript or display issues (If there is and I just missed it, I'd really appreciate hearing how to do that). The other issue, as you mentioned, is the apparent sluggishness. I'm not quite sure the different issues, being unfamiliar with QT, but I found a link at least explaining some of how the Javascript communication works (https://retifrav.github.io/blog/2018/07/14/html-from-qml-over-webchannel-websockets/). In my experience so far, trying to load a sample page with a GLTF file in the help browser (for example this one: https://reon90.github.io/redcube/) doesn't display correctly.
While using an external browser helps to address the speed of display issue, at the moment, the “Scripting Houdini from web pages” help page (https://www.sidefx.com/docs/houdini/hom/browserpython.html) states that communication to Houdini only works with the embedded browser.
This does seem like a longstanding issue that's persisted for a while, so I was wondering if a different direction might help to address the issue. If the help were instead included as an Electron application, with the ability to send commands back to Houdini, then that would gain the benefit of continuous upgrades as browsers update, and have immediate access to familiar browser devtools. Speaking about things that I don't really know much about, going by the above link, my guess is that if the WebSocketTransport were enabled in addition to the WebChannelTransport, that's what would allow the external browser to have equivalent functionality to the embedded browser, of executing Houdini commands. Of course, then a user could roll their own Electron application to have file system access, control Houdini to respond to data streams delivered via web pages, or any other possibilities that the web allows.
-
- Quick Links