Age | Commit message (Collapse) | Author |
|
This reverts part of commit d5c2be7031912cca8f58e90283eb52f63f71b32f.
|
|
This enables static linking of libstdc++ by default when building using
`WITH_STATIC_LIBS`. This makes builds more portable for anyone making
static builds (in particular for older systems).
Reviewed By: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4393
|
|
When edges had small length (less than about .005) the angle
classification didn't work. Needed some normalization of vectors.
|
|
Mistakenly had left a debugging assignment that disabled
the offset pass. This commit re-enables it.
|
|
The subdivision method for getting corner shapes has a fullness
parameter which had been set by eye before. This change uses fullness
as found by offline search process to best match the superellipsoid
octant in the cube corner case (except cube corner case is still handled
by other code). This somewhat improves the look of cube corners with
inner arc miters, however.
|
|
Will document the new options in release notes, then in manual.
Still a bit of work to do on the bulging shape that appears
on cube corners if using arc inner miters, but will do that later.
Also need to do something smarter in clamp overlap.
|
|
Some of Eevee's Bloom defaults are not very good for physically based rendering. This patches addresses this issue.
This picture shows one of the problems with current default. Bloom looks very foggy:
{F6280495}
Even worse, light emitters much dimmer than the Sun can make everything equally hazy if Clamp is set to 1.0 and intensity to 0.8 (current default). Artists often forget to adjust Clamp value and do not know what value to use for realistic intensity. Also, currently both Clamp and Intensity do not have good UI ranges. This is why often Eevee renders end up very hazy and bloom often does not look right.
Bloom effect plays important role to help to distinguish between bright and relatively dim light sources. With current defaults this is broken because Clamp set to 1.0. Also, it cannot be disabled if set to 0 like expected. This patch fixes this and sets it to 0 by default. If users need to clamp, they can do so easily with UI range up to 1000. This range is good enough for most cases and provides enough precision to control lower values, and the highest value helps to limit bloom from the Sun if necessary and will leave untouched most other light emitters. If needed, much higher values for Clamp can be entered manually up to 100000. 10000 is still affects the Sun, but up to 100000 highest limit allows to clamp anything that is much brighter than the Sun if user needs to limit bloom in such cases (for example, bright explosion in the sky or anything else very bright).
I propose new default for bloom Intensity - 0.05 and UI range to suggests realistic values. Bloom Intensity > 0.1 is not realistic for clean lens but the user can enter manually much larger values if needed.
For comparison, here is a my own photo with and without bloom caused by the Sun (on second photo the Sun was occluded with an object).
{F6280500}
{F6280492}
In real life bloom is much more subtle and does not look hazy. If Clamp is disabled, then out of 0.1, 0.05 and 0.025 values I have tried, 0.05 looks most similar to the photo. Here is test render with and without bloom with the Sun in similar position like on the photo:
{F6280496}
{F6280494}
Using color probe 27x27 I compared lightness below the horizon under the Sun. In rendered by Eevee images lightness difference was 17. In case of the photos lightness difference in similar place was 11. I then compared leftmost spot (also below the horizon) and lightness difference was approximately 2 between two photos and 1 between rendered images. In other words, with these settings bloom effect is not too strong and is not too weak. Visually it may seem like decreasing bloom intensity may increase photorealism, but then bloom effect would be too localized even for the Sun.
Besides this single test, I tested in many other scenes as well, with and without the Sun, with different HDRIs, and as far as I can tell 0.05 intensity turned out to be good default - it produces bloom strong enough to be noticeable and not too hazy.
In Cycles shutter default value is 0.50, so for consistency set to 0.5 by default in Eevee too. Besides, 0.5 is typical standard for real cameras, and values higher than 0.5 usually are needed only if very strong motion blur is desired.
Here is summary of all changes:
Bloom Intensity: 0.8 > 0.05
Bloom Intensity UI range: 0-10 > 0-0.1
Bloom Clamp: 1.0 > 0.0 (disabled by default)
Bloom Clamp manual range: 0-1000 > 0-100000
Bloom Clamp UI range: 0-10 > 0-1000
Shutter: 1.0 > 0.5
This patch is related to the discussion in this thread, there are more examples of what bloom will look like with 0.05 intensity by me and others:
https://devtalk.blender.org/t/eevee-needs-to-have-physically-based-defaults/4700
Reviewers: fclem
Reviewed By: fclem
Subscribers: pablovazquez, billreynish, rboxman
Tags: #eevee
Differential Revision: https://developer.blender.org/D4212
|
|
Harden normals causes normal splitting, which will not give the
appearance expected due to autosmooth unless some edges are sharpened,
so this change fixes that. Also bevel tool will turn on autosmooth
if not already on if hardening normals.
|
|
Issue caused probably by typo
|
|
|
|
|
|
Logic to update child windows on workspace changes should simply ignore
temporary child windows. Users opened those for a specific purpose (i.e. edit
user preferences or show render result). Blender should not come in and
repurpose it.
|
|
Used wrong Loop variable in this case.
|
|
Small side effect is that area operators (toggle fullscreen/maximized, duplicate
area) are now displayed in RMB-menu. Makes sense anyway.
|
|
|
|
Need to use the 'use_partial_connect' option in island connect,
so changed signatures of various functions to pass that into and
then down from BM_mesh_intersect (making true for intersect, false
for boolean).
Then fix bm_face_split_edgenet_partial_connect to work when
input edges are not necessarily wire, but at least not in the
face they are being connected in. That caused generalization
of core BM_vert_separate_hflag_wire (which is only used in
this one place in all Blender).
|
|
|
|
loaded.
Stupid mistake in material reading code, thanks to Simon Wendsche (@BYOB) for the investigation and fix!
To be backported to 2.79a.
|
|
A comparison should have not just have been against an epsilon,
but relative to the edge length involved.
Thanks to mano-wii for patch on which this is based.
|
|
The loc one (shift-alt-G) was same as 'remove selected from active group'
action... Clear delta transform is not a common operation, so we can
live without a default shortcut for it.
Note that using same key (G) in same space for two completely different
kind of operations is probably a rather bad thing, nice topic for future
keymap work. ;)
Probably nice to have in 2.79a.
|
|
|
|
This reverts commit 1ad842d432ccacd1f822d7f2b8ff3c542d25e976.
|
|
|
|
|
|
We did not update them for really long time and the currently used
hashes are quite old and probably wouldn't work without manually
updating all submodules.
Not as if it's something totally crucial (we ask to update submodules
all the times and that's what `make update` does) but updating hashes
will save some cloning/checkout time.
|
|
This adds support for dropping a filepath on an open file-selector to set that path.
|
|
|
|
WM_file_read must support background mode already
since it can be called by Python scripts in background mode.
|
|
|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D1003
|
|
|
|
This commit contains:
- Subversion bump to 2.73
- Release cycle is set to "rc"
- Submodules are pointed to appropriate tag now
(addons contrib just points to the latest contrib repo)
- New shiny splash screen!
|
|
This ensures that the beams color does not darken along borders,
by using the last valid color of the ray as the border color (extending
colors in the direction of the source point).
|
|
Particle texture eval was not taking the actual texture space for orco/
generated textures into account at all.
|
|
Update submodules to v2.71-rc1, it got lost on re-tag leading to wrong addons
and translations used in RC1.
|
|
Differential Revision: https://developer.blender.org/D298
Allows users on Windows to enter UNC paths in the filebrowser and to link to .blend files on a UNC path. Functionality is limited still, we can't browse the network yet and have no support to check user rights so far.
What works:
- enter an UNC path in the file browser manually or via copy/paste
- navigation within the UNC share subfolders
- link to a file on a UNC share
What does not (yet) work:
- browse the network for computers and shares
- browse to a folder that requires entering user credentials
Contributors:
Rob McKay - original patch
Campbell Barton - style fixes
Reviewers:
Campbell Barton, Brecht van Lommel
|
|
NEVER use `git commit .` or stage submodules. Leave it to platform maintainers!
See [1] where you'll find few hooks which would help you preventing
accidental commit of submodules.
[1] http://wiki.blender.org/index.php/User:Nazg-gul/DevTools#Git_hooks
|
|
value was mixing operator result with an int/boolean.
|
|
- Addons and locales now points to v2.70-rc tag
- Also updated hashes for addons_contrib and scons
to make them up-to-date while i'm on updating this
hashes.
|
|
* Henyey-Greenstein scattering closure implementation.
* Rename transparent to absorption node and isotropic to scatter node.
* Volume density is folded into the closure weights.
* OSL support for volume closures and nodes.
* This commit has no user visible changes, there is no volume render code yet.
This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
|
|
|
|
|
|
|
|
correct with multiple render layers.
This case is somewhat weak, we now do a few more checks on sync than I would
like, but it's not too bad.
|
|
also check a similar case for bisect
|
|
commit b8b7180760b7c57f15b9930c29207febcf5fefb3
Author: Bastien Montagne <montagne29@wanadoo.fr>
Date: Thu Nov 21 16:31:16 2013 +0100
Code cleanup: replace "LISTLABEL" button type by an "UI_BUT_LIST_ITEM" button flag.
Summary:
Rationals:
I) I was never that happy to have a full button type just to set custom colors to labels inside listitems!
II) If we use (as planned) TEX buttons instead of labels to allow listitems click-rename, I'd like to be able to use listitems' theme color here as well, much easier witha flag than adding yet another button type!
Note: related to D8
Reviewers: brecht
Differential Revision: http://developer.blender.org/D25
|
|
Uses relative paths to repositories, so this is expected
to work fine for any protocol we support (git, ssh and http).
Uses ignore=all for all the submodules, so updating them
to latest remote hash does not tags blender repository
as changes. But it is still possible to make changes to
submodules and commit them from their path.
|