Need more Performance!

Rhino Rhino for Windows
1

Hello!

i am currently working on my Bachelor´s degree and damn, i need more Performance!!

I work a lot with PanelingTools. I already started to model “Low-Poly” and erase all unnecessary surfaces to gain more power. but by time working is like: Klick 1 Operation, wait 45 min. then klick 2. operation. That makes me get mad.

Have you any suggestions how i could increse the Performance of Rhino? How can i use on heavy detailed scenes with not getting crazy?

My System:
Intel i7 870 @ 2.93 Ghz ( 8cores )
16 Gig 1333 Mhz RAM
250 gig SSD
2x Radeon HD5700 in Crossfire
on Windows 7 X64 with Rhino5x64

what can i do to get more Power? Its driving me crazy!
I think the setup is ok, so is it normal that there is a limit or can i do anything about it to boost rhino?

2

Hi Fabio,

Can you tell me what commands you are using specifically when you have to wait. It would also be very useful to see the file and know the exact steps you take to show the slow down in performance. Please use http://www.rhino3d.com/upload to share this file with us if you can.

In general though just to give you something useful in the meantime… ‘Performance’ can come from many places in a computer and therefore slow performance can also come from many places. Some commands in Rhino can use all of your CPU cores but most cannot due to the way those features work within a computer. If we know the command that you wait with, I can run it by the developer of Paneling Tools @rajaa to see if that command can possibly use more cores (called multi-threading). Another area that can slow things down in computers is displaying lots of objects on the screen, so this may be graphics related. Try disabling accelerated hardware which uses features like anti-aliasing as a test in Options>Rhino Options>View>OpenGL. This won’t effect processing speed but if your waiting when rotating the view it may help. Your system specs look good to me though so you may also want to try processing the amount of data in portions if your project is very very large. Give us more details if you can and the file and I can try and help more.

1 Like
3

i am uploading the file… the 3DM itself is 650, already “cleaned up” originally it was 1.5 GB… i upload a zip with 255mb

i just tried to disable hardware acceleration, tried leaving it on and just turn off antialasling…

only a slight difference. i closed all viewports viewed only one, its still like 3 FPS when panning or rotating in wireframe mode.

if the operation itself takes time, thats ok. i used 3d panelling. created points in a grid on a surface, offsetted them and 3d-paneled my lowpoly modules in it. every element on a own layer so i can at least disable them and edit the different groups more confortable.

Its the viewing performance on large scenes that bothers me.

Would it help to buy some Quadro Card or FirePro? Would this help to get a smoother viewingperformance of big scenes in the preview?

For rendering i know, its just CPU, and i use multiple i7 via gigabit network, thats fine so far… But i want to get rid of the 3 FPS lagging Viewing performance. Getting first impressions or searching a camera view is really a pain!

i think its the previewperformance i want to increase, does a quadro or something like that help?

4

Hi Fabio,

I do not think your system is all that bad, and I wonder if adding more hardware power will solve the long waiting times.

Can you elaborate on the type of operations you do that will make you wait 45 minutes?
What it looks like from your images you have a very dense lettuce structure over a large surface. Is that the cause of the long waiting times? The rest of the geometry present seems to be not that complex.

What I’d suggest for a project like this, is to separate different parts of the design in separate files.
Use worksessions if you do not already :
http://docs.mcneel.com/rhino/5/help/en-us/commands/worksession.htm

For this project, I would at least separate out the canopy/roof structure. That makes it easy to work on the design of the floors and other functionalities with just a dummy surface present for the canopy/roof.

