I wouldn’t do that.
I’d rather go for a Quadro K2000, it users less power, is silent and future proof for OpenGL 4.
The 285 is noisy, hot and might use too much power from your system, the Quadros are designed to be power efficient and run stable 24/7.
Hi Jarek,
The script sounds very interesting. I am going to download it and test
this weekend.
I will keep you updated
Ed
Agreed Holo, I’ve got the K2000 and I think it’s a great balance of cost, stability, and power for Rhino use.
Hi gregb
I know that in most cases, we are limited by budget. In our case, we are
limited by performance … budget is not an issue. We have tried a
series of high end video cards and have found that the $700 gaming card
is not the answer for improving viewport rotate speed. I am hoping that
Jeff can help by working with the file I sent … hopefully the
persistence of deleted linked objects can give a clue regarding some
addressing issues that might be slowing performance.
Thanks
Ed
Sure Ed, hope Jeff can find a problem - I wish the display were faster for large assemblies with lots of detail and blocks as well.
It’s possible the Quadro pro cards might be a better fit for your work than gaming cards, though. Here’s a link with some performance data in Rhino, getting a more expensive Quadro than the 2000 is pretty much throwing money away (at least until McNeel figures out how to better utilize high-end video cards, fingers crossed for V6): http://www.simplyrhino.co.uk/rhinotraining/pny_quadro_test.html
Right, I used a low noise fan for it and it solved the noise problem. But I think my current Quadro 6000 is using more power and the speed isn’t much better than the GTX285. Anything is relative. 
[quote=“nowforge”]
I know that in most cases, we are limited by budget. In our case, we are limited by performance … budget is not an issue. We have tried a series of high end video cards and have found that the $700 gaming card is not the answer for improving viewport rotate speed.[/quote]
No budget limit for hardware is a problem if you use Rhino and need more speed. I found no right solution on the hardware side too. I thought a modern Quadro CAD is the answer, but … I bought the Quadro 6000 because I got it for a good price and I was looking for more graphic memory too. But if speed was a problem for a model, than this card doesn’t solved it. The GPU usage is max approx. 15% only. Rhino is the bottle neck!
Hi Micha
I think we can all agree that Rhino seems to be the bottle neck at this
time … hopefully this issue has a solution. I will keep looking and
keep everyone updated.
Ed
Hi Ed,
I have received your file, but I’m a little confused on your instructions…but I think it’s probably a terminology issue.
“Load the Main file” … I did… I loaded “MainFile_Aug14,2014.3dm”
… I got linked-block missing file errors… Looking in the “Objects” subfolder, it seems there are some files there, but I’m missing 2 specifically… “_35_Inner.3dm” and “_35_Outer.3dm”. … So I’m not sure if you purposely left those out or not.
But even if I had those files, I’m still foggy on the remaining instructions…
“create a low res file by deleting linked “high mesh” objects”… What does that really mean? By “low res file” do you mean one that doesn’t take up much disk space? And what are the “linked high mesh objects”… Sorry, I guess I’m being daft on this one.
Since I can’t load the Main File in it’s entirety, I don’t think I’m able to get to the same situation you are. Is deleting the “linked high mesh objects” a necessary step for me to see the problem? If not, then don’t make it part of the reproduction process.
As for your last comment: “the deleted links still show up in the Tool bar” …
What toolbar? But regardless… Selecting objects in your viewport and deleting them is not the same thing as selecting “Blocks” and deleting them… A “Block” is a definition or description of a set or pieces of geometry. Blocks do not exist in Rhino’s object database, they exist inside the “Block Manager’s” database. When you “Insert” a link, reference, or instance of a block, you’re not really inserting the block, but rather a virtual representation of the block with a reference point and orientation. The objects themselves don’t really exist, that’s the whole point of them. So when you select one and hit the delete, you’re not deleting the Block, you’re only deleting the reference to the Block and thus, the Block definition(s) still exist. In order to delete any block, you must do so from within the Block Manager… So even if you run SelAll, hit Delete, and save the file… You will NOT have an empty file. Why? Because all of the Blocks are still defined within the Block Manager, and therefore they’ll get saved to file as well.
The only thing I seem to be able to do with the files you sent (without getting any errors), is to load the “NewFile_Aug14,2014.3dm” file… Once loaded I can easily manipulate the view and spin things around… I get about 20fps here with that file.
So I guess before I can go any further, I’m going to need to get those 2 missing files, and a bit more clarity on the instructions… Specifically on the part “deleting high mesh objects”… what are those, and how do I select them and delete them? Do you just want me to select everything and hit delete? Again, I apologize for not understanding.
Thanks,
-Jeff
Hi Jeff,
I obviously didn’t include all the files … sorry. I will add them
since they are typical of the objects that are causing problems. The
parts are #35 roller chain components that must be separately identified
as objects. In the event that a piece of equipment requires a roller
chain drive, I make a project of the required chain using the linked
components. I then save the project as a separate file (ie Chain_A).
*-> single layer nesting *At this point, we have a file (Chain_A) with
two linked object files -> single layer nesting. Chain_A can typically
be a 350KB file with millions of meshes (… the amount of meshes
needed to model a bicycle chain times 4 or 5, etc)
-> double layer nesting I then insert (Ctrl I) Chain_A into a new
project file (ChainPart_A … includes sprockets, arms etc)-> double
layer nesting. I find that ChainPart_A will render, rotate in a
viewport etc with reasonable speed but the viewport speed starts to
suffer ( … performance degrades) as other similarly nested files are
inserted. As a result, I will purposely keep the ChainPart_A file as
small as possible (minimize the number of linked files). To the shop
techs, ChainPart_A is a self-contained component with a part number that
they will use to build / modify a piece of equipment.
-> triple layer nesting. When designing equipment (NewEquip_A), I
insert ChainPart_A into the project as a component -> triple layer
nesting. As NewEquip_A grows (more linked objects are added), the
viewport rotation ceases to operate, BlockManager does not respond -
file sizes over 1.3GB are impossible to work with.
To overcome these problems ( … a “desparation” work around
solution), I will use BlockManager to turn off or delete the all the
high mesh-count objects in ChainPart_A -> double layer nesting. The
edited object renders correctly in the viewports and the deleted objects
disappear from the Layer ToolBar. When I Exit back to the main file, the
deleted objects reappear in the Layer ToolBar … and I don’t benefit
from a smaller file size.
In the file that I sent, you observe that NewFile rotates quite nicely
in the viewports … the workaround “works”. NewFile was developed
from MainFile by deleting the “/35/Inner.3dm” and “/35/Outer.3dm”.
linked objects using BlockManager.
Unfortunately, If one loads MainFile into a new master project, then
deletes the stated blocks (BlockEdit -> BlockManager -> Exit) from
MainFile, the deleted blocks still appear in the master project Layer
toolbar (they should be deleted).
I will send you a complete file for you to make this test.
Thanks for the help Jeff … much appreciated.
Ed
Hi Jeff,
I am resending the ObjectAddressing file to demonstrate the problems
that we are experiencing with nesting linked blocks. Insert MainFile
into a new project … this effectively creates multi-level object
nesting. Attempt to edit at the third level of nesting … the changes
do not reflect to the top level.
Does Rhino not allow nesting changes to cascade past one level? If so,
this will cause a problem in our work.
I look forward to your comments
Ed
Object Addressing.zip (13.1 MB)
Hi. In the past few years I have used many cards including a 8500gt, GTX460, GTX280-1GB, GTX660-2G , and now Quadro6000.
The GTX460 was actually no faster than the 8500gt.
GTX660-2G was marginally better than the GTX460, and although the display was not much faster, the anti-aliasing was better.
The GTX280 was great and actually pretty much on par with my Quadro6000 in performance.
The Quadro6000 is actually a GTX480 with better firmware and 6gb of ram, although most of it is never used.
This is all of course due to the much documented Nvidia GeForce firmware CAD crippling of all 300+ series Geforce cards, in order to sell more Quadro’s. The 200 series cards were so good at CAD that Nvidia had to do something to sell more quadro’s, so they disabled some crucial Opengl functions in geforce firmware which only CAD software uses. Ok. There is nothing we can do about that but good to know anyway.
So I see why you are using the gtx280. It works great… As suggested somewhere here it might be a good idea to look for a good 2nd hand GTX280 with 1Gig of ram instead of the 512mb card you are using, or try a GTX295-2Gig (Dual GTX275 on single card) - Same chipset , twice the power.
Single core CPU power is already mentioned above, and for Rhino core speed, not core number is what’s important. Michael VS
HI mvyess,
I have found similar results when testing the Nvidia GeForce cards - the
GTX200 series actually gives better performance than the GeForce 660
series (at about 20% of the cost).
I have sent Jeff a corrected file to test linked objects. I am having
issues when I get to third level nesting (changes do not cascade to the
first level), excessive addressing overhead etc. I am hoping that
solving this issue will lead to a lot better performance which will
speed up viewport rotation performance, BlockManager capacity when
reading very large files etc.
Thanks for you comments
Ed
Also note that the AMD FirePro V7900 slightly outperforms the Quardo 4000. So does the V5900 and those are not so expensive. BUT the drivers are not as good as nVidias and the AA is much worse, where nVidia is crisp and smoooooth the AMD AA is jaggy and flickery. It feels like the curves are shown on the screen at the wrong resolution. Now that should not matter too much for anybody who work on construction, but if smooth surfaces are your goal then smooth curves are so much better to look at. AMD does not cripple the Radeon performance either, but Radeon has even worse drivers (read: more likely to crash)
Hi Holo,
I thank you for your information … I sure appreciate the help re:
testing the video cards. I think that I will stay with Nvidia cards
until something changes in Rhino V6. I have been told that OpenGL4 will
be fully functional and the object addressing issue may be worked on.
I will ask Jeff if he can work through the example file I sent on the
weekend and review the problems that occur with third layer nesting. I
have a feeling the alogorithm Rhino uses to access linked files is
"weak" … I am hoping that the developers can come up with a
solution that persists all the linked items in RAM (no disk caching).
Tests with the large files > 1.4GB indicate that there seems to be a lot
of CPU overhead available and RAM usage is negligible compared to what
is available in the system.
I will keep you updated as I continue my research
Ed
I have 2 chains in a project. I’ve lowered the rendering mesh on mine pretty much, with a noticeable improvement. The rollers, and each plates are separate blocks. The plates are extrusions, and the roller, a polysurface, but perhaps 3 extrusions would be faster, but might cause rendering issues where there are coplanar surfaces. The sprockets I was not able to be as stingy with.
Notice: There are no holes in the chain plates. Let the raytracer deal with it : )
(Edit: I just took it down more! )
Hi Brenda,
Thanks for the advice. I will work to lower the rendering mesh and check
the results. What nesting level are you in when you lower the mesh …
the main file or the linked file?
Ed
This is exactly what I was going to try and suggest next… Unfortunately, I have not had the time to look… I will try to experiment with this tomorrow…
I’ll let you know what I find.
-J
Also, there is a single bolt you’re using for I think about 78 instances… Which might seem fine… However, the bolt file itself is meshed at around 24,000 polygons… Inserted 78 times yields about 1.8 million polygons to draw… I know they’re instances of the bolt, but Rhino still has to transform each one and draw the polys…
So if you don’t really need the level of detail you’re showing on the bolt(s), you can eliminate probably at least 1 million of those poly draws…maybe even more…Something to consider.
-J
Hi Jeff,
I have been trying to find these types of objects to eliminate them from
the main file. I find it makes a big difference. Unfortunately, I cannot
seem to delete them when I use BlockEdit at the third level of nesting
… is there a limitation on nesting?
Ed
Hi Jeff, would it be possible to add a LOD to the rendermeshes in V6? I think that would help a lot for objects like bolts etc. It would take longer to mesh ofcourse, but maybe that could be a background process once the initial mesh is calculated.