| Age | Commit message (Collapse) | Author |
|---|
|
There was possible race condition in the point density sampling caused
by access to the same data in particle system from sampling thread and
sampling initialization.
Could have happened when two different point density textures were using
same particle system
|
|
This commit implements point density texture for Cycles shading nodes.
It's done via creating voxel texture at shader compilation time, Not
totally memory efficient, but avoids adding sampling code to kernel
(which keeps render time as low as possible), In the future this will
be compensated by using OpenVDB for more efficient storage of sparse
volume data.
Sampling of the voxel texture is happening at blender side and the
same code is used as for Blender Internal's renderer.
This texture is controlled by only object, particle system and radius.
Linear falloff is used and there's no turbulence. This is because
falloff is expected to happen using Curve Mapping node. Turbulence
will be done as a distortion on the input coordinate. It's already
possible to fake it using nose textures and in the future we can add
more proper turbulence distortion node, which then could also be used
for 2D texture mapping.
Particle color support is done by Lukas, thanks!
|
|
Not currently used, it's a preparation for the further work.
Should not be functional changes.
|
|
|
|
With this patch "Particle Info" node from Cycles works in GLSL and BI
Alexander (Blend4Web Team)
Reviewers: psy-fi
Note: moved particle info to object render instance instead of
shadeinput during review - Antony.
Differential Revision: https://developer.blender.org/D1313
|
|
|
|
|
|
that both use a UV mapped material for render
Not sure it's totally correct solution, but seems reasonable because it's
possible dmcache is set to ISCHILD.
Someone more familiar with the particles code might want to revisit this :)
|
|
This issue was introduced with the wrong fix I committed for dither (rB56ca7f34)
Which also means T45237 has to be re-open
|
|
|
|
Add option to render strip metadata to final result, bypassing current
scene metadata.
|
|
|
|
|
|
|
|
|
|
lighting.
In case scene lighting would only have non-shadow light source, shadow intensity
would remain to 'pitch black'...
|
|
|
|
compiled without OpenEXR.
Seriously!!!
Also, fix a potential buffer overrun here.
This should be backported to final release.
|
|
|
|
Quite straightforward implementation -- all the conversion magic is
happening in IMB_exr_write_channels() and remained changes are only
needed to pass information whether channels is to be converted to
half float or not.
Regular file output will use full-float for Z pass, which matches
behavior of the single layer EXR files. But when saving happens
with File Output node then all the passes are respecting half float
settings because it's not possible to distinguish whether we're
saving Z pass or not.
Reviewers: juicyfruit, campbellbarton
Reviewed By: campbellbarton
Subscribers: maxon, effstops, fsiddi
Differential Revision: https://developer.blender.org/D1353
|
|
Save Buffers option is enabled"
This reverts commit ab417f31f403d74a76fb51fbd6e2aa3f706e15f1.
This workaround caused serious memory corruption issues which is not really acceptable
for the release. We'll be likely sticking to a more limited release when using freestyle
with saved buffers for until proper solution is implemented.
Conflicts:
source/blender/render/intern/source/pipeline.c
|
|
The issue was caused by render pipeline freeing render parts prior to finishing
exr file writing which resulted in unfinished parts not being written into the
file by save_empty_result_tiles().
As a temporary solution we do explicitly write unfinished parts as empty tiles
to the exr file prior to freeing parts.
Not ideal solution, but should work for the release.
|
|
|
|
|
|
Without this extra flush order of stat prints is undefined in the
output. which makes it rather tricky to write custom output in a
reliable way.
|
|
ray intersection
TODO: We might want to refactor debug passes into PASS_DEBUG and some
debug_type (similar to Blender's side passes) to avoid issue of running
out of bits.
|
|
This way it is now possible to select which exact debug pass is to be used
by the render engine. Accessible from the Passes panel.
Currently it could only be one debug pass, in the future we can make menus
and image users smarter and support multiple passes of the same type.
|
|
Quite straightforward implementation, but still needs some work for the split
kernel. Includes both regular and split kernel implementation for that.
The pass is not exposed to the interface yet because it's currently not really
easy to have same pass listed in the menu multiple times.
|
|
this as "Multi-View", not "Multiview"
|
|
Buffers option is enabled
For now we solve this for non-multiview renders by merging exr file back into
full render result prior to rendering freestyle strokes. Multiview case is
still to be supported tho.
|
|
|
|
Applying saturation > 1.0 in HSV space easily leads to negative values in RGB space,
so we have to clamp again...
|
|
|
|
|
|
T44869.
There are a couple of issues here:
* Code repeatedly calculated center of ready rendered parts even though
they would not change while the operation was done.
* Code would calculate distance of tiles from center multiple times
* Code would traverse all items, even the ones already sorted
* Traversal used linked lists which is quite slow.
Mitigated these by doing one pass for the center, a second to calculate
distances and a qsort at the end.
Should result in O (n * (log n + 2)) instead of O (n * (n * 2))
complexity, plus the number of repeated operations is much less as well.
|
|
|
|
|
|
This will fix exporting of metadata and importing for imbufs, but image
editor will not display these metadata since multilayer gets converted
to renderresult, which does not support metadata display yet.
This commit is more meant for external image editors/viewers.
|
|
viewport display
|
|
RE_RenderLayerGetPass
|
|
|
|
In pipeline.c the function add_freestyle() was supposed to be called once
per frame, but after the Multi-view merge the function are called as many
as the number of views. There were however a few Freestyle parameters
that have to be initialized per frame, and initializing one of the
parameters for each view was causing double freeing of allocated memory
which was enough to result in a crash.
|
|
This fixes nothing at the moment, but better safe than sorry since there
are still a few strange multiview issues around.
|
|
(making the duplicate code more like the original one)
|
|
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
|
|
|
|
D1188 by @a.romanov
|
|
multiview.
|
|
Moral of the story: Make sure that size_t is used whenever pointer
arithmetic is involved. For images, that basically means whenever any
squared dimensions are involved. Casting an operand to size_t early in
the operation is usually sufficient to force the entire operation to
size_t.
There might still be places lurking where we don't support this
correctly. This has been tested with render pipeline, quite a few image
functions (meaning we can paint on such images now, albeit somewhat
slowly ;) ) and export to jpeg. Too many places in code to check so I
guess we'll be handling cases as they come.
Don't try this at home unless you have an immense ammount of RAM.
First GPixel render of suzanne in the multiverse can be found here:
http://download.blender.org/demo/test/suzanne-billion-pixel.jpg
Can be viewed from blender (takes about 3.3 GB after loading but may
take more during loading so 8GB might be more safe to try this).
|
|
Bug introduced in f8540d7fd5a47bc9d1d676d5aaaa0de379c71637
|
