Blender Git Commit Log

Calculate UVs while drawing

Now the UV while drawing is calculated using same logic used in final UV.

There will be differences between drawing and final due simplify and smooth postprocessing, but the look is more similar now.

Redo UV calculation using color factor

Now the Pixel size ratio is determined by a parameter of the color and not by view pixelsize.

This solves various problems and allow the user define dfifferent effects.

NOTE: Still pending to use the same logic while draw.

Merge branch 'blender2.8' into topbar

Fix incorrect OSL raytype bits and add some comments.

Fix T54105: random walk SSS missing in branched indirect paths.

Unify the path and branched path indirect SSS code. No performance impact
found on CUDA, for AMD split kernel the extra code was already there.

Fix T54107: bevel shader + normal map gives wrong result.

DRW: Use new gawain context.

Cleanup: Rename function

Merge remote-tracking branch 'origin/blender2.8' into temp-drawcontext

Gawain: VertexFormat: Cleanup

Reorganize struct elements by size, rename a constant.

Gawain: Refactor: VAOs caching AND use new VAOs manager.

A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls.
This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing).

Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself.

--- Batch changes ---
For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime.
The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs.
This mean a VAO can be generated and cached for this instancing case.

A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true.

--- Draw manager changes ---
The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free.
This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches.

--- VAO cache ---
Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives.
If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings.
The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static.
Using this hybrid approach is a bit more performant than the dynamic array alone.
The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed.

--- Results ---
Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw!
In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms.

The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).

Gawain: Add new context/vao manager.

This allows allocation of VAOs from different opengl contexts and thread as long as the drawing happens in the same context.

Allocation is thread safe as long as we abide by the "one opengl context per thread" rule.

We can still free from any thread and actual freeing will occur at new vao allocation or next context binding.

Merge branch 'master' into soc-2017-normal-tools

Cleanup: move new BMesh clnors editing data to more logical place in struct.

Cleanup: Don't perform borderselect on channels that aren't visible

Fix: Return back to conventional way of averaging points for keyframe de-dup

The other approach was causing too much error in some cases (e.g. favouring
the lower-valued keyframes). This fix should make the resulting curves less
bumpy/jagged.

Fix: Forgot to recalculate handles after deleting keyframes

Fix: Don't average keyframe values if FCurve can only have int/discrete values

This is to prevent problems with integer/enum properties getting invalid
values set.

Cleanup: Delete debugging code and the old version of the automerge code

Tweak/Fix for T54106 - Moving multiple selected keyframes on top of an unselected one would not merge the keys

This commit removes an earlier attempt at optimising the lookups
for duplicates of a particular tRetainedKeyframe once we'd already
deleted all the selected copies. The problem was that now, instead
of getting rid of the unselected keys (i.e. the basic function here),
we were only getting rid of the selected duplicates.

With this fix, unselected keyframes will now get removed (as expected)
again. However, we currently don't take their values into account
when merging keyframes, since it is assumed that we don't care so much
about their values when overriding.