The Case for an Official NoDraw Material to Increase Graphic Performance

In Rhino V6, even if we can’t seem to apply custom mappings to different surfaces to a polysurface or an extrusion without first expoding it–we can apply different materials to their surfaces.

As we make things such as buildings, often there are surfaces which will never be seen. Drawing them is often pointless. Though, renderers may need to know that the object surface is still tangible and solid.

If a NoDraw materials is employed, it could increase realtime raytracing and raytracing by perhaps 10% on buildings. It also solves problems caused by Z-fighting in surfaces that come close to being co-planer, such as a radius, blends into a corner. It would also eliminate concern that by placing a 2mm vinyl floor over the floor that there would be rendering problems.

(It would not eliminate Decals, because likely use a stand-off and are likely put on on in a later pass.)

A NoDraw material could even increase preview performance. There could be a toggle to show or not show the surface marked with NoDraw. In use, the No-Draw material would be applied, lastly, and poof, that surface would become unseen, and not slow down the preview renderer. When it’s seen, the NoDraw material would be a simple 1-pass texture, with limited rendering requirements. It would need multi-pass environment maps, or reflections, or optionally even lighting effects.

Lastly, depending on the raytracer, it might be possible to save memory by eliminating meshed surfaces marked with a NoDraw materials all together.

There might even be an appropriate material type that can do this, but as a user, I have no idea which one would work in a beneficial way across all the renders. For instance, one of Rhino’s raytracers uses BSP’s, so it would have to be a material type that won’t interfere with all it has to do.

The user would select any surfaces that aren’t seen, and apply the NoDraw material. If you are showing house framing, you don’t need to see the bottom of the 2x4’s. Because of Rhino3D’s excellent snaps, you could resize the studs without even needing to toggle the NoDraw back on.

This is not new tech, it is 20 year old gaming tech, but to bring it to a CAD modeler, would be revolutionary. When I was doing level editing, I would have loved to have Rhino’s 3D tools.

[In games the standard no-draw material/shader it was simply called: “Caulk.”]

shot in the dark: you can create a display mode that shows no geometry, and assign in per-object for those with No Draw material. Would it do what you are after? I don’t know, but may be worth trying…

The idea is that not every part of your geometry needs to be seen for rendering, and at times.

so if i read you right, you simply want a ‘visible to camera’ toggle?
and if we are at it - ‘visible to reflection / refraction’ would be nice too
and global material override toggle. and so much more…

but i have not much hope - while rhino is a very good modeler, most of its rendering capabilities are underdeveloped and for a big part nonconforming with vfx-industry standards.

A visible to camera toggled material is a lesser part of it.

An invisible-to-raytracer flagged material/shader would speed up rendering, perhaps up to 10% in buildings, as well as solving issues that would cause rendering artifacts, such as rendering thin and near-coplaner objects because the surface below would not need to be rendered.

Any surface that does not need to be rendered could simply be assigned a NoDraw material, and it those surfaces would be excluded from being rendering. What you end up with is a polysurface or an extrusion, that’s solid on all surfaces, but certain surfaces are invisible.

If you wanted to spread some chairs and tables around an office, the legs of the chairs could be marked with the NoDraw material. For each chair there would be 4 surfaces that don’t need to be rendered, giving you 40 for 10 chairs.

The bottom of floortiles could be marked, and so could the top of the underlayment. The edges if window glass usually don’t need to rendered in a building. The casements of windows don’t need to be rendered.

…and the original polysurfaces and extrusions would be preserved–without exploding and deleting surfaces.

modern raytracers don’t much care about triangle count - if you throw 100.000 or 10 million at it is not really a factor. The acceleration structure builds a bit slower, but the rendering is the same speed. Factors are the paths the light has to take - the spatial situation. Shaders play a big role too, but saving 10% of surfaces, that is not changing anything.

Do you really believe that?

In another thread, I am conversing with someone at McNeel, who is recommending that I lift custom triangle meshes from my objects.

Also, this triangle also contain surface area.

Let me tell you, from my perspective,

If you are referring to me telling you to use ExtractRenderMesh then understand it is as an optimization for the conversion, especially where you merge those meshes into one object where you can.

If you have a huge amount of objects it takes a while for Raytraced to go through them all on the .NET side and prepare them for upload to the engine. Mesh data of course has also some impact, but by far not as much. Fewer objects with more mesh data is much more efficient to upload.

Also, extracting the render meshes and using those when doing rendering is because then the conversion step from non-mesh to mesh can be skipped. It is still the same data in the end what you get from your surfaces.

edit add: but indeed it makes sense to hide those surfaces you won’t see in the renderer, those objects that don’t contribute to the end result. That indeed will make things also go faster.

1 Like

If it is only for optimizing your rendering, then you could easily make a layer state for this. Just as much work or maybe less than assigning materials to it that don’t render.
Also instead of stating “maybe 10% faster” why not make a test where you compare the two?

