archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
1b5e3e1c019e5209b557f6699902d275b9bc67aa
blender-archive/source/blender/blenkernel/intern/object_dupli.c

1306 lines
36 KiB
C
Raw Normal View History

Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/*
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
* ***** END GPL LICENSE BLOCK *****
*/
/** \file blender/blenkernel/intern/object_dupli.c
* \ingroup bke
*/
Fix T38306: dupliframes causing viewport render to continually restart. Evaluating the animation is causing the object to get tagged as changed, but in this case it's not a permanent change so no one should be notified. Also found a case where the persistent ID for duplis wasn't unique, fixed that as well.
2014-01-21 21:01:12 +01:00
#include <limits.h>
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
#include <stdlib.h>
#include <stddef.h>
#include "MEM_guardedalloc.h"
#include "BLI_listbase.h"
#include "BLI_string_utf8.h"
#include "BLI_math.h"
#include "BLI_rand.h"
#include "DNA_anim_types.h"
#include "DNA_group_types.h"
#include "DNA_mesh_types.h"
#include "DNA_scene_types.h"
#include "DNA_vfont_types.h"
#include "BKE_animsys.h"
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
#include "BKE_collection.h"
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
#include "BKE_DerivedMesh.h"
#include "BKE_font.h"
#include "BKE_global.h"
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
#include "BKE_idprop.h"
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
#include "BKE_lattice.h"
#include "BKE_main.h"
#include "BKE_mesh.h"
Moved function declarations from BKE_DerivedMesh.h to BKE_mesh_runtime.h The function definitions still reside in DerivedMesh.c. Once we're done porting all the DerivedMesh use to Mesh, we'll move the still-relevant functions to mesh_runtime.c. This move is now cumbersome due to shared statically-declared utility functions in DerivedMesh.c
2018-06-05 16:58:08 +02:00
#include "BKE_mesh_runtime.h"
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
#include "BKE_object.h"
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
#include "BKE_particle.h"
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
#include "BKE_scene.h"
#include "BKE_editmesh.h"
#include "BKE_anim.h"
Depsgraph: More type definitions to new depsgraph header
2017-04-06 15:37:46 +02:00
#include "DEG_depsgraph.h"
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
#include "DEG_depsgraph_query.h"
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
#include "BLI_strict_flags.h"
Object Info node support for GLSL mode and the internal render 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
2017-04-14 18:13:44 +03:00
#include "BLI_hash.h"
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* Dupli-Geometry */
typedef struct DupliContext {
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
Depsgraph *depsgraph;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
Collection *collection; /* XXX child objects are selected from this group if set, could be nicer */
Object Mode: remove Scene.obedit Add ED_screen_window_find, BKE_workspace_edit_object
2018-02-13 20:35:29 +11:00
Object *obedit; /* Only to check if the object is in edit-mode. */
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Scene *scene;
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
ViewLayer *view_layer;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Object *object;
float space_mat[4][4];
int persistent_id[MAX_DUPLI_RECUR];
int level;
const struct DupliGenerator *gen;
/* result containers */
ListBase *duplilist; /* legacy doubly-linked list */
} DupliContext;
typedef struct DupliGenerator {
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
short type; /* dupli type */
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
void (*make_duplis)(const DupliContext *ctx);
} DupliGenerator;
static const DupliGenerator *get_dupli_generator(const DupliContext *ctx);
/* create initial context for root object */
Cleanup: Moar G.main removal of Hell. This commit actually adds some G.main... but at much, much higher level than the ones it removes, so should still be better ;)
2018-06-11 12:14:18 +02:00
static void init_context(
Merge branch 'master' into blender2.8 Conflicts: intern/cycles/blender/blender_object.cpp source/blender/alembic/intern/abc_exporter.cc source/blender/alembic/intern/abc_mball.cc source/blender/alembic/intern/abc_mball.h source/blender/blenkernel/BKE_anim.h source/blender/blenkernel/BKE_displist.h source/blender/blenkernel/BKE_dynamicpaint.h source/blender/blenkernel/BKE_group.h source/blender/blenkernel/BKE_mball.h source/blender/blenkernel/BKE_mball_tessellate.h source/blender/blenkernel/BKE_object.h source/blender/blenkernel/BKE_scene.h source/blender/blenkernel/intern/anim.c source/blender/blenkernel/intern/depsgraph.c source/blender/blenkernel/intern/displist.c source/blender/blenkernel/intern/dynamicpaint.c source/blender/blenkernel/intern/group.c source/blender/blenkernel/intern/mball.c source/blender/blenkernel/intern/mball_tessellate.c source/blender/blenkernel/intern/mesh_convert.c source/blender/blenkernel/intern/object.c source/blender/blenkernel/intern/object_dupli.c source/blender/blenkernel/intern/object_update.c source/blender/blenkernel/intern/pointcache.c source/blender/blenkernel/intern/scene.c source/blender/blenkernel/intern/smoke.c source/blender/depsgraph/intern/builder/deg_builder_nodes.cc source/blender/depsgraph/intern/builder/deg_builder_relations.cc source/blender/editors/include/ED_object.h source/blender/editors/object/object_add.c source/blender/editors/object/object_edit.c source/blender/editors/object/object_modifier.c source/blender/editors/physics/dynamicpaint_ops.c source/blender/editors/sculpt_paint/paint_vertex.c source/blender/editors/sculpt_paint/sculpt_uv.c source/blender/editors/space_view3d/drawobject.c source/blender/editors/space_view3d/view3d_draw.c source/blender/editors/transform/transform_conversions.c source/blender/editors/transform/transform_snap_object.c source/blender/editors/util/ed_util.c source/blender/gpu/intern/gpu_material.c source/blender/makesrna/intern/rna_meta.c source/blender/makesrna/intern/rna_object_api.c source/blender/modifiers/intern/MOD_dynamicpaint.c source/blenderplayer/bad_level_call_stubs/stubs.c
2018-06-11 14:39:38 +02:00
DupliContext *r_ctx, Depsgraph *depsgraph,
Scene *scene, Object *ob, float space_mat[4][4])
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
{
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
r_ctx->depsgraph = depsgraph;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
r_ctx->scene = scene;
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
r_ctx->view_layer = DEG_get_evaluated_view_layer(depsgraph);
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
r_ctx->collection = NULL;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
r_ctx->object = ob;
Remove workspace object mode, reverts changes w/ 2.8 This caused too many problems syncing object modes with multiple objects/windows/workspaces, see: D3130 for details.
2018-04-05 18:20:27 +02:00
r_ctx->obedit = OBEDIT_FROM_OBACT(ob);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (space_mat)
copy_m4_m4(r_ctx->space_mat, space_mat);
else
unit_m4(r_ctx->space_mat);
r_ctx->level = 0;
r_ctx->gen = get_dupli_generator(r_ctx);
r_ctx->duplilist = NULL;
}
/* create sub-context for recursive duplis */
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
static void copy_dupli_context(DupliContext *r_ctx, const DupliContext *ctx, Object *ob, float mat[4][4], int index)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
{
*r_ctx = *ctx;
/* XXX annoying, previously was done by passing an ID* argument, this at least is more explicit */
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
if (ctx->gen->type == OB_DUPLICOLLECTION)
r_ctx->collection = ctx->object->dup_group;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
r_ctx->object = ob;
if (mat)
mul_m4_m4m4(r_ctx->space_mat, (float (*)[4])ctx->space_mat, mat);
r_ctx->persistent_id[r_ctx->level] = index;
++r_ctx->level;
r_ctx->gen = get_dupli_generator(r_ctx);
}
/* generate a dupli instance
* mat is transform of the object relative to current context (including object obmat)
*/
static DupliObject *make_dupli(const DupliContext *ctx,
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
Object *ob, float mat[4][4], int index)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
{
DupliObject *dob;
int i;
/* add a DupliObject instance to the result container */
if (ctx->duplilist) {
dob = MEM_callocN(sizeof(DupliObject), "dupli object");
BLI_addtail(ctx->duplilist, dob);
}
else {
return NULL;
}
dob->ob = ob;
mul_m4_m4m4(dob->mat, (float (*)[4])ctx->space_mat, mat);
dob->type = ctx->gen->type;
/* set persistent id, which is an array with a persistent index for each level
* (particle number, vertex number, ..). by comparing this we can find the same
* dupli object between frames, which is needed for motion blur. last level
* goes first in the array. */
dob->persistent_id[0] = index;
Code Cleanup: style and correct API class ref
2014-01-26 22:17:01 +11:00
for (i = 1; i < ctx->level + 1; i++)
Fix T38306: dupliframes causing viewport render to continually restart. Evaluating the animation is causing the object to get tagged as changed, but in this case it's not a permanent change so no one should be notified. Also found a case where the persistent ID for duplis wasn't unique, fixed that as well.
2014-01-21 21:01:12 +01:00
dob->persistent_id[i] = ctx->persistent_id[ctx->level - i];
/* fill rest of values with INT_MAX which index will never have as value */
for (; i < MAX_DUPLI_RECUR; i++)
dob->persistent_id[i] = INT_MAX;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* metaballs never draw in duplis, they are instead merged into one by the basis
* mball outside of the group. this does mean that if that mball is not in the
* scene, they will not show up at all, limitation that should be solved once. */
if (ob->type == OB_MBALL)
dob->no_draw = true;
Object Info node support for GLSL mode and the internal render 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
2017-04-14 18:13:44 +03:00
/* random number */
/* the logic here is designed to match Cycles */
dob->random_id = BLI_hash_string(dob->ob->id.name + 2);
if (dob->persistent_id[0] != INT_MAX) {
Cleanup: style
2017-04-24 21:58:28 +10:00
for (i = 0; i < MAX_DUPLI_RECUR * 2; i++) {
Object Info node support for GLSL mode and the internal render 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
2017-04-14 18:13:44 +03:00
dob->random_id = BLI_hash_int_2d(dob->random_id, (unsigned int)dob->persistent_id[i]);
Cleanup: style
2017-04-24 21:58:28 +10:00
}
Object Info node support for GLSL mode and the internal render 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
2017-04-14 18:13:44 +03:00
}
else {
dob->random_id = BLI_hash_int_2d(dob->random_id, 0);
}
if (ctx->object != ob) {
dob->random_id ^= BLI_hash_int(BLI_hash_string(ctx->object->id.name + 2));
}
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
return dob;
}
/* recursive dupli objects
* space_mat is the local dupli space (excluding dupli object obmat!)
*/
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
static void make_recursive_duplis(const DupliContext *ctx, Object *ob, float space_mat[4][4], int index)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
{
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* simple preventing of too deep nested collections with MAX_DUPLI_RECUR */
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (ctx->level < MAX_DUPLI_RECUR) {
DupliContext rctx;
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
copy_dupli_context(&rctx, ctx, ob, space_mat, index);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (rctx.gen) {
rctx.gen->make_duplis(&rctx);
}
}
}
/* ---- Child Duplis ---- */
typedef void (*MakeChildDuplisFunc)(const DupliContext *ctx, void *userdata, Object *child);
static bool is_child(const Object *ob, const Object *parent)
{
const Object *ob_parent = ob->parent;
while (ob_parent) {
if (ob_parent == parent)
return true;
ob_parent = ob_parent->parent;
}
return false;
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* create duplis from every child in scene or collection */
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
static void make_child_duplis(const DupliContext *ctx, void *userdata, MakeChildDuplisFunc make_child_duplis_cb)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
{
Object *parent = ctx->object;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
if (ctx->collection) {
int collectionid = 0;
FOREACH_COLLECTION_BASE_RECURSIVE_BEGIN(ctx->collection, base)
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
{
Object *ob = base->object;
Object Mode: remove Scene.obedit Add ED_screen_window_find, BKE_workspace_edit_object
2018-02-13 20:35:29 +11:00
if ((base->flag & BASE_VISIBLED) && ob != ctx->obedit && is_child(ob, parent)) {
Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID.
2016-08-14 15:33:21 +02:00
DupliContext pctx;
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
copy_dupli_context(&pctx, ctx, ctx->object, NULL, collectionid);
Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID.
2016-08-14 15:33:21 +02:00
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* mballs have a different dupli handling */
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
if (ob->type != OB_MBALL) {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
ob->flag |= OB_DONE; /* doesnt render */
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
}
Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID.
2016-08-14 15:33:21 +02:00
make_child_duplis_cb(&pctx, userdata, ob);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
collectionid++;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
FOREACH_COLLECTION_BASE_RECURSIVE_END
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
else {
Fix compiler warning after fix for T48913.
2016-08-18 02:18:39 +02:00
int baseid = 0;
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
ViewLayer *view_layer = ctx->view_layer;
for (Base *base = view_layer->object_bases.first; base; base = base->next, baseid++) {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Object *ob = base->object;
Object Mode: remove Scene.obedit Add ED_screen_window_find, BKE_workspace_edit_object
2018-02-13 20:35:29 +11:00
if ((ob != ctx->obedit) && is_child(ob, parent)) {
Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID.
2016-08-14 15:33:21 +02:00
DupliContext pctx;
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
copy_dupli_context(&pctx, ctx, ctx->object, NULL, baseid);
Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID.
2016-08-14 15:33:21 +02:00
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* mballs have a different dupli handling */
if (ob->type != OB_MBALL)
ob->flag |= OB_DONE; /* doesnt render */
Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID.
2016-08-14 15:33:21 +02:00
make_child_duplis_cb(&pctx, userdata, ob);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
}
}
}
/*---- Implementations ----*/
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* OB_DUPLICOLLECTION */
static void make_duplis_collection(const DupliContext *ctx)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
{
Object *ob = ctx->object;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
Collection *collection;
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
Base *base;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
float collection_mat[4][4];
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
int id;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (ob->dup_group == NULL) return;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
collection = ob->dup_group;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* combine collection offset and obmat */
unit_m4(collection_mat);
sub_v3_v3(collection_mat[3], collection->dupli_ofs);
mul_m4_m4m4(collection_mat, ob->obmat, collection_mat);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* don't access 'ob->obmat' from now on. */
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
const ListBase dup_collection_objects = BKE_collection_object_cache_get(collection);
for (base = dup_collection_objects.first, id = 0; base; base = base->next, id++) {
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
if (base->object != ob && (base->flag & BASE_VISIBLED)) {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
float mat[4][4];
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* collection dupli offset, should apply after everything else */
mul_m4_m4m4(mat, collection_mat, base->object->obmat);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
make_dupli(ctx, base->object, mat, id);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* recursion */
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
make_recursive_duplis(ctx, base->object, collection_mat, id);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
}
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
static const DupliGenerator gen_dupli_collection = {
OB_DUPLICOLLECTION, /* type */
make_duplis_collection /* make_duplis */
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
};
/* OB_DUPLIFRAMES */
static void make_duplis_frames(const DupliContext *ctx)
{
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
Depsgraph *depsgraph = ctx->depsgraph;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Scene *scene = ctx->scene;
Object *ob = ctx->object;
extern int enable_cu_speed; /* object.c */
Object copyob;
int cfrao = scene->r.cfra;
int dupend = ob->dupend;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* dupliframes not supported inside collections */
if (ctx->collection)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
return;
/* if we don't have any data/settings which will lead to object movement,
* don't waste time trying, as it will all look the same...
*/
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
if (ob->parent == NULL && BLI_listbase_is_empty(&ob->constraints) && ob->adt == NULL)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
return;
/* make a copy of the object's original data (before any dupli-data overwrites it)
* as we'll need this to keep track of unkeyed data
* - this doesn't take into account other data that can be reached from the object,
* for example it's shapekeys or bones, hence the need for an update flush at the end
*/
copyob = *ob;
/* duplicate over the required range */
if (ob->transflag & OB_DUPLINOSPEED) enable_cu_speed = 0;
for (scene->r.cfra = ob->dupsta; scene->r.cfra <= dupend; scene->r.cfra++) {
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
int ok = 1;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* - dupoff = how often a frames within the range shouldn't be made into duplis
* - dupon = the length of each "skipping" block in frames
*/
if (ob->dupoff) {
ok = scene->r.cfra - ob->dupsta;
ok = ok % (ob->dupon + ob->dupoff);
ok = (ok < ob->dupon);
}
if (ok) {
/* WARNING: doing animation updates in this way is not terribly accurate, as the dependencies
* and/or other objects which may affect this object's transforms are not updated either.
* However, this has always been the way that this worked (i.e. pre 2.5), so I guess that it'll be fine!
*/
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
/* ob-eval will do drivers, so we don't need to do them */
BKE_animsys_evaluate_animdata(depsgraph, scene, &ob->id, ob->adt, (float)scene->r.cfra, ADT_RECALC_ANIM);
BKE_object_where_is_calc_time(depsgraph, scene, ob, (float)scene->r.cfra);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
make_dupli(ctx, ob, ob->obmat, scene->r.cfra);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
}
enable_cu_speed = 1;
/* reset frame to original frame, then re-evaluate animation as above
* as 2.5 animation data may have far-reaching consequences
*/
scene->r.cfra = cfrao;
Animation: Pass dependency graph to animation system This way we allow animation system to make decisions based on which context dependency graph is coming from, and whether it belongs to an active edit window or not.
2018-05-31 12:52:13 +02:00
/* ob-eval will do drivers, so we don't need to do them */
BKE_animsys_evaluate_animdata(depsgraph, scene, &ob->id, ob->adt, (float)scene->r.cfra, ADT_RECALC_ANIM);
BKE_object_where_is_calc_time(depsgraph, scene, ob, (float)scene->r.cfra);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* but, to make sure unkeyed object transforms are still sane,
* let's copy object's original data back over
*/
*ob = copyob;
}
Cleanup: use static vars where appropriate
2017-08-01 09:06:34 +10:00
static const DupliGenerator gen_dupli_frames = {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
OB_DUPLIFRAMES, /* type */
make_duplis_frames /* make_duplis */
};
/* OB_DUPLIVERTS */
typedef struct VertexDupliData {
DerivedMesh *dm;
BMEditMesh *edit_btmesh;
int totvert;
float (*orco)[3];
bool use_rotation;
const DupliContext *ctx;
Object *inst_ob; /* object to instantiate (argument for vertex map callback) */
float child_imat[4][4];
} VertexDupliData;
static void get_duplivert_transform(const float co[3], const float nor_f[3], const short nor_s[3],
bool use_rotation, short axis, short upflag, float mat[4][4])
{
float quat[4];
const float size[3] = {1.0f, 1.0f, 1.0f};
if (use_rotation) {
float nor[3];
/* construct rotation matrix from normals */
if (nor_f) {
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
nor[0] = -nor_f[0];
nor[1] = -nor_f[1];
nor[2] = -nor_f[2];
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
else if (nor_s) {
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
nor[0] = (float)-nor_s[0];
nor[1] = (float)-nor_s[1];
nor[2] = (float)-nor_s[2];
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
vec_to_quat(quat, nor, axis, upflag);
}
else
unit_qt(quat);
loc_quat_size_to_mat4(mat, co, quat, size);
}
static void vertex_dupli__mapFunc(void *userData, int index, const float co[3],
const float nor_f[3], const short nor_s[3])
{
const VertexDupliData *vdd = userData;
Object *inst_ob = vdd->inst_ob;
DupliObject *dob;
float obmat[4][4], space_mat[4][4];
/* obmat is transform to vertex */
get_duplivert_transform(co, nor_f, nor_s, vdd->use_rotation, inst_ob->trackflag, inst_ob->upflag, obmat);
/* make offset relative to inst_ob using relative child transform */
mul_mat3_m4_v3((float (*)[4])vdd->child_imat, obmat[3]);
/* apply obmat _after_ the local vertex transform */
mul_m4_m4m4(obmat, inst_ob->obmat, obmat);
/* space matrix is constructed by removing obmat transform,
* this yields the worldspace transform for recursive duplis
*/
mul_m4_m4m4(space_mat, obmat, inst_ob->imat);
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
dob = make_dupli(vdd->ctx, vdd->inst_ob, obmat, index);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (vdd->orco)
copy_v3_v3(dob->orco, vdd->orco[index]);
/* recursion */
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
make_recursive_duplis(vdd->ctx, vdd->inst_ob, space_mat, index);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
static void make_child_duplis_verts(const DupliContext *ctx, void *userdata, Object *child)
{
VertexDupliData *vdd = userdata;
DerivedMesh *dm = vdd->dm;
vdd->inst_ob = child;
invert_m4_m4(child->imat, child->obmat);
/* relative transform from parent to child space */
mul_m4_m4m4(vdd->child_imat, child->imat, ctx->object->obmat);
if (vdd->edit_btmesh) {
dm->foreachMappedVert(dm, vertex_dupli__mapFunc, vdd,
vdd->use_rotation ? DM_FOREACH_USE_NORMAL : 0);
}
else {
int a, totvert = vdd->totvert;
float vec[3], no[3];
if (vdd->use_rotation) {
for (a = 0; a < totvert; a++) {
dm->getVertCo(dm, a, vec);
dm->getVertNo(dm, a, no);
vertex_dupli__mapFunc(vdd, a, vec, no, NULL);
}
}
else {
for (a = 0; a < totvert; a++) {
dm->getVertCo(dm, a, vec);
vertex_dupli__mapFunc(vdd, a, vec, NULL, NULL);
}
}
}
}
static void make_duplis_verts(const DupliContext *ctx)
{
Scene *scene = ctx->scene;
Object *parent = ctx->object;
Cleanup: remove unused DAG_EVAL_PREVIEW mode.
2018-06-11 11:48:16 +02:00
bool use_texcoords = (DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
VertexDupliData vdd;
vdd.ctx = ctx;
vdd.use_rotation = parent->transflag & OB_DUPLIROT;
/* gather mesh info */
{
Mesh *me = parent->data;
BMEditMesh *em = BKE_editmesh_from_object(parent);
Fix T40712: Duplicators don't generate orco and UV coordinates in Cycles 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
2014-07-07 10:50:43 +02:00
CustomDataMask dm_mask = (use_texcoords ? CD_MASK_BAREMESH | CD_MASK_ORCO : CD_MASK_BAREMESH);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
if (DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER) {
vdd.dm = mesh_create_derived_render(ctx->depsgraph, scene, parent, dm_mask);
Fix T51890: Turning off viewport display for array modifier is blocking dupliface in final render DupliVert/Face were not using render DM at render time.
2017-06-29 15:44:00 +02:00
}
else if (em) {
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
vdd.dm = editbmesh_get_derived_cage(ctx->depsgraph, scene, parent, em, dm_mask);
Fix T51890: Turning off viewport display for array modifier is blocking dupliface in final render DupliVert/Face were not using render DM at render time.
2017-06-29 15:44:00 +02:00
}
else {
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
vdd.dm = mesh_get_derived_final(ctx->depsgraph, scene, parent, dm_mask);
Fix T51890: Turning off viewport display for array modifier is blocking dupliface in final render DupliVert/Face were not using render DM at render time.
2017-06-29 15:44:00 +02:00
}
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
vdd.edit_btmesh = me->edit_btmesh;
Fix T40712: Duplicators don't generate orco and UV coordinates in Cycles 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
2014-07-07 10:50:43 +02:00
if (use_texcoords)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
vdd.orco = vdd.dm->getVertDataArray(vdd.dm, CD_ORCO);
else
vdd.orco = NULL;
vdd.totvert = vdd.dm->getNumVerts(vdd.dm);
}
make_child_duplis(ctx, &vdd, make_child_duplis_verts);
vdd.dm->release(vdd.dm);
}
Cleanup: use static vars where appropriate
2017-08-01 09:06:34 +10:00
static const DupliGenerator gen_dupli_verts = {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
OB_DUPLIVERTS, /* type */
make_duplis_verts /* make_duplis */
};
/* OB_DUPLIVERTS - FONT */
static Object *find_family_object(const char *family, size_t family_len, unsigned int ch, GHash *family_gh)
{
Object **ob_pt;
Object *ob;
void *ch_key = SET_UINT_IN_POINTER(ch);
if ((ob_pt = (Object **)BLI_ghash_lookup_p(family_gh, ch_key))) {
ob = *ob_pt;
}
else {
char ch_utf8[7];
size_t ch_utf8_len;
ch_utf8_len = BLI_str_utf8_from_unicode(ch, ch_utf8);
ch_utf8[ch_utf8_len] = '\0';
ch_utf8_len += 1; /* compare with null terminator */
for (ob = G.main->object.first; ob; ob = ob->id.next) {
if (STREQLEN(ob->id.name + 2 + family_len, ch_utf8, ch_utf8_len)) {
if (STREQLEN(ob->id.name + 2, family, family_len)) {
break;
}
}
}
/* inserted value can be NULL, just to save searches in future */
BLI_ghash_insert(family_gh, ch_key, ob);
}
return ob;
}
static void make_duplis_font(const DupliContext *ctx)
{
Object *par = ctx->object;
GHash *family_gh;
Object *ob;
Curve *cu;
struct CharTrans *ct, *chartransdata = NULL;
float vec[3], obmat[4][4], pmat[4][4], fsize, xof, yof;
int text_len, a;
size_t family_len;
const wchar_t *text = NULL;
bool text_free = false;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* font dupliverts not supported inside collections */
if (ctx->collection)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
return;
copy_m4_m4(pmat, par->obmat);
/* in par the family name is stored, use this to find the other objects */
Font objects: Support proper auto-space Annoyingly, need to convert vfont to nurbs, do minmax and toss nurbs away. This is likely to be fine, since this function is not intended to be used a lot, and this is the only way to get more meaningful result. However, it's not very clear what to do with font on curve. This fixes rendering of font object with auto texture space in Cycles introduced in c34f3c7. It is probably possible to introduce new mode to vfont_to_curve which will do boundbox without extra allocations, but that's more like an optimization. Reviewers: campbellbarton, mano-wii Reviewed By: campbellbarton Subscribers: zeauro Differential Revision: https://developer.blender.org/D2971
2017-12-19 15:08:29 +01:00
BKE_vfont_to_curve_ex(G.main, par, par->data, FO_DUPLI, NULL,
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
&text, &text_len, &text_free, &chartransdata);
if (text == NULL || chartransdata == NULL) {
return;
}
cu = par->data;
fsize = cu->fsize;
xof = cu->xof;
yof = cu->yof;
ct = chartransdata;
/* cache result */
family_len = strlen(cu->family);
family_gh = BLI_ghash_int_new_ex(__func__, 256);
/* advance matching BLI_strncpy_wchar_from_utf8 */
for (a = 0; a < text_len; a++, ct++) {
Fix for dupli's using float for id's and signed/unsigned conversion Enable strict flags exposed some strange issues.
2014-01-21 22:48:27 +11:00
ob = find_family_object(cu->family, family_len, (unsigned int)text[a], family_gh);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (ob) {
vec[0] = fsize * (ct->xof - xof);
vec[1] = fsize * (ct->yof - yof);
vec[2] = 0.0;
mul_m4_v3(pmat, vec);
copy_m4_m4(obmat, par->obmat);
if (UNLIKELY(ct->rot != 0.0f)) {
float rmat[4][4];
zero_v3(obmat[3]);
Math Lib: rotate matrix cleanup - Remove 'rotate_m2', unlike 'rotate_m4' it created a new matrix duplicating 'angle_to_mat2' - now used instead. (better avoid matching functions having different behavior). - Add 'axis_angle_to_mat4_single', convenience wrapper for 'axis_angle_to_mat3_single'. - Replace 'unit_m4(), rotate_m4()' with a single call to 'axis_angle_to_mat4_single'.
2016-11-25 16:20:30 +11:00
axis_angle_to_mat4_single(rmat, 'Z', -ct->rot);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
mul_m4_m4m4(obmat, obmat, rmat);
}
copy_v3_v3(obmat[3], vec);
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
make_dupli(ctx, ob, obmat, a);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
}
if (text_free) {
MEM_freeN((void *)text);
}
BLI_ghash_free(family_gh, NULL, NULL);
MEM_freeN(chartransdata);
}
Cleanup: use static vars where appropriate
2017-08-01 09:06:34 +10:00
static const DupliGenerator gen_dupli_verts_font = {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
OB_DUPLIVERTS, /* type */
make_duplis_font /* make_duplis */
};
/* OB_DUPLIFACES */
typedef struct FaceDupliData {
DerivedMesh *dm;
int totface;
MPoly *mpoly;
MLoop *mloop;
MVert *mvert;
float (*orco)[3];
MLoopUV *mloopuv;
bool use_scale;
} FaceDupliData;
static void get_dupliface_transform(MPoly *mpoly, MLoop *mloop, MVert *mvert,
bool use_scale, float scale_fac, float mat[4][4])
{
float loc[3], quat[4], scale, size[3];
float f_no[3];
/* location */
BKE_mesh_calc_poly_center(mpoly, mloop, mvert, loc);
/* rotation */
{
Code cleanup: use 'const' for arrays (blenkernel)
2014-04-27 00:20:13 +10:00
const float *v1, *v2, *v3;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
BKE_mesh_calc_poly_normal(mpoly, mloop, mvert, f_no);
v1 = mvert[mloop[0].v].co;
v2 = mvert[mloop[1].v].co;
v3 = mvert[mloop[2].v].co;
tri_to_quat_ex(quat, v1, v2, v3, f_no);
}
/* scale */
if (use_scale) {
Math Lib: avoid having to pass a pre-calculated normal tot area_poly_v3 add normal_poly_v3
2014-04-16 00:27:35 +10:00
float area = BKE_mesh_calc_poly_area(mpoly, mloop, mvert);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
scale = sqrtf(area) * scale_fac;
}
else
scale = 1.0f;
size[0] = size[1] = size[2] = scale;
loc_quat_size_to_mat4(mat, loc, quat, size);
}
static void make_child_duplis_faces(const DupliContext *ctx, void *userdata, Object *inst_ob)
{
FaceDupliData *fdd = userdata;
MPoly *mpoly = fdd->mpoly, *mp;
MLoop *mloop = fdd->mloop;
MVert *mvert = fdd->mvert;
float (*orco)[3] = fdd->orco;
MLoopUV *mloopuv = fdd->mloopuv;
int a, totface = fdd->totface;
Cleanup: remove unused DAG_EVAL_PREVIEW mode.
2018-06-11 11:48:16 +02:00
bool use_texcoords = (DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
float child_imat[4][4];
DupliObject *dob;
invert_m4_m4(inst_ob->imat, inst_ob->obmat);
/* relative transform from parent to child space */
mul_m4_m4m4(child_imat, inst_ob->imat, ctx->object->obmat);
for (a = 0, mp = mpoly; a < totface; a++, mp++) {
MLoop *loopstart = mloop + mp->loopstart;
float space_mat[4][4], obmat[4][4];
if (UNLIKELY(mp->totloop < 3))
continue;
/* obmat is transform to face */
get_dupliface_transform(mp, loopstart, mvert, fdd->use_scale, ctx->object->dupfacesca, obmat);
/* make offset relative to inst_ob using relative child transform */
mul_mat3_m4_v3(child_imat, obmat[3]);
/* XXX ugly hack to ensure same behavior as in master
* this should not be needed, parentinv is not consistent
* outside of parenting.
*/
{
float imat[3][3];
copy_m3_m4(imat, inst_ob->parentinv);
mul_m4_m3m4(obmat, imat, obmat);
}
/* apply obmat _after_ the local face transform */
mul_m4_m4m4(obmat, inst_ob->obmat, obmat);
/* space matrix is constructed by removing obmat transform,
* this yields the worldspace transform for recursive duplis
*/
mul_m4_m4m4(space_mat, obmat, inst_ob->imat);
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
dob = make_dupli(ctx, inst_ob, obmat, a);
Fix T40712: Duplicators don't generate orco and UV coordinates in Cycles 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
2014-07-07 10:50:43 +02:00
if (use_texcoords) {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
float w = 1.0f / (float)mp->totloop;
if (orco) {
int j;
Fix T41160: Rendering duplifaces crashed blender (cycles)
2014-07-24 16:53:03 +06:00
for (j = 0; j < mp->totloop; j++) {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
madd_v3_v3fl(dob->orco, orco[loopstart[j].v], w);
}
}
if (mloopuv) {
int j;
Fix T41160: Rendering duplifaces crashed blender (cycles)
2014-07-24 16:53:03 +06:00
for (j = 0; j < mp->totloop; j++) {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
madd_v2_v2fl(dob->uv, mloopuv[mp->loopstart + j].uv, w);
}
}
}
/* recursion */
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
make_recursive_duplis(ctx, inst_ob, space_mat, a);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
}
static void make_duplis_faces(const DupliContext *ctx)
{
Scene *scene = ctx->scene;
Object *parent = ctx->object;
Cleanup: remove unused DAG_EVAL_PREVIEW mode.
2018-06-11 11:48:16 +02:00
bool use_texcoords = (DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
FaceDupliData fdd;
Fix: compile error due to non-matching type and strict flags for MSVC9 This fixes a small compile error where MSVC9 complains about conversion from int to unsigned char.
2014-02-16 15:47:08 +01:00
fdd.use_scale = ((parent->transflag & OB_DUPLIFACES_SCALE) != 0);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* gather mesh info */
{
BMEditMesh *em = BKE_editmesh_from_object(parent);
Fix T40712: Duplicators don't generate orco and UV coordinates in Cycles 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
2014-07-07 10:50:43 +02:00
CustomDataMask dm_mask = (use_texcoords ? CD_MASK_BAREMESH | CD_MASK_ORCO | CD_MASK_MLOOPUV : CD_MASK_BAREMESH);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
if (DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER) {
fdd.dm = mesh_create_derived_render(ctx->depsgraph, scene, parent, dm_mask);
Fix T51890: Turning off viewport display for array modifier is blocking dupliface in final render DupliVert/Face were not using render DM at render time.
2017-06-29 15:44:00 +02:00
}
else if (em) {
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
fdd.dm = editbmesh_get_derived_cage(ctx->depsgraph, scene, parent, em, dm_mask);
Fix T51890: Turning off viewport display for array modifier is blocking dupliface in final render DupliVert/Face were not using render DM at render time.
2017-06-29 15:44:00 +02:00
}
else {
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
fdd.dm = mesh_get_derived_final(ctx->depsgraph, scene, parent, dm_mask);
Fix T51890: Turning off viewport display for array modifier is blocking dupliface in final render DupliVert/Face were not using render DM at render time.
2017-06-29 15:44:00 +02:00
}
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
Fix T40712: Duplicators don't generate orco and UV coordinates in Cycles 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
2014-07-07 10:50:43 +02:00
if (use_texcoords) {
Fix T47060: Uv form dupli not working with Cycles when the hair/particles mesh has more than one uv sets. In fact, it was not working with BI either - 'UV from dupli' would always take active UVLayer, not render_active one. Fixed now for both Cycles and BI, and for both particles and 'simple' dupli_face.
2016-01-09 12:31:45 +01:00
CustomData *ml_data = fdd.dm->getLoopDataLayout(fdd.dm);
const int uv_idx = CustomData_get_render_layer(ml_data, CD_MLOOPUV);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
fdd.orco = fdd.dm->getVertDataArray(fdd.dm, CD_ORCO);
Fix T47060: Uv form dupli not working with Cycles when the hair/particles mesh has more than one uv sets. In fact, it was not working with BI either - 'UV from dupli' would always take active UVLayer, not render_active one. Fixed now for both Cycles and BI, and for both particles and 'simple' dupli_face.
2016-01-09 12:31:45 +01:00
fdd.mloopuv = CustomData_get_layer_n(ml_data, CD_MLOOPUV, uv_idx);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
else {
fdd.orco = NULL;
fdd.mloopuv = NULL;
}
fdd.totface = fdd.dm->getNumPolys(fdd.dm);
fdd.mpoly = fdd.dm->getPolyArray(fdd.dm);
fdd.mloop = fdd.dm->getLoopArray(fdd.dm);
fdd.mvert = fdd.dm->getVertArray(fdd.dm);
}
make_child_duplis(ctx, &fdd, make_child_duplis_faces);
fdd.dm->release(fdd.dm);
}
Cleanup: use static vars where appropriate
2017-08-01 09:06:34 +10:00
static const DupliGenerator gen_dupli_faces = {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
OB_DUPLIFACES, /* type */
make_duplis_faces /* make_duplis */
};
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
/* OB_DUPLIPARTS */
static void make_duplis_particle_system(const DupliContext *ctx, ParticleSystem *psys)
{
Scene *scene = ctx->scene;
Object *par = ctx->object;
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
bool for_render = DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER;
Cleanup: remove unused DAG_EVAL_PREVIEW mode.
2018-06-11 11:48:16 +02:00
bool use_texcoords = for_render;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
Object *ob = NULL, **oblist = NULL, obcopy, *obcopylist = NULL;
DupliObject *dob;
ParticleDupliWeight *dw;
ParticleSettings *part;
ParticleData *pa;
ChildParticle *cpa = NULL;
ParticleKey state;
ParticleCacheKey *cache;
float ctime, pa_time, scale = 1.0f;
float tmat[4][4], mat[4][4], pamat[4][4], vec[3], size = 0.0;
float (*obmat)[4];
int a, b, hair = 0;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
int totpart, totchild, totcollection = 0 /*, pa_num */;
Duplication: Use local RNG Makes generation safe for threading.
2018-06-12 14:20:21 +02:00
RNG *rng;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
int no_draw_flag = PARS_UNEXIST;
if (psys == NULL) return;
part = psys->part;
if (part == NULL)
return;
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
if (!psys_check_enabled(par, psys, (DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER)))
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
return;
if (!for_render)
no_draw_flag |= PARS_NO_DISP;
Particle System: fixed dupliobject drawing by getting time from depsgraph
2018-05-17 11:42:13 +02:00
ctime = DEG_get_ctime(ctx->depsgraph); /* NOTE: in old animsys, used parent object's timeoffset... */
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
totpart = psys->totpart;
totchild = psys->totchild;
Duplication: Use local RNG Makes generation safe for threading.
2018-06-12 14:20:21 +02:00
rng = BLI_rng_new_srandom(31415926u + (unsigned int)psys->seed);
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
Python API: remove preview/render resolution settings from API functions. For correct results these must have been set already when the depsgraph was created and evaluated, so all dependencies have appropriate resolutions too. For particle we no longer backup and restore the viewport particles to avoid overwriting them during render, as copy-on-write solves this for us. Even without COW particles seem to work ok. This also removes the particle simplification options based on camera. This was never used much and only available in Blender Internal. Differential Revision: https://developer.blender.org/D3148
2018-04-08 09:28:52 +02:00
if ((for_render || part->draw_as == PART_DRAW_REND) && ELEM(part->ren_as, PART_DRAW_OB, PART_DRAW_GR)) {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
ParticleSimulationData sim = {NULL};
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
sim.depsgraph = ctx->depsgraph;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
sim.scene = scene;
sim.ob = par;
sim.psys = psys;
sim.psmd = psys_get_modifier(par, psys);
/* make sure emitter imat is in global coordinates instead of render view coordinates */
invert_m4_m4(par->imat, par->obmat);
/* first check for loops (particle system object used as dupli object) */
if (part->ren_as == PART_DRAW_OB) {
if (ELEM(part->dup_ob, NULL, par))
return;
}
else { /*PART_DRAW_GR */
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
if (part->dup_group == NULL)
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
return;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
const ListBase dup_collection_objects = BKE_collection_object_cache_get(part->dup_group);
if (BLI_listbase_is_empty(&dup_collection_objects))
return;
if (BLI_findptr(&dup_collection_objects, par, offsetof(Base, object))) {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
return;
}
}
/* if we have a hair particle system, use the path cache */
if (part->type == PART_HAIR) {
if (psys->flag & PSYS_HAIR_DONE)
hair = (totchild == 0 || psys->childcache) && psys->pathcache;
if (!hair)
return;
/* we use cache, update totchild according to cached data */
totchild = psys->totchildcache;
totpart = psys->totcached;
}
psys_check_group_weights(part);
psys->lattice_deform_data = psys_create_lattice_deform_data(&sim);
/* gather list of objects or single object */
if (part->ren_as == PART_DRAW_GR) {
if (part->draw & PART_DRAW_COUNT_GR) {
for (dw = part->dupliweights.first; dw; dw = dw->next)
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
totcollection += dw->count;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
}
else {
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
FOREACH_COLLECTION_OBJECT_RECURSIVE_BEGIN(part->dup_group, object)
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
{
(void) object;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
totcollection++;
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
FOREACH_COLLECTION_OBJECT_RECURSIVE_END;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
}
/* we also copy the actual objects to restore afterwards, since
* BKE_object_where_is_calc_time will change the object which breaks transform */
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
oblist = MEM_callocN((size_t)totcollection * sizeof(Object *), "dupcollection object list");
obcopylist = MEM_callocN((size_t)totcollection * sizeof(Object), "dupcollection copy list");
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
if (part->draw & PART_DRAW_COUNT_GR && totcollection) {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
dw = part->dupliweights.first;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
for (a = 0; a < totcollection; dw = dw->next) {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
for (b = 0; b < dw->count; b++, a++) {
oblist[a] = dw->ob;
obcopylist[a] = *dw->ob;
}
}
}
else {
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
a = 0;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
FOREACH_COLLECTION_OBJECT_RECURSIVE_BEGIN(part->dup_group, object)
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
{
oblist[a] = object;
obcopylist[a] = *object;
a++;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
if (a >= totcollection) {
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
continue;
}
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
FOREACH_COLLECTION_OBJECT_RECURSIVE_END;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
}
}
else {
ob = part->dup_ob;
obcopy = *ob;
}
if (totchild == 0 || part->draw & PART_DRAW_PARENT)
a = 0;
else
a = totpart;
for (pa = psys->particles; a < totpart + totchild; a++, pa++) {
if (a < totpart) {
/* handle parent particle */
if (pa->flag & no_draw_flag)
continue;
/* pa_num = pa->num; */ /* UNUSED */
pa_time = pa->time;
size = pa->size;
}
else {
/* handle child particle */
cpa = &psys->child[a - totpart];
/* pa_num = a; */ /* UNUSED */
pa_time = psys->particles[cpa->parent].time;
size = psys_get_child_size(psys, cpa, ctime, NULL);
}
/* some hair paths might be non-existent so they can't be used for duplication */
if (hair && psys->pathcache &&
((a < totpart && psys->pathcache[a]->segments < 0) ||
(a >= totpart && psys->childcache[a - totpart]->segments < 0)))
{
continue;
}
if (part->ren_as == PART_DRAW_GR) {
/* prevent divide by zero below [#28336] */
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
if (totcollection == 0)
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
continue;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* for collections, pick the object based on settings */
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
if (part->draw & PART_DRAW_RAND_GR)
Duplication: Use local RNG Makes generation safe for threading.
2018-06-12 14:20:21 +02:00
b = BLI_rng_get_int(rng) % totcollection;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
else
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
b = a % totcollection;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
ob = oblist[b];
obmat = oblist[b]->obmat;
}
else {
obmat = ob->obmat;
}
if (hair) {
/* hair we handle separate and compute transform based on hair keys */
if (a < totpart) {
cache = psys->pathcache[a];
psys_get_dupli_path_transform(&sim, pa, NULL, cache, pamat, &scale);
}
else {
cache = psys->childcache[a - totpart];
psys_get_dupli_path_transform(&sim, NULL, cpa, cache, pamat, &scale);
}
copy_v3_v3(pamat[3], cache->co);
pamat[3][3] = 1.0f;
}
else {
/* first key */
state.time = ctime;
if (psys_get_particle_state(&sim, a, &state, 0) == 0) {
continue;
}
else {
float tquat[4];
normalize_qt_qt(tquat, state.rot);
quat_to_mat4(pamat, tquat);
copy_v3_v3(pamat[3], state.co);
pamat[3][3] = 1.0f;
}
}
if (part->ren_as == PART_DRAW_GR && psys->part->draw & PART_DRAW_WHOLE_GR) {
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
b = 0;
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
FOREACH_COLLECTION_OBJECT_RECURSIVE_BEGIN(part->dup_group, object)
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
{
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
copy_m4_m4(tmat, oblist[b]->obmat);
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
/* apply particle scale */
mul_mat3_m4_fl(tmat, size * scale);
mul_v3_fl(tmat[3], size * scale);
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
/* collection dupli offset, should apply after everything else */
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
if (!is_zero_v3(part->dup_group->dupli_ofs)) {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
sub_v3_v3(tmat[3], part->dup_group->dupli_ofs);
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
}
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
/* individual particle transform */
mul_m4_m4m4(mat, pamat, tmat);
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
dob = make_dupli(ctx, object, mat, a);
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
dob->particle_system = psys;
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
if (use_texcoords) {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
psys_get_dupli_texture(psys, part, sim.psmd, pa, cpa, dob->uv, dob->orco);
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
}
b++;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
FOREACH_COLLECTION_OBJECT_RECURSIVE_END;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
}
else {
/* to give ipos in object correct offset */
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
BKE_object_where_is_calc_time(ctx->depsgraph, scene, ob, ctime - pa_time);
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
copy_v3_v3(vec, obmat[3]);
obmat[3][0] = obmat[3][1] = obmat[3][2] = 0.0f;
/* particle rotation uses x-axis as the aligned axis, so pre-rotate the object accordingly */
if ((part->draw & PART_DRAW_ROTATE_OB) == 0) {
float xvec[3], q[4], size_mat[4][4], original_size[3];
mat4_to_size(original_size, obmat);
size_to_mat4(size_mat, original_size);
xvec[0] = -1.f;
xvec[1] = xvec[2] = 0;
vec_to_quat(q, xvec, ob->trackflag, ob->upflag);
quat_to_mat4(obmat, q);
obmat[3][3] = 1.0f;
/* add scaling if requested */
if ((part->draw & PART_DRAW_NO_SCALE_OB) == 0)
mul_m4_m4m4(obmat, obmat, size_mat);
}
else if (part->draw & PART_DRAW_NO_SCALE_OB) {
/* remove scaling */
float size_mat[4][4], original_size[3];
mat4_to_size(original_size, obmat);
size_to_mat4(size_mat, original_size);
invert_m4(size_mat);
mul_m4_m4m4(obmat, obmat, size_mat);
}
mul_m4_m4m4(tmat, pamat, obmat);
mul_mat3_m4_fl(tmat, size * scale);
copy_m4_m4(mat, tmat);
if (part->draw & PART_DRAW_GLOBAL_OB)
add_v3_v3v3(mat[3], mat[3], vec);
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
dob = make_dupli(ctx, ob, mat, a);
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
dob->particle_system = psys;
if (use_texcoords)
psys_get_dupli_texture(psys, part, sim.psmd, pa, cpa, dob->uv, dob->orco);
}
}
/* restore objects since they were changed in BKE_object_where_is_calc_time */
if (part->ren_as == PART_DRAW_GR) {
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
for (a = 0; a < totcollection; a++)
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
*(oblist[a]) = obcopylist[a];
}
else
*ob = obcopy;
}
/* clean up */
if (oblist)
MEM_freeN(oblist);
if (obcopylist)
MEM_freeN(obcopylist);
if (psys->lattice_deform_data) {
end_latt_deform(psys->lattice_deform_data);
psys->lattice_deform_data = NULL;
}
Duplication: Use local RNG Makes generation safe for threading.
2018-06-12 14:20:21 +02:00
BLI_rng_free(rng);
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
}
static void make_duplis_particles(const DupliContext *ctx)
{
ParticleSystem *psys;
int psysid;
/* particle system take up one level in id, the particles another */
for (psys = ctx->object->particlesystem.first, psysid = 0; psys; psys = psys->next, psysid++) {
/* particles create one more level for persistent psys index */
DupliContext pctx;
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
copy_dupli_context(&pctx, ctx, ctx->object, NULL, psysid);
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
make_duplis_particle_system(&pctx, psys);
}
}
Cleanup: use static vars where appropriate
2017-08-01 09:06:34 +10:00
static const DupliGenerator gen_dupli_particles = {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
OB_DUPLIPARTS, /* type */
make_duplis_particles /* make_duplis */
};
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
/* ------------- */
/* select dupli generator from given context */
static const DupliGenerator *get_dupli_generator(const DupliContext *ctx)
{
int transflag = ctx->object->transflag;
int restrictflag = ctx->object->restrictflag;
if ((transflag & OB_DUPLI) == 0)
return NULL;
/* Should the dupli's be generated for this object? - Respect restrict flags */
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
if (DEG_get_mode(ctx->depsgraph) == DAG_EVAL_RENDER ? (restrictflag & OB_RESTRICT_RENDER) : (restrictflag & OB_RESTRICT_VIEW))
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
return NULL;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
if (transflag & OB_DUPLIPARTS) {
return &gen_dupli_particles;
}
else if (transflag & OB_DUPLIVERTS) {
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (ctx->object->type == OB_MESH) {
return &gen_dupli_verts;
}
else if (ctx->object->type == OB_FONT) {
return &gen_dupli_verts_font;
}
}
else if (transflag & OB_DUPLIFACES) {
if (ctx->object->type == OB_MESH)
return &gen_dupli_faces;
}
else if (transflag & OB_DUPLIFRAMES) {
return &gen_dupli_frames;
}
Collections and groups unification OVERVIEW * In 2.7 terminology, all layers and groups are now collection datablocks. * These collections are nestable, linkable, instanceable, overrideable, .. which opens up new ways to set up scenes and link + override data. * Viewport/render visibility and selectability are now a part of the collection and shared across all view layers and linkable. * View layers define which subset of the scene collection hierarchy is excluded for each. For many workflows one view layer can be used, these are more of an advanced feature now. OUTLINER * The outliner now has a "View Layer" display mode instead of "Collections", which can display the collections and/or objects in the view layer. * In this display mode, collections can be excluded with the right click menu. These will then be greyed out and their objects will be excluded. * To view collections not linked to any scene, the "Blender File" display mode can be used, with the new filtering option to just see Colleciton datablocks. * The outliner right click menus for collections and objects were reorganized. * Drag and drop still needs to be improved. Like before, dragging the icon or text gives different results, we'll unify this later. LINKING AND OVERRIDES * Collections can now be linked into the scene without creating an instance, with the link/append operator or from the collections view in the outliner. * Collections can get static overrides with the right click menu in the outliner, but this is rather unreliable and not clearly communicated at the moment. * We still need to improve the make override operator to turn collection instances into collections with overrides directly in the scene. PERFORMANCE * We tried to make performance not worse than before and improve it in some cases. The main thing that's still a bit slower is multiple scenes, we have to change the layer syncing to only updated affected scenes. * Collections keep a list of their parent collections for faster incremental updates in syncing and caching. * View layer bases are now in a object -> base hash to avoid quadratic time lookups internally and in API functions like visible_get(). VERSIONING * Compatibility with 2.7 files should be improved due to the new visibility controls. Of course users may not want to set up their scenes differently now to avoid having separate layers and groups. * Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero files. There's a few things which are know to be not quite compatible, like nested layer collections inside groups. * The versioning code for 2.8 files is quite complicated, and isolated behind #ifdef so it can be removed at the end of the release cycle. KNOWN ISSUES * The G-key group operators in the 3D viewport were left mostly as is, they need to be modified still to fit better. * Same for the groups panel in the object properties. This needs to be updated still, or perhaps replaced by something better. * Collections must all have a unique name. Less restrictive namespacing is to be done later, we'll have to see how important this is as all objects within the collections must also have a unique name anyway. * Full scene copy and delete scene are exactly doing the right thing yet. Differential Revision: https://developer.blender.org/D3383 https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
else if (transflag & OB_DUPLICOLLECTION) {
return &gen_dupli_collection;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
}
return NULL;
}
/* ---- ListBase dupli container implementation ---- */
/* Returns a list of DupliObject */
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
ListBase *object_duplilist(Depsgraph *depsgraph, Scene *sce, Object *ob)
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
{
ListBase *duplilist = MEM_callocN(sizeof(ListBase), "duplilist");
DupliContext ctx;
Depsgraph: remove legacy code for dupli group updates. This caused crashes in some cases, and should be fully handled by the depsgraph now.
2018-06-06 14:39:05 +02:00
init_context(&ctx, depsgraph, sce, ob, NULL);
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (ctx.gen) {
ctx.duplilist = duplilist;
ctx.gen->make_duplis(&ctx);
}
return duplilist;
}
void free_object_duplilist(ListBase *lb)
{
BLI_freelistN(lb);
MEM_freeN(lb);
}
int count_duplilist(Object *ob)
{
if (ob->transflag & OB_DUPLI) {
if (ob->transflag & OB_DUPLIVERTS) {
if (ob->type == OB_MESH) {
if (ob->transflag & OB_DUPLIVERTS) {
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
ParticleSystem *psys = ob->particlesystem.first;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
int pdup = 0;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
for (; psys; psys = psys->next)
pdup += psys->totpart;
Code cleanup and structural improvements for dupli generation. This is a first step toward improving our dupli system. It implements a more generic way of treating the various methods of dupli generation by adding a few structs: * DupliContext holds a number of arguments commonly used in the recursive dupli functions and defines a recursion state for generating sub-duplis (nested groups). It also helps to prevent bloated argument lists. * DupliGenerator is a type struct that unifies the different dupli creation methods (groups, frames, verts, text chars, faces, particles). (As with context there should be no overhead from pointer indirection because everything can still be inlined inside anim.c) Beside making the code more easily understandable this implementation should also help to avoid weird side effects from custom matrix hacks by defining clearly what a generator does. The DupliContext is deliberately made const, so a generator can not simply add hidden matrix or flag modifications that are hard to track down. The result container for the generated duplis is stored in the context instead of being passed explicitly. This means the generators are oblivious to the storage of duplis, all they need to do is call the make_dupli function. This will allow us to implement more efficient ways of storing DupliObject instances, such as MemPools or batches. These can be implemented alongside the current ListBase so we can improve dupli bottlenecks without having to replace each and every dupli use case at once. Differential Revision: https://developer.blender.org/D189
2014-01-21 12:11:34 +01:00
if (pdup == 0) {
Mesh *me = ob->data;
return me->totvert;
}
else
return pdup;
}
}
}
else if (ob->transflag & OB_DUPLIFRAMES) {
int tot = ob->dupend - ob->dupsta;
tot /= (ob->dupon + ob->dupoff);
return tot * ob->dupon;
}
}
return 1;
}
Fix T39942: Displacement of group instance objects when switching to textured viewport shading Usual dupli object issue, sometimes it's needed that all the object in dupli group have modified obmat. Made it an utility function now, which is used by convertblender and dupli draw code now.
2014-04-29 17:38:39 +06:00
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
DupliApplyData *duplilist_apply(Depsgraph *depsgraph, Object *ob, Scene *scene, ListBase *duplilist)
Fix T39942: Displacement of group instance objects when switching to textured viewport shading Usual dupli object issue, sometimes it's needed that all the object in dupli group have modified obmat. Made it an utility function now, which is used by convertblender and dupli draw code now.
2014-04-29 17:38:39 +06:00
{
DupliApplyData *apply_data = NULL;
Cleanup: use BLI_listbase_*** prefix for count,sort,sort_r
2014-11-16 13:57:58 +01:00
int num_objects = BLI_listbase_count(duplilist);
Fix T40164: Linking a Group of linked Groups don't take Dupli Visibility correctly. Problem was that object layers are defined by duplis as the top-level duplicator layers. This happens //during// the duplilist construction, which breaks group layer checks for subsequent instances and hides them. Now the duplilist generators leave Object DNA untouched, the modification of layers for drawing, rendering, etc. happens afterward in the duplilist_apply/restore functions, as a kind of second pass.
2014-07-09 12:17:05 +02:00
Fix T39942: Displacement of group instance objects when switching to textured viewport shading Usual dupli object issue, sometimes it's needed that all the object in dupli group have modified obmat. Made it an utility function now, which is used by convertblender and dupli draw code now.
2014-04-29 17:38:39 +06:00
if (num_objects > 0) {
DupliObject *dob;
int i;
apply_data = MEM_mallocN(sizeof(DupliApplyData), "DupliObject apply data");
apply_data->num_objects = num_objects;
apply_data->extra = MEM_mallocN(sizeof(DupliExtraData) * (size_t) num_objects,
"DupliObject apply extra data");
for (dob = duplilist->first, i = 0; dob; dob = dob->next, ++i) {
Fix T44183 particles in linked group offset from object A nice bug combining all the broken features of blender: Particles, duplis and multiple scene dependencies. Fortunately this was solvable: Basically, we need to make sure derivedmesh for dupli instance is generated before obmat is overriden. This also makes sense, since no instance has "true" obmat apart from original. Lazy initialization of derivedmesh just does not work here (or it -does- work but first use should be before instance drawing). Fingers crossed nothing else breaks after this...
2015-04-02 17:13:24 +02:00
/* make sure derivedmesh is calculated once, before drawing */
if (scene && !(dob->ob->transflag & OB_DUPLICALCDERIVED) && dob->ob->type == OB_MESH) {
Depsgraph: remove EvaluationContext, pass Depsgraph instead. The depsgraph was always created within a fixed evaluation context. Passing both risks the depsgraph and evaluation context not matching, and it complicates the Python API where we'd have to expose both which is not so easy to understand. This also removes the global evaluation context in main, which assumed there to be a single active scene and view layer. Differential Revision: https://developer.blender.org/D3152
2018-04-06 12:07:27 +02:00
mesh_get_derived_final(depsgraph, scene, dob->ob, scene->customdata_mask);
Fix T44183 particles in linked group offset from object A nice bug combining all the broken features of blender: Particles, duplis and multiple scene dependencies. Fortunately this was solvable: Basically, we need to make sure derivedmesh for dupli instance is generated before obmat is overriden. This also makes sense, since no instance has "true" obmat apart from original. Lazy initialization of derivedmesh just does not work here (or it -does- work but first use should be before instance drawing). Fingers crossed nothing else breaks after this...
2015-04-02 17:13:24 +02:00
dob->ob->transflag |= OB_DUPLICALCDERIVED;
}
Fix T47754: Meshes glitch on cycling Viewport Shading mode with Linked Groups This is a regression since 4310128 which is cased by really bad logic: there might be dependencies between dupli-objects, which means _if_ we really want to ensure derived mesh on dupli creation we have to do it before any matrix is overwritten. I'm not sure if such derived mesh trick is really the only way to go without major refactor, but seems simple fix for now will do it.
2016-04-12 17:14:13 +02:00
}
Fix T44183 particles in linked group offset from object A nice bug combining all the broken features of blender: Particles, duplis and multiple scene dependencies. Fortunately this was solvable: Basically, we need to make sure derivedmesh for dupli instance is generated before obmat is overriden. This also makes sense, since no instance has "true" obmat apart from original. Lazy initialization of derivedmesh just does not work here (or it -does- work but first use should be before instance drawing). Fingers crossed nothing else breaks after this...
2015-04-02 17:13:24 +02:00
Fix T47754: Meshes glitch on cycling Viewport Shading mode with Linked Groups This is a regression since 4310128 which is cased by really bad logic: there might be dependencies between dupli-objects, which means _if_ we really want to ensure derived mesh on dupli creation we have to do it before any matrix is overwritten. I'm not sure if such derived mesh trick is really the only way to go without major refactor, but seems simple fix for now will do it.
2016-04-12 17:14:13 +02:00
for (dob = duplilist->first, i = 0; dob; dob = dob->next, ++i) {
/* copy obmat from duplis */
copy_m4_m4(apply_data->extra[i].obmat, dob->ob->obmat);
Fix T39942: Displacement of group instance objects when switching to textured viewport shading Usual dupli object issue, sometimes it's needed that all the object in dupli group have modified obmat. Made it an utility function now, which is used by convertblender and dupli draw code now.
2014-04-29 17:38:39 +06:00
copy_m4_m4(dob->ob->obmat, dob->mat);
Fix T40164: Linking a Group of linked Groups don't take Dupli Visibility correctly. Problem was that object layers are defined by duplis as the top-level duplicator layers. This happens //during// the duplilist construction, which breaks group layer checks for subsequent instances and hides them. Now the duplilist generators leave Object DNA untouched, the modification of layers for drawing, rendering, etc. happens afterward in the duplilist_apply/restore functions, as a kind of second pass.
2014-07-09 12:17:05 +02:00
/* copy layers from the main duplicator object */
apply_data->extra[i].lay = dob->ob->lay;
dob->ob->lay = ob->lay;
Fix T39942: Displacement of group instance objects when switching to textured viewport shading Usual dupli object issue, sometimes it's needed that all the object in dupli group have modified obmat. Made it an utility function now, which is used by convertblender and dupli draw code now.
2014-04-29 17:38:39 +06:00
}
}
return apply_data;
}
Fix T40164: Linking a Group of linked Groups don't take Dupli Visibility correctly. Problem was that object layers are defined by duplis as the top-level duplicator layers. This happens //during// the duplilist construction, which breaks group layer checks for subsequent instances and hides them. Now the duplilist generators leave Object DNA untouched, the modification of layers for drawing, rendering, etc. happens afterward in the duplilist_apply/restore functions, as a kind of second pass.
2014-07-09 12:17:05 +02:00
void duplilist_restore(ListBase *duplilist, DupliApplyData *apply_data)
Fix T39942: Displacement of group instance objects when switching to textured viewport shading Usual dupli object issue, sometimes it's needed that all the object in dupli group have modified obmat. Made it an utility function now, which is used by convertblender and dupli draw code now.
2014-04-29 17:38:39 +06:00
{
DupliObject *dob;
int i;
/* Restore object matrices.
* NOTE: this has to happen in reverse order, since nested
* dupli objects can repeatedly override the obmat.
*/
for (dob = duplilist->last, i = apply_data->num_objects - 1; dob; dob = dob->prev, --i) {
copy_m4_m4(dob->ob->obmat, apply_data->extra[i].obmat);
Fix T44183 particles in linked group offset from object A nice bug combining all the broken features of blender: Particles, duplis and multiple scene dependencies. Fortunately this was solvable: Basically, we need to make sure derivedmesh for dupli instance is generated before obmat is overriden. This also makes sense, since no instance has "true" obmat apart from original. Lazy initialization of derivedmesh just does not work here (or it -does- work but first use should be before instance drawing). Fingers crossed nothing else breaks after this...
2015-04-02 17:13:24 +02:00
dob->ob->transflag &= ~OB_DUPLICALCDERIVED;
Fix T40164: Linking a Group of linked Groups don't take Dupli Visibility correctly. Problem was that object layers are defined by duplis as the top-level duplicator layers. This happens //during// the duplilist construction, which breaks group layer checks for subsequent instances and hides them. Now the duplilist generators leave Object DNA untouched, the modification of layers for drawing, rendering, etc. happens afterward in the duplilist_apply/restore functions, as a kind of second pass.
2014-07-09 12:17:05 +02:00
dob->ob->lay = apply_data->extra[i].lay;
Fix T39942: Displacement of group instance objects when switching to textured viewport shading Usual dupli object issue, sometimes it's needed that all the object in dupli group have modified obmat. Made it an utility function now, which is used by convertblender and dupli draw code now.
2014-04-29 17:38:39 +06:00
}
}
void duplilist_free_apply_data(DupliApplyData *apply_data)
{
MEM_freeN(apply_data->extra);
MEM_freeN(apply_data);
}
Copy Permalink