- OS X 10.9
Steps causing the bug to occur:
Using iteration and queuing of a movie file to generate a time cube effect show problem with iteration of 3d objects due to first 3d object not being transparent regardless of transparency settings.
How did the result differ from what you expected?:
I expected every object that was generated by the iterator to observer the transparency settings set within it.
Have you found a workaround?:
Please note that I added a
Please note that I added a draggable camera so you can easily see the effect- and that it is layered correctly. As you can clearly see here- the front image has no transparency at all- even though it is rendered with exactly the same 3D Object generator.
NOTE: I have not attached a
NOTE: I have not attached a video file as you can most probably just copy to a local file that would achieve the same result. I haven 't tested it yet- however I am pretty sure that using a still image would also cause same issue to occur.
Was your crash due to my
Thanks for checking man! Can you get it working by removing any parts of it? It looks like it's using ffmpeg- maybe try an apple codec (proress file?)
I can confirm this.
I can confirm this.
Looking more closely at it,
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.
@Magneson you got a crash
Magneson you got a crash before and have now removed it. Can you let me know if you were able to stop the crash?
I also re-ordered the list of objects but this simply moved the problem frame around.
If this is intended behavior I hope we can get it confirmed.
Yes I removed the crash
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
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.
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.
Movie Iteration (TransparencyFix) 1.1.zip
Ok, this is related to
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). :-)
Screen Shot 2015-12-19 at 8.28.16 am.png
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
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.
@alexmitchellmus ah ok.
alexmitchellmus ah ok.
@Bodysoulspirit can you test
Bodysoulspirit can you test the comp and tell me it there is a difference between rendering video and still image?
There is something going on,
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
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.
Movie Iteration (TransparencyFix) 1.2.zip
And you can use "reverse list
And you can use "reverse list" to get the first or the last frame at front ...
Be great to hear from team
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
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.
@smokris I think this is not
alexmitchellmus Ok I understand what you mean better now.
I think the way I used "Align 3D objects in grid" up above works but when you want to manually do so I'm encountering the same thing as you.
Related to both/or "Build List" and "Enqueue".
Don't know if we are doing something wrong or if it is something like Martinus mentioned.
Let's await some answer.
I'm uploading the composition here too.
Iterate 3D Transparent.vuo
Be great to hear from team
I created a feature request to make transparency behave more intuitively: Automatically sort sceneobject rendering, to better support transparent objects. That feature request would fix the transparency issue in alexmitchellmus's original composition, so I'm marking this bug report as merged with that feature request.
No, there's nothing special about the first object.
I think the problem with alexmitchellmus's original composition is that
Build Listis receiving extra events. It's important that
Process Listonly receive events fired from the
Process Itemport, whereas that composition also has events coming in via
Fire on Startand the window's
Requested Frameport. The extra events cause
Build Listto 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
Process List), by building an object with each frame, enqueuing the object, and using
Arrange 3D Objects in Gridto position them. Composition attached.
Thanks @smokris !!
Thanks Steve !!
Fantastic explanation Steve, I have learned so much just from this issue!
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.
Iterate 3D Transparent - 2.vuo
If you could just look at
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 Colorto 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.
Iterate 3D Transparent - 2 - Edge.vuo