Note that the use of Blocks ( http://docs.mcneel.com/rhino/5/help/en-us/seealso/sak_blocksgroups.htm ) can reduce the filesize, and easy up the workflow very much.
Yet note that blocks are also known to cause a lag in display performance.

Another issue that still run into with complex projects is the desire to constantly see the design in all it’s detail. It’s tempting to always populate such roof structure with detailed geometry at every stage. Yet this has proven to me to cause too much of a distraction, as waiting times increase and my mind wanders of in all direction, but the one I was going to.

When focusing on global structure, use the simplest geometry possible ( be it single mesh faces, curves, points …) Use a global point of view to design the overall positioning and setup of the structure.

Use a local point of view and operate on just a small selection of the paneling points to setup various variations of more detailed structures.

Only occasionally create the complete structure in detail, and even then just for visualization and presentation and not as a working file. If needed save a copy and delete all structure higher up, keeping only the ones in close relation to the base structures.

Maybe I’m approaching you with advice that simplifies your needs and skills, if so don’t feel offended.

If you elaborate in more detail what specific issues you run into, the greater the chances someone over here can help in easing your workflow.

HTH
-Willem

1 Like
5

yeah, its _ptPanel3DCustom that takes so long, and i already devided the building in 3 segments. But building and modeling processes may take that long, thats no problem, but for example if you have to trim single parts later on, you need to show at least 1 module at one roof completely, and there already it lags a lot, of even when the pointcloud is displayed. ok its a lot of points, but cant the viewing performance be increased with on of those mega big GPU monster like a quadro or tesla or whatever? or does the hardware not influence it that much? so why does the viewer “lag” at all, if everything is modelled and ready? wich part of hardware is responsable for displaying-performance of the viewports?

what helped me a lot was eliminating useless surfaces ant points in the meshes. one element as a nurbs was i think 260 polys and with lowpoly and erasing some surfaces completely i managed to pull it down to 103 polys. that helped a lot.
Sure, for example when i worked on the interior i just blended in the simple surface.
But when generating floorplans etc. you still need to display all. and thats not very comfortable. hopefully worksessions and blocks help

i did not know about worksessions and blocks, ill give it a try!
maybe thats the better way to work on this large stuff…

i was just thinking if i can buy sume equipment to get some better experience, cause i quiet work a lot on rhino, mainly…

1 Like
6

Hi Fabio,

Thanks for sending the file into tech. There are two performance issues here which are unconnected… one of which I have a solution for now. The slow display speed is due to having so many separate mesh objects. If you run SelMesh and then Join, you’ll see a huge display speed improvement. This is a known problem for Rhino and one the developers hope to improve. The second performance issue is with how fast the paneling tools command works when deforming panel shapes. Whether or not multi-threading can help here is still yet to be determined but you may want to try not pulling the custom panels to the underlying surface unless you have to. This will speed the calculation.

7

Hi Fabio,

Multi-threading is something I plan to look into for future PT development and it should help calculation-intensive commands like ptPanel3DCustom. During design phase, it also help to create a 2D module and populate that to examine design variations. This is usually much faster. You can also test on a sub-grid to make sure it looks as expected. Populating the final 3D module should be the last step.

I see that you used a mesh module to populate on the grid and this is also faster than using a polysurface. Make sure that your module is joined before populating.

8

oh yeah :smiley: everyone is here, crazy :smiley: the dev´s of my favorite tools on one spot ^^
this model was “finished” but i will rebuild it from scratch anyway.
I need to do a version for 3D Print ^^…

Thanks BrianJ, i will test worksessions, blocks and if it comes to meshes i will join the meshes. lets see if this works for me, ill try out.

@rajaa: if i join the module before populating and then populate it wouldnt it all be 1 piece? means with this large area i could not blend out the layers of each component?
and about populating custom3d, i have the “feeling” that custom3d with distortion populates faster than 3d without distortion, or did i mess up something?
thats the building i was reconstructing: Frei Otto
Any suggestion how i can do it better? “lightwight” and calculateable as possible?
i dont know if pointcloud -> offset -> custom3d a complete module with all parts included is the best way?

9

Fabio,
Aside from all the good stuff mentioned above, here is some general info about video cards and Rhino if you haven’t seen it yet. A touch dated but still some useful info:
http://wiki.mcneel.com/rhino/rhino5videocards
your Radeon is considered a ‘gamer’ card, going to a ‘cad/engineering’ card like a quadro or firepro probably wouldn’t hurt.
oh, and this is a bit dated too but maybe still some relavant tidbits:
http://wiki.mcneel.com/rhino/atiinfo
found this too on the other forum:
http://v5.rhino3d.com/forum/topics/rhino-5-sr1-incompatible-with-ati-firepro-v5700-video-card?commentId=6377196%3AComment%3A121325

10

On the video card question, a fast card does not automatically translate into faster Rhino. It needs to support OpenGL 2 and Shader 1.2. Those are very modest specifications, make Rhino run well on very basic hardware.
Think of this like commuting to work.
You need a safe a reliable car, like maybe a Ford.
Replacing the Ford with a Ferrari won’t get you to work any faster.

11

(this is strictly concerning improving display performance. rotating, panning, etc.)
You mentioned using cross-fired Radeon HD 5700’s. I would suggest upgrading that to something like a single HD 7870. This is basically the cheapest of the higher performing “gamer” cards. I was working with a large detailed model a while back and cursing up a storm waiting for Rhino to haltingly rotate the view. In the middle of that project I upgraded from a much older card to the 7870 and it was like night and day for the display performance. Your mileage may vary. Good site for comparing price/performance across a wide range of GPU’s: PassMark Software - Video Card (GPU) Benchmarks - High End Video Cards I’m unconvinced that the pro cards (Quadro/Firepro) are worth the money.

12

Tests has shown, that you can’t not relay buy much more speed, if you are using NURBS and curves, only in pure mesh displays you get a speed increase. The display pipline + Rhino model organisation cause that CPU+GPU can’t be full used. For example for models where the display speed lags, the GPU of my GTX285 is used at 40% only (my CPU is a Dual Xeon with approx. 3.4GHz). Newer cards can be slower than old ones and you are able to waste a lot of money.

Here a short post where you find a good testmodel:

GTX285 20s
Quadro 4000 15s

13

The car analogy lacks the info about traffic… which translates to “a bottle neck”, and software can be such a bottle neck, limiting the max load and speed of the “car”. Some software are totally optimized for speed, but might lack the modelling tools, others have the modelling tools, but lack the top speed.

So on a road with a lot of traffic you will not benefit from a really fast car. But the truth is that all pro graphiccards are more like really fast trucks. They handle both speed, load and safety at the same time, but most pro software that can utilize these are not optimized to run on “normal” hardware.

There are many users who would gladly pay twice the price for Rhino if it could handle big scenes better, and hopefully some of this will be resolved for V6, as visual realtime evaluation of the files, at high fps and high resolution with smooth AA is a must for many of us.

1 Like
14

if i can have a wish for V6, big detail projects with better viewing performance.
Something like “Minecraft” build… and build…and build… to the infinite :wink:
Processing is ok, if it may take time, but viewing the already build must be functioning.

As for the graficsperformance discussion:
I always say that your Product is definitly influenced by the quality of you tool.
If you draw a floorplan with a blunt pencil and use a dirty ruler the result will look ugly.
If the performance of your PC lags at some time, you think twice to zoom in and refine your model.
Told in cars, if you drive it every day, for long distances. I personally would get the best car i can get. :smiley: its my desk and computer i must feel comfortable with when spending so much time in front of it.

so to the facts:
the cards need to support OpenGL version 2.0 and Shader version 1.2
my HD5700 supports openGL 3.2… soo… ?!
the requirements are quiet low, the risk is to pick some expensive card that does not support the old standards of openGL?

from what was spoken now i would look around to get some HD7870
(should support eyefinity, i use 3 displays )

any other cards you would suggest? and why? Should the core-speed be high as possible, or shoud the memory be big and fast? or smaller and fast?
Wich attribute of the card does influence the viewing performance, like turing view and stuff…?

Does not need to be a quadro, ok. but is there some benchmark or ranking for the best cards for rhino?

15

Read careful this test, important for a NURBS modeller is the little part:
“GPU1 (lines) scores for the four newer cards were virtually identical, giving a 12percent benefit over the older FX1750.”

http://www.simplyrhino.co.uk/rhinotraining/pny_quadro_test.html

The problem is, if your model is slow displayed, than there is no solution available, you can’t do anything than wait for future improvements.

Interesting is, if curves are not needed at the display, than a pure mesh mode could get the same look like the NURBS display (extract render mesh and hide all NURBS, only mesh edges needs to be turned on) and the speed is much higher. But nobody like to implement a mesh display mode based on the render mesh only.

Also at Rhino v4 there was a dynamic bounding box display feature that is broken at v5. I beg to get get it fixed, but it’s ignored. I have frame rates of 0.5…1s frame per second only!!! The dynamic redraw feature could give back some speed.

It looks like Rhino has no display development anymore, the state is freezed, bugs are not fixed, the power isn’t improved, GPU power isn’t used. If you know that than you will see that the official answers and graphic card recommendations from the McNeel side are diplomatic answers only. It looks like there is big problem behind. More and more user will run against this wall and I hope once a day the problem will solved.

1 Like
16

Hi Micha,

The bounding box dynamic display mode feature is working for me here. Can you send a file where it doesn’t and export your display mode ini file too? Let me know if I can help more and I’ll make sure this is a filed issue once I can reproduce it for our developers. If you ever think you’ve been ignored, please message me directly on this forum or email brian.james@mcneel.com We may have missed a post or an issue is known but just hasn’t been possible to fix or improve yet.

Display development is still ongoing for Rhino 6. There are lots of interconnected pieces to display performance in 3D modeling apps. GPU make/model, drivers, display mode settings, model size, geometry conditions specific to the file… etc. All of these factors can make display performance change from one user to another. Let us/me know specifics about what you have issues with and send files and screen shots please. Thanks for the feedback.

17

Can you point me towards a display engine in another 3D app that handles the size scene you’re dealing with at the speed and resolution you need? I’d like to see the display features used and how they differ from Rhino’s defaults. If you can also provide a model and the system specs that would be great too.

18

Don’t get me wrong Brian,
This is not a matter of comparing apples with apples, it’s about our need for Rhino oranges.
I prefer visual fidelity most of the time. Programs like Solid works don’t display true curves, they display faceted versions of them, and that is faster and ok a lot of the time, so that would be a great option for anybody working on large architectural or engineering projects.

I wish Rhino would become optimized to handle blocks as static, single objects, and also be able to handle copies of blocks faster. Now a nested block is slower to handle than exploded versions of the same.

Take a look at this simple file, it consists of “tree” blocks made up of instances of one single block consisting of a cylinder and a sphere. This file is “heavy” for rhino and is a pretty good example of what I mean.Trees.3dm (457.9 KB)

19

Does this file display well for you? The render mesh was very dense resulting in around 10 million polys which is where the slow down happened. Don’t get me wrong, I’d love it if Rhino could flip all 10 million of those little polygons around with ease on modern graphics cards but it is currently the case that custom meshes have to be used. I find Rhino is actually pretty good at large poly counts on most cards (I try to stay under 5 million polys). When it’s sluggish, it is often due to geometry issues, vast numbers of individual meshes or an exorbitantly dense render mesh on small parts. Maybe we’ll be able to make things faster going forward but I can’t say for sure myself. In the meantime… less polys is key. Did I change anything you needed in regards to the blocks in the file? Please let me know if I’m missing something that required the poly count you had.

Trees_reducedrendermesh.3dm (429.2 KB)

20

Hi Brian, this is what we are talking about, Rhino should do a lot of these things by it’s own, and this is the main reason why all games have LOD, and why I in V4 allways messed with the mesh settings. There is no reason to show multiple polygons per pixle, and your model does the testmaxspeed at 5 sec compared to 30 for the original file.

But you have to understand that most users do not fiddle with these kinds of settings, nor should they have to in 2013.

Here is an old link to “numenus” that unfortunately was bought up by Autodesk in 2011… so there are lot’s that can be done. And we need all the speed we can, right out of the box.

2 Likes