Rendered Viewport - Mesh Models & Graphics Cards

unhandled

#1

Hi,

I’m an architect who’s been using Rhino for a long time as a design and render tool with the Maxwell render plugin. The plugin nature of maxwell render and ‘maxwell fire’ preview windows allows me to avoid adding an additional piece of software into my workflow such cinema 4d.

I generally work with a rendered viewport with ‘curves’ linework switched on which is kind of a mimic of the sketchup look which used to be pretty popular.

I keep the actual building model (NURBS) as a reasonable sized file that doesn’t cause many issues even with an average graphics card.
When it comes to rendering i have a library of Vizpark FBX mesh trees, plants cars etc which i add into the file in large quantity. Maxwell render also has a grass generator mesh but i don’t think this affects viewport peformance.

Basically i’m on the design side of the process rather than a renderer and don’t want to go down the path of 3ds max + forestpack/tiles generators/marvelous designer etc, but am aiming for a similar outcome using Rhino. I am always editing designs after ‘final’ renders have been created.

Is there a way to get Rhino to manage very large files in rendered mode, such as getting a high end p2000/ p4000 quadro card. I’ve read that GPU doesn’t really affect rendered display port performance but given the high poly models are mesh format is this a different situation?
By the sounds of it Rhino 6 in shaded mode performance will benefit from such a card although this is not ideal?

Thanks


(Przemysław Doliwa) #2

What is a very large file to you? Generally pushing a lot (i mean here really big ammounts of objects) isn’t good for openGL. Use blocks wherever you can also work in rendered mode isnt best idea. Wireframe without isocurves and bboxes should help somehow.


#3

I was thinking a 150mb nurbs building model and maybe 750mb-2gb in fbx meshes trees and vegetation in render mode.

I understand render mode is an issue but shaded mode isn’t that useful for what I’m after. Was hoping the mesh format may help.


(Przemysław Doliwa) #4

@laurence_clifford would you mind posting screenshot of this building? Vegetation for sure will be an issue here however v6 handles things good enough but you have to use blocks to have dense vegetation. Take a look here i viewed this on m4000m Edge softening shading bug?


#5

It was more a hypothetical. My building models are generally around 100mh and work fine.
I’ve always wondered why rhino can’t handle meshes as well as 3ds max and cinema 4d. Would be really helpful as not all aspects of the files need to be editable.

That rendered image looked pretty heavy. Was that rhino render or a plugin renderer?


(Przemysław Doliwa) #6

@laurence_clifford it is rhino viewport on rendered mode :wink:

V5 coudnt but V6 handles large meshes very well. I don’t know but maybe in max some things are pushed to DirectX instead of gl. Also have in mind that Rhino do its best for clean lineworks while non of sub-d modelers bothers with it.


(Tom) #7

Hello,

I have no idea if this helps you. Just for comparision, from time to time I do realtime virtual reality presentations, displaying full cars, using 2 p6000 displaying 6-14 million polygons with complicated open gl materials. I use autodesk vred with antialising and supersampling on, basically rendering two realtime 2 k images (for one eye each)

How does this help you? Well I bet you can display 1-3 million polygons with an „above-average“ graphics card for sure, even in Rhino. And we are talking about one or four tiny render views.The point is scene optimisation.

Well without comparing apple with oranges (vred is highly optimised for realtime rendering), I still believe you should think more about level of detail, light- and ao-prerendering (maya,blender etc can do this) and moving some vegetational elements like grass to photoshop. If you model accurate, most parts looking awesome without or with little raycasting.

Furthermore you can improve polycount and also improve Nurbsmodels. Imagine having a screw somewhere in your house. You wont see it, but it may produce tens of thousands of pointless polygons. So render models are not models for engineering. The reason why polygonmodels are still prefered in visualisation is the explicit control over polycount. Although I prefer using nurbs as well. However Rhino misses some functionality here.

Before using two p6000 we had two quadros, cost went up for a factor 3, performance around 1.3 only.
In conclusion I would rather spend money on professional books about visualisation or workshops instead of high end graphics, unless you have a lot of money leftover or you work for clients willing to pay for it.


(Przemysław Doliwa) #8

Well that depends mostly on software if you use something that will drain from GPU every possible % of its performance there are huge leaps between k/m/p architectures and also within range of 4k/5k/6k models i have k5000 and m4000m and m4km drasticly beats k5k even on short runs


#10

Thanks, Tom Tom. i agree with what you’re saying about the screw but don’t think it’s always practical.

An example would be having a few hundred mb worth of furniture in a house design.
When presenting the project it would be nice not to have to fiddle with layer visibility because the model is lagging as it would detract from the presentation.

I suppose i’m saying it would be good to have elements of the model as smarter Nurbs components and other mesh elements as ‘dumber’ elements purely for presentation value.
It seems that high end graphics cards could probably achieve this but the rhino rendered viewport is not currently taking advantage of them


(Nathan 'jesterKing' Letwory) #11

Before displaying all NURBS is converted to meshes. If the NURBS model is complex (curvy bits) then you may end up with quite dense meshes.

In v6 for presentations you should look into using SnapShots, where you set up your snaps for vantage points that are useful for your manuscript. With these you can ensure that necessary parts are not shown when unnecessary: the screws and much of the furniture when outdoors, the trees and other outdoor elements when indoors, and when indoors it will be possible to still hide elements that won’t be visible.

Once done with the drawing part it really makes sense to organize your model further such that even with a clear layer layout you can manage vast amounts.

If you have more than one copy of the same object consider using blocks, even for the trees, people, furniture and other scene layout elements. Rhino 6 does take advantage of modern OpenGL (it is not without reason that recommended minimum version is OpenGL 4.1, where in my experience for some GPUs it is even better if you have 4.5 or newer).

Further look into render mesh settings. Again, all your NURBS are converted to meshes before drawn onto your screen. As such it makes sense to check the settings to ensure the render mesh you end up with isn’t any more dense than it needs to be.

I’m not sure where you heard that, but GPU most certainly will have a huge performance impact on how the Rendered display mode works, at least in Rhino 6. Many display modes will benefit from good GPUs, not only Shaded.