More transformation/display molasses experiences

Scripting
1

So, now I have my file with all 160 objects in it, each composed of multiple parts (so that the parts can have different render colors/materials). There are over 8000 mesh objects in the file… Don’t know how many polys there are total, but the file is 260 Mb - all meshes.

Now, I just want to script rotate ONE of those objects around its axis as a test. In a file all by itself it can spin 360 degrees with 90 steps (4 deg. increments) in under 5 seconds.

In the file with the other objects, however, it takes… it takes… well, it will probably about 10 minutes, I didn’t wait. I reduced the steps to 16 (22.5 deg. increment “jumps”), it still takes over a minute.

OK, I reasoned, that’s maybe because it has to redraw the whole scene with all the objects at every step, even though nothing moved… Too bad, I wanted to see the others fixed in place while I rotate one, but OK, let’s try making the rest disappear before rotating (hidden or layers off, I tried both) and see if that helps.

Much to my disappointment, nothing changes…

So what’s going on here? Does it have to recalculate the whole scene including all the unseen objects every time it redraws? That would really be too bad. But I don’t have any other explanation. The memory usage is between 1-2 Gb, but there’s 16 in the machine, so it’s not that. And note I can tumble the view pretty much as fast as I can move the mouse and I don’t see any jerkyness - I was surprised at that - so it’s not the graphics card… During the script, the CPU is cranking to the max though (on 2/8 cores that is).

Oh well, I’ve been working on this thing in parts for several weeks now and it looks like that’s all it will ever be - just parts - can’t put them together into a whole, so basically the whole idea is out the window… Guess I was just completely overly optimistic as to how Rhino might handle this large an amount of geometric and graphic data… :confounded:

–Mitch

2

Hey Mitch,
This type of functionality is going to be a lot faster using conduit draw callbacks. I’m sorry, but I’m not at a spot at the moment to put together a sample for you. I’ll try to write something up soon since this has been requested before.
-Steve

3

Mitch, I haven’t written any code for at least 3 years now and as such not in a position to help.
But, while waiting for Steve to get a moment, (1) there’s been a lot of talk about conduits here in the past and a search might get you a bit further, or (2) could you use Grasshopper to do this since it does all that conduit stuff on the fly?
cheers,
w

4

Hi Wim,

Grasshopper won’t do it as I need to have materials applied and be in rendered mode… I’m creating a video here. Display conduits largely exceeds my meager competence in scripting/programming…

The thing is, I have a test file that I used to try to simulate this stuff that works fine - in that when the other objects are hidden or even just outside the viewport frame, the object I am rotating spins just fine - but unfortunately on my “real” file it doesn’t. And I really don’t know where the bottleneck is…

–Mitch

5

Hi Mitch,
You can assign a material to certain attributes, then bake your grasshopper geometry with that attributes. Do the batch render, delete the geometry, execute geometry transformation, and start all over again (bake, render…).

6

Do you think that would actually be faster than simply transforming the existing Rhino geometry in the file?

–Mitch

7

Probably. As you are only adding completed geometry to Rhino document, rendering, and deleting the same geometry. All other calculations are done in grasshopper.

8

OK, but what’s the difference between calculations done in Grasshopper (calling RhinoCommon behind the scenes) and a Python script (calling RhinoCommon behind the scenes)?

And the video isn’t being rendered frame by frame - it’s a simple screen capture in Rendered mode of a normal Rhino viewport. If it had to be done frame by frame in a batch render, there would be 32,000 individual frames to render. I can’t imagine how long that would take, but probably weeks…

–Mitch

9

This may be a question for Giulio or Steve, as I do not think I am competent enough.
Nevertheless those RhinoCommon methods you will be calling, are called upon and executed on actual geometry from grasshopper document. Grasshopper document is faster than Rhino one.

Each time you rotate an object for some amount, perform a render. If I understood you correctly, that’s what you were trying to do in Rhino too? Or not?
Rendered photos could easily be saved as animated .gif or .avi.

10

No, I just want to rotate the objects real-time in the Rhino window and capture the movement with video screen-capture software.

–Mitch

11

Have you seen this:

You can set the geometry color by using “Custom preview” component.

12

Interesting… have to look at that more closely…

Unfortunately, what are marching are not cubes, and they have render materials applied to them…

File is 260 Mb, here’s a quick preview…

–Mitch