We might not have tested it during development. But we should support the viewport compositor during viewport rendering. We should follow the settings that the user has setup. Might need some tweaking to existing code (copy over settings, where the render job is created.).
4 Likes
Here.
The Displace node one is not that different from the startup file except the node setup.
@sunkper Your UV image has a different size than the compositing space. The opaque passepartout trick is only useful to maintain the aspect ratio, not the size. So just use a scale node with the render size option to also match the size.
3 Likes
I dont understand why the transformations are not the same in the realtime compositor and the render compositorā¦
Same dimensions as render 1080p, overlaid with an alpha over nodeā¦ Its completely differentā¦
Hard to see but on the left in the compositor it nearly matches and on the right the realtime compositor is completely off and has a way bigger overlaid picture.
I cant never match the viewport and the compositor bg either with images. Also panning and zooming in the viewport totally messes it up.
I donāt see how your setup attempts to match the size. First, make sure you have an opaque camera passepartout, then insert a scale node with the Render Size option to the input image as shown in my previous reply. That way you maintain the same aspect ratio and size as the actual render.
1 Like
Well, if you zoom in and out in the camera view the image is changing in sizeā¦ How do i know which zoom step is the right one?
Am i missing something obvious here?
I added the scale node with the rendersize option and changed the passpartout which should now be default because how would anyone know that it can have an effect on it?
Fits in compositing but viewport is off.
Try using a Translate node with the relative option enabled, instead of pixel-space translation in the Transform node.
You can press home and it the camera viewport will fit the bounds, so your image can be 1:1
2 Likes
Thanks for the tips!
I also tried the Texture node support and found some issues. I was going to post this on the repo but thought it might be helpful if other people here test this as well since these could be GPU-specific issues.
(Windows/RTX 2060 Super)
-
Artifacts when using procedural textures
-
Viewport gets slower when using custom image for texture and camera view/opaque passepartout is active
Does this happen for other textures types like Blend?
Can you try opening Blender from the terminal using blender -t 1 and see if that fixes the issue?
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