No-Draw Material, Please

Rendering
1

Please add support for a no-draw material. The application of a no-draw material would keep that face from being seen, rendered, or mapping created for it.

The benefits will be:

  • Faster Cycles real-time view-port panning and movement for showing your work to clients.
  • Faster rendering on projects with many parts.
  • Faster rendering on projects with larger textures in their materials.
  • Faster texture baking before rendering.
  • Faster animations with Bongo.
  • Likely lower GPU and CPU memory usage.
  • With care, it could offer a bit relief for owners: of lower-powered systems, who have big aspirations.
  • Stepping toward virtual-reality building walk-throughs, where rendering speed will be vitally important.
  • (Speculative/future, but having a no-draw material applied to a face might terminate/extinguish a path-traced sample more efficiently other means.)

In usage, the no-draw material is applied to any face which needs not to be seen or presently edited by using a single-face selection, and applying it like a regular material: Shift-Click, and apply the material, making the face is as good as deleted, as far as rendering goes, but the object is intact.

If you were making a building: the no-draw material could be applied manually, to objects in Blocks, or applied with Grasshopper, using the material input on the Custom Preview to:

  • The butted or mitered ends of door and window frames.
  • The edges of glass sheets, so that there is never a coplaner rendering issue.
  • The backs of: panels, trim, and ornamentation, and wall sconces.
  • The bottoms of columns, furniture, tables, chairs, and cubicals, and throw rugs.
  • The backs of backs of cabinets, and wall art.

For the material preview, a checkerboard appearance is traditional in Photoshop and game editors. On request, I could make one, as anyone else could.

In the following example, indeed, there several of the material textures are 2048’s, but there’s not a lot of geometry here, compared to a skyscraper, or an airport, a gas-station, or stadium. I can make the file is available to McNeel, as long as it stays there.

1035×582 151 KB

Below, there are more than 1700 surfaces that don’t need to be rendered. On a 4k screen on a 3900x/gtx1080, the response in real-time Cycles is about 5 frames a second for the overdraw, alone. In many mitered things, there are not one extra surface, but two.

image
image1920×1080 216 KB

Thank you for the consideration.

2

The thing is, renderers like Cycles are very ‘brute force realistic’ in how they work, and as such they actually seem to struggle with non-realistic effects–I use iRay, that has very very few ‘utility’ materials you might use to help with compositing–it’s something that has to be added on, and doing so to try to speed things up may not actually work. It’s not like obsolete Brazil were you could turn on or off every channel of every part of the process for every object and material and whatever, it’s not the intent, the intent is if you want to add more speed just add more CUDA cores.

Nah, the future of rendering seems to be to make a crude quick render and pass it along with some instructions to an AI ‘upscaler’ creates all the detail out of the ether. Also, according to UE5 it’s being able to force-feed the system all the polygons you want and it automatically does all this optimization for visibility and LOD.

3

A no-draw texture isn’t an effect, as much as it is the total elimination or drastic reduction of the triangles/quads that make up the rendering mesh itself, as well as the time it takes to fill/render/light/trace them in. If a No-Draw material was well-implemented, it would be like taking out 1700 surfaces from the view, what needs to be filled or traced and the triangles and quads they rode in on.

Even a $1800 RTX 3080 would not give me snappy performance using Cycles for realtime rendering like when adjust lights and textures on the project above, which has large textures. Still, someone is welcome to send me just such a video card, I guess I could experiment with it : )

Not all renders scenes may fit on the video card’s memory. Sometimes CPU rendering is needed, also.

