| Age | Commit message (Collapse) | Author |
|---|
|
- lamp
- camera
- font
- empty & effector
Also fix inconsistency with apply transform
(modified shape-keys for meshes but not curve/lattice)
|
|
BKE_mball_basis_find()
BKE_mball_basis_find() was making a bunch of string manipulations for all MBall objects
(including duplis), and then making a (broken!) check to do nothing in case of duplis mball!
Now it makes correct check in early stage.
|
|
viewport preview.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously this only worked for some datablocks relevant to rendering, now it
can be used to detect if any type of datablock was added or removed (but not
yet to detect if it was modified, we need many more depsgraph tags for that).
Most of the changes are some function parameter changes, the important parts
are the DAG_id_type_tag calls.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D195
|
|
This incorrectly use abs(), that's for integers, not floats.
|
|
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
|
|
rename change/is_change/is_changed/modified -> changed
also use bools over int/short/char and once accidental float.
|
|
|
|
G.is_rendering
|
|
--
svn merge -r58150:58151 ^/branches/soc-2013-depsgraph_mt
|
|
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
|
|
- BKE_mball_center_median(), didn't work.
- clip_refresh was removing handlers from wrong space.
- new_modifier, replace strcpy with BLI_strncpy
|
|
crashes Blender
Issue was caused by size influence affecting on object's matrix, which
is nice by it's own. But mball code was using ob->size to check whether
it's zero-sized object or not, but then was using ob->obmat to scale
the meta elements.
This lead to situation when zero-sized elements were trying to tessellate,
which is for sure a really bad idea.
|
|
This time issue was caused by static variables used in
BKE_scene_base_iter_next function.
Change is not so much ultimate actually, but didn't
find more clear solution for now. So the changes are:
- Wrap almost all the static variables into own context-
like structure, which is owned by the callee function
and getting passed to the iteration function.
- Recursion detection wasn't possible with such approach,
so recursion detection still uses static in_next_object
variable, but which is now stored in thread local
storage (TLS, or thread variable if this names are more
clear for you).
This makes code thread-safe, but for sure final solution
shall be completely different. Ideally, dependency graph
shall be possible to answer on question "which object is
a motherball for this metaball". This will avoid iterating
via all the bases, objects and duplis just to get needed
motherball.
Further, metaball evaluation ideally will use the same
kind of depsgraph filtering, which will get result for
question like "which objects belongs to this group of
metaballs".
But this ideal things are to be solved in Joshua's and
mind GSoC projects.
Tested on linux (gcc and clang) and windows (msvc2008),
hopefully no compilation error will happen.
Thanks to Brecht for reviewing the change and getting
feedback for other possible ways we've dicussed!
|
|
commit was 2x too large too).
|
|
|
|
of the active object in the 3D view. This was due to sharing a global G.moving
flag to indicate that transform is active, now it's only set per transform data
type so different editors don't influence each other.
|
|
Moved all the static variables into a PROCESS
structure which is now passing all over to where
static variables used to be used.
There's still one static variable which is
cubetable, but it's being initialized once
and then used read-only. Maybe we'll need
to move cubetable initialization to blender
startup, but that could wait a bit for now.
For users it means BI rendered viewport
wouldn't crash when using metaballs.
--
svn merge -r57515:57516 ^/branches/soc-2013-depsgraph_mt
|
|
- mult_m4_m4m4 -> mul_m4_m4m4
- mult_m3_m3m4 -> mul_m3_m3m4
these temporary names were used to avoid problems when argument order was switched.
|
|
* Also fixed some more cases of "more then" -> "more than".
|
|
var names.
|
|
|
|
|
|
|
|
|
|
|
|
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
|
|
|
|
now blenlib/BLI doesn't depend on any blenkern/BKE functions,
there are still some bad level includes but these are only to access G.background and the blender version define.
|
|
|
|
|
|
hair_velocity_smoothing()
and a unlikely NULL pointer dereference in unlink_material_cb().
|
|
the mouse about to see the result).
also remove print from last commit.
|
|
utility metaball functions to (de)select all.
|
|
|
|
|
|
types to the end of the switch statement when evaluating metaballs.
|
|
|
|
from reading code what was defined in the function.
|
|
|
|
and just use float[3] instead.
|
|
|
|
|
