I Found a Way to Make the OpenGL Textured Viewports Faster

Currently, there’s no way to shut off the material effects, such as the environment or environment maps–even with “Advanced Texture Preview” off. Shutting off the environment would eliminate one rendering pass.

To work on multiple object projects, people who make larger drawings, buildings, and machines, need a display mode to see a material texture such as a diffuse map, with no effects other than having enough lighting so we can work on geometry, material, and mapping. Perhaps there can even be a toggle for texture filtering in the viewport settings for that particular mode.

Elsewhere, I am working on a diner project. Yes, it difficult to draw, with transparent and reflective materials, but I don’t need any of those effects to edit geometry, and apply texture mappings. When not in wireframe, my machine hangs constantly, sometimes whiting out, if I am not careful. For single objects like a vase, the viewport works fine, but once you try to make a building, any viewport that shows textures, slows to an agonizing, locky, crash-teetering crawl.

Currently, I use a variant of the Shaded mode, with no cast shadows (just vertex lighting?), and only 2 custom light sources, but with textures showing. For speed, all I want rendered while I am working is a single texture, and a light cue or two, so that I can work sustained over 12FPS with a GTX 1080 and a Quadcore, today’s drivers, and 16GB memory.

I know that viewport speed isn’t as sexy as Sub-D, or Grasshopper, but core program usability is still important.

I know nothing about Sub-D, but viewport speed is king where I live. I wanna commend Rhino Team on fantastic improvements in R6 in that regard. It allowed us work with larger pointclouds and larger architectural Revit models with comfortable 24+ fps.

I agree with giving credit where do. From what I hear Rhino3D is far more stable that Revit.

It was not purpose to undermine the moral of the rendering team, but the fact there is an extra unneeded rendering pass being used.

In another thread, I have been trying to do a bug report on the rendering, sharing what I feel is a challenging but appropriate file, as well as finding ways to make things faster, such as this thread, such as my suggestion that a No-Draw material be implemented.

I had read that pointclouds were being made faster. I wish I had been more vocal/literal about wanting viewport speed, then.

Do you think that more people use textured surfaces, extrusions, and polysufaces–or pointclouds?

Why specifically did you come to this thread to congratulate the rendering team on the pointcloud rendering?

Hi Brenda,

for me it sounds like something is wrong at your machine, since I’m working on quite complex scenes too and I’m quite happy with the speed too. Could you show a slow scene screenshot, so we could get an impression what kind of scene you mean.

Is the GPU driver up-to-date?

Do you mean you use 16GB RAM only? If yes, than this could be a problem for complex scenes. Most of the time I have an usage above 16GB RAM usage here. What says the taskmanger about the RAM usage if the scene is slow?

Thank you for the suggestions.

I am using yesterday’s video diver. There is still more than 7 GB out of 16 GB RAM remaining as watched with Window System Monitor, including in the video card, which was checked with GPUz. I am using a lot of blocks.

I am recreating a 1940s art-deco diner. it’s a visual-thing, so I am using some large textures, and that could part of the speed issue. The rendering hopefully will be a background for a book cover. Superimposed in front of the diner will be real-life model people, so my very, very best photo-realism is still only going to look, at best, dreamy once you can see what’s, or really, who is real, against what I have made.

Though, those textures are still small compared to what the video card can handle, but when I use Cycles, memory is an issue because the video card also likely has to hold the render buffer, so things don’t have to keep hopping over the PCIe bus. Still, checked with GPUz, I am not out of the GTX 1080s 8GB of video-card memory–even at 4k, likely even at 8k.

Even though this computer doesn’t have ECC RAM, and it’s a little fussy about power, it runs pretty reliably, for an old Sandybridge, which is 70% per core as fast as the fastest modern processor. More cores would help during rendering, and perhaps even Cycles use, but when I am rotating the scene, it’s likely up to the video card, and just a few cores.