There was a test, it’s called Quake 3, and another called Doom 3, in which a No-Draw shader called “Caulk” solved z-fighting from near co-planer surfaces, allowing NURBS arches to used. They cut down on overdraw, while still permitting the BSP process to work, without exploding objects into their constituent surfaces.

I have spent hundreds of hours testing this type of technique. I have at length examined files with 15,000 objects, searching any place I failed to apply this kind of shader/material.

I should think that if NoDraw surfaces are included, you would be under no requirement to use them.

No-Draw surfaces would likely allow faster rendering and view speeds, and would likely allow realtime raytracing to be used on larger projects, than can be used now*. They might also allow faster walkthroughs for building proposals.

No-Draw surfaces also might save a little bit of memory during the rendering process.

If a NoDraw material was implemented, the makers of 3rd-party renderers could decide for themselves what to do with a surfaces that doesn’t need to be rendered, that doesn’t need to have reflections, that doesn’t need a texturemap.

If a renderer, such as Rhino3D’s own? (non-cycles) render uses shadow maps, memory does not need to be used for keeping shadows and mappings for shadows on surfaces that don’t need to exist.

There is no sure way for a layer widget to know which surfaces you need to see, and which ones you don’t, so except for checking every surface against every other for a co-planar situation, or BSP’ing the whole kit and kaboodle, at every instant, and running viability calculations, the optimization would have to be done manually, by merely selecting a surface(s) and applying a no-draw material.

[*In my diner project, I am well beyond the point where the realtime raytracing can be used in a realtime fashion.]

As long as it fits in GPU RAM…that’s certainly true with these newfangled GPU-accelerated raytracers, within reason, it’s not so much the number of polygons as the complexity of the scene, materials, lighting. That’s my experience with iRay…heck that was I believe my experience with Neon in software mode, I’m like"Geez why is this getting kinda slow?..Oh, my model has ballooned to 30 million polygons, I was adding foliage and not paying attention." (And again, how much of that is sheer polygon count and how much of that is “complexity” of the scene?)

The speedup form optimization like ExtractRenderMesh and joining like materials together is mostly in copying the data over to the renderer, and I know that iRay and probably all plugins have this thing where they copy the whole damn model over instead of what’s on visible layers. What would the speedup even actually be to do it first except for models with a ton of hidden stuff? Either way at some point it has comb through every object. How does adding a “don’t render” material do anything to help this? It has nothing to do with it.

In Rhino’s OpenGL view, I am also finding that surface area/fillrate is an issue. I have a driveway and a backdrop that will make my system hang for half of a second when they fall into the view frustum.

In the case of your foliage, what you are working with is likely just simple planes, but in the case of a building frame there are sticks of wood with bottoms that do not need to be rendered.

[On large projects, I would rather not extract meshes because it negates some of the advantages of using NURBS, as well as complicating the build process.]

Using a No-Draw material would help because any object with a no-draw material does not need any Materials/Shader passes, and perhaps does not even need meshing, or perhaps the meshes could be more simple, as long as the edge verts are the same.

The “combing” check would exclude triangles from being filled with textures in the first place, in all visual passes. It would likely extinguish all lightrays that meet it, stopping a light ray dead in it’s tracks.

Also, using a No-Draw material eliminates problems with Z-fighting on thin things such as flooring, shingles, and things at a distance. While Z-buffers are quite large, they still have their limits. On that note, Rhino3D’s decals work very well, and I suspect that they use a Z-standoff and a later rendering pass. Good work!

GPU RAM is also an issue with large projects. Everything that goes into the GPU has to go across a bus. PCIExpress4 is not quite out, yet.

It’s not RTX, but my GTX 1080 is woefully incapable of rotating the scene I am working on. A RTX 2080 can do real-time raytracing at good framerates–only on a 20 year old, low polygon, architecture*. Additionally, the burdens of a real-time rayracer such Cycles to render Rhino geometry are much more demanding, because for the greater need for accuracy, and because a CAD-style models are generally not expected to be optimized for rending speed. Though, adding a No-Draw material with be a good step, just as custom rendering meshes are, adoptive degradation, and so forth. AFAIK, Rhino’s stock raytracer uses BSP’s but we aren’t expected to enclose our project. We aren’t expected to use only positive constructive geometry, and we aren’t expected to separate our objects for good splitters and details. It’s like a walk through the park, but sometimes, the speed would be nice.

As I stated, the NoDraw thing need only be used when you need a little more speed, and you don’t need every single polygon, every single surface drawn. The feature aside, is it too much to ask to ask the user to flag stuff they don’t need to see? The NURB extrusions and polysurfaces would still be intact when working with them.

When laying out an office, who really needs to see the bottoms of the filing cabinets? The bottoms of the chair feet? Yet, these suface need not be deleted, just flagged to be ignored by the renderer.