What is your biggest development barrier?

What do you think is your biggest barrier to being a successful Rhino plug-in developer?

Just curious…

Thanks,

– Dale

1 Like

Really? Nobody has any barriers to being a successful Rhino plug-in developer?

Time :smile:

2 Likes

There are many.
I agree with Time.
Pocket book is the overall most important consideration when beginning a new project.
Most forums are incredibly un-organized.
It is a slow process with a lot of overlap compounded by the lack of quick communication.
We here suffer a lack of team.
This is my first day here.
Forgive me if I have not discovered previous points I mention.

The biggest barrier for ExactFlat is probably synchronization of internal data structures with the Rhino document. There are so many ways a user can edit a mesh and produce a result in which the Rhino document mesh is out of sync with the internal structures. We’ve pretty much resorted to simply obliterating the existing mesh and replacing it with the ExactFlat mesh for each redraw. We try to train our users to do all their flattening work first, then export the mesh back to the Rhino editing environment. It’s not perfect, but it works.

Also, while in the ExactFlat flattening environment, we have our 2D pattern mesh, but we also maintain a 3D reference mesh. These two meshes should always be topologically equivalent (same number of vertices, edges, faces, etc…). I currently lock the 3D mesh since editing this mesh doesn’t make much sense. However, it’s very easy for a user to unlock it and edit the mesh. Again, we simply replace the mesh every time we redraw.

This replacement technique can prove to be frustrating because a users actions or desires are simply destroyed as a result.

I’d love to have the ability to blacklist, or even whitelist certain commands to prevent unintentional editing of the meshes while in the flattening environment.

-Luke

I completely missed this post half a year ago.

The biggest barrier to being successful, I think, is disorganised documentation. It is scattered all over the place (wiki, Github, Discourse, RhinoCommon, C++, Python). I have pointed this out before, but not much has changed. I would love to see a comprehensive developer manual that is easy enough to get started as a fresh developer of Rhino, but has sufficient depth to cover advanced topics (display conduits, custom objects, custom views, render plug-ins to name a few). I have considered authoring such a guide but I really have no time, nor sufficient understanding of advanced topics.

5 Likes

Well, the absence of something cannot be a barrier - right? However, what helps me most are small examples which demonstrate how to use the complex stuff correctly. So a big thanks at this point for all the example code you guys at RMA (and some others like Menno) have provided so far! These are the best resources - not just about advanced SDK stuff, also about good programming style in general - for me at least :wink:

But I have to agree with Menno that these examples are a bit scattered. A beginner will have problems to find the best resources.

Maybe some kind of overview about the structure of the SDKs and how things are organized in general might be very helpful.

Hi Dale
I agree with what he says Jess
Ciao Vittorio

I think rhinopython 101 it’s a good and big help in starting do development, but there’s anything similar for the most powerful. NET.
This could be a starting point.

Incomplete Python implementation. It seems like Python implementation has been abandoned. If we have to wait for V6 for something as basic as GetDistance or MultiListBox, then that’s going to be a long wait and I consider Python for V5 as being an abandoned project. The are ListBox methods that don’t retain their last positions (although PropertyListBox is the exception for some reason), a compiler that corrupts scripts and general lack of attention on any of these topics from RMA. While I would grade RMA an A+ on Rhinoscript implementation the best I would give them is a C for Python.

Dan

1 Like

I think we are all in agreement here. We (here) have some ideas on how we’d like to (try to) resolve this. Someday…

Our concern here is the information would be outdated before it was finished. Perhaps instead of a monolithic document, perhaps something granular and maintainable…

1 Like

I believe the incompleteness you are referring to is the rhinoscryptsyntax portion, correct? This is written in Python. Our hope was that by providing the source, it would be easy for scripters to fill in the blanks. But as you and others find holes, we are filling them…

Hi Dale,

Yes, the RhinoScript syntax for Python.

You have to remember that “filling in the blanks” doesn’t come easy for some (like me). I don’t have a programming background, I’m a Tool & Die maker. I would surmise that some others who create Python scripts are in the same position as I am, in that none of this comes easy. For example, I would have no clue as to how to create a MultiListBox method on my own, but if it’s implemented by you folks, I can certainly figure out how to use it.

Thanks,

Dan

2 Likes

Here is my two cents:

Python:
Code completion/intellisense . For single document scripts it isn’t that big of a deal, but when projects start to have several documents and imports, and I try to build on old code, the quick reminder saves a lot of mistakes and looking up of things. I tried once to do a trick with VS express with python tools to get better intellisense by importing the rhinocommon dll and other things, then just running the script in rhino. It almost worked, except, I think, for script context things. I still think it might work if I knew more about what to import but I eventually had to move on.

Also there is the compiling problem for commercial viability. I know there is a compiler out there but am not too sure it works 100% based on what I have read.

C#:
Maybe I am just doing it wrong as I am new to the language and process, but iteration. Especially if you are used to using the python editor. Change->Compile->wait for rhino to load->load plugin->run is not very quick. I know there are probably debugging tools in VS I’m not utilizing, so maybe this isn’t a big deal for real coders.

Thanks,

Nathan

It would be really nice if you could just write over the .rhp or any .dll that’s being used by an open Rhino instance, then reload those on the fly. But DLLs and RHPs are locked when Rhino is running, hence the need for restart of Rhino.

There are indeed debugging tools, and they are worth your time to learn. That said, my main debugging tool is RhinoApp.WriteLine(), RhinoCycles is boasting a good amount of those currently :smile:

/Nathan

Not exactly true; many people are having success with edit and continue in the latest version of Visual Studio when they are writing pure .NET plug-ins.

1 Like

You are writing a render exporter in c#?

Wish I was one of them. I’m working with VB.net and so far the only way I’ve found is to shutdown Rhino, compile, restart Rhino and reload plugin.

I’m writing a render plugin in C#. Not so much an exporter, but more integrating tightly.

It can already render into a Render Window. I’m currently making an effort now to integrate further to have eventually real-time rendering in the viewport.

/Nathan

Probably with pure .NET plug-ins possible. But I rather meant that it’d be nice if it were possible to have Rhino itself reload plugins without having to restart Rhino. This means one would have to be able to overwrite any RHP and DLL that’s loaded already by Rhino.