| Age | Commit message (Collapse) | Author |
|---|
|
This was already mixed a bit, but the dot belongs there.
|
|
|
|
We might remove this again in the future, but for testing purposes
during the release cycle, this will be useful.
The setting defaults to QBVH, and can be found in the Performance panel.
|
|
This is harmless for now because tail of the node is zero in there, but better
to fix it early so in the case of extending BVH nodes this code doesn't give
issues.
|
|
This commit enables QBVH optimization structure automatically if rendering
with CPU and SSE2 support is detected.
This brings render time of agent shot back to the speed it used to be before
the watertight intersections commit, single koro and sponza scenes are about
7% faster here.
|
|
This commit implements traversal for QBVH tree, which is based on the old loop
code for traversal itself and Embree for node intersection.
This commit also does some changes to the loop inspired by Embree:
- Visibility flags are only checked for primitives.
Doing visibility check for every node cost quite reasonable amount of time
and in most cases those checks are true-positive.
Other idea here would be to do visibility checks for leaf nodes only, but
this would need to be investigated further.
- For minimum hair width we extend all the nodes' bounding boxes.
Again doing curve visibility check is quite costly for each of the nodes and
those checks returns truth for most of the hierarchy anyway.
There are number of possible optimization still, but current state is good
enough in terms it makes rendering faster a little bit after recent watertight
commit.
Currently QBVH is only implemented for CPU with SSE2 support at least. All
other devices would need to be supported later (if that'd make sense from
performance point of view).
The code is enabled for compilation in kernel. but blender wouldn't use it
still.
|
|
The idea is to make sure those childs would never be intersected with a ray
in order to make it so kernel never worries about number of child nodes.
|
|
Previously every BVH traversal file was defining macro to check which features
should be compiled in, now this macro is defined in the parent header.
|
|
Basic idea is to allow multiple implementation per feature-set, meaning this
commit tries to make it easier to hook new algorithms for BVH traversal.
|
|
Most of them are not currently used but are essential for the further work.
- CPU kernels with SSE2 support will now have sse3b, sse3f and sse3i
- Added templatedversions of min4, max4 which are handy to use with register
variables.
- Added util_swap function which gets arguments by pointers.
So hopefully it'll be a portable version of std::swap.
|
|
Using this paper: Sven Woop, Watertight Ray/Triangle Intersection
http://jcgt.org/published/0002/01/05/paper.pdf
This change is expected to address quite reasonable amount of reports from the
bug tracker, plus it might help reducing the noise in some scenes.
Unfortunately, it's currently about 7% slower than the previous solution with
pre-computed triangle plane equations, but maybe with some smart tweaks to the
code (tests reshuffle, using SIMD in a nice way or so) we can avoid the speed
regression.
But perhaps smartest thing to do here would be to change single triangle / ray
intersection with multiple triangles / ray intersections. That's how Embree does
this and it's watertight single ray intersection is not any faster that this.
Currently only triangle intersection is modified accordingly to the paper, in
the future we would also want to modify the node / ray intersection.
Reviewers: brecht, juicyfruit
Subscribers: dingto, ton
Differential Revision: https://developer.blender.org/D819
|
|
The idea is to store visibility flags for leaf nodes only since visibility check
for inner nodes costs too much for QBVH hence it is not optimal to perform.
Leaf QBVH nodes have plenty of space to store all sort of flags, so we can make
nodes one element smaller, saving noticeable amount of memory.
|
|
|
|
Previously offsets were calculated based on the BVH node size,
which is wrong and real PITA in cases when some extra data is
to be added into (or removed from) the node.
Now use offsets which are not calculated form the node size.
|
|
|
|
This solves quite an over-allocation in BVH instances packing code,
unfortunately, it's not a magic bullet to solve memory bump caused
by the recent QBVH changes.
For that we'll likely need to decouple storage for leaf and inner
nodes. However, it's not really clear for now if it's something
important since that'd still be just a fraction of memory comparing
to all the hi-res textures.
|
|
Title says it all, quite straightforward implementation.
Would only mention that there's a bit of code duplication around packing node
into pack.nodes. Trying to de-duplicate it ends up in quite hairy code (like
functions with loads of arguments some of which could be NULL in certain
circumstances etc..). Leaving solving this duplication for later.
|
|
Before all the nodes were counted and allocated, leading to situations when
bunch of allocated memory is not used because reasonable amount of nodes are
simply ignored.
|
|
Visibility flags are set to all visibility anyway, So there was no reason
to perform that test.
TODO: We need to investigate if having primitive intersection functions
which doesn't do visibility check gives any speedup here as well.
|
|
This way extending intersection routines with some pre-calculation step wouldn't
explode the single file size, hopefully keeping them all in a nice maintainable
state.
|
|
|
|
|
|
|
|
|
|
More like a feature request but was simple to support.
|
|
|
|
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!
|
|
side/front/top ortho views would no more adapt their snapping unit to zoom factor.
This code would need slightly more refactor actually, but this will be for after release!
|
|
|
|
Origins of this issue goes back to T33402, where compo wasn't sure what kind
of image it is working with (compo should know if it's multilayer or regular
image).
Now we only reload images when dar-dropping from outside of blender.
|
|
mesh
Curve and array modifiers requires curve path to be evaluated, dependency graph
will make sure that curve eval would create such a path, but if curve was already
evaluated we might miss path.
So what we do now is: if path was not calculated for target curve we tag it for
update.
|
|
|
|
|
|
This only happened for SCons builds and caused by pure human stupidnes.
|
|
* correct API convention: in rB071ec918f4cd gp_draw_data drew mulitple data blocks, I added gp_draw_data_all which now calles gp_draw_data multiple times (if needed). This follows our normal convention, e.g. see UI_panel_category_draw_all
* Draw scene data first, users may expect it like this
Points raised by @aligorith, thanks for this!
|
|
For now, do as RNA material update functions - tag object for update too.
|
|
D937 with minor edits (whitespace only)
@aligorith, I double checked everything runs smoothly, blame me if I missed something ;). Sorry for just taking the initiative and committing without talking to you, but I wasn't able to catch you the last days. This should be fixed before the release IMHO, but I don't think it's important enough to be committed during BCon5, so sorry again, but hopefully everything is okay :)
|
|
parent object.
So 'advanced' parenting like e.g. bones or vertices need further processing
to get a real parent-relative matrix...
|
|
|
|
This is a convenience makefile only,
files if they exist by accident shouldn't ever be used.
|
|
x
|
|
|
|
deletion of baked caches.
This happens when objects use file names with matching prefixes:
"CubeX" -> not baked
"CubeXYZ" -> baked
The first objects cache should be discarded up to the current frame on
file load, but the second should be left intact. But because the cache
file names for both use the same prefix as well (based on hex name
representation) they both match the "CubeX" name and get discarded.
Adding the underscore terminator solves this issue, because it is never
part of the hex file name string.
WARNING: this solution does not work with custom names for point caches.
This feature is pretty much broken, users have to ensure their names
are unique themselves. Due to the possibility of underscores in names
and the ambiguity of point cache suffixes there is no reliable way to
encode filenames in that case.
|
|
This is UV barycentric interpolation failing for triangles where vertices are
colinear in screen space. To fix this, we detect this early on so we do the
interpolation on edges instead of triangles.
Such triangles will never be painted on unless we have occlusion and culling
off (since, arguably they are self occluded and almost back-facing).
The code still does not fill the whole area but this can be checked separately.
|
|
Note 'same' values are kept for now, even though it was probably meant the
other way around, it's safer to keep current behavior for now.
|
|
This fixes both transform snapping in persp views, and 'snap cursor to grid' feature.
Was only really visible with Imperial units.
|
|
This directory does not exist even.
|
|
|
|
It should now fill the whole mesh with color even if parts of it are
outside the screen - still need to be in fron of the camera though.
Thanks @Campbell for the trick :)
|
|
Thanks to @nesse for the fix
|
