| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
D1344 with edits
|
|
|
|
Was harmless but confused some sanity checks, also kinda makes sense
to be more verbose about what's going on there.
|
|
|
|
|
|
|
|
It's quite tricky to see if the driver actually depends on time or not,
so currently used approach when we'll be doing some extra updates.
This seems to correspond to how old depsgraph was dealing with this.
|
|
|
|
|
|
|
|
|
|
Its out of date, better use the wiki building docs.
|
|
|
|
This ensures that vertices are grid-aligned while transforming,
instead of just snapping the input values for translate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An attempt to treat @sebastian_k's blood pressure a bit.
|
|
Performance tests now have their own CMake macro, which ensures they do not get
added to ctest list, so we do not have to bother about them anymore, and can always
build them (when GTests are enabled, of course).
|
|
'make test')...
|
|
|
|
This is essential for video projection, and the alternative until now was to manually change the projection matrix via Python.
( http://www.blender.org/manual/game_engine/camera/introduction.html#camera-lens-shift
- this page will be removed as soon as I commit this)
Also this is working for perspective and orto cameras BUT if the sensor is not AUTO it will only look correct in blenderplayer (this is an unrelated bug, but just in case someone runs into it while testing this, now you know why you got the issue).
Kudos for the BlenderVR project for supporting this feature development.
Differential Revision: https://developer.blender.org/D1379
|
|
Parallel rendering was not working.
The idea of having parallel convergence mode to render as parallel but
visualize as off-axis was good, but it was leading to some complications
in the code.
I think it's more clear to the user if parallel looks and render as
parallel, and if she wants to pre-visualize the converged planes, simply
temporarily set the camera to off-axis.
|
|
|
|
|
|
The issue was caused by some changes made to msgfmt which were needed to make
modified (cleaned-up, stripped-comments messages) working.
Unfortunately that fix was merged into the release branch, so this fix is to
be ported there as well and verified against rc1 translations.
|
|
'ar->winy' may not be initialized, making regions zoom in (past limits)
and attempt to draw very large text (~10x10k size characters), often crashing.
Fix isn't complete since it only corrects factory startup.
|
|
|
|
|
|
Previous idea behind having vector during building and array for actual storage
was needed in order to minimize amount of re-allocations happening during the
build, but it lead to double memory overhead used by those arrays at the vector
to array conversion stage.
Issue with such approach was that for BVH without spatial split size of arrays
is known in advance and it never changes, which made vector to array conversion
totally redundant.
Also after testing with several rather complex from spatial split scenes (such
as trees) it seems even conservative approach of reallocation (when we perform
re-allocation when leaf does not fit into the memory) doesn't give measurable
difference in time.
This makes it so we can switch to array, which will avoid unneeded memory
re-allocations when spatial split is disabled without harming other cases.
it's a bit difficult to measure exact benefit of this change on our production
files here, but depending on the scene it might give quite reasonable memory
save.
|
|
memory access
|
|
|
|
Angular velocity clamping was missing from the BGE. It is implemented
similarly to the linear velocity clamping. It is needed to be able to
drive physical simulations of systems that have a limited rotational
speed.
Reviewed by: campbellbarton, panzergame, ton
Differential Revision: https://developer.blender.org/D1365
|
|
This patch uses the Bullet "internal tick callback" functionality to
ensure that velocity clamping is performed after every physics update.
This makes a difference when physics subticks > 1, as in that case the
too-high velocity could have impacted the simulation.
This patch follows the examples at [1] and [2]; the latter example
also explains that the way we limit velocity in the BGE (before this
patch) is wrong.
[1] http://bulletphysics.org/mediawiki-1.5.8/index.php/Simulation_Tick_Callbacks
[2] http://www.bulletphysics.org/mediawiki-1.5.8/index.php/Code_Snippets#I_want_to_cap_the_speed_of_my_spaceship;
Reviewed by: panzergame
Differential Revision: https://developer.blender.org/D1364
|
|
|
|
lighting.
In case scene lighting would only have non-shadow light source, shadow intensity
would remain to 'pitch black'...
|
|
This really should have been finalized as a design task first,
there are too many open topics on how it should work.
|
|
Simply backport small part of work from asset-experiments here (using double and
adding tera-bytes unit), looks like off_t is not always 64bits even on a 64bit OS...
|
|
This way we solve possible issues caused by regular allocator not being aware of
some classes preferring 16 bytes alignment needed for SSE to work properly. This
caused random crashes during rendering.
Now we always use aligned allocation in GuardedAllocator which shouldn't be any
measurable performance impact and the code is only used by developers after
defining special symbol, so there is no impact on release builds at all.
|
|
Enable debug output in debug contexts for gl 4.3+
|
|
it is the same issue as described in the previous commit, original changes
in this area were wrong and only worked on a bugger optimus driver which
simply appeared to work by co-incident and in fact used wrong device..
|
|
It was annoying copy-paste happened across OpenCL device constructor, device
enumeration and split kernel checks. Now those areas are using an utility
function which returns pairs of platform and device IDs for devices which are
supported by Cycles and enumeration is happening inside that list.
This makes it so filtering is happening in a single place, so there's no need
to keep 3 different functions in sync.
This commit also fixes a bug with wrong enumeration of devices caused by recent
fixes. Those fixes were in fact wrong and only happened to appear to be working
on laptop with optimus card on Linux. Root of those issues is in fact in bad
Linux driver for optimus cards.
|
|
|
|
This commit makes it so light which has zero energy or doesn't has
emission shader at all is being ignored by the path tracing.
|
