… tell you the weight (in pixels) of a particular object while you’re actively working in the file that it lives in? Anotherwords, as you create it, or right afterwards. I have a feeling there isn’t, but – I wonder if someone has come up with a wonderful script for this?
Thank you.
Cosmas
How much does a pixel weigh?
Enough to slow down my file: (
it doesn’t work the same way in a 3D program as it would in a 2D image editor. the 3d model space doesn’t have a resolution per se.
for instance-- draw a line… it may be 25 pixels long… zoom in on line-- it’s now 1000 pixels long.
do you see what I’m getting at?
My bad. You’re right. @Mitch and @jeff_hammond I meant to say bytes. When you close the file, or save it the program calculates its “weight” in bytes.
Hi Cosmas- this will not help you now, but in V6 there is (Will be! ) testGetBigObjects. it reports in the size of the object.
-Pascal
Don’t know how accurate this would be but the file size in brackets beside the file name top left updates each time you save the file, so maybe you could; save - temporarily copy the object - save again - undo.
Does this just mean the amount of bytes it will take to store the object, or also how hard it is to shove down the display pipeline? I always wanted a getHeavies when things were getting chunky display wise.
Same here. It should be possible to script something meaningful by using the PolygonCount command on all objects and returning the heavies.
That’s a good question, Sam. What I’m looking for are the elements that slow down the program, and make it “stutter”, for example, when you move around the perspective viewport, or make moving from named view to named view super slow. I noticed (and the technical side of Rhino is not my forte) that this does not seem to have to do with the overall size of the file, but with the nature of some of the elements in it. For example, I have a model I built of a marina in Boston, with boats, trees and street furniture imported from the Google 3d warehouse, about 400mb – was slow. But when I built a pile of lobster traps (basically a 18"x18"x30" cage of pipes) repeated 30 times, it was virtually impossible to move through the model-- even though I used blocks. I had to put the “heavy” stuff on one layer and turn it off every time I wanted to move the camera (and switch to wireframe).
You asked “Does this just mean the amount of bytes it will take to store the object, or also how hard it is to shove down the display pipeline?” I think it is display we are talking about, right? What one sees in the viewports and how it slows down our ability to move the camera around.
Thank you.
To Brian and Pascal – that sounds good.
Hi Cosmas,
Actually blocks will keep the size of your file down, BUT… it slow the display quite a bit.
So blocks are good to setup repetitive shapes that you want to edit downstream.
However, if you are satisfied with the shape and you do not need to edit them anymore.
Explode the blocks and group the parts, even better is to convert them into a mesh and join those, but only if all you need is visuals. (note that Make2D does not handle meshes)
HTH
-Willem
Hi Cosmas- if you are using the animated view transitions between named views, you may want to look at the animation settings- these can be slow for reasons only to do with the two views involved and animation settings, not the model itself. For modeling I’d use ‘constant time’ (default I think, but architects may like to use ‘constant speed’, I think, as a sort of walk through style for presentations)
The testGetBigObjects thing I mentioned looks for size in bytes.
-Pascal
I’m trying to get my head around Willem’s advice “Actually blocks will keep the size of your file down, BUT … ll slow the display quite a bit.” This is interesting. I’ll have to check this out.
In the meantime, guys, I wonder if we could define what kind of geometry tends to slow down Rhino-- meaning our ability to move the camera around? Why is it that some big files are not slow and others – really slow. What is it that we should watch for? (In addition to blocks…) Is,there anything one can do when importing sketchup files to make them perform more efficiently?
Thank you.
One problem is in the transforms that need to be applied to blocks- keep in mind that the block definition for all the instances of a given block is ‘somewhere’, not where the instances are, typically. So the display of the instances has to take into account the transforms required to get a picture of the definition in the right place, size, orientation in space for each instance and get the shading right etc.
-Pascal
Interesting. So then, blocks slow it down a bit, and exploding the blocks makes the file bigger (of course) but allows you to move around more easily. Willem suggested that converting them in to mesh helps – is that because what you see in the viewport is render mesh and it doesn’t have to transform nurbs to render mesh to show it – since it’s already mesh?
Hi Cosmas- if you convert to meshes (Mesh command, and you can tune the settings to make the coarsest acceptable mesh for your display) and Join all meshes that are ‘the same thing’ (all objects that get the same material and mapping for example) into a single mesh, that should help in simply reducing the number of objects to keep track of, and reduce file size, potentially, by removing the repeated overhead of info required for each separate object. I would do this to a copy of the file perhaps, allowing you to delete the surfaces/polysurfaces that are meshed. The ‘transforms’ I mentioned above are the move/rotate/scale calculations needed, from the definition to each instance, to show the instance in the right location/orientation/size.
-Pascal