I suspect that complexity is a matter of perspective. Someone from McNeel also reports the going isn’t too fast on the project that I am working on. I’ve done several layers of optimizations for rendering speed. Almost everything has a hand-tweaked custom mesh, adjusted given to the objects viability rendering, though I don’t want to detach the meshes because that causes an exponential organizational problem.

(Cycles has been putting out some surprisingly good rendering quality, during screen capture. I’ll likely post one today.)

I also designed a machine with the complexity of lawn tractor for a series of patent drawings, in which I wanted more performance, as well. The machine had thousands of parts, almost every one blocked.

I am sure that a lot of people are happy with the Rhino viewport speed, but when there are thousands parts, triangle count becomes an issue. When making large objects, fill rate becomes an issue. When you need to use bump-maps, texture passes becomes an issue. When you need to fool the eye, or when you need a large render, then texture size becomes a problem. On what I am working on, a cropped rendering needs to look good poster-sized.

There are things that can be done to make the viewport faster, such as mentioned in the OP. Rhino 3D is a big program. I think of it as a system. There must be millions of lines of code. Everyone wants and expects everything from it, and that places demands on the people who make it. There is a saying that sometimes the obvious eludes the genus. And if, I as a user, notice something little that might have been missed, then I’ll try to do my little community member value-added thing.

With that stated, I’ve been cranky lately about the viewport speed, and well, a bug or two, and I complain, but I am not going to just complain, I am going to do what I did, and also try to work through things, and help out. McNeel might not always like the nature of my help, and I am not always the most diplomatic person in the world…especially when I only get to make one material change a given minute, but I try to trudge onward. And when I make a suggestion to that proposes to fix a problem I have, people here oppose me.

I went through over 120 hours of Grasshopper tutorials, and I did perhaps another 40 hours of experience, and could only find a few shortcomings in what must be a work to be very proud of. Yet I did find a few things. I think they were: a line-cutter, a spiral command, and a line-midpoint, with the last one being for legibility. 160 hours to notice only those changes, but when I did mention them, people voice there opinion, as it is their place to here on a forum…repeatably against something, in one case that other people wanted too. It’s interesting.

[I have been using Rhino3D for some 12 years. I’ve made more than 83 projects. Most of them are small; others are not. In that time, I wanted and asked for: texturing per face, a better block manager, the Dragline centerpoint tool that Pascal scripted for me that’s so useful, I use every day, a callout labeling function, node/vextex edting on a polysurface NURBs object like Radiant could do, a cordon exclusion viability function like Worldcraft/Radiant could do, and a way of selecting/excluding objects by type, and one more thing, I mentioned but haven’t had the time to write up. But that’s not a lot missing 12 years, or 1.5 average marriages.

Unless you have used Maya, StudioMax, 3 computer game level editors, a few old versions of Autocad, DesignCAD, FormZ, Vectorworks, and a few other open source and shareware triangle modelers, you likely have no idea how good and what could be done with Rhino’s toolset.]

I think that with Rhino’s tools, people could make more complex and large objects than the average user makes, but I found not only a bottle neck, but a way to make it better, so I go on the forum and make a post. I am reminded was Ani Defranco who said, “Wherever you stand someone will stand against you.” Having an inquisitive nature, sometimes, I wonder why they do.

If you find the videoports plenty fast enough, then why did you read this thread? : )
Were you worried that the viewports might become too fast?

No problem for me that you ask for a solution for a problem. I try to understand it and find a possible issues. It’s like a riddle. :wink:

You wrote you use a lot of blocks. This could be the problem here. So far I have seen Rhino has a problem with to much blocks. Last I got a scene from a client with hundred of very simple blocks and the scene was slow. I exploded the blocks and use the objects without instancing and the speed was no problem anymore.

Maybe also useful could be to use mesh objects instead NURBS objects. For example if I have a train full of complex seats it helps me to create optimized low poly meshes at the seat blocks instead the original NURBS data. It was very useful at Rhino 5 and I’m still using this workflow at Rhino6.

