This port the Blurring of blf fonts to the final drawing shader.
We add a bit of extra padding to each glyph so that jittering the texture
coord does not sample the neighbor glyphs.
Replace the 12 iterations of UI_draw_roundbox_4fv with only one batch.
This mean less overdraw and less drawcalls.
I had to hack the opacity falloff curve manually to get approximatly the
same result as previous technique. I'm sure with a bit more brain power
somebody could find the perfect function.
Special shader to draw nodelinks for the node editor.
We only pass bezier points to the GPU and vertex position is handled inside
the vertex shader.
The arrow is also part of the batch to avoid separate drawcalls for it.
We still draw 2 pass one for shadow and one for the link color on top.
One variation to draw instances of theses links so that we only do one
drawcall.
For this we use a new shader that gets it's data from a uniform array.
Vertex shader position the vertices using these data.
Using glUniform is way faster than using imm for that matter.
Like BLF rendering, UI icons are always (as far as I know) non occluded and
displayed above everything else. They also does not overlap with texts so
they can be batched at the same time.
I've made a separate version of the geom shader that works with full
3D modelviewmat.
This commit also includes some fixup inside blf_batching_start().
This means smaller imm buffer usage.
This does not reduce the number of drawcalls.
This uses geometry shader which is slow for the GPU but given we are really
CPU bound on this case, it should not matter.
A perfect implementation would:
- Set the glyph coord in a bufferTexture and just send the glyph ID to the
GPU to read the bufferTexture.
- Use GWN_draw_primitive and draw 2*strllen triangle and just retrieve the
glyph ID and color based on gl_VertexID / 6.
- Stream fixed size buffer that the Driver can discard quickly but this is
the same as improving IMM directly.
This is a bit useless because gpu lamps are only used by the game engine
and it is planned to be "remove" in some way.
Doing this to clean gpu_framebuffer.c.
This module has no use now with the new DrawManager and DrawEngines and it
is using deprecated paths.
Moving gpu_shader_fullscreen_vert.glsl
to draw/modes/shaders/common_fullscreen_vert.glsl
This separate context allows two things:
- It allows viewports in multi-windows configuration.
- F12 render can use this context in a separate thread and do a non-blocking render.
The downside is that the context cannot be used while rendering so a request to refresh a viewport will lock the UI. This is something that will be adressed in the future.
Under the hood what does that mean:
- Not adding more mess with VAOs management in gawain.
- Doing depth only draw for operators / selection needs to be done in an offscreen buffer.
- The 3D cursor "autodis" operator is still reading the backbuffer so we need to copy the result to it.
- All FBOs needed by the drawmanager must to be created/destroyed with its context active.
- We cannot use batches created for UI in the DRW context and vice-versa. There is a clear separation of resources that enables the use of safe multi-threading.
This replaces the blackbody to RGB code with the simpler and faster one from
Cycles. It's a little different but the other placing using this is the legacy
volume drawing, so no need to stay compatible with that.
It seems to be useful still in cases where the particle are distributed in
a particular order or pattern, to colorize them along with that. This isn't
really well defined, but might as well avoid breaking backwards compatibility
for now.
This adds midlevel and object/world space for displacement, and a
vector displacement node with tangent/object/world space, midlevel
and scale.
Note that tangent space vector displacement still is not exactly
compatible with maps created by other software, this will require
changes to the tangent computation.
Differential Revision: https://developer.blender.org/D1734
Previously only scalar displacement along the normal was supported,
now displacement can go in any direction. For backwards compatibility,
a Displacement node will be automatically inserted in existing files.
This will make it possible to support vector displacement maps in the
future. It's already possible to use them to some extent, but requires
a manual shader node setup. For tangent space maps the right tangent
may also not be available yet, depends on the map.
Differential Revision: https://developer.blender.org/D3015
This converts object space height to world space displacement, to be
linked to the new vector displacement material output.
Differential Revision: https://developer.blender.org/D3015
Was due to the fact that the instances don't have a "static" obmat that can be referenced to use as a uniform.
Solution : precompute the full matrix for each bone and pass it as instance data. (theses are copied into a buffer and can be discarded right away)
Note: this could be optimized further and make only one drawcall (shgroup) to draw all bone instance of one type (vs. one call per armature).
This option prevent from automatically blurring the albedo color applied to the SSS.
While this is great for preserving details it can bleed more light onto the nearby objects since the blurring will be done on pure "white" irradiance.
This issue is to be tackled in a separate commit.
This cleanup removes the need of gigantic code duplication for each closure.
This also make some preformance improvement since it removes some branches and duplicated loops.
It also fix some mismatch (between cycles and eevee) with the principled shader.
This is a hack to make the user control the SSS radius even though the profile is baked with the default radius values.
This is completly against UI principles since you cannot edit the profile radiuses while there is something plugged into the radius socket.
Better solution will be to either have a dedicated node value for RGB radiuses and a SSS scale socket only for eevee.
This adds the possibility to simulate things like red ears with strong backlight or material with high scattering distances.
To enable it you need to turn on the "Subsurface Translucency" option in the "Options" tab of the Material Panel (and of course to have "regular" SSS enabled in both render settings and material options).
Since the effect is adding another overhead I prefer to make it optional. But this is open to discussion.
Be aware that the effect only works for direct lights (so no indirect/world lighting) that have shadowmaps, and is affected by the "softness" of the shadowmap and resolution.
Technical notes:
This is inspired by http://www.iryoku.com/translucency/ but goes a bit beyond that.
We do not use a sum of gaussian to apply in regards to the object thickness but we precompute a 1D kernel texture.
This texture stores the light transmited to a point at the back of an infinite slab of material of variying thickness.
We make the assumption that the slab is perpendicular to the light so that no fresnel or diffusion term is taken into account.
The light is considered constant.
If the setup is similar to the one assume during the profile baking, the realtime render matches cycles reference.
Due to these assumptions the computed transmitted light is in most cases too bright for curvy objects.
Finally we jitter the shadow map sample per pixel so we can simulate dispersion inside the medium.
Radius of the dispersion is in world space and derived by from the "soft" shadowmap parameter.
Idea for this come from this presentation http://www.iryoku.com/stare-into-the-future (slide 164).
