Hi folks. Following from a closed issue, it seems the Realtime Compositor will not support Translate Wrapping outside of the render bounds in 4.1, Omar may be looking into an alternative for 4.2. See below:
This does leave a gap in 4.1 where tiling and scaling a texture isn’t feasible in the realtime compositor (with current methods), although it’s good to see alternative plans on the cards. Does anyone else tile/scale textures much in their composite workflow/are there any viable workarounds?
You certainly want a node that is unexpectedly not working to produce an error.
Muting it should however be a method of stopping the error message.
Hi @OmarEmaraDev
Would like to ask, do you planning to add some new sharpening tool like Unsharp Mask or High pass?
Often the only reason to do post in external programs.
Those can be achieved already using a blur node and a couple of mix nodes, using the equation described here Unsharp masking - Wikipedia. So using external programs is unnecessary for that.
Are there plans to upgrade the Glare node to get better intensity matching between GPU and CPU versions? I understand they use two different rendering algorithms, but the fog glow looks almost 10x stronger in the GPU than in the CPU 
It’s not a big problem if the overall shape of the glow doesn’t match exactly between the two versions, but such a discrepancy in intensity makes it almost unusable.
I will look into it, maybe we should be doing some energy conservation mapping.
But first, at this point, I will move Bloom into its own new option and implement it for CPU compositor, until we implement Fog Glow for GPU.
Optimisation question :
When a Mix Color node with the “Mix” blending mode has its factor set to 0 or 1, are the nodes linked to the opposite input ignored or are they processed anyway ?
They are currently processed anyways.
And I guess there is no workaround to conditionally shutdown a part of the node graph, right ?
Not for the GPU compositor at the moment, no.
We added a new mode to the Glare node called Bloom, which you are probably familiar with from EEVEE.
Glad to finally see this!
Since the mode is no longer limited by having the same options as glare, could it be updated to include the additional options from EEVEE-Legacy bloom? Namely:
I wonder if this is final or you dont add inputs to the node?This way you could make custom node group inputs from.Additional you could further use the inputs for the use of masking etc.
- Float size/radius, that’s not hard limited between 6-9
I am reluctant to support float radii, at least in the same way EEVEE implements them, since they produce instability in how Bloom is computed. But I can look into other implementation methods.
- Knee
This will be added for all glare types indeed.
- Clamp (this one might be possible to do with nodes?)
Probably not going to add it to the glare node, since clamping introduce light clipping, which is undesirable in most cases. That can be done manually as you noted.
I wonder if this is final or you dont add inputs to the node?
We used preexisting node options, so we didn’t add any new inputs. But I understand what you are after, and that’s a project that we intend to tackle, though not very soon.
Do you think that this maybe a way to work around this bug at the moment if a user were to use object ID as a way of masking?
These are available in real-time already in the viewport. How are these render layers meant to be used at the moment? I simply do viewport renders to use them. What if these had check boxes next to them or add as nodes/ switches or all of the above? Blender render slots maybe could be utilized perhaps?
Could each layer act as a way of stacking the viewport through nodes? Throwing ideas around is ok right?
No. The information is not available to the compositor and thus can’t be made visible through it.
Those will be available as part of the render layer node in the future. But for now, they just change what the combined output of the compositor will be.
Hi there, I was playing with Blender 4.2 and, surprise!, the denoise node is now supported. Cool!
Yes, cool but… any chances it will be using GPU somewhere in time?
Yes, though it appears we will still pay the cost of CPU<->GPU memory transfer for the initial implementation.
I’ve just read in the 4.2 release notes that Transform nodes get applied immediately.
https://developer.blender.org/docs/release_notes/4.2/compositor/
What’s the justification for this? All the major node based compositors concatenate image
transforms to avoid resampling until absolutely necessary to prevent image degradation.
It’s a core design principle for Nuke to keep full image resolution until the composite is
reformatted or rendered.
Wouldn’t a Rasterise node make more sense?