An other trick which helps some times is to join meshes with the same material. For example I have complex electrical parts on the top of a train, but all objects needs to be black only. I created a low poly mesh and joined the objects. Now, Rhino hast to handle one object only instead a few hundred.

If a lot of blocks are used the CPU speed could be important too. So, if someone want to buy a new computer for Rhino use, it’s recommended to buy a computer with a high speed per core and not so much to use a CPU with a lot of cores. So, better 6 cores at 4GHz than 12 cores at 2GHz.

Thanks for offering help. : )

Even though the block manager needs a little love, as a system of replicating objects, it’s a sound idea that saves memory and duplicated effort. I have read elsewhere that the block manager might slow things, but oddly, that’s not the axe I’m grinding today.

I also think that making a custom mesh associated with objects, or blocked objects also makes sense, and it’s not that inconvenient, but once the two are separated it becomes a versioning-situation.

[Oddly enough, I think I remember reading that the old ID3 engine created 4 copies of their map objects on compile/export, based from their NURBs, and switched them in and out given the distance. From the mapmakers perspective, it just looked like triangles dropped out.]

I am fancying the the new AMD 3800x, or 3900x with a 12 cores, and a base clock of 3.8GHz, with turbo up to 4.6GHz, but for a lot of single core chores, that’s only going to be about 30-35% faster than what I have for some single core operations, according to Cinebench figures, and guesstimating how much performance gain they had over Zen+ from their marketing claims.

[Oddly, I’ve been watching Cycles, and even though I am rendering images on the GPU, it’s still a bit processor bound on my system, sometimes having short spikes to 100 percent, on more than one core at once. I’ve found that I had to turn up the Monitor Update speed to see them. My GPU is also on adoptive power scheme, and there’s a latency penalty to pay for that power and cooling savings. Though, I think that on adoptive, the GPU may sometimes cool a bit more allowing for longer bursts–even if the burst has a bit of latency from the start-line]

Anyway, I found a way to make the viewport faster. The change shouldn’t be that difficult, and there could be a Display Mode checkbox for Single Pass Material for Large Projects, in which the OpenGL renderer would not add things on like enviroment maps. Perhaps it could also use a custom lighting which only has 2 lights.

This also might help you with large things: I made a copy of Shaded View, Called it Shaded Color. Then I edited, it, switched on the rendering material, shut off, the 3rd light, and of course made sure there were no shadows showing, no Advanced Material/Texture Preview. It’s faster than Rendered mode, and it could be faster yet.

The drawing-wide environment maps in V6 can be toggled on/off. While the mapping is pretty cheap for environments, the environments can get large.

This is rending of the diner I am working on. Rending wise: it must be difficult, but the OpenGL needn’t be that fancy. I think that almost every mesh is custom, and individualized.

This is part of the machine structure I was working, empty of the parts that are usually showing. When it’s filled, it’s more of a triangle count thing.

1 Like

This shouldn’t be an issue anymore for V6. The rest of the optimizations that you point out should still be valid.

1 Like

@Brenda that is a nice diner, to me it looks like streamline rather than art deco, but i am not so well with american forms of art deco still i admire it major impact on industrial design. did you anyhow acquire construction plans from it? i would love to see some.

1 Like

Thank you Eencephalon. The diner was made mostly from 3 pics. There was once 2000 of these; 20 remain. In this pic, the diner looks like art-deco throwing up art-deco. One of the aspects are the fanfold metal, which is similar that that on the Golden Gate Bridge. I think that the castlations are hiding the air-conditioning in the roof. I wish I designed it. Most of the rest is from the same company, and the diner name is called the Olympia Diner, found in Connecticut, USA.


1 Like

Also, you’ll want to turn off skylight for rendered mode.


Thank you Pascal. Though, I tend not to use it because I like a soft penumbra. Well, that and I usually do indoor stuff…um…like… the diner?