Vuo currently renders objects in the order they appear in the object list. This works fine for opaque objects, but it doesn't work well for transparent objects (see these discussions).
This feature request would change the rendering algorithm to use depth peeling-style order independent transparency (OIT).
The end result would be that transparent objects should render correctly when added anywhere to the scene (regardless of list order). Both the left and right sides of the scene on this discussion would then render identically.
QC equivalent:
Kineme GLTools "Depth Sort Sprite/Environment"
Comments
Won't this slow down the
Won't this slow down the rendering and the fps ?
If yes, will / could this be optional ? I mean would this be needed by default for non-transparent objects ? If no difference in the algorithm calculation time, then yes, if there could any, perhaps this could be added as a option for the "Render Scene to x" nodes ?
Well, I wanted to make a
Well, I wanted to make a simple smoke type particle system. And stopped dev since objects don't blend nicely.
Shame this has to be considered a feature request.
Won't this slow down the
In theory if the scene contains only solid objects it shouldn't have a noticeable performance impact. The more layers of transparent objects there are, the more render passes it'll have to do, meaning it'll take longer to render.
Part of the implementation of this feature request will be looking at the performance and seeing if we need to provide some controls (as you suggest) to lessen the impact. One way to keep depth peeling from taking too long is to limit the number of passes (either say "do no more than X passes", or say "stop if the last pass affected fewer than N% of the pixels").
Well, I wanted to make a
@krezrock, sorry your composition didn't work out.
I hear you. Sometimes there's a gray area between feature requests and bug reports. Improving rendering of transparent objects is clearly something that would be good to add. It's just a question of whether it's more or less urgent than other things to add and fix. Especially whether it should preempt feature requests that more people have voted for. As we plan each release, it's difficult to decide what to put in and what to leave out.
Getting more votes would help this feature request get implemented sooner. Maybe it would help folks understand the importance if you posted your composition and pointed out how it doesn't look right?
I'm very upset to discover
I'm very upset to discover this and considder it to be a major flaw. It makes working with 3D objects almost totally unviable, we cannot achieve anything other than very basic styles. In my opinion this really should be a priority for you to implement and should not be a feature request.
See the composition attached. When rotated infront of object one, object twos back faces have no transparency and block out object one.
fading squares objects back faces no transparency.vuo
Yup, I also end up searching
Yup, I also often end up searching workarounds for this.
One workaround sometimes useful is to convert the 3D objects to layers using the custom Paradox nodes (see node gallery).
Composition joined
Capture d’écran 2019-03-05 à 14.24.54.png
fading squares objects back faces no transparency - 1.vuo
Thanks for the workaround. Do
Thanks for the workaround. Do you have any examples of when this does not fix the issue? I would really like to know how and why that solves it.
The reason this workaround
The reason this workaround kinda sorta works is that the
Render Layers to Windows/Imagenodes disable depth-culling, so they always draw all of each object (rather than skipping drawing pixels that are behind another object).The workaround only works well when both objects are 50% transparent. It doesn't solve the problem that Vuo doesn't know how to paint objects in the desired order, but it masks the problem because at 50% transparency the order in which objects are painted doesn't matter.