In QC we are able to set an object to disregard the Depth Mapping, thus rendering close objects behind distant objects, depending on layer position in scene. It would be FANTASTIC to have this in Vuo as well, if it is not already.

QC equivalent: 

Depth Mapping Settings in objects


Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo CE and Vuo Pro


●○○○ — Up to a few days of work


●○○ — Appeals to current community


When implementing a node with

jstrecker's picture
Submitted by
Feature status:
Waiting for review by Team Vuo
Waiting for more information from reporter

When implementing a node with the Vuo SDK, you can turn off depth masking by setting VuoShader::isTransparent. Existing nodes that do that are Shade with Frosted Glass and Shade Edges with Color.

Are you saying you want to be able to modify this setting via Vuo Editor, as opposed to the node source code? Could you give an example of how you intend to use this?

Basically it would be cool to

alexmitchellmus's picture
Submitted by

Basically it would be cool to 'fake' an object in-front of another object. If this can already be done with Shade with Frosted Glass and Shade Edges with Color, could this also be added somewhere to the default shader as an option? Or does each shader have to have the option? Either way it would be good.

[@alexmitchellmus] In QC you get 3

jstrecker's picture
Submitted by

[alexmitchellmus] In QC you get 3 modes: Read/Write, Read Only; None

Those options on the Depth Testing port correspond to OpenGL calls that enable/disable depth testing and depth masking:

  • None — disable depth testing, disable depth masking
  • Read/Write — enable depth testing, enable depth masking
  • Read Only — enable depth testing, disable depth masking

Depth testing means that individual object pixels are checked to see whether they're nearer than what's already in the buffer — if they are, they're rendered; if not, they're discarded. When depth testing is disabled, the pixel is always rendered.

Depth masking means that newly drawn objects also write to the depth buffer. When depth masking is disabled, the depth buffer is left unchanged.

The Read/Write mode (for rendering solid objects) and the None mode (for rendering transparent objects) will be handled automatically by Vuo's rendering engine after FR Improve rendering of transparent objects (OIT, Depth Peeling).

Could you give an example of how you'd want to use the 3 modes if they were all exposed via an input port on Change Depth Mode?

[Bodysoulspirit] I guess your FR covers what Steve mentions here in his comment Transparency on 3D objects Comment.

Actually that's covered by Improve rendering of transparent objects (OIT, Depth Peeling).


Bodysoulspirit's picture
Submitted by


Love the explanations of the different modes in QC !

A bit technical for me tu understand this deeply but

Actually what I meant with Steve's comment was that specific part of the comment on Transparancy on 3D Objects Comment (should have write more precisely) :

However, for a very large number of particles, it would probably be more efficient for a (hypothetical) particle system to produce a single object with many vertices (rendered as points, like Make Point Mesh does). The feature request wouldn't help with that; in that case the only solution I know of is to disable depth writing (like our Shade Edges with Color does).

I just hope the automatic and by default change of Improve rendering of transparent objects (OIT, Depth Peeling) won't slow down the rendering.

But what I like with this feature request from alexmitchellmus here is the ability to choose your modes.
In QC Sprites or Billboards could handle that separately, so a node like Jaymie's suggestion would be great.
Especially because I can imagine one could set different modes for different group of 3D objects ! Like you could feed Combine 3D Objects A into a mode and another Combine 3D Objects B into another mode, before connecting those in a Render Scene to x.

Feature status

  • Submitted to
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for.

If anyone would like to help this happen sooner, we're also accepting open source contributions and commissioned work.

Read more about how Vuo feature requests work.


1 vote so far!

Who voted?

George_Toledo's picture