viewport and rendered result look great!
Will it work with V-Ray out of the box? Will they support this?
viewport and rendered result look great!
Will it work with V-Ray out of the box? Will they support this?
We’re talking already. However, this doesn’t change a thing that it would be better for everyone if communication would be done through RhinoAPI.
Hi @D-W,
User text, on either geometry, object attribute, or document, can be accessed from Rhino commands, RhinoScript, Python, .NET plug-in, C++ plug-in, and standalone openNURBS.
– Dale
I’m not entirely sure what it is you are referring to as this post just refers to us not doing something which is not specific. The only thing I can gather is that you need some technique for sharing data between your plugin and other other plugins. Dale just mentioned a few ways to share data. There is also the possibility to expose plug-in custom functionality through the GetPluginObject function.
Hi @dale, @stevebaer,
Strings on doc is only one that suits but don’t raise an event on change. If it is on C++ side sorry, other renderer dev didn’t found it so i thought it isn’t there.
Hmm, that’s interesting i thought someone would have to cast it to appropriate type so would need original source code, but i guess i’m missing sth here.
I wrote PM to talk about it further so we won’t bore people here about tech stuff.
Please don’t use PMs unless absolutely necessary to keep things private. This thread is already heading in the wrong direction due to vague reports of a simple thing that we refuse to do.
I’ll chat with Dale and Andy today so we can compare notes.
Steve, I think you got me wrong. The simplest approach to my problem is fairly simple to do, but i’m fully aware that a single plugin developer cannot have an impact on SDK structure otherwise it would be a big mess and my idea not necessary fits the SDK as a whole. Andy wanted to take it a step further and i’m thankful for his initiative but he told me he is unable to deliver it for v6 due to tight schedules what i also fully understand. I only informed interested people about it since i received a lot of questions when RN will be ready thats all. Besides as i said earlier most of my questions due to API are answered quickly and informatively. I don’t find anything wrong about it.
My concern with the PM approach is that this just continues to keep what this “simple thing” is that we refuse to add to the SDK vague to everyone here including myself and Dale. I see reports of “come on McNeel, why don’t you help?” when I don’t even understand what the issue is to begin with. I need to have a good understanding of exactly what the issue is that you are facing to be able to even begin to help.
I have a phone meeting with Andy in a couple hours and have already placed a comment to have him fill me in on the details to the agenda. Once I understand what has been tried and what the problems are we can then figure out if there really is something that can be done or if this simple thing is really not so simple after all.
I wasn’t intending to make any harsh comments with my last post and do appreciate your patience. I’m just trying to get all of the information out so we can make decisions.
Steve did i ever wrote that McNeel team refused to do sth here? No. If you would read carefuly i said that i had informative support and i believe that if there would be enough spare time in your schedules it would be solved.
If you want to go in public with this sure i need Dictionary<Guid,Transform[]>
like structure available only at runtime not bound deeper than doc on C++/C# ends to get at least naive and clunky way to give other renderers access to data which can be used by their internal instancing systems to allow rendering tons of objects with minimal memory footprint. Supplying that with OnChange event and simple listenable bool switch should allow get it quite right and keep resources fit.
From my knowledge, Andy tried to do much more complex things saving others headache and making good ground for further improvements and features and as i said really appreciate his goodwill.
Well, i hope we’ll find a way to not shuffle your schedules and put it there in reasonable form for both sides.
Cross plug-in communication has never been an easy thing in Rhino. We’re looking into some options for this
HI @D-W, @stevebaer:
I’ve put together a sample solution that demonstrates how to share application data between RhinoCommon plug-ins and Rhino C++ plug-ins. In this example, the data shared is a Dictionary<Guid,Transform[]>
type of structure.
You can find the sample source code here:
Note, when the owning plug-in modifies an object’s transformations, a serial number is incremented. A client plug-in can poll this serial number to determine whether or not the transformations have changed.
Hope this helps.
– Dale
Hi @dale,
Many thanks for your effort and for composing a full example of such dll. It is still “outside” API solution but i hope now it will suit renderers devs needs. We’ll see. Let’s keep our fingers crossed.
This time i have a question Anybody here using Maxwell for Rhino and wants to join beta? If interested drop me a PM.
Any news masta?
In general RN functionality is fully on place - it became a real “spaceship” with all bells and whistles - bridge still in dev, currently polishing library, presets and photo scanned models. Besides there are tons of things “around” for eg. legal stuff, docs etc. to do. Soon video teaser will be online
Anybody who would like to join the closed beta and don’t use VRay please send me a PM.
Does it or will it have grasshopper integration?
Umm no it doesn’t. Would you mind elaborate probable pros of making such workflow? I mean how do you imagine to use it in your workflow?
Thank you for replying. Umm to be honest i didn’t really think my question through and just thought that somehow maybe it could automate certain tasks such as shape boundary creation and selection to be used for geometry population One could maybe imagine creating many iterations of a surface and have RN automatically populate the updated surface. Maybe with grasshopper we can extend the RN’s rules to distribute geometry. I hope I am not confusing anyone.
(thinking loud)
certain aspects of the plugin could be managed by grasshopper. For example, instance distribution maps could be controlled by a logic controlled in grasshopper. In other sofware, this is usually controlled by shaders, but hey, here in rhino we have this very capable.
We also could (somehow) create custom parametrized/generative ecosystems of species, being the logic defined in GH instead of an ready-made logic hard coded in the plugin…