It happens with most textures I tested. Only time it does not happen is when Blend texture is connected from the Value output (instead of the Color output) of the node. (With other textures it happens with both outputs.)
Yes! It fixes the issue.
Okay, thanks for testing! It seems legacy textures does not support multi-threaded evaluation, I will see if this can be resolved or otherwise disabled multi-threading for now.
Does the following commit fix the bad performance of image textures? And does it have any effect on the other issue?
a32dbb892fe557573f432f22008c40af57dd7183
Thanks, the opaque camera framing solves the issue, but why does the opaque passport change the behavior? Is this intentional?
Hi Omar!
First want to say love what you have done so far! It greatly improves artistic workflows by reducing iteration time. At the same time, however, you also broke a long standing method for quickly cycling through different parts of the node tree output via preview nodes without affecting the final Composite node output.
This is the “CTRL-SHIFT-LEFT CLICK” workflow to connect any node to a Viewer preview node to see its effect. This has been a long standing* workflow in the compositor, displaying the preview on the backdrop or in an image editor with the Viewer selected. This same work flow was recently added to geometry nodes as well.
Since the Real-time Compositor weighs the Output node higher than the Viewer node, “ctrl-shift-left click” changes the links in the node tree, but not the output, when both an Output and Viewer node are in the tree. In order to make it work, one has to delete the Output node while working, and then add it back at the end when a final look has been decided.
Could the heuristic be changed to match the regular compositor and geometry nodes?
*Although I couldn’t find when it was first added, it was removed at one point. I did find the Commit from Ton in 2010 adding it back, which you can see here.
This is intentional, yes. The logic is that since areas outside of the camera region are no longer visible, the compositing space is now limited to the camera region, which has the same aspect ratio as the render size.
@EWA Technically, there is no such heuristic for the regular compositor, since the choice of its output nodes is context sensitive, not prioritized, depending on whether it is executing as part of the render pipeline or the compositor editor.
However, your concern makes sense, so I went ahead and changed the priority in:
5 Likes
Tested, works great, thank you so much!
Tried the latest daily build and the performance has been improved a lot. I still see some minor performance drops when the passepartout touches the border of the viewport and the image is being scaled to fit. It’s more noticeable as the displayed size of the image is bigger. But all in all it’s not serve as before. (At least in my 1080p screen!)
I see no changes in the artifact issue.
That’s because the requested size of the texture changes as the compositing region intersects the viewport region, so the implemented cache is useless in that case. So there isn’t much we can do for now.
For the artifacts, I can’t reproduce the issue, so can you create a bug report to get more testing?
1 Like
@OmarEmaraDev I was not sure if I should report this as a bug since it’s related the the last issue, but there is something wrong with hsv in viewport. Even with the difference in the hsv conversion as you can see in the images below, just boosting the the saturation from 1 to 1.055 the difference node shows no diff in the flower compared to the cpu compositor thats shows a diff all the way up the scale.
here are the images with saturation boosted to 2
1 Like
I am not entirely sure what the issue is, can you open a bug report regardless? I will be off for a week unfortunately, so I will look into it in a week.
1 Like
hi glare not working in cycles Viewport Compositor why ?
Are you sure this is an issue with the Glare node itself? Does lowering the threshold make it work?
Getting differences when multiplying the mask node with an image from scale with fit. Using scale with crop and stretch gives me the same results.
I have to add a multiply after the mask to get the same results , I think the cpu comp is the is the wrong one , but just wanted to mention the differences
Can you share a minimal blend file for that case?
Differences on how the two compositors handle transformations and different resolutions are expected and currently being looked into, so having that as an example would be useful.
didn’t want to include the image since it’s big , but when I tried with an rgb node and a different image I got correct results , so I had to add it to show the prob. The muted multiply node will make the comps match when enabled.
1 Like
checked my settings real quick and it seems I had full frame compositor enabled. the bug does not happen with it disabled
Thanks, this will be useful for our investigation.
2 Likes
Some nodes would be great to work with if they had on screen controls like corner pin for example
And the onscreen controls must be (especially for corner pin) must be present with respect to camera instead of the entire viewport
1 Like