2011-02-18 13:05:18 +00:00
|
|
|
|
/*
|
2002-10-12 11:37:38 +00:00
|
|
|
|
* 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
|
2008-01-07 19:13:47 +00:00
|
|
|
|
* of the License, or (at your option) any later version.
|
2002-10-12 11:37:38 +00:00
|
|
|
|
*
|
|
|
|
|
|
* 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,
|
2010-02-12 13:34:04 +00:00
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2002-10-12 11:37:38 +00:00
|
|
|
|
*
|
|
|
|
|
|
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
|
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
|
*/
|
2012-02-17 18:59:41 +00:00
|
|
|
|
#ifndef __BKE_MAIN_H__
|
|
|
|
|
|
#define __BKE_MAIN_H__
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
|
/** \file
|
|
|
|
|
|
* \ingroup bke
|
|
|
|
|
|
* \section aboutmain Main struct
|
2011-02-18 13:05:18 +00:00
|
|
|
|
* Main is the root of the 'database' of a Blender context. All data
|
|
|
|
|
|
* is stuffed into lists, and all these lists are knotted to here. A
|
|
|
|
|
|
* Blender file is not much more but a binary dump of these
|
|
|
|
|
|
* lists. This list of lists is not serialized itself.
|
|
|
|
|
|
*
|
|
|
|
|
|
* Oops... this should be a _types.h file.
|
|
|
|
|
|
*/
|
2002-10-12 11:37:38 +00:00
|
|
|
|
#include "DNA_listBase.h"
|
|
|
|
|
|
|
2018-11-07 16:06:36 +01:00
|
|
|
|
#include "BLI_compiler_attrs.h"
|
|
|
|
|
|
#include "BLI_sys_types.h"
|
|
|
|
|
|
|
2010-10-05 00:05:14 +00:00
|
|
|
|
#ifdef __cplusplus
|
|
|
|
|
|
extern "C" {
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
2018-11-07 16:06:36 +01:00
|
|
|
|
struct BLI_mempool;
|
2019-01-28 21:08:24 +11:00
|
|
|
|
struct BlendThumbnail;
|
2018-04-06 12:07:27 +02:00
|
|
|
|
struct Depsgraph;
|
2018-11-07 16:06:36 +01:00
|
|
|
|
struct GHash;
|
2019-02-08 18:44:37 +01:00
|
|
|
|
struct GSet;
|
2018-11-07 16:06:36 +01:00
|
|
|
|
struct ImBuf;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
struct Library;
|
2014-06-26 14:55:40 +06:00
|
|
|
|
struct MainLock;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
Make .blend file thumbnail reading simpler and more coherent, read/store them when reading in background mode.
Primary goal of this commit is to fix an annoying issue - when processing and saving .blend
files in background mode you lose their thumbnails, since it can only be generated with
an OpenGL context.
Solution to that is to read .blend thumbnail while reading .blend file (only done in background
mode currently), and store it in Main struct.
Also, this lead to removing .blend file reading code from thumb_blend (no need to have doublons).
We now have a small interface in regular reading code area, which keeps it reasonbaly light
by only reading/parsing header info, and first few BHead blocks.
This makes code reading .blend thumbnail about 3 to 4 times slower than previous highly specialized
one in blend_thumb.c, but overall thumbnail generation of a big .blend files folder only grows
of about 1%, think we can bare with it.
Finally, since thumbnail is now optionally stored in Main struct, it makes it easy to allow user
to define their own custom one (instead of auto-generated one). RNA API for this was not added though,
accessing that kind of .blend meta-data has to be rethought a bit on a bigger level first.
Reviewers: sergey, campbellbarton
Subscribers: Severin, psy-fi
Differential Revision: https://developer.blender.org/D1469
2015-08-27 15:53:23 +02:00
|
|
|
|
/* Blender thumbnail, as written on file (width, height, and data as char RGBA). */
|
|
|
|
|
|
/* We pack pixel data after that struct. */
|
|
|
|
|
|
typedef struct BlendThumbnail {
|
|
|
|
|
|
int width, height;
|
|
|
|
|
|
char rect[0];
|
|
|
|
|
|
} BlendThumbnail;
|
|
|
|
|
|
|
2017-01-30 21:00:07 +01:00
|
|
|
|
/* Structs caching relations between data-blocks in a given Main. */
|
|
|
|
|
|
typedef struct MainIDRelationsEntry {
|
|
|
|
|
|
struct MainIDRelationsEntry *next;
|
|
|
|
|
|
/* WARNING! for user_to_used, that pointer is really an ID** one, but for used_to_user, it’s only an ID* one! */
|
|
|
|
|
|
struct ID **id_pointer;
|
|
|
|
|
|
int usage_flag; /* Using IDWALK_ enums, in BKE_library_query.h */
|
|
|
|
|
|
} MainIDRelationsEntry;
|
|
|
|
|
|
|
|
|
|
|
|
typedef struct MainIDRelations {
|
|
|
|
|
|
struct GHash *id_user_to_used;
|
|
|
|
|
|
struct GHash *id_used_to_user;
|
|
|
|
|
|
|
|
|
|
|
|
/* Private... */
|
|
|
|
|
|
struct BLI_mempool *entry_pool;
|
|
|
|
|
|
} MainIDRelations;
|
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
|
typedef struct Main {
|
|
|
|
|
|
struct Main *next, *prev;
|
2012-01-21 14:54:53 +00:00
|
|
|
|
char name[1024]; /* 1024 = FILE_MAX */
|
2012-12-17 05:38:50 +00:00
|
|
|
|
short versionfile, subversionfile; /* see BLENDER_VERSION, BLENDER_SUBVERSION */
|
2006-11-26 21:17:15 +00:00
|
|
|
|
short minversionfile, minsubversionfile;
|
2013-11-18 18:13:23 +06:00
|
|
|
|
uint64_t build_commit_timestamp; /* commit's timestamp from buildinfo */
|
2013-11-15 17:11:59 +06:00
|
|
|
|
char build_hash[16]; /* hash from buildinfo */
|
2018-03-19 14:17:59 +01:00
|
|
|
|
char recovered; /* indicate the main->name (file) is the recovered one */
|
|
|
|
|
|
/** All current ID's exist in the last memfile undo step. */
|
|
|
|
|
|
char is_memfile_undo_written;
|
Make .blend file thumbnail reading simpler and more coherent, read/store them when reading in background mode.
Primary goal of this commit is to fix an annoying issue - when processing and saving .blend
files in background mode you lose their thumbnails, since it can only be generated with
an OpenGL context.
Solution to that is to read .blend thumbnail while reading .blend file (only done in background
mode currently), and store it in Main struct.
Also, this lead to removing .blend file reading code from thumb_blend (no need to have doublons).
We now have a small interface in regular reading code area, which keeps it reasonbaly light
by only reading/parsing header info, and first few BHead blocks.
This makes code reading .blend thumbnail about 3 to 4 times slower than previous highly specialized
one in blend_thumb.c, but overall thumbnail generation of a big .blend files folder only grows
of about 1%, think we can bare with it.
Finally, since thumbnail is now optionally stored in Main struct, it makes it easy to allow user
to define their own custom one (instead of auto-generated one). RNA API for this was not added though,
accessing that kind of .blend meta-data has to be rethought a bit on a bigger level first.
Reviewers: sergey, campbellbarton
Subscribers: Severin, psy-fi
Differential Revision: https://developer.blender.org/D1469
2015-08-27 15:53:23 +02:00
|
|
|
|
|
|
|
|
|
|
BlendThumbnail *blen_thumb;
|
2018-03-19 14:17:59 +01:00
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
|
struct Library *curlib;
|
|
|
|
|
|
ListBase scene;
|
|
|
|
|
|
ListBase library;
|
|
|
|
|
|
ListBase object;
|
|
|
|
|
|
ListBase mesh;
|
|
|
|
|
|
ListBase curve;
|
|
|
|
|
|
ListBase mball;
|
|
|
|
|
|
ListBase mat;
|
|
|
|
|
|
ListBase tex;
|
|
|
|
|
|
ListBase image;
|
2019-02-27 11:14:41 +11:00
|
|
|
|
ListBase lattice;
|
2019-02-27 10:46:48 +11:00
|
|
|
|
ListBase light;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
ListBase camera;
|
2012-09-26 20:05:38 +00:00
|
|
|
|
ListBase ipo; // XXX deprecated
|
2002-10-12 11:37:38 +00:00
|
|
|
|
ListBase key;
|
|
|
|
|
|
ListBase world;
|
|
|
|
|
|
ListBase screen;
|
|
|
|
|
|
ListBase vfont;
|
|
|
|
|
|
ListBase text;
|
2011-08-01 11:44:20 +00:00
|
|
|
|
ListBase speaker;
|
2017-06-12 20:59:54 +10:00
|
|
|
|
ListBase lightprobe;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
ListBase sound;
|
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
|
|
|
|
ListBase collection;
|
Orange: more noodle updates!
**** NEW: Group Nodes
Node trees usually become messy and confusing quickly, so we need
not only a way to collapse Nodes into single 'groups', but also a
way to re-use that data to create libraries of effects.
This has been done by making a new Library data type, the NodeTree.
Everything that has been grouped is stored here, and available for
re-use, appending or linking. These NodeTrees are fully generic,
i.e. can store shader trees, composit trees, and so on. The 'type'
value as stored in the NodeTree will keep track of internal type
definitions and execute/drawing callbacks. Needless to say, re-using
shader trees in a composit tree is a bit useless, and will be
prevented in the browsing code. :)
So; any NodeTree can become a "Goup Node" inside in a NodeTree. This
Group Node then works just like any Node.
To prevent the current code to become too complex, I've disabled
the possibility to insert Groups inside of Groups. That might be
enabled later, but is a real nasty piece of code to get OK.
Since Group Nodes are a dynamic Node type, a lot of work has been
done to ensure Node definitions can be dynamic too, but still allow
to be stored in files, and allow to be verified for type-definition
changes on reloading. This system needs a little bit maturing still,
so the Python gurus should better wait a little bit! (Also for me to
write the definite API docs for it).
What works now:
- Press CTRL+G to create a new Group. The grouping code checks for
impossible selections (like an unselected node between selected nodes).
Everthing that's selected then gets removed from the current tree, and
inserted in a new NodeTree library data block. A Group Node then is
added which links to this new NodeTree.
- Press ALT+G to ungroup. This will not delete the NodeTree library
data, but just duplicate the Group into the current tree.
- Press TAB, or click on the NodeTree icon to edit Groups. Note that
NodeTrees are instances, so editing one Group will also change the
other users.
This also means that when removing nodes in a Group (or hiding sockets
or changing internal links) this is immediately corrected for all users
of this Group, also in other Materials.
- While editing Groups, only the internal Nodes can be edited. A single
click outside of the Group boundary will close this 'edit mode'.
What needs to be done:
- SHIFT+A menu in toolbox style, also including a list of Groups
- Enable the single-user button in the Group Node
- Displaying all (visible) internal group UI elements in the Node Panel
- Enable Library linking and prevent editing of Groups then.
**** NEW: Socket Visibility control
Node types will be generated with a lot of possible inputs or outputs,
and drawing all sockets all the time isn't very useful then.
A new option in the Node header ('plus' icon) allows to either hide all
unused sockets (first keypress) or to reveil them (when there are hidden
sockets, the icon displays black, otherwise it's blended).
Hidden sockets in Nodes also are not exported to a Group, so this way
you can control what options (in/outputs) exactly are available.
To be done:
- a way to hide individual sockets, like with a RMB click on it.
**** NEW: Nodes now render!
This is still quite primitive, more on a level to replace the (now
obsolete and disabled) Material Layers.
What needs to be done:
- make the "Geometry" node work properly, also for AA textures
- make the Texture Node work (does very little at the moment)
- give Material Nodes all inputs as needed (like Map-to Panel)
- find a way to export more data from a Material Node, like the
shadow value, or light intensity only, etc
Very important also to separate from the Material Buttons the
"global" options, like "Ztransp" or "Wire" or "Halo". These can not
be set for each Material-Node individually.
Also note that the Preview Render (Buttons window) now renders a bit
differently. This was a horrid piece of antique code, using a totally
incompatible way of rendering. Target is to fully re-use internal
render code for previews.
OK... that's it mostly. Now test!
2006-01-02 13:06:05 +00:00
|
|
|
|
ListBase armature;
|
|
|
|
|
|
ListBase action;
|
|
|
|
|
|
ListBase nodetree;
|
Brush Datablock:
- Added a new Brush datablock, only used by image paint, but intended
to be used in texture paint, vertex paint, weight paint and sculpt
mode also.
- Being a datablock, these brushes can be saved, appended and linked.
They have a fake user by default, to make sure they are saved even if
not selected.
Image Painting:
- Replaced the img module with C code in imagepaint.c
- Airbrush is no longer a separate tool, but rather an option that can
be used for soften, smear and clone also.
- Blend modes mix, add, subtract, multiply, darken and lighten have been
added, code taken directly from vertex paint.
Note to project files maintainers:
- The img module was removed from SCons and Makefiles, and this should
be done in other build systems also. I'll wait to remove the module
from cvs, to not break compilation.
2006-07-26 22:29:23 +00:00
|
|
|
|
ListBase brush;
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
|
ListBase particle;
|
2019-02-27 11:14:41 +11:00
|
|
|
|
ListBase palette;
|
|
|
|
|
|
ListBase paintcurve;
|
2007-12-24 18:38:03 +00:00
|
|
|
|
ListBase wm;
|
2.5
Patch from Joshua, converting Grease Pencil to 2.5.
All GP data now is an ID block, allowing re-use, link and append.
For better contextual control within 2.5, these GP ID's will get
linked to actual data, like NodeTrees, Scenes, Images or Objects.
That will ensure Undo works, and opens up exciting new use cases
as well. :)
Patch note: on reading files, GPencils linked from editors will
get moved to the main library, using standard naming (indicating
where it was used), and with "Fake User" set. That way the user
can manually relink the pencils where appropriate.
We can check on just linking GP to some default, like 3d window
pencils to Scene? Nice to experiment with.
Notes for Joshua:
- for reading old GPencil, it has to use old code as well, meaning
to tread data as "indirect data, within another ID".
- Saving ID data means the chunk in file BHead needs the ID_GD code,
and not "DATA", which indicates 'indirect data'. That's the file
format spec.
- I've added do_versions_gpencil_2_50(), feel free to further tweak
things here, like linking things to scene or so.
- Formerly GPencil saved 2.50 files won't convert gpencil
2009-04-20 10:13:55 +00:00
|
|
|
|
ListBase gpencil;
|
2011-11-07 12:55:18 +00:00
|
|
|
|
ListBase movieclip;
|
2012-06-04 16:42:58 +00:00
|
|
|
|
ListBase mask;
|
2010-06-25 22:45:42 +00:00
|
|
|
|
ListBase linestyle;
|
2019-02-27 11:14:41 +11:00
|
|
|
|
ListBase cachefile;
|
|
|
|
|
|
ListBase workspace;
|
2010-12-05 18:59:23 +00:00
|
|
|
|
|
2017-01-30 21:00:07 +01:00
|
|
|
|
/* Must be generated, used and freed by same code - never assume this is valid data unless you know
|
|
|
|
|
|
* when, who and how it was created.
|
|
|
|
|
|
* Used by code doing a lot of remapping etc. at once to speed things up. */
|
|
|
|
|
|
struct MainIDRelations *relations;
|
|
|
|
|
|
|
2014-06-26 14:55:40 +06:00
|
|
|
|
struct MainLock *lock;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
} Main;
|
|
|
|
|
|
|
2018-11-07 16:06:36 +01:00
|
|
|
|
struct Main *BKE_main_new(void);
|
|
|
|
|
|
void BKE_main_free(struct Main *mainvar);
|
|
|
|
|
|
|
|
|
|
|
|
void BKE_main_lock(struct Main *bmain);
|
|
|
|
|
|
void BKE_main_unlock(struct Main *bmain);
|
|
|
|
|
|
|
|
|
|
|
|
void BKE_main_relations_create(struct Main *bmain);
|
|
|
|
|
|
void BKE_main_relations_free(struct Main *bmain);
|
|
|
|
|
|
|
2019-02-08 18:44:37 +01:00
|
|
|
|
struct GSet *BKE_main_gset_create(struct Main *bmain, struct GSet *gset);
|
|
|
|
|
|
|
2019-02-07 17:16:15 +01:00
|
|
|
|
/* *** Generic utils to loop over whole Main database. *** */
|
2019-02-14 16:24:49 +01:00
|
|
|
|
|
|
|
|
|
|
#define FOREACH_MAIN_LISTBASE_ID_BEGIN(_lb, _id) \
|
2019-02-18 15:45:52 +01:00
|
|
|
|
{ \
|
|
|
|
|
|
ID *_id_next = _lb->first; \
|
|
|
|
|
|
for (_id = _id_next; _id != NULL; _id = _id_next) { \
|
|
|
|
|
|
_id_next = _id->next;
|
2019-02-14 16:24:49 +01:00
|
|
|
|
|
|
|
|
|
|
#define FOREACH_MAIN_LISTBASE_ID_END \
|
2019-02-18 15:45:52 +01:00
|
|
|
|
} \
|
2019-02-14 16:24:49 +01:00
|
|
|
|
} ((void)0)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#define FOREACH_MAIN_ID_BEGIN(_bmain, _id) \
|
|
|
|
|
|
{ \
|
|
|
|
|
|
ListBase *_lbarray[MAX_LIBARRAY]; \
|
2019-02-18 16:12:36 +01:00
|
|
|
|
int _i = set_listbasepointers(_bmain, _lbarray); \
|
|
|
|
|
|
while (_i--) { \
|
|
|
|
|
|
FOREACH_MAIN_LISTBASE_ID_BEGIN(_lbarray[_i], _id)
|
2019-02-14 16:24:49 +01:00
|
|
|
|
|
|
|
|
|
|
#define FOREACH_MAIN_ID_END \
|
|
|
|
|
|
FOREACH_MAIN_LISTBASE_ID_END; \
|
|
|
|
|
|
} \
|
|
|
|
|
|
} ((void)0)
|
|
|
|
|
|
|
|
|
|
|
|
/** \param _do_break A boolean, to allow breaking iteration (only used to break by type,
|
|
|
|
|
|
* you must also use an explicit `break;` operation if you want to
|
|
|
|
|
|
* immediately break from inner by-ID loop).
|
|
|
|
|
|
*/
|
|
|
|
|
|
#define FOREACH_MAIN_ID_BREAKABLE_BEGIN(_bmain, _id, _do_break) \
|
|
|
|
|
|
{ \
|
|
|
|
|
|
ListBase *_lbarray[MAX_LIBARRAY]; \
|
|
|
|
|
|
int i = set_listbasepointers(_bmain, _lbarray); \
|
|
|
|
|
|
while (i-- && !_do_break) { \
|
|
|
|
|
|
FOREACH_MAIN_LISTBASE_ID_BEGIN(_lbarray[i], _id) \
|
|
|
|
|
|
|
|
|
|
|
|
#define FOREACH_MAIN_ID_BREAKABLE_END FOREACH_MAIN_ID_END
|
|
|
|
|
|
|
2019-02-07 17:16:15 +01:00
|
|
|
|
|
2018-11-07 16:06:36 +01:00
|
|
|
|
struct BlendThumbnail *BKE_main_thumbnail_from_imbuf(struct Main *bmain, struct ImBuf *img);
|
|
|
|
|
|
struct ImBuf *BKE_main_thumbnail_to_imbuf(struct Main *bmain, struct BlendThumbnail *data);
|
|
|
|
|
|
void BKE_main_thumbnail_create(struct Main *bmain);
|
|
|
|
|
|
|
|
|
|
|
|
const char *BKE_main_blendfile_path(const struct Main *bmain) ATTR_NONNULL();
|
|
|
|
|
|
const char *BKE_main_blendfile_path_from_global(void);
|
|
|
|
|
|
|
|
|
|
|
|
struct ListBase *which_libbase(struct Main *mainlib, short type);
|
|
|
|
|
|
|
|
|
|
|
|
#define MAX_LIBARRAY 37
|
|
|
|
|
|
int set_listbasepointers(struct Main *main, struct ListBase *lb[MAX_LIBARRAY]);
|
|
|
|
|
|
|
2012-12-17 05:38:50 +00:00
|
|
|
|
#define MAIN_VERSION_ATLEAST(main, ver, subver) \
|
2013-01-07 15:42:42 +00:00
|
|
|
|
((main)->versionfile > (ver) || (main->versionfile == (ver) && (main)->subversionfile >= (subver)))
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
2013-03-17 14:38:58 +00:00
|
|
|
|
#define MAIN_VERSION_OLDER(main, ver, subver) \
|
|
|
|
|
|
((main)->versionfile < (ver) || (main->versionfile == (ver) && (main)->subversionfile < (subver)))
|
|
|
|
|
|
|
Make .blend file thumbnail reading simpler and more coherent, read/store them when reading in background mode.
Primary goal of this commit is to fix an annoying issue - when processing and saving .blend
files in background mode you lose their thumbnails, since it can only be generated with
an OpenGL context.
Solution to that is to read .blend thumbnail while reading .blend file (only done in background
mode currently), and store it in Main struct.
Also, this lead to removing .blend file reading code from thumb_blend (no need to have doublons).
We now have a small interface in regular reading code area, which keeps it reasonbaly light
by only reading/parsing header info, and first few BHead blocks.
This makes code reading .blend thumbnail about 3 to 4 times slower than previous highly specialized
one in blend_thumb.c, but overall thumbnail generation of a big .blend files folder only grows
of about 1%, think we can bare with it.
Finally, since thumbnail is now optionally stored in Main struct, it makes it easy to allow user
to define their own custom one (instead of auto-generated one). RNA API for this was not added though,
accessing that kind of .blend meta-data has to be rethought a bit on a bigger level first.
Reviewers: sergey, campbellbarton
Subscribers: Severin, psy-fi
Differential Revision: https://developer.blender.org/D1469
2015-08-27 15:53:23 +02:00
|
|
|
|
#define BLEN_THUMB_SIZE 128
|
|
|
|
|
|
|
2019-02-11 19:09:27 +11:00
|
|
|
|
#define BLEN_THUMB_MEMSIZE(_x, _y) \
|
|
|
|
|
|
(sizeof(BlendThumbnail) + ((size_t)(_x) * (size_t)(_y)) * sizeof(int))
|
|
|
|
|
|
/** Protect against buffer overflow vulnerability & negative sizes. */
|
|
|
|
|
|
#define BLEN_THUMB_MEMSIZE_IS_VALID(_x, _y) \
|
|
|
|
|
|
(((_x) > 0 && (_y) > 0) && \
|
|
|
|
|
|
((uint64_t)(_x) * (uint64_t)(_y) < (SIZE_MAX / (sizeof(int) * 4))))
|
Make .blend file thumbnail reading simpler and more coherent, read/store them when reading in background mode.
Primary goal of this commit is to fix an annoying issue - when processing and saving .blend
files in background mode you lose their thumbnails, since it can only be generated with
an OpenGL context.
Solution to that is to read .blend thumbnail while reading .blend file (only done in background
mode currently), and store it in Main struct.
Also, this lead to removing .blend file reading code from thumb_blend (no need to have doublons).
We now have a small interface in regular reading code area, which keeps it reasonbaly light
by only reading/parsing header info, and first few BHead blocks.
This makes code reading .blend thumbnail about 3 to 4 times slower than previous highly specialized
one in blend_thumb.c, but overall thumbnail generation of a big .blend files folder only grows
of about 1%, think we can bare with it.
Finally, since thumbnail is now optionally stored in Main struct, it makes it easy to allow user
to define their own custom one (instead of auto-generated one). RNA API for this was not added though,
accessing that kind of .blend meta-data has to be rethought a bit on a bigger level first.
Reviewers: sergey, campbellbarton
Subscribers: Severin, psy-fi
Differential Revision: https://developer.blender.org/D1469
2015-08-27 15:53:23 +02:00
|
|
|
|
|
2010-10-05 00:05:14 +00:00
|
|
|
|
#ifdef __cplusplus
|
|
|
|
|
|
}
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
2013-01-24 21:57:13 +00:00
|
|
|
|
#endif /* __BKE_MAIN_H__ */
|