Hi all.
As title…
Given a document object, we can have its control points move, rotate, etc while we are still dragging the gumball.
We get an interactive preview of the resulting shape…
even without losing the current preview of some analysis tool active on it, some material, shading, etc!
How to replicate the same behavior?
If you’re drawing something custom in a display conduit or by manually registering an event listener to Rhino’s display pipeline, you can check if a Rhino object is being drawn dynamically (the interactive preview you see when dragging the gumball or using the Copy command) during a given frame using the HasDynamicTransform and GetDynamicTransform methods of the rhino object. You can then apply the same transformation to whatever overlay you’re drawing and it will move with the object.
As I’m making a new type of gumball, what I’m trying to do is the opposite of what you described:
i created a clickable/draggable overlay on screen (the gumball), and now I want to dynamically move/transform the actual rhino object (a control point) with the information created by my gumball.
I would need something like a “SetDynamicTransform” …
@Joshua_Kennedy - can you help here?
Hi again… @dale , @Joshua_Kennedy
I’m trying this:
private void RunScript(Guid id, double Z)
{
obj = this.RhinoDocument.Objects.FindId(id);
Rhino.Geometry.SubD s = (Rhino.Geometry.SubD) obj.Geometry;
if(s.Vertices.First.ControlNetPoint.Z != Z){
s.Vertices.First.ControlNetPoint = new Rhino.Geometry.Point3d(0, 0, Z);
this.GrasshopperDocument.ScheduleSolution(10, ScheduledMethod);
}
}
// <Custom additional code>
public Rhino.DocObjects.RhinoObject obj;
public void ScheduledMethod(GH_Document gh){
obj.CommitChanges();
}
And it sort of works… but:
1 - I have yet to search about how to implement Undo/Redo …
2 - it creeps the memory!
ram usage go up and never go back…
memory bug.gh (13.3 KB)
(Using gh as a dev platform, final project want to be a Rhino feature. This does not want to be related to Grasshopper…)
I hope I’m just using the wrong method… I couldn’t find anything better from c#.
Please, help!
Thanks in advance.
Those previews are handled in the object grips. Outside creating your own grips there’s no way to make a preview as far as I know.
This exists in the C++ SDK but needs wrapped up to C#. I’m not sure why that wasn’t done. Just to be clear this will affect the drawing of an entire object and not the changes made by moving an individual grip.
Ok. I can work with those.
But it still eat tons of memory.
memory bug 2.gh (13.1 KB)
private void RunScript(double Z)
{
foreach(Rhino.DocObjects.RhinoObject obj in RhinoDocument.Objects.GetSelectedObjects(false, true)){
Rhino.DocObjects.GripObject grip = (Rhino.DocObjects.GripObject) obj;
grip.Move(new Rhino.Geometry.Point3d(0, 0, Z));
Rhino.DocObjects.RhinoObject owner = RhinoDocument.Objects.FindId(grip.OwnerId);
RhinoDocument.Objects.GripUpdate(owner, true);
}
}
If I manually drag a grip once, the memory is flushed… but this won’t happen since I plan to make lots of edits through my code.
With a simple SubD object it can fill many GB in seconds.
I tried with a 100x100 (UV divisions) SubD cylinder and Rhino instantly crashed.
There is a rhinocommon/c# method to “flush memory” (or whatever in that direction) for a object?
Clarification: my custom gumball is a straight new custom class from scratch. I’m not overloading or anything similar. Just a class that draw 2D elements on screen after mouse movements/clicks…
I’m using Rhinocommon grip objects, and I would expect them to work… “normally”?
What do you mean?
Using Rhinocommon grip objects with curves, surfaces, meshes works fine.
grip.Move() and then RhinoDocument.Objects.GripUpdate() do the task as expected, no memory problems.
The problem is there only for SubDs…
Here you can see how dragging my custom gumball make the ram usage go up.
Dragging the grip once with the normal gumball “fix” the memory bug…
No.
I’m using my own custom gumball-like class. But let’s forget about “gumball” concept…
I’m moving grips.
I’m simply using Rhino.DocObjects.GripObject.Move() method and then RhinoDocument.Objects.GripUpdate() method.
With curve, surfaces and meshes it have no problem.
With SubD objects it gradually use more and more memory (RAM).
(the more faces the subd have, the faster the memory filling usage)
See attachment for quick test:
Doesn’t GripObject.Move() method exist for this case?
Am I using it wrong?
What else could or should I use to dynamically move grips? (to have a realtime feedback, like with move/rotate/etc)
Is this something doable from c#/rhinocommon?
Hi @maje90,
Have a look-see and let me know if you have any questions.
test_move_grips.py (2.4 KB)
– Dale
Ok, the method .AddTransformObjects() alone doesn’t have the memory problem.
Do I have to push all my UI dynamic updates inside the CalculateTransform() override?
Anyway, that python script , too, increase the memory usage endlessly, if launched repeatedly.
Memory is “flushed” only after a manual transform in Rhino…
…