You are making things needlessly complicated. Do things as simple as possible. While separate windows, and even separate processes (to the point of using processes running on other machines via compute) are possible. But all you need is the conduit (also: love, but that is besides the point) - and some creative thinking to handle calculations.
If you think you’ll be doing heavier calculations you can do as already pointed out by @lando.schumpich: subscribe to the SelectObjects event and do your calculations. Then draw the data you’ve created in the conduit - or any other panel you write yourself.
Perhaps a great moment to finally make the step to C#.
With IronPython3 being in active development and Unity and other applications beginning to support IronPython I don’t know what will drive me to learn any statically typed language.
Be it as it may, I don’t want stuff drawn on my screen inside Rhino viewports that is an unnecessary clutter while I have curves and points in wireframe mode. At least not with the current use case in mind. Conduit seems a nifty way to create video game like gui. (perhaps Blender Game Engine embedding could be a nice addition to Rhino as well )
This will use the Rhino sole process for the calculation and just like Grasshopper lags that will lag as well. I want the calculations done in another process. Whether I’m going to use subprocess or some other method… That is something I need to clear out since I don’t know anything there and good IronPython examples are a rarity in internet. Just look at Clement’s example
Try moving the point. Before you release it the conduit text doesn’t update. This is because sticky is not updating in real-time.
I want exactly that. I want the value displayed in that separate process window to be displayed in real-time and not to start recalculation after I release the point.
I want an update of this conduit to be implemented the same as in Grasshopper canvas. But only when moving components around and connecting/disconnecting wires. As soon as Grasshopper starts taking Rhino objects it can no longer display values in real-time.
Hi @ivelin.peychev, the reason why the text displayed by the conduit is not updated while you’re moving the point is that the conduit text is only updated when Rhino is idle. If you look at the event, it is the idle event.
To update the conduit text in realtime, you would create a dynamic conduit, which means you’re inside a point picker and then block Rhino until you’re done with picking or moving your mouse while you’re prompted for a point.
There is an example in the EditPythonScript / Help menu called CustomGetPoint.
I think wat you want can be done with a different event, or by listening to any mouse movement and other events but you have to keep in mind that your calculation really needs to run very fast for that, it is restarted probably over 30times per second.
I’m afraid what I seek is not possible with the current setup of Rhino and its plugins.
Perhaps in the future. When the devs start agreeing with me that each plugin has to run in as a separate process. Then it will be possible without Rhino lock to perform calculations by any plugin and also displaying in real-time Rhino object data inside any plugin.
Unfortunately that seems a lot of work and I don’t expect it any time soon.
At least I hope to see a workaround somehow. Perhaps VSC’s plugin RhinoPython, more particularly its RhinoPlugin part CodeListener is currently the right way to go.
In the video you see a python script that makes use of the progress bar. However at a certain point since PythonEngine uses Rhino’s sole process to calculate everything it locks up. Rhino becomes non-responsive and as a result the progress bar is rendered useless.
McNeel, could you please provide a workaround for this. I want to see the progress of my script.
In some cases inserting Rhino.RhinoApp.Wait() after the status bar update call will help, it tells Rhino to wait for the “message pump” to catch up before going forward with the calculation.
That does help a bit, but the progress bar fills up quicker that the whole process, so at the end you’re stuck with 100% waiting twice as much the time you waited for it to fill up to 100%
I’ll try to figure out if I can re-position the update and waiting calls.
Normally you should be able to make it work. Of course, there are things you can’t “status bar”, for example the waiting time to create meshes or calculate a certain operation. It can only really tell you the percentage of your loop iterations that are done.
# nlist is a list of sufraces that join_surfaces_by_name() joins
Rhino.UI.StatusBar.ShowProgressMeter(0, len(nlist), "Join Surfaces", True, True)
c = 0
for k in range(len(nlist)):
c = c + k*len(nlist)/100
join_surfaces_by_name(nlist)
Rhino.UI.StatusBar.UpdateProgressMeter(c, True)
Rhino.RhinoApp.Wait()
Rhino.UI.StatusBar.UpdateProgressMeter(0,True)
Rhino.UI.StatusBar.HideProgressMeter()
Interestingly enough, using this code takes less time than waiting for the same function to complete when it locks Rhino.
I can bet if I could run the calculation for joining these surfaces using a separate Python process. This would’ve been done 1/4 of the time it takes now.
)