Performance of multiple materials for transparent & non-transparent mesh?

Geosmith

Hello.

As of my understanding, transparent materials/shaders require more power than a standard opaque one. That considered, take an object such as a weapon scope for example where a large portion of it is opaque, though there are transparent lenses. 

What would be the performance difference between giving the entire scope a transparent material, and setting the plastic/metal areas to be opaque in the opacity and the lenses to be transparent
vs
Giving it two materials, an opaque for the plastic/metals and a transparent material for the lenses. 

I guess the underlying question is, does opaque geometry cost more to render with a transparent material or is it treated the same as a standard opaque material?

Since the lenses aren't part of the same element as the rest of the scope, if I'm not wrong giving it another material ID wouldn't increase the vert count,  but neither should there be overdraw since the opaque parts are fully opaque in the transparent material. Correct me if I'm wrong.

Larry

I am not entirely sure but transparency has to do with the amount of pixels that are drawn from your scene to your screen, and do not really affect geometry. A transparent texture will need to calculate the pixels, remove them, then calculate what is behind it.So i think transparency is heavy in real time. Or something like that, don't take my word for it since i just read all of these information once when i had performance questions to optimise my modeling.

Modern day hardware can draw about to 11million tris in a real time high quality game.

Obscura

Have you tried the shader complexity view mode?

Geosmith

Obscura said:

Have you tried the shader complexity view mode?

As far as I'm aware it isn't a definitive way to calculate what something costs to render like its said in the UE documentation, but it does show the transparent material with 100% opacity as being red (pretty bad). It doesn't change with any opacity setting. My mesh also renders faces behind itself, not sure if this is fixable.

Larry said:

A transparent texture will need to calculate the pixels, remove them, then calculate what is behind it.

I'm more interested in what's the performance like when the pixel it's rendering hits a transparent material, but that pixel is completely opaque. The shader complexity view shows it as red, but I can't imagine it costing that much to just check whether it's transparent or not, but maybe it's really sensitive. It's also rendering faces behind itself, I'm not sure if this is intended or if I'm doing something wrong. It's a pretty complex mesh I'm using. 

Obscura

Its a fairly accurate way to measure expensiveness of transparency. I would assume it shows the whole as red and every overlapping because you have one material for the whole object and the most of the opacity map is white. You should have 2 materials. One opaque for the non translucent , and one more for the translucent ones. So to answer your question, having white opacity doesn't really help.

There is also some sorting errors going on, thats why you see pieces through it. The opaque material would solve this too. 

Obscura

The original question is bad though. Performance of multiple materials. Seriously? 

Obscura

You could also use the console command "profile gpu" to get some rendering stats about the last frame rendered. It has a transparancy section.

Geosmith

Obscura said:

The original question is bad though. Performance of multiple materials. Seriously? 

The original question was whether having two seperate materials, a transparent and an opaque for the full object is of much benefit to having a single transparent material. Since the pixels hit are fully opaque it shouldn't have to render anything beyond that. 
Clearly there are issues with using a transparent material for the full thing, neither was I intending to use a single material, it was a question of curiosity. 

poopipe

It's almost always a better idea to apply a separate material to the transparent bits. 

If you don't split it, the opaque bits of the material are still alpha blended so you're paying for transparency on pixels that don't need it.
The calculations still need to be done regardless of opacity (I assume this is blended rather than clipped) 

One extra primitive is bugger all in the grand scheme of things - and it'll sort properly..