i’ve tried to use Rhino.Geometry.Mesh.CreateRefinedLoopMesh using a simple quad or mesh plane. The result is always that some vertices are converged at the world origin, regardless of the loop formula used.
Using Rhino.Geometry.Mesh.CreateRefinedCatmullClarkMesh, i provided the settings for NakedEdgeMode like below:
the result is always that the corner faces are missing. My guess is both methods need further investigation. Could these 2 methods preserve mesh texture coordinates in the future ?
Those methods are not currently for public consumption.
In fact, they do not autocomplete. They may be changed or removed without warning in any SR.
I am not sure why they appear in the help, but they should not.
So sad, i really was pleased to see them and would have a lot of use for it. But i’ve found more bugs, eg. when using Mesh.ClosestPoint on the resulting meshes when they are in memory and not created in the document…
Will try to do access wb now to create the subdivided meshes i need.
thanks @piac, i had bookmarked the example @Jess provided but i have this problem: If GH has not been opened and the example script is run the first time, i get this:
After clicking on No, my script runs. But above takes quite a while to complete. I do not get the errors if GH has been opened and closed at least once, Is there a way to avoid that or is opening GH a precondition to access the WB features ?
Importing ghpythonlib in the Rhino editor is not supposed to do any of these. However, it seems you have a lot of plug-ins, and some may expect Grasshopper to be loaded to do some ‘tricks’, like adding menus, or other unspecified operations that are not necessarily ‘allowed’.
ghpythonlib and NodeInCode require Grasshopper to open. I would like to investigate what plug-in/plug-ins cause this. Would you be helpful and try disabling some of the add-ons (MeshFromPoints_1 as a test) and the Arduino one (what is that one called?).
It’s also allowed to add references to Weaverbird.CommonSdkSupport.dll (provided that you do not distribute it). It’s not so straightforward, but then you can execute WB operations without loading GH.
HI @piac, yes it does this too if i try to use NodeInCode. I’ll have no idea how to disable certain plugins and think this is not a good idea as i have no clue if my client likes this behavior (the loooong load times together with the disabling of plugins).
How would you use the FindComponent method to access “wbCatmullClark” ? I always get None. The helpfile mentions to use a library name and period, i’ve tried all possible combinations but could not access it.
Thank you, i can try this, but i need to redistribute my scripts to my clients. Thats why i have been exited to see a CatmullClark method in RhinoCommon. I could use it at least in V6 without further hassle. I have one script which does CC as well, but it is not as fast as the C# version. All in all, it’s pretty cumbersome to make this work on all platforms and V5 + V6 using the same code , the subdivision i need is only done in memory and the meshes should never be added to the doc…
I just meant to temporarily uninstall them from your machine. See if the problem for the Arduino one goes away. If you then report that plug-in name to me, I will contact the developers and see with them a way to improve their plug-in or Rhino so that they work with one another .
A = Rhino.NodeInCode.Components.NodeInCodeFunctions.GetDynamicMemberNames();
The “.” is only for Python.
Just as a comment, NodeInCode in C# and ghpythonlib essentially work in the same manner. The same error dialogs will be present also in C#, unless we fix them. I can tell you that I fixed the first one today, and the fix will be included in Rhino 6 SR7. With your help, also the next two will be fixed, soon. Thanks!
using the dll works flawless, no error messages and no load messages are printed to the commandline. I just need a way to find out if the file location i use on my system can be found on other systems. It is currently the best of all methods as it works with V5 and V6 in the same way.
Regarding the NodeInCode problem, i guess the arduino.exe error comes from the FireFly plugin. I’ve not installed any plugins in GH for RH6 myself, they where all automagically migrated from my GH installation i use in RH5. When i disable that plugin (3 entries under Preferences / Solver / Plug-In Loading) by adding the load protection, the error message dialog does not come up again but i get these instead:
When calling NodeInCode i do get this one from goat too:
I’ve checked this “Do not show this warning message again” numerouos times, but after reopening GH in RH6, it comes up again. When i add the loadprotection (2 entries) i get this everytime:
All the plugin load messages are still printed to the command line though. After all this, i can select the mesh and continue. Note this only happens once and only if GH has not been opened yet. Does this help ?
If you do it in Python, then just clr.AddReference("Weaverbird.CommonSdkSupport") will necessarily work if WB is installed correctly. In C#, just adding the reference and using it from a specific method will work, again if WB is installed in Rhino.
Thanks; this is helpful.
The “automagical” migration was something that was discussed.
Regarding all these dialogs, I think @DavidRutten might want to chime in regarding the reasons why the dialogs should appear every time.
EDIT: I just remembered about the _GrasshopperIgnorePlugin command, that can be used to remove “automagically migrated” plug-ins from V6. See more info.
Thanks, i can confirm this works from RH6 without a path where i have WB installed in GH. But i do not have it in V5 so there i get the message:
Could not add reference to assembly Weaverbird.CommonSdkSupport
So basically i need to know the default paths for V5 and V6 to verify i can add the reference, i guess i will just put it into a try / except block…
After using the command for all 3 firefly gha files and the two goat gha files, i can call NodeInCode without error dialogs popping up. Only the loading messages are printed to the commandline and i notice the loading time.
_
c.
So sad, i really was pleased to see them and would have a lot of use for it. But i’ve found more bugs, eg. when using 
.