(Please forgive this OT: There are a lot of pre-optimization done in video games, which is done for the sake of rendering (even a little bit in Guild Wars 2), such as face removal/extraction, which is fine if you don’t need to change things like you do in CAD, or in the case of ID family renderers, they used Caulk.

There likely a lot of preprocessing done to get a scene ready for even the latest and greatest Unreal Engine. There’s never been enough hardware to overcome inefficient design. With rendering it’s always been a cat and mouse, because the resolution is always going up. With realtime raytracing it’s not easy to maintain framerates even though the light is sampled so much lower, with much more filtering than cycles uses.

As an ex-professional level designer, I enjoyed finding the backside of Dying Light and Guild Wars 2, where you may notice see a lot of missing faces.

GW2 03532
GW2 035321920×1200 237 KB

screen_0116_145151
screen_0116_1451511920×1080 261 KB

That stated, unlike a game engine, a modeling/CAD program cannot take as long to pre-process its geometry between each step, each trim, each new object as a video game can, which could take an entire day to optimize–with a result of geometry which would be unsuitable for editing, making changes.

4

Not a total solution to your problem, but, have you tried using the _SelVisible command? When working with a heavy scenes, I will often use this to strip away unneeded geometry for a given view.

2 Likes
5

I just did a little experiment on iray. I took a current project(about 1.2M polys, 5000 exploded surfaces) and stuck it in a giant box. Time to render some set number of passes: 57s. I deleted the ‘invisible’ geometry from the model and rendered again: 58s. Brought the model back, opened up the box so that the model isn’t visible to the camera but still ‘open’ to the environment lighting: 60s. Time to render the original model was 1:18, whether it was joined up into 100 objects or exploded to 5000–which is definitely not how things work for the OpenGl display! Iray’s really pretty good guys, more of you should be trying it out.

While I’m sure every bit helps when you’re pushing the limits, it would seem that if no rays touch something, it’s not rendered, and doesn’t seem to do much harm. And I would guess that people who make renderers for non-game-designers who don’t want to spend a week optimizing everything have thought about this before, whether this is the nature of how path-tracing works or the result of preprocessing.

6

i would assume that when the bounces of a render engine are increased, parts which are more in the shade would have a bit more impact on the rendertime. just a guess though

7

Thank you, but on larger projects, I am constantly changing object layers and hiding what I don’t need to see.

8

To make the experiment interesting: apply some 2048 sized and above materials on some objects., perhaps some bumpmaps too. It’s probably easier to throw a solid color on things than map a material.

[Ironically, Rhino is supposed to be able to use 4096, in it’s better rendering modes. That would be slow going.]

A No-Draw material could not only help with rendering–but also reduce the creation of needless mappings on objects. If you use Cycles, check your user temp folder for a McNeel folder, which you will find lots of mappings of some kind saved to the drive.

(Noting, part of what I want: not to have to explode objects.)

9

I have used at least 8K textures. It all depends on whether it will fit in (GPU) memory.

If you have many 4K textures you’ll easily exhaust RAM and VRAM.

10

I have OpenHardwareMonitor going on the desktop. The GPU memory is fine but this, but for reliability, I am sticking with 2048s, even then I need to be patient and careful.

11

i read this topic .it base full information
Thank you every One

12

Creating a ‘shadow catcher’ with a non-rendering material is a common workflow for Vray style rendering, for serious compositing it’s almost a must-have.

The automatic ground plane, for example, would be one place where it would really make sense. I believe it exists in Cycles in Blender as a “Shadow Catcher/Holdout”.

13

The shadow catcher is already in use on the automatic groundplane for the shadows-only case. It still means there is geometry in there, though.

14

My apologies, I should have tested before posting.

Is this an option in other materials?

15

No, it is not an option in other materials.

16

Ah okay, I’ve just found this thread;

Having a greater level of control over a material appearing in certain situations would be the ultimate luxury and would help in these situations.

image
image951×662 30.3 KB

VRay allows granular control (though obviously it’s an expensive and fully featured engine - Cycles is still great!)

17

Well, the underlying Cycles engine could do it no problem. We just don’t have the GUI for that, and because there is currently no GUI for it I didn’t also hook it up either.

18

Oh that’s great! So it might make an appearance in the future?

19

Yes, with time I’d like to be able to present more of the features of Cycles to Rhino users as well.

1 Like
20

I guess I just don’t get the significance of this statement. Do you mean that you don’t write the GUI for Cycles; that this is handled by some “GUI department” at McNeel and you can only use what they come up with?

Maybe you could give a few more details about the policies and procedures involved?