english Sivu saatavilla vain englanninkielisenä.

Blender Git Statistics -> Branches -> temp-lanpr-cleanup

"Temp-lanpr-cleanup" branch

Total commits : 280
Total committers : 32
First Commit : September 12, 2019
Latest Commit : October 30, 2019

Commits by Month

DateNumber of Commits
October, 2019190
September, 201990

Latest commits Feed

October 30, 2019, 08:47 (GMT)
LANPR: Remove unused "restore transformation" script.

This should be the user's effort to keep the object at their positions.
And LANPR should handle target object transformation when converting to grease pencil.
October 30, 2019, 08:32 (GMT)
Merge branch 'temp-lanpr-cleanup' into temp-lanpr-cleanup2
October 30, 2019, 07:58 (GMT)
LANPR: Fix merge errors in eevee_materials.c
October 30, 2019, 07:24 (GMT)
LANPR: Consistent naming in shader variables.

eg: Use color_xxx normal_xxx thickness_xxx consistently for easy formatting.
October 21, 2019, 12:03 (GMT)
Merge remote-tracking branch 'origin/master' into temp-lanpr-cleanup
October 20, 2019, 06:29 (GMT)
Merge remote-tracking branch 'origin/master' into temp-lanpr-cleanup
October 19, 2019, 05:30 (GMT)
Merge remote-tracking branch 'origin/master' into temp-lanpr-cleanup
October 18, 2019, 12:55 (GMT)
Merge remote-tracking branch 'origin/master' into temp-lanpr-cleanup
October 18, 2019, 12:45 (GMT)
Merge remote-tracking branch 'origin/master' into temp-lanpr-cleanup
October 18, 2019, 12:43 (GMT)
Cleanup: warnings
October 18, 2019, 12:43 (GMT)
Workbench: Background Dithering

Background dithering was introduced to solve banding issues on gradient backgrounds.
This patch will enable dithering based on the texture that is used for drawing.
Only when using a GPU_RGBA8 texture the dithering will be enabled.

This disables dithering for final rendering, vertex and texture paint modes.

Reviewed By: fclem

Differential Revision: https://developer.blender.org/D6056
October 18, 2019, 12:43 (GMT)
Fix T70249 EEVEE: Light bleeding on SSS translucency

This was caused by 2 things: Shadow map bias and aliasing.

It made the expected depth of the shadowmap further than the surface
itself in some cases. In normal time this leads to light leaking on normal
shadow mapping but here we need to always have the shadowmap depth above
the shading point.

To fix this, we use a 5 tap inflate filter using the minimum depth of all
5 samples. Using these 5 taps, we can deduce entrance surface derivatives
and there orientation towards the light ray. We use these derivatives to
bias the depth to avoid wrong depth at depth discontinuity in the shadowmap.

This bias can lead to some shadowleaks that are less distracting than the
lightleaks it fixes.

We also add a small bias to counteract the shadowmap depth precision.
October 18, 2019, 12:43 (GMT)
Cleanup: spelling

Also remove historic bftgl reference.
October 18, 2019, 12:43 (GMT)
Node shader wrapper: use 'Non-Color' profile for BW textures inputs.

All the single-value texture inputs of Principled BSDF node should use
non-color colorspace profile, not sRGB one (issue raised in
https://blender.stackexchange.com/questions/155617, thanks).

That also revealed another issue - since those color space settings are
stored at the image level itself, not the node one, we need to
duplicate those image data-blocks when we use same picture for e.g. base
color (sRGB) and specular (non-color) inputs...

For now using a basic mechanism for that, might generate several extra,
uneeded copies of the image ID, but that?s better than breaking custom
settings and such.

Note that while this will modify the behavior of the impporters using
that node wrapper, no change should be needed in IO add-ons themselves.
October 18, 2019, 12:43 (GMT)
Cleanup: shadow warning
October 18, 2019, 12:43 (GMT)
Fix T70543 Rigid Body Collision Shape Not Displayed In Viewport
October 18, 2019, 12:43 (GMT)
Fix assert and memleak in recent Skin Root Display patch

Caused by 4ddf3215a7df
October 18, 2019, 12:43 (GMT)
PyAPI: use public API's for module & builtin access

D6038 by @Dormouse
October 18, 2019, 12:43 (GMT)
GPencil: Fix unreported performance issue with relative onion mode

When the relative mode was used, the calculation of the total number of vertices was not done and it was using the total number of vertices in the datablock. This worked for small files, but with complex files the time to allocate all the data was too long and the performance was very bad.

Now, for relative mode the real number of vertex is calculated.

Also fixed the same problem when onion and multiedit is enabled.
October 18, 2019, 12:43 (GMT)
Fix T70887: GPencil edit lines are not displayed in the right place

The lines were not using the matrix to calc the tarnsformation.

MiikaHweb - Blender Git Statistics v1.06
Tehnyt: Miika HämäläinenViimeksi päivitetty: 07.11.2014 14:18MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021