Looking more closely at it, it’s not actually a bug. The way I suspect Vuos objects work, is that the first object is what would be used for “world” in other 3d software . This in essence means that it is a background (or something like it, I think the black background you see is actually transparent), which can not be transparent. So when you build a list of items on the Z-axis and multiply a negative number with the item number from the build-list node, the first object will be in front. As it is a “background object”, all objects behind it will not be visible. To make it work like you intend, just make the list range from 0 to intended position (10?), and then subtract 10 from the number. That way the first object will be at the back. See the attached composition for a working sample.
Yes I removed the crash report because I looked over it again and it was just referring to the composition instead of transparency-something-to-do-with-code, so I think it’s unrelated to this issue.
I was actually wrong again, it is not a world thing at all, it’s a layer thing! All the frames are the problem frames in that an object can seemingly only be transparent if it is in front of an object with lower priority (lower input number, think layers). At least from the “Unlit 3d object from image” node. What are you trying to achieve with it? There might be ways to get around it with some careful placement and boolean logic, but I think that probably is better suited in the discussions forum (and reverse transparency in the feature requests).
In it’s basic form - when an object is iterated (drawn many times) theoretically each object should retain its correct characteristics.
Also bare in mind Vuos itterator is very much an if-loop - so that the objects are being built between frames- not some sort of dark-art that does strange things. (Yes I’m talking about QC)
Like Martinus said, it has somehow to do with who’s in front or end.
Keep in mind you can also use the “Copy 3D object” and the “Make points along curve” instead of the “Build list, add values, copy Object with transform” thus allowing direct use of lists.
Look,
Left image is when the object interpolation starts at -5 to the front 0 ZAxis. It is transparent.
Right image when the object is interpolated from 0 to -5 on the ZAxis. It’s solid.
Ok, this is related to enqueue events. If you use the attached composition with a “movie” file then you will get a translucent texture. However when you reconnect “requested frame” to “time” on the node: decode movie image, then you get the solid frame.
So please test with a playing movie.
Screenshot is paused movie (time disconnected from decode movie image). :-)
Thanks for the “TransparencyFix” however your comp does not use Enqueue to create a “TimeCube” effect, so does not exhibit the issue due to not using Enqueue. Unless I am using Enqueue incorrectly- I call this a bug.
@Bodysoulspirit the main reason why I am not using a COPY node is due to the fact I am loading into the quad a different texture all the time. I don’t know how to load a different texture into a COPY node for every copy- or even if it is possible. I am assuming that a copy is just that, a copy. This is why I am building each quad in an iterator. So I can get unique textures from the que all the time.
There is something going on, but It seems to be related to the alpha channel. You are probably using enqueue correctly, but none of the image 3d objects can be the first in the objects input in the renderer (not including cameras) to have opacity working as intended. Try inserting a cube as the first object, and then setting the translation scale of it to 0,0,0.
Other blending options for the 3d objects are apparently not affected by this.
@alexmitchellmus yes your composition also does show the first frame solid.
Not sure if that matches your need but you could use “Process List” instead of “Build List” and push these through “Align 3D Objects in Grid”.
And I tried with “Play Movie Image” instead of “Decode Image” so that it would loop and use “Play” instead of the “requested frame”.
Not sure that matches your need but I think it does push a different Time Stamp Frame Image to each object and the front one is transparent too.
Hope it help.
PS : I’ve joined the “Chess.mov” that comes with Vuo.
Be great to hear from team Vuo if this is indeed a bug or simply the way Vuo works. If it is the way it works then is there a part of the manual that states don’t use transparency in 1st layer objects? (ie: use a sacrificial object at scale 0,0,0)
@Bodysoulspirit will have a look at your comp when I get the chance! Pretty hectic here right now, I am assuming the holiday season is like that for everyone.
[magneson] the first object is what would be used for “world” in other 3d software
[alexmitchellmus] don’t use transparency in 1st layer objects? (ie: use a sacrificial object at scale 0,0,0)
No, there’s nothing special about the first object.
I think the problem with @alexmitchellmus’s original composition is that Build List is receiving extra events. It’s important that Build List and Process Listonly receive events fired from the Build Item/Process Item port, whereas that composition also has events coming in via Fire on Start and the window’s Requested Frame port. The extra events cause Build List to get out of sync, and the objects get added to the list in an unexpected order — the object that actually gets rendered first is the one in front (closer to the camera), and now that the depth buffer has been filled with those near pixels, some pixels in the objects behind it aren’t rendered.
But I think you can make a videocube in a simpler way (no need for Build List or Process List), by building an object with each frame, enqueuing the object, and using Arrange 3D Objects in Grid to position them. Composition attached.
Well done that VideoCube composition. A bit like the way I did it up above, using Align 3D object in grid but without the use of “Process List”. Much easier the way you did it !
You say in @alexmitchellmus’s original composition “Build List” is receiving some extra events.
I tried to simplify something similar without “Build list” to focus on the problem but still the 1th object in the list stays opaque. So I more think its related to the way Vuo handles those 1th 3D objects (like you described).
If you could just look at this composition I’m attaching and confirm me that will be solved with that feature request you created.
If you could just look at this composition I’m attaching and confirm me that will be solved with that feature request you created.
Yes, after we implement the “Automatically sort sceneobject rendering” feature request, that composition will always show both squiggles (instead of hiding one of them behind the other half the time).
In the meantime, for solid-color shading, you can use Shade Edges with Color to always see both squiggles (like in the attached composition) — that shader doesn’t write to the depth buffer, and thus it doesn’t matter which order the squiggles are rendered.
