Iterate over invisible objects too, so lamps can still lit the scene.
Also, now you can use a collection to set an object to invisible, not
only to visible.
For example:
Scene > Master collection > bedroom > furniture
Scene > View Layer > bedroom (visible)
> furniture (invisible)
The View Layer has two linked collections, bedroom and furniture.
This setup will make the furniture collection invisible.
Note: Unlike what was suggested on D2849, this does not make collection
visibility influence camera visibility. I will keep this as a separate
patch.
Reviewers: sergey
Subscribers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D2849
It doesn't seem that useful in practice, was mostly added to match some
other renderers but also seems to be causing user confusing and accidental
long render times. So let's just keep the UI simple and remove this.
Differential Revision: https://developer.blender.org/D2768
The issue was caused by usage of address of dupli-object (which will vary
from iteration process to iteration process) as something denoting whether
we've got the data synchronized to Cycles or not.
For now solved by using address of original object (the one DupliObject
points to) as a pointer for the map.
Need to do more thoughts about this.
This commit extends the work from Dalai made around scene iterators to
support iterating into objects from dupli-lists.
Changes can be summarized as:
- Depsgraph iterator will hold pointer to an object which created current
duplilist. It is available via `dupli_parent` field of the iterator.
It is only set when duplilist is not NULL and guaranteed to be NULL
for all other cases.
- Introduced new depsgraph.duplis collection which gives a more extended
information about depsgraph iterator. It is basically a collection on top
of DEGObjectsIteratorData.
It is used to provide access to such data as persistent ID, generated space
and so on.
Things which still needs to be done/finished/clarified:
- Need to introduce some sort of `is_instance` boolean property which will
indicate Python and C++ RNA that we are inside of dupli-list.
- Introduce a way to skip dupli-list for particular objects.
So, for example, if we are culling object due to distance we can skip all
objects it was duplicating.
- Introduce a way to skip particular duplicators.
So we can skip iterating into particle system.
- Introduce some cleaner API for C side of operators to access all data such as
persistent ID and friends.
This way we wouldn't need de-reference iterator and could keep access to such
data really abstract. Who knows how we'll be storing internal state of the
operator in the future.
While there is still stuff to do, current state works and moves us in the proper
direction.
Previously the logic was different for duplis and regular objects: regular objects
were using render visibility when Render Layer option is enabled which duplis were
always using viewport visibility when rendering from the viewport.
This was quite confusing because caused different results in viewport and render
when artists were expecting them to match 1:1.
Object Info node can be useful to give some variation to a single material assigned to multiple instances. This patch adds support for Viewport and BI.
{F499530}
Example: {F499528}
Reviewers: merwin, brecht, dfelinto
Reviewed By: brecht
Subscribers: duarteframos, fclem, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D2425
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
It uses an idea of accumulating all possible light reachable across the
light path (without taking shadow blocked into account) and accumulating
total shaded light across the path. Dividing second figure by first one
seems to be giving good estimate of the shadow.
In fact, to my knowledge, it's something really similar to what is
happening in the denoising branch, so we are aligned here which is good.
The workflow is following:
- Create an object which matches real-life object on which shadow is
to be catched.
- Create approximate similar material on that object.
This is needed to make indirect light properly affecting CG objects
in the scene.
- Mark object as Shadow Catcher in the Object properties.
Ideally, after doing that it will be possible to render the image and
simply alpha-over it on top of real footage.
This can be used together with camera culling to keep nearby objects visible in
reflections, using a minimum distance within which objects are visible. It is
also useful to cull small objects far from the camera.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2332
When using the Normal output of the Texture Coordinate node on Point and Spot lamps, the coordinates now depend on the rotation of the lamp.
On Area lamps, the Parametric output of the Geometry node now returns UV coordinates on the area lamp.
Credit for the Area lamp part goes to Stefan Werner (from D1995).
Another issue with the modified particle motion blur fix: since
pre and post are used as validity markers, they must be set even
if there is no actual motion, like the original bool flags were.
Otherwise an object starting to move or stopping is interpreted
as having invalid blur data and hidden.
Currently cycles cannot correctly render motion blur for objects that appear or
disappear during the shutter window. Until that can be fixed properly, it may be
better to hide such particles rather than let them render as if they were
stationary for half of the frame.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2125
At some point the idea was that we could have an optimization where we could
render multiple render layers without re-exporting the scene, by just updating
the layer bits. We are not doing this now and in practice with the available
render layer control like exclude layers it's not always possible anyway.
This makes it easier to support an arbitrary number of layers in the future
(hopefully this summer), and frees up some useful bits in the kernel.
Reviewed By: sergey, dingto
Differential Revision: https://developer.blender.org/D2020
This way we avoid passing structures which could be up to
few hundred bytes by value to the utility functions.
Ideally we'll also have to add `const` qualifier in majority
of the calls, but C++ RNA does not allow us to do that because
it does not know if some function modifies contents or not.
This adds an option to control at what time relative to the current frame
the shutter is fully opened. Supported options are:
- Shutter is starting to open at the current frame
- Shutter is fully opened at the current frame
- Shutter is fully closed at the current frame
Custom shutter time offset is possible, same as custom curve for shutter
openness but those are considered nice things to have rather than something
crucial.
Reviewers: juicyfruit, dingto
Subscribers: venomgfx, hjalti
Differential Revision: https://developer.blender.org/D1380
Title says it all, based on feedback of artists from gooseberry team.
This mainly affects cases when going to a local view from layers setup
when some lamps were on invisible layers. Those lights are no longer
becoming visible to the object in local view.
Reviewers: brecht, juicyfruit, dingto
Reviewed By: juicyfruit, dingto
Subscribers: maxon, eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1326
Works totally similar to camera motion blur and majority of the changes are
related on just passing extra arguments to sync() functions.
Couple of things still to look into:
- Motion pass will not include motion caused by the zoom.
- Only perspective cameras are supported currently.
- Motion is being interpolated on projected coordinates, which might give
different results from constructing projection matrix from interpolated
field of view.
This could be good enough for us, but we need to consider improving this
at some point.
Reviewers: juicyfruit, dingto
Reviewed By: dingto
Differential Revision: https://developer.blender.org/D1383
The idea is to give artists a simplier way to control memory usage in such
scenes as grass fields by doing automatic object culling based on whether
object is visible in the frame or not.
This is controlled on per-object level. In order to use this option few steps
are required:
- Enable Simplify in scene settings
- Enable Camera Cull option in the Simplify panel
- Set camera cull margin (measured in relative value to the render resolution)
This setting is used to avoid possible flickering caused by changes in shadow
which are cast by objects outside of the frame.
- Enable Camera Cull for objects which are desired to be culled
(object culling option could be found in Option panel in object buttons).
There is still room for improvements, but this worked quite well during
Gooseberry open movie project, so think it's useful feature even in it's current
non-ideal state.
When using MIS, the world is treated as regular light and in this case
we can now also limit the maximum amount of bounces, the background light
will contribute to the scene.
This can improve performance in some cases, where it's e.g. sufficient to
only have a contribution on first 1-2 bounces.
Examples can be found in the differential.
Differential revision: https://developer.blender.org/D1399
The idea is to make it possible to control linked duplicated objects motion
blur from the scene file without need to do overrides on the linked object
settings. Currently only supported for dupligroup duplication and all now
if duplicator object has motion blur disabled then it'll be inherited into
all the duplicated objects.
There should be no regressions/changes in look of existing files because
objects do have motion blur enabled by default.
This patch adds support for light portals: objects that help sampling the
environment light, therefore improving convergence. Using them tor other
lights in a unidirectional pathtracer is virtually useless.
The sampling is done with the area-preserving code already used for area lamps.
MIS is used both for combination of different portals and for combining portal-
and envmap-sampling.
The direction of portals is considered, they aren't used if the sampling point
is behind them.
Reviewers: sergey, dingto, #cycles
Reviewed By: dingto, #cycles
Subscribers: Lapineige, nutel, jtheninja, dsisco11, januz, vitorbalbio, candreacchio, TARDISMaker, lichtwerk, ace_dragon, marcog, mib2berlin, Tunge, lopataasdf, lordodin, sergey, dingto
Differential Revision: https://developer.blender.org/D1133
This inconsistency drove me totally crazy, it's really confusing
when it's inconsistent especially when you work on both Cycles and
Blender sides.
Shouldn;t cause merge PITA, it's whitespace changes only, Git should
be able to merge it nicely.
Seems the parent check didn't go deep enough and only checked single parent.
Now it checks the chain of parents which seems to be correct but requires
much more intense testing.
material is applied to multiple Dupli instances of an object.
One of the random_id initialization lines for cycles objects slipped
into the basic update part in this commit:
rBb98ff5cb5b2c14c33b16e3b129e1e08810e90a6c
This would constantly re-shuffle the random_id ...
Fix T39286: Display percentage ignored in Cycles viewport.
The threaded depsgraph update changes included a cleanup of the global
is_rendering flag, which was replaced by a general EvalContext being
passed to dupli functions.
Problem is that the global flag was true for viewport duplis before
(ugly hack), which was used as a check for generating dupli orco/UV from
mesh data layers. The new flag is stricter and only true for actual
renders, which disables these attributes and breaks the Cycles
Texture Coordinates and UVMap nodes.
The solution is to extend the simple for_render boolean to an enum:
* VIEWPORT: OpenGL viewport drawing (dupli tex coords omitted)
* PREVIEW: Viewport preview render (simplified modifiers)
* RENDER: Full render with all details and attributes
There are still some areas that need to be examined, in particular
modifiers seem to totally ignore the EvaluationContext!
Instead they generally execute without render params from the depsgraph
(BKE_object_handle_update_ex) and are built with render settings
explicitly.
Differential Revision: https://developer.blender.org/D613
