About this, do you think it would be possible for Blender to export the manifest file? (maybe as json with an additional checkbox in the output node or output panel), I saw that other DDCs do this and in compositing programs you can use that to retrieve the names, it could work in the case of PXR24.
I am not sure, I feel like extracting the manifest from the EXRs would be easy enough, so there would be no reason to add dedicated functionality for it.
about compositing the image sequence , when render it really slow, not like nuke ,for like 10000 frame doing nothing to render out ,blender need 0.5/frame, about 5000s = 1.38hrs and nuke only take minute to finish,
so i try open 5 blender like 1-2000 for one,2001-3000 for second blender … and 5 blender run compositing together, and it working good, faster than one, so any idea to accelerate this kind of image sequence comcompositing in one blender instead of open many blender instance?
This is a bit stretching the purpose of this feedback thread.
Don’t think there is anything you can do on your side to speed things up without changing code. From development perspective we are always looking into solving slow things, but there is evergoing topic of priorities and amount of resources.
Don’t know if I miss some option somewhere or if it’s not just there, but I can’t get the compositor denoiser to work on the GPU. I would really like to do command line renders that denoises each pass separately for better noise levels/shorter renders. Can it be done?
The work for the GPU denoiier in compositor is not yet finished, unfortunately. You can subscribe to #115242 - Compositor: Enable GPU denoising for OpenImageDenoise - blender - Blender Projects to track the development progress (please keep the code review limited to development discussions only though )
Can the automatic masking of the background channel have a switch? Some effects require a complete background image.
Can you explain better the scene you’ve got, compositor setup you’re using, and what is not working as expected. From looking at the images it is not really obvious what’s going on there.
Also, it is something that was never supported, or got lost with the improved compositor project landing?
Hi. I noticed that the scale node is behaving non-intuitively in 4.3 (it seems since the compositor improvements), it is much more noticeable when used with an alpha over. I’m still testing, but from what I understand, after scaling in the fit render size mode the alpha of the image (mainly imported) shift up or to the side (usually unpredictable), when using this image as the second input of the alpha Over strange things happen, sometimes it does not respect the scale given by the previous node, when the image of the first input has alpha in some areas the second input is cut by that alpha and in other areas it does not. When you disable alpha display in the viewer and composer node you can see where the alpha actually went.
Ok, I think I have a video that shows more or less what I understood. I also share the blend file.
4.1:
4.2 and 4.3:
alpha issue.blend.txt (1.2 MB)
EDIT: Forgot to mention, in 4.2 and 4.3 what you see in the viewer is not what you see in the render window, at least in the case of this file
with alpha active:
without alpha:
This seems like a bug. It’s best to file a bug report by:
- Opening Blender
- Selecting
Help -> Report a bug
from the top of Blender - Filling out the online form with all the relevant information.
I’ve been going back to update a number of compositing setups from before 4.2, and I’m bumping up against the wrapping changes in the translate node: Compositor - Blender Developer Documentation
I understand the change and that the functionality is planned to be replaced in the future, but I’m having difficulty finding any recommendations for mimicking its functionality in the meantime. I can’t imagine I’m the only one having trouble with this, is there a known solution for this while we wait for news on whatever the official next version of this is?
Apologies if this is the wrong thread for this, or if this has already come up. I did some scrolling and skimming and didn’t find anything, but it’s nearly a year-old thread at this point so I won’t be shocked if I missed something, haha.
You can use the Map UV node for now. See for instance: https://www.youtube.com/watch?v=C-9S1EWdHZk
Sorry for removing this functionality, it was bad decision. We will try to restore it as soon as possible.
FWIW I actually kinda get it? I’m not really a programmer, but I can definitely see how the sort of resolution-agnosticism that the live compositor upgrades would require could make something like a to-infinity wrapper fall apart.
Obviously there’s no predicting the future, but do you have an idea of how/how soon this functionality would be restored? A lot of these updates I’m working on are for node setups I’m planning to sell, which means it would be really useful to have an idea of what to future-proof for. Are you expecting the fix to look like the node going back to the way it used to work, or would it be more likely to come in the form of something like some sort of new “wrap” node?
Thank you for the link, it looks promising but I’m getting problems straight from the jump. Connecting anything to the Output in the Texture Node Editor doesn’t seem to give me any result at all, and I can’t tell why. I’ve got it set to “Brush” and “Use Nodes,” googling around doesn’t give me anything else that’s helpful. Is there some other setting I don’t know about?
I’m using 4.2.1, if that gives any clues.
If all goes according to plan, the functionality should be restored in v4.4. My personal opinion is that we will have multiple ways to achieve this, by restoring the old behavior, adding a new node for repeating, and providing a procedural method.
For context, about 4 years ago, a new CPU compositor called the Full Frame compositor was developed, and its design removed the functionality of repetition. Restoring that functionality would have been difficult, so a decision was made to make the GPU compositor follow that design as well.
However, we are currently removing the CPU compositor entirely and replacing it with a new compositor based on the Realtime Compositor (The one used for GPU and viewport compositing). This will allow us to restore all the functionality we need.
So the plan is to finish the new compositor by the end of the year, then resolve the transformation design issues after that before the v4.4 release.
I haven’t watched the full video, but don’t use “Use Nodes”, use two texture nodes, one is horizontal gradient in X and one is a gradient in Y.
First off, thanks or your solution, it’s got me exactly where I needed to be.
Second, thanks for all the info about the compositor’s development. It’s so rare to hear this kind of genuine insight and openness when it comes to these sort of estimates. I’ve been a longtime lurker on the devtalk forum, couldn’t have asked for a better first experience posting here.
IMO, Blender’s compositor is it’s most underappreciated feature. Thanks for all the hard work you and the rest of the team have put into it. Looking forward to seeing more!