2008-01-01 15:53:38 +00:00
|
|
|
/*
|
2007-12-24 18:53:37 +00:00
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
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-04-16 22:40:48 +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.
|
|
|
|
*
|
|
|
|
*
|
2007-12-24 18:53:37 +00:00
|
|
|
* Contributor(s): Blender Foundation
|
2002-10-12 11:37:38 +00:00
|
|
|
*
|
2008-04-16 22:40:48 +00:00
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
|
|
|
|
2011-02-27 20:35:41 +00:00
|
|
|
/** \file blender/blenloader/intern/writefile.c
|
|
|
|
* \ingroup blenloader
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2016-06-27 11:21:03 +10:00
|
|
|
/**
|
|
|
|
*
|
|
|
|
* FILE FORMAT
|
|
|
|
* ===========
|
|
|
|
*
|
|
|
|
* IFF-style structure (but not IFF compatible!)
|
2012-10-04 13:26:15 +00:00
|
|
|
*
|
|
|
|
* start file:
|
2016-06-27 11:21:03 +10:00
|
|
|
* <pre>
|
2012-10-04 13:26:15 +00:00
|
|
|
* BLENDER_V100 12 bytes (versie 1.00)
|
|
|
|
* V = big endian, v = little endian
|
|
|
|
* _ = 4 byte pointer, - = 8 byte pointer
|
2016-06-27 11:21:03 +10:00
|
|
|
* </pre>
|
2012-10-04 13:26:15 +00:00
|
|
|
*
|
2016-06-27 11:21:03 +10:00
|
|
|
* datablocks: (also see struct #BHead).
|
|
|
|
* <pre>
|
2012-10-04 13:26:15 +00:00
|
|
|
* <bh.code> 4 chars
|
|
|
|
* <bh.len> int, len data after BHead
|
|
|
|
* <bh.old> void, old pointer
|
|
|
|
* <bh.SDNAnr> int
|
2016-08-25 16:22:26 +02:00
|
|
|
* <bh.nr> int, in case of array: number of structs
|
2012-10-04 13:26:15 +00:00
|
|
|
* data
|
|
|
|
* ...
|
|
|
|
* ...
|
2016-06-27 11:21:03 +10:00
|
|
|
* </pre>
|
2012-10-04 13:26:15 +00:00
|
|
|
*
|
|
|
|
* Almost all data in Blender are structures. Each struct saved
|
|
|
|
* gets a BHead header. With BHead the struct can be linked again
|
|
|
|
* and compared with StructDNA .
|
|
|
|
*
|
2016-06-27 11:21:03 +10:00
|
|
|
*
|
2012-10-04 13:26:15 +00:00
|
|
|
* WRITE
|
2016-06-27 11:21:03 +10:00
|
|
|
* =====
|
2012-10-04 13:26:15 +00:00
|
|
|
*
|
|
|
|
* Preferred writing order: (not really a must, but why would you do it random?)
|
|
|
|
* Any case: direct data is ALWAYS after the lib block
|
|
|
|
*
|
|
|
|
* (Local file data)
|
|
|
|
* - for each LibBlock
|
2016-06-27 11:21:03 +10:00
|
|
|
* - write LibBlock
|
|
|
|
* - write associated direct data
|
2012-10-04 13:26:15 +00:00
|
|
|
* (External file data)
|
|
|
|
* - per library
|
2016-06-27 11:21:03 +10:00
|
|
|
* - write library block
|
|
|
|
* - per LibBlock
|
|
|
|
* - write the ID of LibBlock
|
|
|
|
* - write #TEST (#RenderInfo struct. 128x128 blend file preview is optional).
|
|
|
|
* - write #GLOB (#FileGlobal struct) (some global vars).
|
|
|
|
* - write #DNA1 (#SDNA struct)
|
2017-02-15 14:10:42 +11:00
|
|
|
* - write #USER (#UserDef struct) if filename is ``~/.config/blender/X.XX/config/startup.blend``.
|
2012-10-04 13:26:15 +00:00
|
|
|
*/
|
2003-04-26 18:01:01 +00:00
|
|
|
|
|
|
|
|
2009-09-06 13:20:05 +00:00
|
|
|
#include <math.h>
|
|
|
|
#include <fcntl.h>
|
2013-03-18 16:34:57 +00:00
|
|
|
#include <limits.h>
|
2009-09-06 13:20:05 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
2014-04-02 11:43:54 +02:00
|
|
|
#ifdef WIN32
|
2014-11-29 19:12:33 +01:00
|
|
|
# include <zlib.h> /* odd include order-issue */
|
2012-04-15 07:54:07 +00:00
|
|
|
# include "winsock2.h"
|
|
|
|
# include <io.h>
|
|
|
|
# include "BLI_winstuff.h"
|
2014-04-03 09:20:04 +02:00
|
|
|
#else
|
|
|
|
# include <unistd.h> /* FreeBSD, for write() and close(). */
|
2002-10-12 11:37:38 +00:00
|
|
|
#endif
|
|
|
|
|
2013-02-22 13:35:32 +00:00
|
|
|
#include "BLI_utildefines.h"
|
|
|
|
|
2012-01-21 11:15:01 +00:00
|
|
|
/* allow writefile to use deprecated functionality (for forward compatibility code) */
|
|
|
|
#define DNA_DEPRECATED_ALLOW
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
/* Allow using DNA struct members that are marked as private for read/write.
|
|
|
|
* Note: Each header that uses this needs to define its own way of handling
|
|
|
|
* it. There's no generic implementation, direct use does nothing. */
|
|
|
|
#define DNA_PRIVATE_READ_WRITE_ALLOW
|
2012-01-21 11:15:01 +00:00
|
|
|
|
2009-01-18 10:41:45 +00:00
|
|
|
#include "DNA_anim_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_armature_types.h"
|
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
|
|
|
#include "DNA_brush_types.h"
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
#include "DNA_cachefile_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_camera_types.h"
|
2008-01-29 21:01:12 +00:00
|
|
|
#include "DNA_cloth_types.h"
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
#include "DNA_constraint_types.h"
|
2011-05-24 07:08:58 +00:00
|
|
|
#include "DNA_dynamicpaint_types.h"
|
2008-10-31 23:50:02 +00:00
|
|
|
#include "DNA_genfile.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_group_types.h"
|
2008-07-22 09:53:25 +00:00
|
|
|
#include "DNA_gpencil_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_fileglobal_types.h"
|
|
|
|
#include "DNA_key_types.h"
|
|
|
|
#include "DNA_lattice_types.h"
|
|
|
|
#include "DNA_lamp_types.h"
|
Render Layers and Collections (merge from render-layers)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
2017-02-07 10:18:38 +01:00
|
|
|
#include "DNA_layer_types.h"
|
2013-03-23 03:00:37 +00:00
|
|
|
#include "DNA_linestyle_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_meta_types.h"
|
|
|
|
#include "DNA_mesh_types.h"
|
2004-03-20 22:55:42 +00:00
|
|
|
#include "DNA_meshdata_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_material_types.h"
|
Christmas coding work!
********* Node editor work:
- To enable Nodes for Materials, you have to set the "Use Nodes"
button, in the new Material buttons "Nodes" Panel or in header
of the Node editor. Doing this will disable Material-Layers.
- Nodes now execute materials ("shaders"), but still only using the
previewrender code.
- Nodes have (optional) previews for rendered images.
- Node headers allow to hide buttons and/or preview image
- Nodes can be dragged larger/smaller (right-bottom corner)
- Nodes can be hidden (minimized) with hotkey H
- CTRL+click on an Input Socket gives a popup with default values.
- Changing Material/Texture or Mix node will adjust Node title.
- Click-drag outside of a Node changes cursor to "Knife' and allows to
draw a rect where to cut Links.
- Added new node types RGBtoBW, Texture, In/Output, ColorRamp
- Material Nodes have options to ouput diffuse or specular, or to use
a negative normal. The input socket 'Normal' will force the material
to use that normal, otherwise it uses the normal from the Material
that has the node tree.
- When drawing a link between two not-matching sockets, Blender inserts
a converting node (now only for value/rgb combos)
- When drawing a link to an input socket that's already in use, the
old link will either disappear or flip to another unused socket.
- A click on a Material Node will activate it, and show all its settings
in the Material Buttons. Active Material Nodes draw the material icon
in red.
- A click on any node will show its options in the Node Panel in the
Material buttons.
- Multiple Output Nodes can be used, to sample contents of a tree, but
only one Output is the real one, which is indicated in a different
color and red material icon.
- Added ThemeColors for node types
- ALT+C will convert existing Material-Layers to Node... this currently
only adds the material/mix nodes and connects them. Dunno if this is
worth a lot of coding work to make perfect?
- Press C to call another "Solve order", which will show all possible
cyclic conflicts (if there are).
- Technical: nodes now use "Type" structs which define the
structure of nodes and in/output sockets. The Type structs store all
fixed info, callbacks, and allow to reconstruct saved Nodes to match
what is required by Blender.
- Defining (new) nodes now is as simple as filling in a fixed
Type struct, plus code some callbacks. A doc will be made!
- Node preview images are by default float
********* Icon drawing:
- Cleanup of how old icons were implemented in new system, making
them 16x16 too, correctly centered *and* scaled.
- Made drawing Icons use float coordinates
- Moved BIF_calcpreview_image() into interface_icons.c, renamed it
icon_from_image(). Removed a lot of unneeded Imbuf magic here! :)
- Skipped scaling and imbuf copying when icons are OK size
********* Preview render:
- Huge cleanup of code....
- renaming BIF_xxx calls that only were used internally
- BIF_previewrender() now accepts an argument for rendering method,
so it supports icons, buttonwindow previewrender and node editor
- Only a single BIF_preview_changed() call now exists, supporting all
signals as needed for buttos and node editor
********* More stuff:
- glutil.c, glaDrawPixelsSafe() and glaDrawPixelsTex() now accept format
argument for GL_FLOAT rects
- Made the ColorBand become a built-in button for interface.c
Was a load of cleanup work in buttons_shading.c...
- removed a load of unneeded glBlendFunc() calls
- Fixed bug in calculating text length for buttons (ancient!)
2005-12-28 15:42:51 +00:00
|
|
|
#include "DNA_node_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_object_types.h"
|
2018-02-07 11:14:08 +11:00
|
|
|
#include "DNA_object_force_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_packedFile_types.h"
|
2016-12-28 17:30:58 +01:00
|
|
|
#include "DNA_particle_types.h"
|
2017-06-12 20:59:54 +10:00
|
|
|
#include "DNA_lightprobe_types.h"
|
2013-01-23 05:56:22 +00:00
|
|
|
#include "DNA_rigidbody_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_scene_types.h"
|
|
|
|
#include "DNA_sdna_types.h"
|
|
|
|
#include "DNA_sequence_types.h"
|
2009-07-30 15:00:26 +00:00
|
|
|
#include "DNA_smoke_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_space_types.h"
|
|
|
|
#include "DNA_screen_types.h"
|
2011-08-01 11:44:20 +00:00
|
|
|
#include "DNA_speaker_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "DNA_sound_types.h"
|
|
|
|
#include "DNA_text_types.h"
|
2005-05-02 13:28:13 +00:00
|
|
|
#include "DNA_view3d_types.h"
|
|
|
|
#include "DNA_vfont_types.h"
|
Giant commit!
A full detailed description of this will be done later... is several days
of work. Here's a summary:
Render:
- Full cleanup of render code, removing *all* globals and bad level calls
all over blender. Render module is now not called abusive anymore
- API-fied calls to rendering
- Full recode of internal render pipeline. Is now rendering tiles by
default, prepared for much smarter 'bucket' render later.
- Each thread now can render a full part
- Renders were tested with 4 threads, goes fine, apart from some lookup
tables in softshadow and AO still
- Rendering is prepared to do multiple layers and passes
- No single 32 bits trick in render code anymore, all 100% floats now.
Writing images/movies
- moved writing images to blender kernel (bye bye 'schrijfplaatje'!)
- made a new Movie handle system, also in kernel. This will enable much
easier use of movies in Blender
PreviewRender:
- Using new render API, previewrender (in buttons) now uses regular render
code to generate images.
- new datafile 'preview.blend.c' has the preview scenes in it
- previews get rendered in exact displayed size (1 pixel = 1 pixel)
3D Preview render
- new; press Pkey in 3d window, for a panel that continuously renders
(pkey is for games, i know... but we dont do that in orange now!)
- this render works nearly identical to buttons-preview render, so it stops
rendering on any event (mouse, keyboard, etc)
- on moving/scaling the panel, the render code doesn't recreate all geometry
- same for shifting/panning view
- all other operations (now) regenerate the full render database still.
- this is WIP... but big fun, especially for simple scenes!
Compositor
- Using same node system as now in use for shaders, you can composit images
- works pretty straightforward... needs much more options/tools and integration
with rendering still
- is not threaded yet, nor is so smart to only recalculate changes... will be
done soon!
- the "Render Result" node will get all layers/passes as output sockets
- The "Output" node renders to a builtin image, which you can view in the Image
window. (yes, output nodes to render-result, and to files, is on the list!)
The Bad News
- "Unified Render" is removed. It might come back in some stage, but this
system should be built from scratch. I can't really understand this code...
I expect it is not much needed, especially with advanced layer/passes
control
- Panorama render, Field render, Motion blur, is not coded yet... (I had to
recode every single feature in render, so...!)
- Lens Flare is also not back... needs total revision, might become composit
effect though (using zbuffer for visibility)
- Part render is gone! (well, thats obvious, its default now).
- The render window is only restored with limited functionality... I am going
to check first the option to render to a Image window, so Blender can become
a true single-window application. :)
For example, the 'Spare render buffer' (jkey) doesnt work.
- Render with border, now default creates a smaller image
- No zbuffers are written yet... on the todo!
- Scons files and MSVC will need work to get compiling again
OK... thats what I can quickly recall. Now go compiling!
2006-01-23 22:05:47 +00:00
|
|
|
#include "DNA_world_types.h"
|
2007-12-24 18:53:37 +00:00
|
|
|
#include "DNA_windowmanager_types.h"
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
#include "DNA_workspace_types.h"
|
2011-11-07 12:55:18 +00:00
|
|
|
#include "DNA_movieclip_types.h"
|
2012-06-04 16:42:58 +00:00
|
|
|
#include "DNA_mask_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2004-06-23 18:22:51 +00:00
|
|
|
#include "MEM_guardedalloc.h" // MEM_freeN
|
2012-03-14 06:31:38 +00:00
|
|
|
#include "BLI_bitmap.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BLI_blenlib.h"
|
|
|
|
#include "BLI_linklist.h"
|
2013-08-03 11:35:09 +00:00
|
|
|
#include "BLI_mempool.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
#include "BKE_action.h"
|
2016-04-24 22:42:41 +10:00
|
|
|
#include "BKE_blender_version.h"
|
2013-08-03 11:35:09 +00:00
|
|
|
#include "BKE_bpath.h"
|
Biiig commit! Thanks to 2-3 weeks of cvs freeze...
Render:
- New; support for dual CPU render (SDL thread)
Currently only works with alternating scanlines, but gives excellent
performance. For both normal render as unified implemented.
Note the "mutex" locks on z-transp buffer render and imbuf loads.
- This has been made possible by major cleanups in render code, especially
getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct
OSA or using Materials or Texture data to write to.
- Made normal render fully 4x32 floats too, and removed all old optimizes
with chars or shorts.
- Made normal render and unified render use same code for sky and halo
render, giving equal (and better) results for halo render. Old render
now also uses PostProcess options (brightness, mul, gamma)
- Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer
after render. Using PostProcess menu you will note an immediate re-
display of image too (32 bits RGBA)
- Added "Hue" and "Saturation" sliders to PostProcess options
- Render module is still not having a "nice" API, but amount of dependencies
went down a lot. Next todo: remove abusive "previewrender" code.
The last main global in Render (struct Render) now can be re-used for fully
controlling a render, to allow multiple "instances" of render to open.
- Renderwindow now displays a smal bar on top with the stats, and keeps the
stats after render too. Including "spare" page support.
Not only easier visible that way, but also to remove the awkward code that
was drawing stats in the Info header (extreme slow on some ATIs too)
- Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping
defines.
- I might have forgotten stuff... and will write a nice doc on the architecture!
2004-12-27 19:28:52 +00:00
|
|
|
#include "BKE_curve.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"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BKE_constraint.h"
|
|
|
|
#include "BKE_global.h" // for G
|
2015-11-13 15:34:07 +01:00
|
|
|
#include "BKE_idcode.h"
|
2018-07-04 13:00:46 +02:00
|
|
|
#include "BKE_layer.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BKE_library.h" // for set_listbasepointers
|
2017-11-29 15:05:03 +01:00
|
|
|
#include "BKE_library_override.h"
|
2008-12-19 16:36:15 +00:00
|
|
|
#include "BKE_main.h"
|
Christmas coding work!
********* Node editor work:
- To enable Nodes for Materials, you have to set the "Use Nodes"
button, in the new Material buttons "Nodes" Panel or in header
of the Node editor. Doing this will disable Material-Layers.
- Nodes now execute materials ("shaders"), but still only using the
previewrender code.
- Nodes have (optional) previews for rendered images.
- Node headers allow to hide buttons and/or preview image
- Nodes can be dragged larger/smaller (right-bottom corner)
- Nodes can be hidden (minimized) with hotkey H
- CTRL+click on an Input Socket gives a popup with default values.
- Changing Material/Texture or Mix node will adjust Node title.
- Click-drag outside of a Node changes cursor to "Knife' and allows to
draw a rect where to cut Links.
- Added new node types RGBtoBW, Texture, In/Output, ColorRamp
- Material Nodes have options to ouput diffuse or specular, or to use
a negative normal. The input socket 'Normal' will force the material
to use that normal, otherwise it uses the normal from the Material
that has the node tree.
- When drawing a link between two not-matching sockets, Blender inserts
a converting node (now only for value/rgb combos)
- When drawing a link to an input socket that's already in use, the
old link will either disappear or flip to another unused socket.
- A click on a Material Node will activate it, and show all its settings
in the Material Buttons. Active Material Nodes draw the material icon
in red.
- A click on any node will show its options in the Node Panel in the
Material buttons.
- Multiple Output Nodes can be used, to sample contents of a tree, but
only one Output is the real one, which is indicated in a different
color and red material icon.
- Added ThemeColors for node types
- ALT+C will convert existing Material-Layers to Node... this currently
only adds the material/mix nodes and connects them. Dunno if this is
worth a lot of coding work to make perfect?
- Press C to call another "Solve order", which will show all possible
cyclic conflicts (if there are).
- Technical: nodes now use "Type" structs which define the
structure of nodes and in/output sockets. The Type structs store all
fixed info, callbacks, and allow to reconstruct saved Nodes to match
what is required by Blender.
- Defining (new) nodes now is as simple as filling in a fixed
Type struct, plus code some callbacks. A doc will be made!
- Node preview images are by default float
********* Icon drawing:
- Cleanup of how old icons were implemented in new system, making
them 16x16 too, correctly centered *and* scaled.
- Made drawing Icons use float coordinates
- Moved BIF_calcpreview_image() into interface_icons.c, renamed it
icon_from_image(). Removed a lot of unneeded Imbuf magic here! :)
- Skipped scaling and imbuf copying when icons are OK size
********* Preview render:
- Huge cleanup of code....
- renaming BIF_xxx calls that only were used internally
- BIF_previewrender() now accepts an argument for rendering method,
so it supports icons, buttonwindow previewrender and node editor
- Only a single BIF_preview_changed() call now exists, supporting all
signals as needed for buttos and node editor
********* More stuff:
- glutil.c, glaDrawPixelsSafe() and glaDrawPixelsTex() now accept format
argument for GL_FLOAT rects
- Made the ColorBand become a built-in button for interface.c
Was a load of cleanup work in buttons_shading.c...
- removed a load of unneeded glBlendFunc() calls
- Fixed bug in calculating text length for buttons (ancient!)
2005-12-28 15:42:51 +00:00
|
|
|
#include "BKE_node.h"
|
2008-12-19 00:50:21 +00:00
|
|
|
#include "BKE_report.h"
|
2009-12-13 14:56:45 +00:00
|
|
|
#include "BKE_sequencer.h"
|
2012-05-10 20:33:24 +00:00
|
|
|
#include "BKE_subsurf.h"
|
2005-07-19 20:14:17 +00:00
|
|
|
#include "BKE_modifier.h"
|
2009-01-18 10:41:45 +00:00
|
|
|
#include "BKE_fcurve.h"
|
2016-12-28 17:30:58 +01:00
|
|
|
#include "BKE_pointcache.h"
|
2011-12-27 08:39:55 +00:00
|
|
|
#include "BKE_mesh.h"
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
#include "BKE_workspace.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
#ifdef USE_NODE_COMPAT_CUSTOMNODES
|
2016-06-28 17:35:35 +10:00
|
|
|
#include "NOD_socket.h" /* for sock->default_value data */
|
2013-03-18 16:34:57 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BLO_writefile.h"
|
|
|
|
#include "BLO_readfile.h"
|
2018-04-18 18:22:18 +02:00
|
|
|
#include "BLO_runtime.h"
|
2004-09-05 13:43:51 +00:00
|
|
|
#include "BLO_undofile.h"
|
2012-09-03 10:12:25 +00:00
|
|
|
#include "BLO_blend_defs.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
#include "readfile.h"
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
/* for SDNA_TYPE_FROM_STRUCT() macro */
|
|
|
|
#include "dna_type_offsets.h"
|
|
|
|
|
Patch provided by Shaul Kedem: Compressed files are back!
He even made a nice doc in wiki:
http://wiki.blender.org/bin/view.pl/Blenderdev/Blendgz
Usage: set the option "Compress File" in the main "File" pulldown menu.
This setting is a user-def, meaning it is not changed on reading files.
If you want it default, save it with CTRL+U.
The longest debate went over the file naming convention. Shaul started
with .blend.gz files, which gave issues in Blender because of the code
hanging out everywhere that detects blender files, and that appends the
.blend extension if needed.
Daniel Dunbar proposed to just save it as .blend, and not bother users
with such details. This is indeed the most elegant solution, with as
only drawback that old Blender executables cannot read it.
This drawback isn't very relevant at the moment, since we're heading
towards a release that isn't upward compatible anyway... the recode
going on on Meshes, Modfiers, Armatures, Poses, Actions, NLA already
have upward compatibility issues.
We might check - during the next month(s) - on a builtin system to
warn users in the future when we change things that make a file risky
to read in an older release.
2005-07-27 19:46:06 +00:00
|
|
|
#include <errno.h>
|
2004-09-05 13:43:51 +00:00
|
|
|
|
2008-03-05 15:13:41 +00:00
|
|
|
/* ********* my write, buffered writing with minimum size chunks ************ */
|
|
|
|
|
2016-07-08 14:32:29 +10:00
|
|
|
/* Use optimal allocation since blocks of this size are kept in memory for undo. */
|
|
|
|
#define MYWRITE_BUFFER_SIZE (MEM_SIZE_OPTIMAL(1 << 17)) /* 128kb */
|
|
|
|
#define MYWRITE_MAX_CHUNK (MEM_SIZE_OPTIMAL(1 << 15)) /* ~32kb */
|
2014-09-04 21:48:36 +10:00
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/** Use if we want to store how many bytes have been written to the file. */
|
|
|
|
// #define USE_WRITE_DATA_LEN
|
2014-09-04 21:48:36 +10:00
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name Internal Write Wrapper's (Abstracts Compression)
|
2014-09-04 21:48:36 +10:00
|
|
|
* \{ */
|
|
|
|
|
|
|
|
typedef enum {
|
|
|
|
WW_WRAP_NONE = 1,
|
|
|
|
WW_WRAP_ZLIB,
|
|
|
|
} eWriteWrapType;
|
|
|
|
|
|
|
|
typedef struct WriteWrap WriteWrap;
|
|
|
|
struct WriteWrap {
|
|
|
|
/* callbacks */
|
|
|
|
bool (*open)(WriteWrap *ww, const char *filepath);
|
|
|
|
bool (*close)(WriteWrap *ww);
|
|
|
|
size_t (*write)(WriteWrap *ww, const char *data, size_t data_len);
|
|
|
|
|
|
|
|
/* internal */
|
|
|
|
union {
|
|
|
|
int file_handle;
|
|
|
|
gzFile gz_handle;
|
|
|
|
} _user_data;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* none */
|
|
|
|
#define FILE_HANDLE(ww) \
|
|
|
|
(ww)->_user_data.file_handle
|
|
|
|
|
|
|
|
static bool ww_open_none(WriteWrap *ww, const char *filepath)
|
|
|
|
{
|
|
|
|
int file;
|
|
|
|
|
|
|
|
file = BLI_open(filepath, O_BINARY + O_WRONLY + O_CREAT + O_TRUNC, 0666);
|
|
|
|
|
|
|
|
if (file != -1) {
|
|
|
|
FILE_HANDLE(ww) = file;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
static bool ww_close_none(WriteWrap *ww)
|
|
|
|
{
|
|
|
|
return (close(FILE_HANDLE(ww)) != -1);
|
|
|
|
}
|
|
|
|
static size_t ww_write_none(WriteWrap *ww, const char *buf, size_t buf_len)
|
|
|
|
{
|
|
|
|
return write(FILE_HANDLE(ww), buf, buf_len);
|
|
|
|
}
|
|
|
|
#undef FILE_HANDLE
|
|
|
|
|
|
|
|
/* zlib */
|
|
|
|
#define FILE_HANDLE(ww) \
|
|
|
|
(ww)->_user_data.gz_handle
|
|
|
|
|
|
|
|
static bool ww_open_zlib(WriteWrap *ww, const char *filepath)
|
|
|
|
{
|
|
|
|
gzFile file;
|
|
|
|
|
|
|
|
file = BLI_gzopen(filepath, "wb1");
|
|
|
|
|
|
|
|
if (file != Z_NULL) {
|
|
|
|
FILE_HANDLE(ww) = file;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
static bool ww_close_zlib(WriteWrap *ww)
|
|
|
|
{
|
|
|
|
return (gzclose(FILE_HANDLE(ww)) == Z_OK);
|
|
|
|
}
|
|
|
|
static size_t ww_write_zlib(WriteWrap *ww, const char *buf, size_t buf_len)
|
|
|
|
{
|
|
|
|
return gzwrite(FILE_HANDLE(ww), buf, buf_len);
|
|
|
|
}
|
|
|
|
#undef FILE_HANDLE
|
|
|
|
|
|
|
|
/* --- end compression types --- */
|
|
|
|
|
|
|
|
static void ww_handle_init(eWriteWrapType ww_type, WriteWrap *r_ww)
|
|
|
|
{
|
|
|
|
memset(r_ww, 0, sizeof(*r_ww));
|
|
|
|
|
|
|
|
switch (ww_type) {
|
|
|
|
case WW_WRAP_ZLIB:
|
|
|
|
{
|
|
|
|
r_ww->open = ww_open_zlib;
|
|
|
|
r_ww->close = ww_close_zlib;
|
|
|
|
r_ww->write = ww_write_zlib;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
{
|
|
|
|
r_ww->open = ww_open_none;
|
|
|
|
r_ww->close = ww_close_none;
|
|
|
|
r_ww->write = ww_write_none;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/** \} */
|
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name Write Data Type & Functions
|
|
|
|
* \{ */
|
2014-09-04 21:48:36 +10:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
typedef struct {
|
2016-07-12 12:53:49 +10:00
|
|
|
const struct SDNA *sdna;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2018-04-14 12:33:19 +02:00
|
|
|
/** Use for file and memory writing (fixed size of #MYWRITE_BUFFER_SIZE). */
|
|
|
|
uchar *buf;
|
2018-04-14 13:17:11 +02:00
|
|
|
/** Number of bytes used in #WriteData.buf (flushed when exceeded). */
|
|
|
|
int buf_used_len;
|
|
|
|
|
|
|
|
#ifdef USE_WRITE_DATA_LEN
|
|
|
|
/** Total number of bytes written. */
|
|
|
|
size_t write_len;
|
|
|
|
#endif
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/** Set on unlikely case of an error (ignores further file writing). */
|
2016-06-28 21:00:00 +10:00
|
|
|
bool error;
|
2011-12-27 13:17:58 +00:00
|
|
|
|
2018-04-14 12:33:19 +02:00
|
|
|
/** #MemFile writing (used for undo). */
|
|
|
|
struct {
|
|
|
|
MemFile *current;
|
|
|
|
MemFile *compare;
|
|
|
|
/** Use to de-duplicate chunks when writing. */
|
|
|
|
MemFileChunk *compare_chunk;
|
|
|
|
} mem;
|
|
|
|
/** When true, write to #WriteData.current, could also call 'is_undo'. */
|
|
|
|
bool use_memfile;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Wrap writing, so we can use zlib or
|
2014-09-04 21:48:36 +10:00
|
|
|
* other compression types later, see: G_FILE_COMPRESS
|
2018-04-14 12:33:19 +02:00
|
|
|
* Will be NULL for UNDO.
|
|
|
|
*/
|
2014-09-04 21:48:36 +10:00
|
|
|
WriteWrap *ww;
|
2002-10-12 11:37:38 +00:00
|
|
|
} WriteData;
|
|
|
|
|
2014-09-04 21:48:36 +10:00
|
|
|
static WriteData *writedata_new(WriteWrap *ww)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
WriteData *wd = MEM_callocN(sizeof(*wd), "writedata");
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2016-07-12 12:53:49 +10:00
|
|
|
wd->sdna = DNA_sdna_current_get();
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2014-09-04 21:48:36 +10:00
|
|
|
wd->ww = ww;
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
wd->buf = MEM_mallocN(MYWRITE_BUFFER_SIZE, "wd->buf");
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return wd;
|
|
|
|
}
|
|
|
|
|
2012-04-17 19:51:40 +00:00
|
|
|
static void writedata_do_write(WriteData *wd, const void *mem, int memlen)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
if ((wd == NULL) || wd->error || (mem == NULL) || memlen < 1) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (UNLIKELY(wd->error)) {
|
|
|
|
return;
|
|
|
|
}
|
2004-09-05 13:43:51 +00:00
|
|
|
|
|
|
|
/* memory based save */
|
2018-04-14 12:33:19 +02:00
|
|
|
if (wd->use_memfile) {
|
|
|
|
memfile_chunk_add(wd->mem.current, mem, memlen, &wd->mem.compare_chunk);
|
2004-09-05 13:43:51 +00:00
|
|
|
}
|
|
|
|
else {
|
2014-09-04 21:48:36 +10:00
|
|
|
if (wd->ww->write(wd->ww, mem, memlen) != memlen) {
|
2016-06-28 21:00:00 +10:00
|
|
|
wd->error = true;
|
2014-09-04 21:48:36 +10:00
|
|
|
}
|
2004-09-05 13:43:51 +00:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2004-06-23 18:22:51 +00:00
|
|
|
static void writedata_free(WriteData *wd)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
|
|
|
MEM_freeN(wd->buf);
|
|
|
|
MEM_freeN(wd);
|
|
|
|
}
|
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name Local Writing API 'mywrite'
|
|
|
|
* \{ */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2016-07-07 16:02:45 +10:00
|
|
|
/**
|
|
|
|
* Flush helps the de-duplicating memory for undo-save by logically segmenting data,
|
|
|
|
* so differences in one part of memory won't cause unrelated data to be duplicated.
|
|
|
|
*/
|
|
|
|
static void mywrite_flush(WriteData *wd)
|
|
|
|
{
|
2018-04-14 13:17:11 +02:00
|
|
|
if (wd->buf_used_len) {
|
|
|
|
writedata_do_write(wd, wd->buf, wd->buf_used_len);
|
|
|
|
wd->buf_used_len = 0;
|
2016-07-07 16:02:45 +10:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
/**
|
|
|
|
* Low level WRITE(2) wrapper that buffers data
|
2012-03-02 16:05:54 +00:00
|
|
|
* \param adr Pointer to new chunk of data
|
|
|
|
* \param len Length of new chunk of data
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
2012-04-29 17:11:40 +00:00
|
|
|
static void mywrite(WriteData *wd, const void *adr, int len)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
if (UNLIKELY(wd->error)) {
|
|
|
|
return;
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
if (UNLIKELY(adr == NULL)) {
|
2016-07-07 16:02:45 +10:00
|
|
|
BLI_assert(0);
|
2004-09-05 13:43:51 +00:00
|
|
|
return;
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
#ifdef USE_WRITE_DATA_LEN
|
|
|
|
wd->write_len += len;
|
|
|
|
#endif
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2008-03-05 15:13:41 +00:00
|
|
|
/* if we have a single big chunk, write existing data in
|
|
|
|
* buffer and write out big chunk in smaller pieces */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (len > MYWRITE_MAX_CHUNK) {
|
2018-04-14 13:17:11 +02:00
|
|
|
if (wd->buf_used_len) {
|
|
|
|
writedata_do_write(wd, wd->buf, wd->buf_used_len);
|
|
|
|
wd->buf_used_len = 0;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2008-03-05 15:13:41 +00:00
|
|
|
|
|
|
|
do {
|
2016-06-28 17:35:35 +10:00
|
|
|
int writelen = MIN2(len, MYWRITE_MAX_CHUNK);
|
2008-03-05 15:13:41 +00:00
|
|
|
writedata_do_write(wd, adr, writelen);
|
2012-04-17 19:51:40 +00:00
|
|
|
adr = (const char *)adr + writelen;
|
2008-03-05 15:13:41 +00:00
|
|
|
len -= writelen;
|
2012-03-24 07:52:14 +00:00
|
|
|
} while (len > 0);
|
2008-03-05 15:13:41 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return;
|
|
|
|
}
|
2008-03-05 15:13:41 +00:00
|
|
|
|
|
|
|
/* if data would overflow buffer, write out the buffer */
|
2018-04-14 13:17:11 +02:00
|
|
|
if (len + wd->buf_used_len > MYWRITE_BUFFER_SIZE - 1) {
|
|
|
|
writedata_do_write(wd, wd->buf, wd->buf_used_len);
|
|
|
|
wd->buf_used_len = 0;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2008-03-05 15:13:41 +00:00
|
|
|
|
|
|
|
/* append data at end of buffer */
|
2018-04-14 13:17:11 +02:00
|
|
|
memcpy(&wd->buf[wd->buf_used_len], adr, len);
|
|
|
|
wd->buf_used_len += len;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* BeGiN initializer for mywrite
|
2015-05-20 12:54:45 +10:00
|
|
|
* \param ww: File write wrapper.
|
2012-03-02 16:05:54 +00:00
|
|
|
* \param compare Previous memory file (can be NULL).
|
|
|
|
* \param current The current memory file (can be NULL).
|
|
|
|
* \warning Talks to other functions with global parameters
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
2018-04-14 13:17:11 +02:00
|
|
|
static WriteData *mywrite_begin(WriteWrap *ww, MemFile *compare, MemFile *current)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
WriteData *wd = writedata_new(ww);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2018-04-14 12:33:19 +02:00
|
|
|
if (current != NULL) {
|
|
|
|
wd->mem.current = current;
|
|
|
|
wd->mem.compare = compare;
|
|
|
|
wd->mem.compare_chunk = compare ? compare->chunks.first : NULL;
|
|
|
|
wd->use_memfile = true;
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2006-10-27 18:24:10 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return wd;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* END the mywrite wrapper
|
2012-03-02 16:05:54 +00:00
|
|
|
* \return 1 if write failed
|
|
|
|
* \return unknown global variable otherwise
|
|
|
|
* \warning Talks to other functions with global parameters
|
2002-10-12 11:37:38 +00:00
|
|
|
*/
|
2018-04-14 13:17:11 +02:00
|
|
|
static bool mywrite_end(WriteData *wd)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 13:17:11 +02:00
|
|
|
if (wd->buf_used_len) {
|
|
|
|
writedata_do_write(wd, wd->buf, wd->buf_used_len);
|
|
|
|
wd->buf_used_len = 0;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-06-28 21:00:00 +10:00
|
|
|
const bool err = wd->error;
|
2002-10-12 11:37:38 +00:00
|
|
|
writedata_free(wd);
|
2007-02-14 11:00:05 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name Generic DNA File Writing
|
|
|
|
* \{ */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
static void writestruct_at_address_nr(
|
|
|
|
WriteData *wd, int filecode, const int struct_nr, int nr,
|
2016-06-22 08:44:26 +10:00
|
|
|
const void *adr, const void *data)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
|
|
|
BHead bh;
|
2014-04-27 00:24:11 +10:00
|
|
|
const short *sp;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
BLI_assert(struct_nr > 0 && struct_nr < SDNA_TYPE_MAX);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (adr == NULL || data == NULL || nr == 0) {
|
2002-10-12 11:37:38 +00:00
|
|
|
return;
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2003-04-26 18:01:01 +00:00
|
|
|
/* init BHead */
|
2016-06-28 17:35:35 +10:00
|
|
|
bh.code = filecode;
|
|
|
|
bh.old = adr;
|
|
|
|
bh.nr = nr;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
bh.SDNAnr = struct_nr;
|
2016-06-28 17:35:35 +10:00
|
|
|
sp = wd->sdna->structs[bh.SDNAnr];
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
bh.len = nr * wd->sdna->typelens[sp[0]];
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (bh.len == 0) {
|
|
|
|
return;
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
mywrite(wd, &bh, sizeof(BHead));
|
2013-04-12 15:33:09 +00:00
|
|
|
mywrite(wd, data, bh.len);
|
|
|
|
}
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
static void writestruct_at_address_id(
|
|
|
|
WriteData *wd, int filecode, const char *structname, int nr,
|
|
|
|
const void *adr, const void *data)
|
|
|
|
{
|
|
|
|
if (adr == NULL || data == NULL || nr == 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
const int SDNAnr = DNA_struct_find_nr(wd->sdna, structname);
|
|
|
|
if (UNLIKELY(SDNAnr == -1)) {
|
|
|
|
printf("error: can't find SDNA code <%s>\n", structname);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
writestruct_at_address_nr(wd, filecode, SDNAnr, nr, adr, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void writestruct_nr(
|
|
|
|
WriteData *wd, int filecode, const int struct_nr, int nr,
|
2016-06-29 20:37:54 +10:00
|
|
|
const void *adr)
|
2016-06-28 20:05:42 +10:00
|
|
|
{
|
|
|
|
writestruct_at_address_nr(wd, filecode, struct_nr, nr, adr, adr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void writestruct_id(
|
2016-06-22 08:44:26 +10:00
|
|
|
WriteData *wd, int filecode, const char *structname, int nr,
|
|
|
|
const void *adr)
|
2013-04-12 15:33:09 +00:00
|
|
|
{
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_at_address_id(wd, filecode, structname, nr, adr, adr);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2012-04-17 19:51:40 +00:00
|
|
|
static void writedata(WriteData *wd, int filecode, int len, const void *adr) /* do not use for structs */
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
|
|
|
BHead bh;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (adr == NULL || len == 0) {
|
|
|
|
return;
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2013-05-08 13:00:06 +00:00
|
|
|
/* align to 4 (writes uninitialized bytes in some cases) */
|
|
|
|
len = (len + 3) & ~3;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2003-04-26 18:01:01 +00:00
|
|
|
/* init BHead */
|
2012-04-17 19:51:40 +00:00
|
|
|
bh.code = filecode;
|
2016-06-22 08:44:26 +10:00
|
|
|
bh.old = adr;
|
2012-04-17 19:51:40 +00:00
|
|
|
bh.nr = 1;
|
|
|
|
bh.SDNAnr = 0;
|
|
|
|
bh.len = len;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
mywrite(wd, &bh, sizeof(BHead));
|
2013-05-08 13:00:06 +00:00
|
|
|
mywrite(wd, adr, len);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2013-03-07 16:57:53 +00:00
|
|
|
/* use this to force writing of lists in same order as reading (using link_list) */
|
2016-06-28 20:05:42 +10:00
|
|
|
static void writelist_nr(WriteData *wd, int filecode, const int struct_nr, const ListBase *lb)
|
2013-03-07 16:57:53 +00:00
|
|
|
{
|
2016-06-22 08:44:26 +10:00
|
|
|
const Link *link = lb->first;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-07 16:57:53 +00:00
|
|
|
while (link) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_nr(wd, filecode, struct_nr, 1, link);
|
2013-03-07 16:57:53 +00:00
|
|
|
link = link->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
#if 0
|
|
|
|
static void writelist_id(WriteData *wd, int filecode, const char *structname, const ListBase *lb)
|
|
|
|
{
|
|
|
|
const Link *link = lb->first;
|
|
|
|
if (link) {
|
|
|
|
|
|
|
|
const int struct_nr = DNA_struct_find_nr(wd->sdna, structname);
|
|
|
|
if (struct_nr == -1) {
|
|
|
|
printf("error: can't find SDNA code <%s>\n", structname);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (link) {
|
|
|
|
writestruct_nr(wd, filecode, struct_nr, 1, link);
|
|
|
|
link = link->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define writestruct_at_address(wd, filecode, struct_id, nr, adr, data) \
|
|
|
|
writestruct_at_address_nr(wd, filecode, SDNA_TYPE_FROM_STRUCT(struct_id), nr, adr, data)
|
|
|
|
|
|
|
|
#define writestruct(wd, filecode, struct_id, nr, adr) \
|
|
|
|
writestruct_nr(wd, filecode, SDNA_TYPE_FROM_STRUCT(struct_id), nr, adr)
|
|
|
|
|
|
|
|
#define writelist(wd, filecode, struct_id, lb) \
|
|
|
|
writelist_nr(wd, filecode, SDNA_TYPE_FROM_STRUCT(struct_id), lb)
|
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name Typed DNA File Writing
|
|
|
|
*
|
|
|
|
* These functions are used by blender's .blend system for file saving/loading.
|
|
|
|
* \{ */
|
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
void IDP_WriteProperty_OnlyData(const IDProperty *prop, void *wd);
|
|
|
|
void IDP_WriteProperty(const IDProperty *prop, void *wd);
|
2006-11-17 04:46:48 +00:00
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
static void IDP_WriteArray(const IDProperty *prop, void *wd)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
|
|
|
/*REMEMBER to set totalen to len in the linking code!!*/
|
|
|
|
if (prop->data.pointer) {
|
|
|
|
writedata(wd, DATA, MEM_allocN_len(prop->data.pointer), prop->data.pointer);
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (prop->subtype == IDP_GROUP) {
|
2016-06-28 17:35:35 +10:00
|
|
|
IDProperty **array = prop->data.pointer;
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
int a;
|
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
for (a = 0; a < prop->len; a++) {
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
IDP_WriteProperty(array[a], wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
}
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
static void IDP_WriteIDPArray(const IDProperty *prop, void *wd)
|
2008-12-31 13:16:37 +00:00
|
|
|
{
|
|
|
|
/*REMEMBER to set totalen to len in the linking code!!*/
|
|
|
|
if (prop->data.pointer) {
|
2016-06-22 08:44:26 +10:00
|
|
|
const IDProperty *array = prop->data.pointer;
|
2008-12-31 13:16:37 +00:00
|
|
|
int a;
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, IDProperty, prop->len, array);
|
2008-12-31 13:16:37 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
for (a = 0; a < prop->len; a++) {
|
2.5: RNA, defining enums, pointers and collections properties is now
possible from python, but it's still work in progress.
Pointers and collections are restricted to types derived from
IDPropertyGroup (same as for operators), because RNA knows how to
allocate/deallocate those.
Collections have .add() and .remove(number) functions that can be
used. The remove function should be fixed to take an other argument
than a number.
With the IDPropertyGroup restriction, pointers are more like nested
structs. They don't have add(), remove() yet, not sure where to put
them. Currently the pointer / nested struct is automatically allocated
in the get() function, this needs to be fixed, rule is that RNA get()
will not change any data for thread safety.
Also, it is only possible to add properties to structs after they have
been registered, which needs to be improved as well.
Example code:
http://www.pasteall.org/7201/python
2009-08-18 01:29:25 +00:00
|
|
|
IDP_WriteProperty_OnlyData(&array[a], wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2008-12-31 13:16:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
static void IDP_WriteString(const IDProperty *prop, void *wd)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
|
|
|
/*REMEMBER to set totalen to len in the linking code!!*/
|
2014-02-15 12:27:23 +11:00
|
|
|
writedata(wd, DATA, prop->len, prop->data.pointer);
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
static void IDP_WriteGroup(const IDProperty *prop, void *wd)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
|
|
|
IDProperty *loop;
|
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
for (loop = prop->data.group.first; loop; loop = loop->next) {
|
2006-11-17 04:46:48 +00:00
|
|
|
IDP_WriteProperty(loop, wd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Functions to read/write ID Properties */
|
2016-06-22 08:44:26 +10:00
|
|
|
void IDP_WriteProperty_OnlyData(const IDProperty *prop, void *wd)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
|
|
|
switch (prop->type) {
|
|
|
|
case IDP_GROUP:
|
|
|
|
IDP_WriteGroup(prop, wd);
|
|
|
|
break;
|
|
|
|
case IDP_STRING:
|
|
|
|
IDP_WriteString(prop, wd);
|
|
|
|
break;
|
|
|
|
case IDP_ARRAY:
|
|
|
|
IDP_WriteArray(prop, wd);
|
|
|
|
break;
|
2008-12-31 13:16:37 +00:00
|
|
|
case IDP_IDPARRAY:
|
|
|
|
IDP_WriteIDPArray(prop, wd);
|
|
|
|
break;
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
void IDP_WriteProperty(const IDProperty *prop, void *wd)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, IDProperty, 1, prop);
|
2006-11-17 04:46:48 +00:00
|
|
|
IDP_WriteProperty_OnlyData(prop, wd);
|
|
|
|
}
|
Orange:
- New UI element: the "Curve Button".
For mapping ranges (like 0 - 1) to another range, the curve button can be
used for proportional falloff, bone influences, painting density, etc.
Most evident use is of course to map RGB color with curves.
To be able to use it, you have to allocate a CurveMapping struct and pass
this on to the button. The CurveMapping API is in the new C file
blenkernel/intern/colortools.c
It's as simple as calling:
curvemap= curvemapping_add(3, 0, 0, 1, 1)
Which will create 3 curves, and sets a default 0-1 range. The current code
only supports up to 4 curves maximum per mapping struct.
The CurveMap button in Blender than handles allmost all editing.
Evaluating a single channel:
float newvalue= curvemapping_evaluateF(curvemap, 0, oldval);
Where the second argument is the channel index, here 0-1-2 are possible.
Or mapping a vector:
curvemapping_evaluate3F(curvemap, newvec, oldvec);
Optimized versions for byte or short mapping is possible too, not done yet.
In butspace.c I've added a template wrapper for buttons around the curve, to
reveil settings or show tools; check this screenie:
http://www.blender.org/bf/curves.jpg
- Buttons R, G, B: select channel
- icons + and -: zoom in, out
- icon 'wrench': menu with tools, like clear curve, set handle type
- icon 'clipping': menu with clip values, and to dis/enable clipping
- icon 'x': delete selection
In the curve button itself, only LMB clicks are handled (like all UI elements
in Blender).
- click on point: select
- shift+click on point: swap select
- click on point + drag: select point (if not selected) and move it
- click outside point + drag: translate view
- CTRL+click: add new point
- hold SHIFT while dragging to snap to grid
(Yes I know... either one of these can be Blender compliant, not both!)
- if you drag a point exactly on top of another, it merges them
Other fixes:
- Icons now draw using "Safe RasterPos", so they align with pixel boundary.
the old code made ints from the raster pos coordinate, which doesn't work
well for zoom in/out situations
- bug in Node editing: buttons could not get freed, causing in memory error
prints at end of a Blender session. That one was a very simple, but nasty
error causing me all evening last night to find!
(Hint; check diff of editnode.c, where uiDoButtons is called)
Last note: this adds 3 new files in our tree, I did scons, but not MSVC!
2006-01-08 11:41:06 +00:00
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
static void write_iddata(void *wd, const ID *id)
|
2016-06-14 14:53:39 +02:00
|
|
|
{
|
|
|
|
/* ID_WM's id->properties are considered runtime only, and never written in .blend file. */
|
|
|
|
if (id->properties && !ELEM(GS(id->name), ID_WM)) {
|
|
|
|
IDP_WriteProperty(id->properties, wd);
|
|
|
|
}
|
2017-11-29 15:05:03 +01:00
|
|
|
|
|
|
|
if (id->override_static) {
|
|
|
|
writestruct(wd, DATA, IDOverrideStatic, 1, id->override_static);
|
|
|
|
|
|
|
|
writelist(wd, DATA, IDOverrideStaticProperty, &id->override_static->properties);
|
|
|
|
for (IDOverrideStaticProperty *op = id->override_static->properties.first; op; op = op->next) {
|
|
|
|
writedata(wd, DATA, strlen(op->rna_path) + 1, op->rna_path);
|
|
|
|
|
|
|
|
writelist(wd, DATA, IDOverrideStaticPropertyOperation, &op->operations);
|
|
|
|
for (IDOverrideStaticPropertyOperation *opop = op->operations.first; opop; opop = opop->next) {
|
|
|
|
if (opop->subitem_reference_name) {
|
|
|
|
writedata(wd, DATA, strlen(opop->subitem_reference_name) + 1, opop->subitem_reference_name);
|
|
|
|
}
|
|
|
|
if (opop->subitem_local_name) {
|
|
|
|
writedata(wd, DATA, strlen(opop->subitem_local_name) + 1, opop->subitem_local_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-06-14 14:53:39 +02:00
|
|
|
}
|
|
|
|
|
2016-06-22 08:44:26 +10:00
|
|
|
static void write_previews(WriteData *wd, const PreviewImage *prv_orig)
|
2015-08-10 15:41:28 +02:00
|
|
|
{
|
2018-01-26 07:54:09 +01:00
|
|
|
/* Note we write previews also for undo steps. It takes up some memory,
|
|
|
|
* but not doing so would causes all previews to be re-rendered after
|
|
|
|
* undo which is too expensive. */
|
|
|
|
if (prv_orig) {
|
2016-06-22 08:44:26 +10:00
|
|
|
PreviewImage prv = *prv_orig;
|
2015-08-10 15:41:28 +02:00
|
|
|
|
|
|
|
/* don't write out large previews if not requested */
|
|
|
|
if (!(U.flag & USER_SAVE_PREVIEWS)) {
|
2016-06-22 08:44:26 +10:00
|
|
|
prv.w[1] = 0;
|
|
|
|
prv.h[1] = 0;
|
|
|
|
prv.rect[1] = NULL;
|
2015-08-10 15:41:28 +02:00
|
|
|
}
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_at_address(wd, DATA, PreviewImage, 1, prv_orig, &prv);
|
2016-06-22 08:44:26 +10:00
|
|
|
if (prv.rect[0]) {
|
|
|
|
writedata(wd, DATA, prv.w[0] * prv.h[0] * sizeof(unsigned int), prv.rect[0]);
|
|
|
|
}
|
|
|
|
if (prv.rect[1]) {
|
|
|
|
writedata(wd, DATA, prv.w[1] * prv.h[1] * sizeof(unsigned int), prv.rect[1]);
|
2015-08-10 15:41:28 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
static void write_fmodifiers(WriteData *wd, ListBase *fmodifiers)
|
|
|
|
{
|
|
|
|
FModifier *fcm;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-08 10:59:43 +00:00
|
|
|
/* Write all modifiers first (for faster reloading) */
|
2016-06-28 20:05:42 +10:00
|
|
|
writelist(wd, DATA, FModifier, fmodifiers);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* Modifiers */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (fcm = fmodifiers->first; fcm; fcm = fcm->next) {
|
|
|
|
const FModifierTypeInfo *fmi = fmodifier_get_typeinfo(fcm);
|
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* Write the specific data */
|
|
|
|
if (fmi && fcm->data) {
|
|
|
|
/* firstly, just write the plain fmi->data struct */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, fmi->structName, 1, fcm->data);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* do any modifier specific stuff */
|
|
|
|
switch (fcm->type) {
|
|
|
|
case FMODIFIER_TYPE_GENERATOR:
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
FMod_Generator *data = fcm->data;
|
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write coefficients array */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (data->coefficients) {
|
|
|
|
writedata(wd, DATA, sizeof(float) * (data->arraysize), data->coefficients);
|
|
|
|
}
|
2015-07-18 19:02:39 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
break;
|
2015-07-18 19:02:39 +10:00
|
|
|
}
|
2010-12-13 08:08:09 +00:00
|
|
|
case FMODIFIER_TYPE_ENVELOPE:
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
FMod_Envelope *data = fcm->data;
|
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write envelope data */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (data->data) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, FCM_EnvelopeData, data->totvert, data->data);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2015-07-18 19:02:39 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
break;
|
2015-07-18 19:02:39 +10:00
|
|
|
}
|
2010-12-13 08:08:09 +00:00
|
|
|
case FMODIFIER_TYPE_PYTHON:
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
FMod_Python *data = fcm->data;
|
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* Write ID Properties -- and copy this comment EXACTLY for easy finding
|
2012-04-22 11:54:53 +00:00
|
|
|
* of library blocks that implement this.*/
|
2010-12-13 08:08:09 +00:00
|
|
|
IDP_WriteProperty(data->prop, wd);
|
2015-07-18 19:02:39 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
break;
|
2015-07-18 19:02:39 +10:00
|
|
|
}
|
2010-12-13 08:08:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_fcurves(WriteData *wd, ListBase *fcurves)
|
|
|
|
{
|
|
|
|
FCurve *fcu;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writelist(wd, DATA, FCurve, fcurves);
|
2016-06-28 17:35:35 +10:00
|
|
|
for (fcu = fcurves->first; fcu; fcu = fcu->next) {
|
2010-12-13 08:08:09 +00:00
|
|
|
/* curve data */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (fcu->bezt) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, BezTriple, fcu->totvert, fcu->bezt);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
if (fcu->fpt) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, FPoint, fcu->totvert, fcu->fpt);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
if (fcu->rna_path) {
|
|
|
|
writedata(wd, DATA, strlen(fcu->rna_path) + 1, fcu->rna_path);
|
|
|
|
}
|
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* driver data */
|
|
|
|
if (fcu->driver) {
|
2016-06-28 17:35:35 +10:00
|
|
|
ChannelDriver *driver = fcu->driver;
|
2010-12-13 08:08:09 +00:00
|
|
|
DriverVar *dvar;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ChannelDriver, 1, driver);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* variables */
|
2016-06-28 20:05:42 +10:00
|
|
|
writelist(wd, DATA, DriverVar, &driver->variables);
|
2016-06-28 17:35:35 +10:00
|
|
|
for (dvar = driver->variables.first; dvar; dvar = dvar->next) {
|
2010-12-13 08:08:09 +00:00
|
|
|
DRIVER_TARGETS_USED_LOOPER(dvar)
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
if (dtar->rna_path) {
|
|
|
|
writedata(wd, DATA, strlen(dtar->rna_path) + 1, dtar->rna_path);
|
|
|
|
}
|
2010-12-13 08:08:09 +00:00
|
|
|
}
|
|
|
|
DRIVER_TARGETS_LOOPER_END
|
|
|
|
}
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write F-Modifiers */
|
|
|
|
write_fmodifiers(wd, &fcu->modifiers);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_action(WriteData *wd, bAction *act)
|
2010-12-13 08:08:09 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (act->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_AC, bAction, 1, act);
|
|
|
|
write_iddata(wd, &act->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_fcurves(wd, &act->curves);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (bActionGroup *grp = act->groups.first; grp; grp = grp->next) {
|
|
|
|
writestruct(wd, DATA, bActionGroup, 1, grp);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (TimeMarker *marker = act->markers.first; marker; marker = marker->next) {
|
|
|
|
writestruct(wd, DATA, TimeMarker, 1, marker);
|
2010-12-13 08:08:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_keyingsets(WriteData *wd, ListBase *list)
|
|
|
|
{
|
|
|
|
KeyingSet *ks;
|
|
|
|
KS_Path *ksp;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
for (ks = list->first; ks; ks = ks->next) {
|
2010-12-13 08:08:09 +00:00
|
|
|
/* KeyingSet */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, KeyingSet, 1, ks);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* Paths */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (ksp = ks->paths.first; ksp; ksp = ksp->next) {
|
2010-12-13 08:08:09 +00:00
|
|
|
/* Path */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, KS_Path, 1, ksp);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
if (ksp->rna_path) {
|
|
|
|
writedata(wd, DATA, strlen(ksp->rna_path) + 1, ksp->rna_path);
|
|
|
|
}
|
2010-12-13 08:08:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_nlastrips(WriteData *wd, ListBase *strips)
|
|
|
|
{
|
|
|
|
NlaStrip *strip;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writelist(wd, DATA, NlaStrip, strips);
|
2016-06-28 17:35:35 +10:00
|
|
|
for (strip = strips->first; strip; strip = strip->next) {
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write the strip's F-Curves and modifiers */
|
|
|
|
write_fcurves(wd, &strip->fcurves);
|
|
|
|
write_fmodifiers(wd, &strip->modifiers);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write the strip's children */
|
|
|
|
write_nlastrips(wd, &strip->strips);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_nladata(WriteData *wd, ListBase *nlabase)
|
|
|
|
{
|
|
|
|
NlaTrack *nlt;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write all the tracks */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (nlt = nlabase->first; nlt; nlt = nlt->next) {
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write the track first */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, NlaTrack, 1, nlt);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write the track's strips */
|
|
|
|
write_nlastrips(wd, &nlt->strips);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_animdata(WriteData *wd, AnimData *adt)
|
|
|
|
{
|
|
|
|
AnimOverride *aor;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* firstly, just write the AnimData block */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, AnimData, 1, adt);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write drivers */
|
|
|
|
write_fcurves(wd, &adt->drivers);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write overrides */
|
|
|
|
// FIXME: are these needed?
|
2016-06-28 17:35:35 +10:00
|
|
|
for (aor = adt->overrides.first; aor; aor = aor->next) {
|
2010-12-13 08:08:09 +00:00
|
|
|
/* overrides consist of base data + rna_path */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, AnimOverride, 1, aor);
|
2016-06-28 17:35:35 +10:00
|
|
|
writedata(wd, DATA, strlen(aor->rna_path) + 1, aor->rna_path);
|
2010-12-13 08:08:09 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
// TODO write the remaps (if they are needed)
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2010-12-13 08:08:09 +00:00
|
|
|
/* write NLA data */
|
|
|
|
write_nladata(wd, &adt->nla_tracks);
|
|
|
|
}
|
|
|
|
|
2012-08-19 15:41:56 +00:00
|
|
|
static void write_curvemapping_curves(WriteData *wd, CurveMapping *cumap)
|
Orange:
- New UI element: the "Curve Button".
For mapping ranges (like 0 - 1) to another range, the curve button can be
used for proportional falloff, bone influences, painting density, etc.
Most evident use is of course to map RGB color with curves.
To be able to use it, you have to allocate a CurveMapping struct and pass
this on to the button. The CurveMapping API is in the new C file
blenkernel/intern/colortools.c
It's as simple as calling:
curvemap= curvemapping_add(3, 0, 0, 1, 1)
Which will create 3 curves, and sets a default 0-1 range. The current code
only supports up to 4 curves maximum per mapping struct.
The CurveMap button in Blender than handles allmost all editing.
Evaluating a single channel:
float newvalue= curvemapping_evaluateF(curvemap, 0, oldval);
Where the second argument is the channel index, here 0-1-2 are possible.
Or mapping a vector:
curvemapping_evaluate3F(curvemap, newvec, oldvec);
Optimized versions for byte or short mapping is possible too, not done yet.
In butspace.c I've added a template wrapper for buttons around the curve, to
reveil settings or show tools; check this screenie:
http://www.blender.org/bf/curves.jpg
- Buttons R, G, B: select channel
- icons + and -: zoom in, out
- icon 'wrench': menu with tools, like clear curve, set handle type
- icon 'clipping': menu with clip values, and to dis/enable clipping
- icon 'x': delete selection
In the curve button itself, only LMB clicks are handled (like all UI elements
in Blender).
- click on point: select
- shift+click on point: swap select
- click on point + drag: select point (if not selected) and move it
- click outside point + drag: translate view
- CTRL+click: add new point
- hold SHIFT while dragging to snap to grid
(Yes I know... either one of these can be Blender compliant, not both!)
- if you drag a point exactly on top of another, it merges them
Other fixes:
- Icons now draw using "Safe RasterPos", so they align with pixel boundary.
the old code made ints from the raster pos coordinate, which doesn't work
well for zoom in/out situations
- bug in Node editing: buttons could not get freed, causing in memory error
prints at end of a Blender session. That one was a very simple, but nasty
error causing me all evening last night to find!
(Hint; check diff of editnode.c, where uiDoButtons is called)
Last note: this adds 3 new files in our tree, I did scons, but not MSVC!
2006-01-08 11:41:06 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
for (int a = 0; a < CM_TOT; a++) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, CurveMapPoint, cumap->cm[a].totpoint, cumap->cm[a].curve);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
Orange:
- New UI element: the "Curve Button".
For mapping ranges (like 0 - 1) to another range, the curve button can be
used for proportional falloff, bone influences, painting density, etc.
Most evident use is of course to map RGB color with curves.
To be able to use it, you have to allocate a CurveMapping struct and pass
this on to the button. The CurveMapping API is in the new C file
blenkernel/intern/colortools.c
It's as simple as calling:
curvemap= curvemapping_add(3, 0, 0, 1, 1)
Which will create 3 curves, and sets a default 0-1 range. The current code
only supports up to 4 curves maximum per mapping struct.
The CurveMap button in Blender than handles allmost all editing.
Evaluating a single channel:
float newvalue= curvemapping_evaluateF(curvemap, 0, oldval);
Where the second argument is the channel index, here 0-1-2 are possible.
Or mapping a vector:
curvemapping_evaluate3F(curvemap, newvec, oldvec);
Optimized versions for byte or short mapping is possible too, not done yet.
In butspace.c I've added a template wrapper for buttons around the curve, to
reveil settings or show tools; check this screenie:
http://www.blender.org/bf/curves.jpg
- Buttons R, G, B: select channel
- icons + and -: zoom in, out
- icon 'wrench': menu with tools, like clear curve, set handle type
- icon 'clipping': menu with clip values, and to dis/enable clipping
- icon 'x': delete selection
In the curve button itself, only LMB clicks are handled (like all UI elements
in Blender).
- click on point: select
- shift+click on point: swap select
- click on point + drag: select point (if not selected) and move it
- click outside point + drag: translate view
- CTRL+click: add new point
- hold SHIFT while dragging to snap to grid
(Yes I know... either one of these can be Blender compliant, not both!)
- if you drag a point exactly on top of another, it merges them
Other fixes:
- Icons now draw using "Safe RasterPos", so they align with pixel boundary.
the old code made ints from the raster pos coordinate, which doesn't work
well for zoom in/out situations
- bug in Node editing: buttons could not get freed, causing in memory error
prints at end of a Blender session. That one was a very simple, but nasty
error causing me all evening last night to find!
(Hint; check diff of editnode.c, where uiDoButtons is called)
Last note: this adds 3 new files in our tree, I did scons, but not MSVC!
2006-01-08 11:41:06 +00:00
|
|
|
}
|
|
|
|
|
2012-08-19 15:41:56 +00:00
|
|
|
static void write_curvemapping(WriteData *wd, CurveMapping *cumap)
|
|
|
|
{
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, CurveMapping, 1, cumap);
|
2012-08-19 15:41:56 +00:00
|
|
|
|
|
|
|
write_curvemapping_curves(wd, cumap);
|
|
|
|
}
|
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
static void write_node_socket(WriteData *wd, bNodeTree *UNUSED(ntree), bNode *node, bNodeSocket *sock)
|
2011-09-05 21:01:50 +00:00
|
|
|
{
|
2013-03-18 16:34:57 +00:00
|
|
|
#ifdef USE_NODE_COMPAT_CUSTOMNODES
|
2016-11-18 22:41:56 +01:00
|
|
|
/* forward compatibility code, so older blenders still open (not for undo) */
|
2018-04-14 12:33:19 +02:00
|
|
|
if (wd->use_memfile == false) {
|
2016-11-18 22:41:56 +01:00
|
|
|
sock->stack_type = 1;
|
|
|
|
|
|
|
|
if (node->type == NODE_GROUP) {
|
|
|
|
bNodeTree *ngroup = (bNodeTree *)node->id;
|
|
|
|
if (ngroup) {
|
|
|
|
/* for node groups: look up the deprecated groupsock pointer */
|
|
|
|
sock->groupsock = ntreeFindSocketInterface(ngroup, sock->in_out, sock->identifier);
|
|
|
|
BLI_assert(sock->groupsock != NULL);
|
|
|
|
|
|
|
|
/* node group sockets now use the generic identifier string to verify group nodes,
|
|
|
|
* old blender uses the own_index.
|
|
|
|
*/
|
|
|
|
sock->own_index = sock->groupsock->own_index;
|
|
|
|
}
|
2011-09-06 16:51:10 +00:00
|
|
|
}
|
|
|
|
}
|
2013-03-18 16:34:57 +00:00
|
|
|
#endif
|
2011-09-06 16:51:10 +00:00
|
|
|
|
|
|
|
/* actual socket writing */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bNodeSocket, 1, sock);
|
2013-03-18 16:34:57 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (sock->prop) {
|
2013-03-18 16:34:57 +00:00
|
|
|
IDP_WriteProperty(sock->prop, wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
if (sock->default_value) {
|
2013-03-18 16:34:57 +00:00
|
|
|
writedata(wd, DATA, MEM_allocN_len(sock->default_value), sock->default_value);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2011-09-05 21:01:50 +00:00
|
|
|
}
|
2013-03-18 16:34:57 +00:00
|
|
|
static void write_node_socket_interface(WriteData *wd, bNodeTree *UNUSED(ntree), bNodeSocket *sock)
|
|
|
|
{
|
|
|
|
#ifdef USE_NODE_COMPAT_CUSTOMNODES
|
|
|
|
/* forward compatibility code, so older blenders still open */
|
|
|
|
sock->stack_type = 1;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
/* Reconstruct the deprecated default_value structs in socket interface DNA. */
|
|
|
|
if (sock->default_value == NULL && sock->typeinfo) {
|
|
|
|
node_socket_init_default_value(sock);
|
|
|
|
}
|
|
|
|
#endif
|
2011-09-05 21:01:50 +00:00
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
/* actual socket writing */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bNodeSocket, 1, sock);
|
2011-09-05 21:01:50 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (sock->prop) {
|
2013-03-18 16:34:57 +00:00
|
|
|
IDP_WriteProperty(sock->prop, wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
if (sock->default_value) {
|
2013-04-05 11:16:06 +00:00
|
|
|
writedata(wd, DATA, MEM_allocN_len(sock->default_value), sock->default_value);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2013-03-18 16:34:57 +00:00
|
|
|
}
|
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
|
|
|
/* this is only direct data, tree itself should have been written */
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_nodetree_nolib(WriteData *wd, bNodeTree *ntree)
|
Christmas coding work!
********* Node editor work:
- To enable Nodes for Materials, you have to set the "Use Nodes"
button, in the new Material buttons "Nodes" Panel or in header
of the Node editor. Doing this will disable Material-Layers.
- Nodes now execute materials ("shaders"), but still only using the
previewrender code.
- Nodes have (optional) previews for rendered images.
- Node headers allow to hide buttons and/or preview image
- Nodes can be dragged larger/smaller (right-bottom corner)
- Nodes can be hidden (minimized) with hotkey H
- CTRL+click on an Input Socket gives a popup with default values.
- Changing Material/Texture or Mix node will adjust Node title.
- Click-drag outside of a Node changes cursor to "Knife' and allows to
draw a rect where to cut Links.
- Added new node types RGBtoBW, Texture, In/Output, ColorRamp
- Material Nodes have options to ouput diffuse or specular, or to use
a negative normal. The input socket 'Normal' will force the material
to use that normal, otherwise it uses the normal from the Material
that has the node tree.
- When drawing a link between two not-matching sockets, Blender inserts
a converting node (now only for value/rgb combos)
- When drawing a link to an input socket that's already in use, the
old link will either disappear or flip to another unused socket.
- A click on a Material Node will activate it, and show all its settings
in the Material Buttons. Active Material Nodes draw the material icon
in red.
- A click on any node will show its options in the Node Panel in the
Material buttons.
- Multiple Output Nodes can be used, to sample contents of a tree, but
only one Output is the real one, which is indicated in a different
color and red material icon.
- Added ThemeColors for node types
- ALT+C will convert existing Material-Layers to Node... this currently
only adds the material/mix nodes and connects them. Dunno if this is
worth a lot of coding work to make perfect?
- Press C to call another "Solve order", which will show all possible
cyclic conflicts (if there are).
- Technical: nodes now use "Type" structs which define the
structure of nodes and in/output sockets. The Type structs store all
fixed info, callbacks, and allow to reconstruct saved Nodes to match
what is required by Blender.
- Defining (new) nodes now is as simple as filling in a fixed
Type struct, plus code some callbacks. A doc will be made!
- Node preview images are by default float
********* Icon drawing:
- Cleanup of how old icons were implemented in new system, making
them 16x16 too, correctly centered *and* scaled.
- Made drawing Icons use float coordinates
- Moved BIF_calcpreview_image() into interface_icons.c, renamed it
icon_from_image(). Removed a lot of unneeded Imbuf magic here! :)
- Skipped scaling and imbuf copying when icons are OK size
********* Preview render:
- Huge cleanup of code....
- renaming BIF_xxx calls that only were used internally
- BIF_previewrender() now accepts an argument for rendering method,
so it supports icons, buttonwindow previewrender and node editor
- Only a single BIF_preview_changed() call now exists, supporting all
signals as needed for buttos and node editor
********* More stuff:
- glutil.c, glaDrawPixelsSafe() and glaDrawPixelsTex() now accept format
argument for GL_FLOAT rects
- Made the ColorBand become a built-in button for interface.c
Was a load of cleanup work in buttons_shading.c...
- removed a load of unneeded glBlendFunc() calls
- Fixed bug in calculating text length for buttons (ancient!)
2005-12-28 15:42:51 +00:00
|
|
|
{
|
|
|
|
bNode *node;
|
|
|
|
bNodeSocket *sock;
|
|
|
|
bNodeLink *link;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Christmas coding work!
********* Node editor work:
- To enable Nodes for Materials, you have to set the "Use Nodes"
button, in the new Material buttons "Nodes" Panel or in header
of the Node editor. Doing this will disable Material-Layers.
- Nodes now execute materials ("shaders"), but still only using the
previewrender code.
- Nodes have (optional) previews for rendered images.
- Node headers allow to hide buttons and/or preview image
- Nodes can be dragged larger/smaller (right-bottom corner)
- Nodes can be hidden (minimized) with hotkey H
- CTRL+click on an Input Socket gives a popup with default values.
- Changing Material/Texture or Mix node will adjust Node title.
- Click-drag outside of a Node changes cursor to "Knife' and allows to
draw a rect where to cut Links.
- Added new node types RGBtoBW, Texture, In/Output, ColorRamp
- Material Nodes have options to ouput diffuse or specular, or to use
a negative normal. The input socket 'Normal' will force the material
to use that normal, otherwise it uses the normal from the Material
that has the node tree.
- When drawing a link between two not-matching sockets, Blender inserts
a converting node (now only for value/rgb combos)
- When drawing a link to an input socket that's already in use, the
old link will either disappear or flip to another unused socket.
- A click on a Material Node will activate it, and show all its settings
in the Material Buttons. Active Material Nodes draw the material icon
in red.
- A click on any node will show its options in the Node Panel in the
Material buttons.
- Multiple Output Nodes can be used, to sample contents of a tree, but
only one Output is the real one, which is indicated in a different
color and red material icon.
- Added ThemeColors for node types
- ALT+C will convert existing Material-Layers to Node... this currently
only adds the material/mix nodes and connects them. Dunno if this is
worth a lot of coding work to make perfect?
- Press C to call another "Solve order", which will show all possible
cyclic conflicts (if there are).
- Technical: nodes now use "Type" structs which define the
structure of nodes and in/output sockets. The Type structs store all
fixed info, callbacks, and allow to reconstruct saved Nodes to match
what is required by Blender.
- Defining (new) nodes now is as simple as filling in a fixed
Type struct, plus code some callbacks. A doc will be made!
- Node preview images are by default float
********* Icon drawing:
- Cleanup of how old icons were implemented in new system, making
them 16x16 too, correctly centered *and* scaled.
- Made drawing Icons use float coordinates
- Moved BIF_calcpreview_image() into interface_icons.c, renamed it
icon_from_image(). Removed a lot of unneeded Imbuf magic here! :)
- Skipped scaling and imbuf copying when icons are OK size
********* Preview render:
- Huge cleanup of code....
- renaming BIF_xxx calls that only were used internally
- BIF_previewrender() now accepts an argument for rendering method,
so it supports icons, buttonwindow previewrender and node editor
- Only a single BIF_preview_changed() call now exists, supporting all
signals as needed for buttos and node editor
********* More stuff:
- glutil.c, glaDrawPixelsSafe() and glaDrawPixelsTex() now accept format
argument for GL_FLOAT rects
- Made the ColorBand become a built-in button for interface.c
Was a load of cleanup work in buttons_shading.c...
- removed a load of unneeded glBlendFunc() calls
- Fixed bug in calculating text length for buttons (ancient!)
2005-12-28 15:42:51 +00:00
|
|
|
/* for link_list() speed, we write per list */
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
if (ntree->adt) {
|
|
|
|
write_animdata(wd, ntree->adt);
|
|
|
|
}
|
|
|
|
|
2013-03-18 18:25:05 +00:00
|
|
|
for (node = ntree->nodes.first; node; node = node->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bNode, 1, node);
|
Christmas coding work!
********* Node editor work:
- To enable Nodes for Materials, you have to set the "Use Nodes"
button, in the new Material buttons "Nodes" Panel or in header
of the Node editor. Doing this will disable Material-Layers.
- Nodes now execute materials ("shaders"), but still only using the
previewrender code.
- Nodes have (optional) previews for rendered images.
- Node headers allow to hide buttons and/or preview image
- Nodes can be dragged larger/smaller (right-bottom corner)
- Nodes can be hidden (minimized) with hotkey H
- CTRL+click on an Input Socket gives a popup with default values.
- Changing Material/Texture or Mix node will adjust Node title.
- Click-drag outside of a Node changes cursor to "Knife' and allows to
draw a rect where to cut Links.
- Added new node types RGBtoBW, Texture, In/Output, ColorRamp
- Material Nodes have options to ouput diffuse or specular, or to use
a negative normal. The input socket 'Normal' will force the material
to use that normal, otherwise it uses the normal from the Material
that has the node tree.
- When drawing a link between two not-matching sockets, Blender inserts
a converting node (now only for value/rgb combos)
- When drawing a link to an input socket that's already in use, the
old link will either disappear or flip to another unused socket.
- A click on a Material Node will activate it, and show all its settings
in the Material Buttons. Active Material Nodes draw the material icon
in red.
- A click on any node will show its options in the Node Panel in the
Material buttons.
- Multiple Output Nodes can be used, to sample contents of a tree, but
only one Output is the real one, which is indicated in a different
color and red material icon.
- Added ThemeColors for node types
- ALT+C will convert existing Material-Layers to Node... this currently
only adds the material/mix nodes and connects them. Dunno if this is
worth a lot of coding work to make perfect?
- Press C to call another "Solve order", which will show all possible
cyclic conflicts (if there are).
- Technical: nodes now use "Type" structs which define the
structure of nodes and in/output sockets. The Type structs store all
fixed info, callbacks, and allow to reconstruct saved Nodes to match
what is required by Blender.
- Defining (new) nodes now is as simple as filling in a fixed
Type struct, plus code some callbacks. A doc will be made!
- Node preview images are by default float
********* Icon drawing:
- Cleanup of how old icons were implemented in new system, making
them 16x16 too, correctly centered *and* scaled.
- Made drawing Icons use float coordinates
- Moved BIF_calcpreview_image() into interface_icons.c, renamed it
icon_from_image(). Removed a lot of unneeded Imbuf magic here! :)
- Skipped scaling and imbuf copying when icons are OK size
********* Preview render:
- Huge cleanup of code....
- renaming BIF_xxx calls that only were used internally
- BIF_previewrender() now accepts an argument for rendering method,
so it supports icons, buttonwindow previewrender and node editor
- Only a single BIF_preview_changed() call now exists, supporting all
signals as needed for buttos and node editor
********* More stuff:
- glutil.c, glaDrawPixelsSafe() and glaDrawPixelsTex() now accept format
argument for GL_FLOAT rects
- Made the ColorBand become a built-in button for interface.c
Was a load of cleanup work in buttons_shading.c...
- removed a load of unneeded glBlendFunc() calls
- Fixed bug in calculating text length for buttons (ancient!)
2005-12-28 15:42:51 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (node->prop) {
|
2013-03-18 16:34:57 +00:00
|
|
|
IDP_WriteProperty(node->prop, wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2013-03-18 16:34:57 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
for (sock = node->inputs.first; sock; sock = sock->next) {
|
2013-03-18 16:34:57 +00:00
|
|
|
write_node_socket(wd, ntree, node, sock);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
for (sock = node->outputs.first; sock; sock = sock->next) {
|
2013-03-18 16:34:57 +00:00
|
|
|
write_node_socket(wd, ntree, node, sock);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
for (link = node->internal_links.first; link; link = link->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bNodeLink, 1, link);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
2012-05-29 09:37:23 +00:00
|
|
|
if (node->storage) {
|
Orange:
- New UI element: the "Curve Button".
For mapping ranges (like 0 - 1) to another range, the curve button can be
used for proportional falloff, bone influences, painting density, etc.
Most evident use is of course to map RGB color with curves.
To be able to use it, you have to allocate a CurveMapping struct and pass
this on to the button. The CurveMapping API is in the new C file
blenkernel/intern/colortools.c
It's as simple as calling:
curvemap= curvemapping_add(3, 0, 0, 1, 1)
Which will create 3 curves, and sets a default 0-1 range. The current code
only supports up to 4 curves maximum per mapping struct.
The CurveMap button in Blender than handles allmost all editing.
Evaluating a single channel:
float newvalue= curvemapping_evaluateF(curvemap, 0, oldval);
Where the second argument is the channel index, here 0-1-2 are possible.
Or mapping a vector:
curvemapping_evaluate3F(curvemap, newvec, oldvec);
Optimized versions for byte or short mapping is possible too, not done yet.
In butspace.c I've added a template wrapper for buttons around the curve, to
reveil settings or show tools; check this screenie:
http://www.blender.org/bf/curves.jpg
- Buttons R, G, B: select channel
- icons + and -: zoom in, out
- icon 'wrench': menu with tools, like clear curve, set handle type
- icon 'clipping': menu with clip values, and to dis/enable clipping
- icon 'x': delete selection
In the curve button itself, only LMB clicks are handled (like all UI elements
in Blender).
- click on point: select
- shift+click on point: swap select
- click on point + drag: select point (if not selected) and move it
- click outside point + drag: translate view
- CTRL+click: add new point
- hold SHIFT while dragging to snap to grid
(Yes I know... either one of these can be Blender compliant, not both!)
- if you drag a point exactly on top of another, it merges them
Other fixes:
- Icons now draw using "Safe RasterPos", so they align with pixel boundary.
the old code made ints from the raster pos coordinate, which doesn't work
well for zoom in/out situations
- bug in Node editing: buttons could not get freed, causing in memory error
prints at end of a Blender session. That one was a very simple, but nasty
error causing me all evening last night to find!
(Hint; check diff of editnode.c, where uiDoButtons is called)
Last note: this adds 3 new files in our tree, I did scons, but not MSVC!
2006-01-08 11:41:06 +00:00
|
|
|
/* could be handlerized at some point, now only 1 exception still */
|
2016-06-28 17:35:35 +10:00
|
|
|
if ((ntree->type == NTREE_SHADER) &&
|
|
|
|
ELEM(node->type, SH_NODE_CURVE_VEC, SH_NODE_CURVE_RGB))
|
|
|
|
{
|
Orange:
- New UI element: the "Curve Button".
For mapping ranges (like 0 - 1) to another range, the curve button can be
used for proportional falloff, bone influences, painting density, etc.
Most evident use is of course to map RGB color with curves.
To be able to use it, you have to allocate a CurveMapping struct and pass
this on to the button. The CurveMapping API is in the new C file
blenkernel/intern/colortools.c
It's as simple as calling:
curvemap= curvemapping_add(3, 0, 0, 1, 1)
Which will create 3 curves, and sets a default 0-1 range. The current code
only supports up to 4 curves maximum per mapping struct.
The CurveMap button in Blender than handles allmost all editing.
Evaluating a single channel:
float newvalue= curvemapping_evaluateF(curvemap, 0, oldval);
Where the second argument is the channel index, here 0-1-2 are possible.
Or mapping a vector:
curvemapping_evaluate3F(curvemap, newvec, oldvec);
Optimized versions for byte or short mapping is possible too, not done yet.
In butspace.c I've added a template wrapper for buttons around the curve, to
reveil settings or show tools; check this screenie:
http://www.blender.org/bf/curves.jpg
- Buttons R, G, B: select channel
- icons + and -: zoom in, out
- icon 'wrench': menu with tools, like clear curve, set handle type
- icon 'clipping': menu with clip values, and to dis/enable clipping
- icon 'x': delete selection
In the curve button itself, only LMB clicks are handled (like all UI elements
in Blender).
- click on point: select
- shift+click on point: swap select
- click on point + drag: select point (if not selected) and move it
- click outside point + drag: translate view
- CTRL+click: add new point
- hold SHIFT while dragging to snap to grid
(Yes I know... either one of these can be Blender compliant, not both!)
- if you drag a point exactly on top of another, it merges them
Other fixes:
- Icons now draw using "Safe RasterPos", so they align with pixel boundary.
the old code made ints from the raster pos coordinate, which doesn't work
well for zoom in/out situations
- bug in Node editing: buttons could not get freed, causing in memory error
prints at end of a Blender session. That one was a very simple, but nasty
error causing me all evening last night to find!
(Hint; check diff of editnode.c, where uiDoButtons is called)
Last note: this adds 3 new files in our tree, I did scons, but not MSVC!
2006-01-08 11:41:06 +00:00
|
|
|
write_curvemapping(wd, node->storage);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
else if (ntree->type == NTREE_SHADER &&
|
|
|
|
(node->type == SH_NODE_SCRIPT))
|
|
|
|
{
|
2012-11-03 14:32:26 +00:00
|
|
|
NodeShaderScript *nss = (NodeShaderScript *)node->storage;
|
2016-06-28 17:35:35 +10:00
|
|
|
if (nss->bytecode) {
|
|
|
|
writedata(wd, DATA, strlen(nss->bytecode) + 1, nss->bytecode);
|
|
|
|
}
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, node->typeinfo->storagename, 1, node->storage);
|
2012-11-03 14:32:26 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if ((ntree->type == NTREE_COMPOSIT) &&
|
|
|
|
ELEM(node->type, CMP_NODE_TIME, CMP_NODE_CURVE_VEC, CMP_NODE_CURVE_RGB, CMP_NODE_HUECORRECT))
|
|
|
|
{
|
Giant commit!
A full detailed description of this will be done later... is several days
of work. Here's a summary:
Render:
- Full cleanup of render code, removing *all* globals and bad level calls
all over blender. Render module is now not called abusive anymore
- API-fied calls to rendering
- Full recode of internal render pipeline. Is now rendering tiles by
default, prepared for much smarter 'bucket' render later.
- Each thread now can render a full part
- Renders were tested with 4 threads, goes fine, apart from some lookup
tables in softshadow and AO still
- Rendering is prepared to do multiple layers and passes
- No single 32 bits trick in render code anymore, all 100% floats now.
Writing images/movies
- moved writing images to blender kernel (bye bye 'schrijfplaatje'!)
- made a new Movie handle system, also in kernel. This will enable much
easier use of movies in Blender
PreviewRender:
- Using new render API, previewrender (in buttons) now uses regular render
code to generate images.
- new datafile 'preview.blend.c' has the preview scenes in it
- previews get rendered in exact displayed size (1 pixel = 1 pixel)
3D Preview render
- new; press Pkey in 3d window, for a panel that continuously renders
(pkey is for games, i know... but we dont do that in orange now!)
- this render works nearly identical to buttons-preview render, so it stops
rendering on any event (mouse, keyboard, etc)
- on moving/scaling the panel, the render code doesn't recreate all geometry
- same for shifting/panning view
- all other operations (now) regenerate the full render database still.
- this is WIP... but big fun, especially for simple scenes!
Compositor
- Using same node system as now in use for shaders, you can composit images
- works pretty straightforward... needs much more options/tools and integration
with rendering still
- is not threaded yet, nor is so smart to only recalculate changes... will be
done soon!
- the "Render Result" node will get all layers/passes as output sockets
- The "Output" node renders to a builtin image, which you can view in the Image
window. (yes, output nodes to render-result, and to files, is on the list!)
The Bad News
- "Unified Render" is removed. It might come back in some stage, but this
system should be built from scratch. I can't really understand this code...
I expect it is not much needed, especially with advanced layer/passes
control
- Panorama render, Field render, Motion blur, is not coded yet... (I had to
recode every single feature in render, so...!)
- Lens Flare is also not back... needs total revision, might become composit
effect though (using zbuffer for visibility)
- Part render is gone! (well, thats obvious, its default now).
- The render window is only restored with limited functionality... I am going
to check first the option to render to a Image window, so Blender can become
a true single-window application. :)
For example, the 'Spare render buffer' (jkey) doesnt work.
- Render with border, now default creates a smaller image
- No zbuffers are written yet... on the todo!
- Scons files and MSVC will need work to get compiling again
OK... thats what I can quickly recall. Now go compiling!
2006-01-23 22:05:47 +00:00
|
|
|
write_curvemapping(wd, node->storage);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
else if ((ntree->type == NTREE_TEXTURE) &&
|
|
|
|
(node->type == TEX_NODE_CURVE_RGB || node->type == TEX_NODE_CURVE_TIME))
|
|
|
|
{
|
2008-11-12 22:03:11 +00:00
|
|
|
write_curvemapping(wd, node->storage);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
else if ((ntree->type == NTREE_COMPOSIT) &&
|
|
|
|
(node->type == CMP_NODE_MOVIEDISTORTION))
|
|
|
|
{
|
2012-10-14 13:08:19 +00:00
|
|
|
/* pass */
|
|
|
|
}
|
2017-02-23 10:39:51 +01:00
|
|
|
else if ((ntree->type == NTREE_COMPOSIT) && (node->type == CMP_NODE_GLARE)) {
|
|
|
|
/* Simple forward compat for fix for T50736.
|
|
|
|
* Not ideal (there is no ideal solution here), but should do for now. */
|
|
|
|
NodeGlare *ndg = node->storage;
|
|
|
|
/* Not in undo case. */
|
2018-04-14 12:33:19 +02:00
|
|
|
if (wd->use_memfile == false) {
|
2017-02-23 10:39:51 +01:00
|
|
|
switch (ndg->type) {
|
|
|
|
case 2: /* Grrrr! magic numbers :( */
|
|
|
|
ndg->angle = ndg->streaks;
|
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
ndg->angle = ndg->star_45;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
writestruct_id(wd, DATA, node->typeinfo->storagename, 1, node->storage);
|
|
|
|
}
|
2018-07-18 13:03:09 +02:00
|
|
|
else if ((ntree->type == NTREE_COMPOSIT) && (node->type == CMP_NODE_CRYPTOMATTE)) {
|
|
|
|
NodeCryptomatte *nc = (NodeCryptomatte *)node->storage;
|
|
|
|
if (nc->matte_id) {
|
|
|
|
writedata(wd, DATA, strlen(nc->matte_id) + 1, nc->matte_id);
|
|
|
|
}
|
|
|
|
writestruct_id(wd, DATA, node->typeinfo->storagename, 1, node->storage);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, node->typeinfo->storagename, 1, node->storage);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
Orange:
- New UI element: the "Curve Button".
For mapping ranges (like 0 - 1) to another range, the curve button can be
used for proportional falloff, bone influences, painting density, etc.
Most evident use is of course to map RGB color with curves.
To be able to use it, you have to allocate a CurveMapping struct and pass
this on to the button. The CurveMapping API is in the new C file
blenkernel/intern/colortools.c
It's as simple as calling:
curvemap= curvemapping_add(3, 0, 0, 1, 1)
Which will create 3 curves, and sets a default 0-1 range. The current code
only supports up to 4 curves maximum per mapping struct.
The CurveMap button in Blender than handles allmost all editing.
Evaluating a single channel:
float newvalue= curvemapping_evaluateF(curvemap, 0, oldval);
Where the second argument is the channel index, here 0-1-2 are possible.
Or mapping a vector:
curvemapping_evaluate3F(curvemap, newvec, oldvec);
Optimized versions for byte or short mapping is possible too, not done yet.
In butspace.c I've added a template wrapper for buttons around the curve, to
reveil settings or show tools; check this screenie:
http://www.blender.org/bf/curves.jpg
- Buttons R, G, B: select channel
- icons + and -: zoom in, out
- icon 'wrench': menu with tools, like clear curve, set handle type
- icon 'clipping': menu with clip values, and to dis/enable clipping
- icon 'x': delete selection
In the curve button itself, only LMB clicks are handled (like all UI elements
in Blender).
- click on point: select
- shift+click on point: swap select
- click on point + drag: select point (if not selected) and move it
- click outside point + drag: translate view
- CTRL+click: add new point
- hold SHIFT while dragging to snap to grid
(Yes I know... either one of these can be Blender compliant, not both!)
- if you drag a point exactly on top of another, it merges them
Other fixes:
- Icons now draw using "Safe RasterPos", so they align with pixel boundary.
the old code made ints from the raster pos coordinate, which doesn't work
well for zoom in/out situations
- bug in Node editing: buttons could not get freed, causing in memory error
prints at end of a Blender session. That one was a very simple, but nasty
error causing me all evening last night to find!
(Hint; check diff of editnode.c, where uiDoButtons is called)
Last note: this adds 3 new files in our tree, I did scons, but not MSVC!
2006-01-08 11:41:06 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
if (node->type == CMP_NODE_OUTPUT_FILE) {
|
Adds a new node type for saving multiple image files from a single node.
Unlike the existing file output node this node has an arbitrary number of
possible input slots. It has a base path string that can be set to a general
base folder. Every input socket then uses its name as an extension of the base
path for file organization. This can include further subfolders on top of the
base path. Example:
Base path: '/home/user/myproject'
Input 1: 'Compo'
Input 2: 'Diffuse/'
Input 3: 'details/Normals'
would create output files
in /home/user/myproject: Compo0001.png, Compo0002.png, ...
in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base
given)
in /home/user/myproject/details: Normals0001.png, Normals0002.png, ...
Most settings for the node can be found in the sidebar (NKEY). New input sockets
can be added with the "Add Input" button. There is a list of input sockets and
below that the details for each socket can be changed, including the sub-path
and filename. Sockets can be removed here as well. By default each socket uses
the render settings file output format, but each can use its own format if
necessary.
To my knowledge this is the first node making use of such dynamic sockets in
trunk. So this is also a design test, other nodes might use this in the future.
Adding operator buttons on top of a node is a bit unwieldy atm, because all node
operators generally work on selected and/or active node(s). The operator button
would therefore either have to make sure the node is activated before the
operator is called (block callback maybe?) OR it has to store the node name
(risky, weak reference). For now it is only used in the sidebar, where only the
active node's buttons are displayed.
Also adds a new struct_type value to bNodeSocket, in order to distinguish
different socket types with the same data type (file inputs are SOCK_RGBA color
sockets). Would be nicer to use data type only for actual data evaluation, but
used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
|
|
|
/* inputs have own storage data */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (sock = node->inputs.first; sock; sock = sock->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, NodeImageMultiFileSocket, 1, sock->storage);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
Adds a new node type for saving multiple image files from a single node.
Unlike the existing file output node this node has an arbitrary number of
possible input slots. It has a base path string that can be set to a general
base folder. Every input socket then uses its name as an extension of the base
path for file organization. This can include further subfolders on top of the
base path. Example:
Base path: '/home/user/myproject'
Input 1: 'Compo'
Input 2: 'Diffuse/'
Input 3: 'details/Normals'
would create output files
in /home/user/myproject: Compo0001.png, Compo0002.png, ...
in /home/user/myproject/Diffuse: 0001.png, 0002.png, ... (no filename base
given)
in /home/user/myproject/details: Normals0001.png, Normals0002.png, ...
Most settings for the node can be found in the sidebar (NKEY). New input sockets
can be added with the "Add Input" button. There is a list of input sockets and
below that the details for each socket can be changed, including the sub-path
and filename. Sockets can be removed here as well. By default each socket uses
the render settings file output format, but each can use its own format if
necessary.
To my knowledge this is the first node making use of such dynamic sockets in
trunk. So this is also a design test, other nodes might use this in the future.
Adding operator buttons on top of a node is a bit unwieldy atm, because all node
operators generally work on selected and/or active node(s). The operator button
would therefore either have to make sure the node is activated before the
operator is called (block callback maybe?) OR it has to store the node name
(risky, weak reference). For now it is only used in the sidebar, where only the
active node's buttons are displayed.
Also adds a new struct_type value to bNodeSocket, in order to distinguish
different socket types with the same data type (file inputs are SOCK_RGBA color
sockets). Would be nicer to use data type only for actual data evaluation, but
used in too many places, this works ok for now.
2012-02-22 12:24:04 +00:00
|
|
|
}
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
if (ELEM(node->type, CMP_NODE_IMAGE, CMP_NODE_R_LAYERS)) {
|
2012-05-11 08:06:01 +00:00
|
|
|
/* write extra socket info */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (sock = node->outputs.first; sock; sock = sock->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, NodeImageLayer, 1, sock->storage);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2012-05-11 08:06:01 +00:00
|
|
|
}
|
Christmas coding work!
********* Node editor work:
- To enable Nodes for Materials, you have to set the "Use Nodes"
button, in the new Material buttons "Nodes" Panel or in header
of the Node editor. Doing this will disable Material-Layers.
- Nodes now execute materials ("shaders"), but still only using the
previewrender code.
- Nodes have (optional) previews for rendered images.
- Node headers allow to hide buttons and/or preview image
- Nodes can be dragged larger/smaller (right-bottom corner)
- Nodes can be hidden (minimized) with hotkey H
- CTRL+click on an Input Socket gives a popup with default values.
- Changing Material/Texture or Mix node will adjust Node title.
- Click-drag outside of a Node changes cursor to "Knife' and allows to
draw a rect where to cut Links.
- Added new node types RGBtoBW, Texture, In/Output, ColorRamp
- Material Nodes have options to ouput diffuse or specular, or to use
a negative normal. The input socket 'Normal' will force the material
to use that normal, otherwise it uses the normal from the Material
that has the node tree.
- When drawing a link between two not-matching sockets, Blender inserts
a converting node (now only for value/rgb combos)
- When drawing a link to an input socket that's already in use, the
old link will either disappear or flip to another unused socket.
- A click on a Material Node will activate it, and show all its settings
in the Material Buttons. Active Material Nodes draw the material icon
in red.
- A click on any node will show its options in the Node Panel in the
Material buttons.
- Multiple Output Nodes can be used, to sample contents of a tree, but
only one Output is the real one, which is indicated in a different
color and red material icon.
- Added ThemeColors for node types
- ALT+C will convert existing Material-Layers to Node... this currently
only adds the material/mix nodes and connects them. Dunno if this is
worth a lot of coding work to make perfect?
- Press C to call another "Solve order", which will show all possible
cyclic conflicts (if there are).
- Technical: nodes now use "Type" structs which define the
structure of nodes and in/output sockets. The Type structs store all
fixed info, callbacks, and allow to reconstruct saved Nodes to match
what is required by Blender.
- Defining (new) nodes now is as simple as filling in a fixed
Type struct, plus code some callbacks. A doc will be made!
- Node preview images are by default float
********* Icon drawing:
- Cleanup of how old icons were implemented in new system, making
them 16x16 too, correctly centered *and* scaled.
- Made drawing Icons use float coordinates
- Moved BIF_calcpreview_image() into interface_icons.c, renamed it
icon_from_image(). Removed a lot of unneeded Imbuf magic here! :)
- Skipped scaling and imbuf copying when icons are OK size
********* Preview render:
- Huge cleanup of code....
- renaming BIF_xxx calls that only were used internally
- BIF_previewrender() now accepts an argument for rendering method,
so it supports icons, buttonwindow previewrender and node editor
- Only a single BIF_preview_changed() call now exists, supporting all
signals as needed for buttos and node editor
********* More stuff:
- glutil.c, glaDrawPixelsSafe() and glaDrawPixelsTex() now accept format
argument for GL_FLOAT rects
- Made the ColorBand become a built-in button for interface.c
Was a load of cleanup work in buttons_shading.c...
- removed a load of unneeded glBlendFunc() calls
- Fixed bug in calculating text length for buttons (ancient!)
2005-12-28 15:42:51 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
for (link = ntree->links.first; link; link = link->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bNodeLink, 1, link);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
for (sock = ntree->inputs.first; sock; sock = sock->next) {
|
2013-03-18 16:34:57 +00:00
|
|
|
write_node_socket_interface(wd, ntree, sock);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
for (sock = ntree->outputs.first; sock; sock = sock->next) {
|
2013-03-18 16:34:57 +00:00
|
|
|
write_node_socket_interface(wd, ntree, sock);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
Christmas coding work!
********* Node editor work:
- To enable Nodes for Materials, you have to set the "Use Nodes"
button, in the new Material buttons "Nodes" Panel or in header
of the Node editor. Doing this will disable Material-Layers.
- Nodes now execute materials ("shaders"), but still only using the
previewrender code.
- Nodes have (optional) previews for rendered images.
- Node headers allow to hide buttons and/or preview image
- Nodes can be dragged larger/smaller (right-bottom corner)
- Nodes can be hidden (minimized) with hotkey H
- CTRL+click on an Input Socket gives a popup with default values.
- Changing Material/Texture or Mix node will adjust Node title.
- Click-drag outside of a Node changes cursor to "Knife' and allows to
draw a rect where to cut Links.
- Added new node types RGBtoBW, Texture, In/Output, ColorRamp
- Material Nodes have options to ouput diffuse or specular, or to use
a negative normal. The input socket 'Normal' will force the material
to use that normal, otherwise it uses the normal from the Material
that has the node tree.
- When drawing a link between two not-matching sockets, Blender inserts
a converting node (now only for value/rgb combos)
- When drawing a link to an input socket that's already in use, the
old link will either disappear or flip to another unused socket.
- A click on a Material Node will activate it, and show all its settings
in the Material Buttons. Active Material Nodes draw the material icon
in red.
- A click on any node will show its options in the Node Panel in the
Material buttons.
- Multiple Output Nodes can be used, to sample contents of a tree, but
only one Output is the real one, which is indicated in a different
color and red material icon.
- Added ThemeColors for node types
- ALT+C will convert existing Material-Layers to Node... this currently
only adds the material/mix nodes and connects them. Dunno if this is
worth a lot of coding work to make perfect?
- Press C to call another "Solve order", which will show all possible
cyclic conflicts (if there are).
- Technical: nodes now use "Type" structs which define the
structure of nodes and in/output sockets. The Type structs store all
fixed info, callbacks, and allow to reconstruct saved Nodes to match
what is required by Blender.
- Defining (new) nodes now is as simple as filling in a fixed
Type struct, plus code some callbacks. A doc will be made!
- Node preview images are by default float
********* Icon drawing:
- Cleanup of how old icons were implemented in new system, making
them 16x16 too, correctly centered *and* scaled.
- Made drawing Icons use float coordinates
- Moved BIF_calcpreview_image() into interface_icons.c, renamed it
icon_from_image(). Removed a lot of unneeded Imbuf magic here! :)
- Skipped scaling and imbuf copying when icons are OK size
********* Preview render:
- Huge cleanup of code....
- renaming BIF_xxx calls that only were used internally
- BIF_previewrender() now accepts an argument for rendering method,
so it supports icons, buttonwindow previewrender and node editor
- Only a single BIF_preview_changed() call now exists, supporting all
signals as needed for buttos and node editor
********* More stuff:
- glutil.c, glaDrawPixelsSafe() and glaDrawPixelsTex() now accept format
argument for GL_FLOAT rects
- Made the ColorBand become a built-in button for interface.c
Was a load of cleanup work in buttons_shading.c...
- removed a load of unneeded glBlendFunc() calls
- Fixed bug in calculating text length for buttons (ancient!)
2005-12-28 15:42:51 +00:00
|
|
|
}
|
|
|
|
|
2015-02-10 05:45:57 +11:00
|
|
|
/**
|
|
|
|
* Take care using 'use_active_win', since we wont want the currently active window
|
|
|
|
* to change which scene renders (currently only used for undo).
|
|
|
|
*/
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
static void current_screen_compat(
|
|
|
|
Main *mainvar, bool use_active_win,
|
2018-07-24 11:21:32 +02:00
|
|
|
bScreen **r_screen, Scene **r_scene, ViewLayer **r_view_layer)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2008-12-19 16:36:15 +00:00
|
|
|
wmWindowManager *wm;
|
2015-02-10 05:45:57 +11:00
|
|
|
wmWindow *window = NULL;
|
2008-12-19 16:36:15 +00:00
|
|
|
|
|
|
|
/* find a global current screen in the first open window, to have
|
|
|
|
* a reasonable default for reading in older versions */
|
2013-03-31 03:28:46 +00:00
|
|
|
wm = mainvar->wm.first;
|
2015-02-10 05:45:57 +11:00
|
|
|
|
|
|
|
if (wm) {
|
|
|
|
if (use_active_win) {
|
|
|
|
/* write the active window into the file, needed for multi-window undo T43424 */
|
|
|
|
for (window = wm->windows.first; window; window = window->next) {
|
|
|
|
if (window->active) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* fallback */
|
|
|
|
if (window == NULL) {
|
|
|
|
window = wm->windows.first;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
window = wm->windows.first;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
*r_screen = (window) ? BKE_workspace_active_screen_get(window->workspace_hook) : NULL;
|
|
|
|
*r_scene = (window) ? window->scene : NULL;
|
2018-07-24 11:21:32 +02:00
|
|
|
*r_view_layer = (window && *r_scene) ? BKE_view_layer_find(*r_scene, window->view_layer_name) : NULL;
|
2008-12-19 16:36:15 +00:00
|
|
|
}
|
|
|
|
|
2012-04-26 04:03:25 +00:00
|
|
|
typedef struct RenderInfo {
|
|
|
|
int sfra;
|
|
|
|
int efra;
|
|
|
|
char scene_name[MAX_ID_NAME - 2];
|
|
|
|
} RenderInfo;
|
|
|
|
|
2012-10-15 02:15:07 +00:00
|
|
|
/* was for historic render-deamon feature,
|
|
|
|
* now write because it can be easily extracted without
|
|
|
|
* reading the whole blend file */
|
|
|
|
static void write_renderinfo(WriteData *wd, Main *mainvar)
|
2008-12-19 16:36:15 +00:00
|
|
|
{
|
|
|
|
bScreen *curscreen;
|
2013-03-05 11:19:21 +00:00
|
|
|
Scene *sce, *curscene = NULL;
|
2018-07-24 11:21:32 +02:00
|
|
|
ViewLayer *view_layer;
|
2012-04-26 04:03:25 +00:00
|
|
|
RenderInfo data;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2012-10-15 02:15:07 +00:00
|
|
|
/* XXX in future, handle multiple windows with multiple screens? */
|
2018-07-24 11:21:32 +02:00
|
|
|
current_screen_compat(mainvar, false, &curscreen, &curscene, &view_layer);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
for (sce = mainvar->scene.first; sce; sce = sce->id.next) {
|
2013-03-05 11:19:21 +00:00
|
|
|
if (sce->id.lib == NULL && (sce == curscene || (sce->r.scemode & R_BG_RENDER))) {
|
2012-04-26 04:03:25 +00:00
|
|
|
data.sfra = sce->r.sfra;
|
|
|
|
data.efra = sce->r.efra;
|
|
|
|
memset(data.scene_name, 0, sizeof(data.scene_name));
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2012-04-26 04:03:25 +00:00
|
|
|
BLI_strncpy(data.scene_name, sce->id.name + 2, sizeof(data.scene_name));
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2012-04-26 04:03:25 +00:00
|
|
|
writedata(wd, REND, sizeof(data), &data);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
static void write_keymapitem(WriteData *wd, const wmKeyMapItem *kmi)
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
{
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, wmKeyMapItem, 1, kmi);
|
2016-06-28 17:35:35 +10:00
|
|
|
if (kmi->properties) {
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
IDP_WriteProperty(kmi->properties, wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
}
|
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
static void write_userdef(WriteData *wd, const UserDef *userdef)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-02-01 15:16:36 +11:00
|
|
|
writestruct(wd, USER, UserDef, 1, userdef);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
for (const bTheme *btheme = userdef->themes.first; btheme; btheme = btheme->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bTheme, 1, btheme);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
for (const wmKeyMap *keymap = userdef->user_keymaps.first; keymap; keymap = keymap->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, wmKeyMap, 1, keymap);
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
for (const wmKeyMapDiffItem *kmdi = keymap->diff_items.first; kmdi; kmdi = kmdi->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, wmKeyMapDiffItem, 1, kmdi);
|
2016-06-28 17:35:35 +10:00
|
|
|
if (kmdi->remove_item) {
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
write_keymapitem(wd, kmdi->remove_item);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
if (kmdi->add_item) {
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
write_keymapitem(wd, kmdi->add_item);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
}
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
for (const wmKeyMapItem *kmi = keymap->items.first; kmi; kmi = kmi->next) {
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
write_keymapitem(wd, kmi);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
- The basic layer for Themes in place!
- currently only implemented for 3d window
- create as many themes you like, and name them
- default theme is not editable, and always will be defined at startup
(initTheme)
- saves in .B.blend
- themes for spaces can become local too, so you can set individual
3d windows at theme 'Maya' or so. (to be implemented)
- it uses alpha as well...!
API:
This doesnt use the old method with BFCOLORID blahblah. The API is copied
from OpenGL conventions (naming) as much as possible:
- void BIF_ThemeColor(ScrArea *sa, int colorid)
sets a color... id's are in BIF_resources.h (TH_GRID, TH_WIRE, etc)
- void BIF_ThemeColorShade(ScrArea *sa, int colorid, int offset)
sets a color with offset, no more weird COLORSHADE_LGREY stuff
- void BIF_GetThemeColor3fv(ScrArea *sa, int colorid, float *col)
like opengl, this gives you in *col the three rgb values
- void BIF_GetThemeColor4ubv(ScrArea *sa, int colorid, char *col)
or the one to get 4 bytes
ThemeColor calls for globals (UI etc) can also call NULL for *sa... this
is to be implemented still.
Next step: cleaning up interface.c for all weird colorcalls.
2003-10-17 14:02:08 +00:00
|
|
|
}
|
2010-02-14 23:33:18 +00:00
|
|
|
|
2018-06-24 16:07:34 +02:00
|
|
|
for (const bUserMenu *um = userdef->user_menus.first; um; um = um->next) {
|
|
|
|
writestruct(wd, DATA, bUserMenu, 1, um);
|
|
|
|
for (const bUserMenuItem *umi = um->items.first; umi; umi = umi->next) {
|
|
|
|
if (umi->type == USER_MENU_TYPE_OPERATOR) {
|
|
|
|
const bUserMenuItem_Op *umi_op = (const bUserMenuItem_Op *)umi;
|
|
|
|
writestruct(wd, DATA, bUserMenuItem_Op, 1, umi_op);
|
|
|
|
if (umi_op->prop) {
|
|
|
|
IDP_WriteProperty(umi_op->prop, wd);
|
|
|
|
}
|
|
|
|
}
|
2018-06-30 20:59:10 +02:00
|
|
|
else if (umi->type == USER_MENU_TYPE_MENU) {
|
|
|
|
const bUserMenuItem_Menu *umi_mt = (const bUserMenuItem_Menu *)umi;
|
|
|
|
writestruct(wd, DATA, bUserMenuItem_Menu, 1, umi_mt);
|
|
|
|
}
|
|
|
|
else if (umi->type == USER_MENU_TYPE_PROP) {
|
|
|
|
const bUserMenuItem_Prop *umi_pr = (const bUserMenuItem_Prop *)umi;
|
|
|
|
writestruct(wd, DATA, bUserMenuItem_Prop, 1, umi_pr);
|
|
|
|
}
|
2018-06-24 16:07:34 +02:00
|
|
|
else {
|
|
|
|
writestruct(wd, DATA, bUserMenuItem, 1, umi);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
for (const bAddon *bext = userdef->addons.first; bext; bext = bext->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bAddon, 1, bext);
|
2012-12-29 10:24:42 +00:00
|
|
|
if (bext->prop) {
|
|
|
|
IDP_WriteProperty(bext->prop, wd);
|
|
|
|
}
|
|
|
|
}
|
2013-06-18 18:11:52 +00:00
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
for (const bPathCompare *path_cmp = userdef->autoexec_paths.first; path_cmp; path_cmp = path_cmp->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bPathCompare, 1, path_cmp);
|
2013-06-18 18:11:52 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-02-01 15:16:36 +11:00
|
|
|
for (const uiStyle *style = userdef->uistyles.first; style; style = style->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, uiStyle, 1, style);
|
2011-06-24 14:00:15 +00:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2016-12-28 17:30:58 +01:00
|
|
|
static void write_boid_state(WriteData *wd, BoidState *state)
|
|
|
|
{
|
|
|
|
BoidRule *rule = state->rules.first;
|
|
|
|
|
|
|
|
writestruct(wd, DATA, BoidState, 1, state);
|
|
|
|
|
|
|
|
for (; rule; rule = rule->next) {
|
|
|
|
switch (rule->type) {
|
|
|
|
case eBoidRuleType_Goal:
|
|
|
|
case eBoidRuleType_Avoid:
|
|
|
|
writestruct(wd, DATA, BoidRuleGoalAvoid, 1, rule);
|
|
|
|
break;
|
|
|
|
case eBoidRuleType_AvoidCollision:
|
|
|
|
writestruct(wd, DATA, BoidRuleAvoidCollision, 1, rule);
|
|
|
|
break;
|
|
|
|
case eBoidRuleType_FollowLeader:
|
|
|
|
writestruct(wd, DATA, BoidRuleFollowLeader, 1, rule);
|
|
|
|
break;
|
|
|
|
case eBoidRuleType_AverageSpeed:
|
|
|
|
writestruct(wd, DATA, BoidRuleAverageSpeed, 1, rule);
|
|
|
|
break;
|
|
|
|
case eBoidRuleType_Fight:
|
|
|
|
writestruct(wd, DATA, BoidRuleFight, 1, rule);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
writestruct(wd, DATA, BoidRule, 1, rule);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#if 0
|
|
|
|
BoidCondition *cond = state->conditions.first;
|
|
|
|
for (; cond; cond = cond->next) {
|
|
|
|
writestruct(wd, DATA, BoidCondition, 1, cond);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/* update this also to readfile.c */
|
|
|
|
static const char *ptcache_data_struct[] = {
|
|
|
|
"", // BPHYS_DATA_INDEX
|
|
|
|
"", // BPHYS_DATA_LOCATION
|
|
|
|
"", // BPHYS_DATA_VELOCITY
|
|
|
|
"", // BPHYS_DATA_ROTATION
|
|
|
|
"", // BPHYS_DATA_AVELOCITY / BPHYS_DATA_XCONST */
|
|
|
|
"", // BPHYS_DATA_SIZE:
|
|
|
|
"", // BPHYS_DATA_TIMES:
|
|
|
|
"BoidData" // case BPHYS_DATA_BOIDS:
|
|
|
|
};
|
|
|
|
static const char *ptcache_extra_struct[] = {
|
|
|
|
"",
|
|
|
|
"ParticleSpring"
|
|
|
|
};
|
|
|
|
static void write_pointcaches(WriteData *wd, ListBase *ptcaches)
|
|
|
|
{
|
|
|
|
PointCache *cache = ptcaches->first;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (; cache; cache = cache->next) {
|
|
|
|
writestruct(wd, DATA, PointCache, 1, cache);
|
|
|
|
|
|
|
|
if ((cache->flag & PTCACHE_DISK_CACHE) == 0) {
|
|
|
|
PTCacheMem *pm = cache->mem_cache.first;
|
|
|
|
|
|
|
|
for (; pm; pm = pm->next) {
|
|
|
|
PTCacheExtra *extra = pm->extradata.first;
|
|
|
|
|
|
|
|
writestruct(wd, DATA, PTCacheMem, 1, pm);
|
|
|
|
|
|
|
|
for (i = 0; i < BPHYS_TOT_DATA; i++) {
|
|
|
|
if (pm->data[i] && pm->data_types & (1 << i)) {
|
|
|
|
if (ptcache_data_struct[i][0] == '\0') {
|
|
|
|
writedata(wd, DATA, MEM_allocN_len(pm->data[i]), pm->data[i]);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
writestruct_id(wd, DATA, ptcache_data_struct[i], pm->totpoint, pm->data[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (; extra; extra = extra->next) {
|
|
|
|
if (ptcache_extra_struct[extra->type][0] == '\0') {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
writestruct(wd, DATA, PTCacheExtra, 1, extra);
|
|
|
|
writestruct_id(wd, DATA, ptcache_extra_struct[extra->type], extra->totdata, extra->data);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
|
|
|
static void write_particlesettings(WriteData *wd, ParticleSettings *part)
|
2016-12-28 17:30:58 +01:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (part->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_PA, ParticleSettings, 1, part);
|
|
|
|
write_iddata(wd, &part->id);
|
2016-12-28 17:30:58 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (part->adt) {
|
|
|
|
write_animdata(wd, part->adt);
|
|
|
|
}
|
|
|
|
writestruct(wd, DATA, PartDeflect, 1, part->pd);
|
|
|
|
writestruct(wd, DATA, PartDeflect, 1, part->pd2);
|
|
|
|
writestruct(wd, DATA, EffectorWeights, 1, part->effector_weights);
|
2016-12-28 17:30:58 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (part->clumpcurve) {
|
|
|
|
write_curvemapping(wd, part->clumpcurve);
|
|
|
|
}
|
|
|
|
if (part->roughcurve) {
|
|
|
|
write_curvemapping(wd, part->roughcurve);
|
|
|
|
}
|
2018-02-14 14:33:53 +01:00
|
|
|
if (part->twistcurve) {
|
|
|
|
write_curvemapping(wd, part->twistcurve);
|
|
|
|
}
|
2016-12-28 17:30:58 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (ParticleDupliWeight *dw = part->dupliweights.first; dw; dw = dw->next) {
|
|
|
|
/* update indices, but only if dw->ob is set (can be NULL after loading e.g.) */
|
|
|
|
if (dw->ob != NULL) {
|
|
|
|
dw->index = 0;
|
|
|
|
if (part->dup_group) { /* can be NULL if lining fails or set to None */
|
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)
|
2017-12-01 11:24:21 -02:00
|
|
|
{
|
|
|
|
if (object != dw->ob) {
|
|
|
|
dw->index++;
|
|
|
|
}
|
|
|
|
}
|
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;
|
2016-12-28 17:30:58 +01:00
|
|
|
}
|
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, ParticleDupliWeight, 1, dw);
|
|
|
|
}
|
2016-12-28 17:30:58 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (part->boids && part->phystype == PART_PHYS_BOIDS) {
|
|
|
|
writestruct(wd, DATA, BoidSettings, 1, part->boids);
|
2016-12-28 17:30:58 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (BoidState *state = part->boids->states.first; state; state = state->next) {
|
|
|
|
write_boid_state(wd, state);
|
2016-12-28 17:30:58 +01:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
|
|
|
if (part->fluid && part->phystype == PART_PHYS_FLUID) {
|
|
|
|
writestruct(wd, DATA, SPHFluidSettings, 1, part->fluid);
|
|
|
|
}
|
2016-12-28 17:30:58 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (int a = 0; a < MAX_MTEX; a++) {
|
|
|
|
if (part->mtex[a]) {
|
|
|
|
writestruct(wd, DATA, MTex, 1, part->mtex[a]);
|
2016-12-28 17:30:58 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2016-12-28 17:30:58 +01:00
|
|
|
static void write_particlesystems(WriteData *wd, ListBase *particles)
|
|
|
|
{
|
|
|
|
ParticleSystem *psys = particles->first;
|
|
|
|
ParticleTarget *pt;
|
|
|
|
int a;
|
|
|
|
|
|
|
|
for (; psys; psys = psys->next) {
|
|
|
|
writestruct(wd, DATA, ParticleSystem, 1, psys);
|
|
|
|
|
|
|
|
if (psys->particles) {
|
|
|
|
writestruct(wd, DATA, ParticleData, psys->totpart, psys->particles);
|
|
|
|
|
|
|
|
if (psys->particles->hair) {
|
|
|
|
ParticleData *pa = psys->particles;
|
|
|
|
|
|
|
|
for (a = 0; a < psys->totpart; a++, pa++) {
|
|
|
|
writestruct(wd, DATA, HairKey, pa->totkey, pa->hair);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (psys->particles->boid &&
|
|
|
|
(psys->part->phystype == PART_PHYS_BOIDS))
|
|
|
|
{
|
|
|
|
writestruct(wd, DATA, BoidParticle, psys->totpart, psys->particles->boid);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (psys->part->fluid &&
|
|
|
|
(psys->part->phystype == PART_PHYS_FLUID) &&
|
|
|
|
(psys->part->fluid->flag & SPH_VISCOELASTIC_SPRINGS))
|
|
|
|
{
|
|
|
|
writestruct(wd, DATA, ParticleSpring, psys->tot_fluidsprings, psys->fluid_springs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
pt = psys->targets.first;
|
|
|
|
for (; pt; pt = pt->next) {
|
|
|
|
writestruct(wd, DATA, ParticleTarget, 1, pt);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (psys->child) {
|
|
|
|
writestruct(wd, DATA, ChildParticle, psys->totchild, psys->child);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (psys->clmd) {
|
|
|
|
writestruct(wd, DATA, ClothModifierData, 1, psys->clmd);
|
|
|
|
writestruct(wd, DATA, ClothSimSettings, 1, psys->clmd->sim_parms);
|
|
|
|
writestruct(wd, DATA, ClothCollSettings, 1, psys->clmd->coll_parms);
|
|
|
|
}
|
|
|
|
|
|
|
|
write_pointcaches(wd, &psys->ptcaches);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Cleanup of MotionPaths+Ghosts (AnimViz) - Part 1
This commit sets up some of the groundwork necessary to extend the animation visualisation capabilities, previously only available for bones in PoseMode, to Objects as well. Also, some of the other goals of this refactor is to make future visualisation goodies (i.e. editable paths) more feasible...
(There's really nothing to see here yet. The following log notes are really just for my own reference to keep track of things.)
Currently, the following things have been done:
* New datastructures + settings have been tidied up, ready for usage
* Added these new types into the Object and PoseBone code as necessary, with freeing/adding/copying accounted for
* File IO code for the new data, including version patching to convert the old system to the new one.
* Set up the drawing system for motionpaths based on the old armature path drawing code. Armatures still draw using the old system, since the two systems use different storage systems.
* Started setting up the motionpath 'baking' code, but the core of this still needs to be coded...
Next Steps (after some semi-urgent Durian Driver changes):
* Port the ghosting/onionskinning code over too
* Finish motionpath baking code
* RNA wrapping for the new types
* Hooking up all the new code into the operators, etc.
2010-01-01 12:24:16 +00:00
|
|
|
static void write_motionpath(WriteData *wd, bMotionPath *mpath)
|
|
|
|
{
|
|
|
|
/* sanity checks */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (mpath == NULL) {
|
Cleanup of MotionPaths+Ghosts (AnimViz) - Part 1
This commit sets up some of the groundwork necessary to extend the animation visualisation capabilities, previously only available for bones in PoseMode, to Objects as well. Also, some of the other goals of this refactor is to make future visualisation goodies (i.e. editable paths) more feasible...
(There's really nothing to see here yet. The following log notes are really just for my own reference to keep track of things.)
Currently, the following things have been done:
* New datastructures + settings have been tidied up, ready for usage
* Added these new types into the Object and PoseBone code as necessary, with freeing/adding/copying accounted for
* File IO code for the new data, including version patching to convert the old system to the new one.
* Set up the drawing system for motionpaths based on the old armature path drawing code. Armatures still draw using the old system, since the two systems use different storage systems.
* Started setting up the motionpath 'baking' code, but the core of this still needs to be coded...
Next Steps (after some semi-urgent Durian Driver changes):
* Port the ghosting/onionskinning code over too
* Finish motionpath baking code
* RNA wrapping for the new types
* Hooking up all the new code into the operators, etc.
2010-01-01 12:24:16 +00:00
|
|
|
return;
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
Cleanup of MotionPaths+Ghosts (AnimViz) - Part 1
This commit sets up some of the groundwork necessary to extend the animation visualisation capabilities, previously only available for bones in PoseMode, to Objects as well. Also, some of the other goals of this refactor is to make future visualisation goodies (i.e. editable paths) more feasible...
(There's really nothing to see here yet. The following log notes are really just for my own reference to keep track of things.)
Currently, the following things have been done:
* New datastructures + settings have been tidied up, ready for usage
* Added these new types into the Object and PoseBone code as necessary, with freeing/adding/copying accounted for
* File IO code for the new data, including version patching to convert the old system to the new one.
* Set up the drawing system for motionpaths based on the old armature path drawing code. Armatures still draw using the old system, since the two systems use different storage systems.
* Started setting up the motionpath 'baking' code, but the core of this still needs to be coded...
Next Steps (after some semi-urgent Durian Driver changes):
* Port the ghosting/onionskinning code over too
* Finish motionpath baking code
* RNA wrapping for the new types
* Hooking up all the new code into the operators, etc.
2010-01-01 12:24:16 +00:00
|
|
|
/* firstly, just write the motionpath struct */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bMotionPath, 1, mpath);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Cleanup of MotionPaths+Ghosts (AnimViz) - Part 1
This commit sets up some of the groundwork necessary to extend the animation visualisation capabilities, previously only available for bones in PoseMode, to Objects as well. Also, some of the other goals of this refactor is to make future visualisation goodies (i.e. editable paths) more feasible...
(There's really nothing to see here yet. The following log notes are really just for my own reference to keep track of things.)
Currently, the following things have been done:
* New datastructures + settings have been tidied up, ready for usage
* Added these new types into the Object and PoseBone code as necessary, with freeing/adding/copying accounted for
* File IO code for the new data, including version patching to convert the old system to the new one.
* Set up the drawing system for motionpaths based on the old armature path drawing code. Armatures still draw using the old system, since the two systems use different storage systems.
* Started setting up the motionpath 'baking' code, but the core of this still needs to be coded...
Next Steps (after some semi-urgent Durian Driver changes):
* Port the ghosting/onionskinning code over too
* Finish motionpath baking code
* RNA wrapping for the new types
* Hooking up all the new code into the operators, etc.
2010-01-01 12:24:16 +00:00
|
|
|
/* now write the array of data */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bMotionPathVert, mpath->length, mpath->points);
|
Cleanup of MotionPaths+Ghosts (AnimViz) - Part 1
This commit sets up some of the groundwork necessary to extend the animation visualisation capabilities, previously only available for bones in PoseMode, to Objects as well. Also, some of the other goals of this refactor is to make future visualisation goodies (i.e. editable paths) more feasible...
(There's really nothing to see here yet. The following log notes are really just for my own reference to keep track of things.)
Currently, the following things have been done:
* New datastructures + settings have been tidied up, ready for usage
* Added these new types into the Object and PoseBone code as necessary, with freeing/adding/copying accounted for
* File IO code for the new data, including version patching to convert the old system to the new one.
* Set up the drawing system for motionpaths based on the old armature path drawing code. Armatures still draw using the old system, since the two systems use different storage systems.
* Started setting up the motionpath 'baking' code, but the core of this still needs to be coded...
Next Steps (after some semi-urgent Durian Driver changes):
* Port the ghosting/onionskinning code over too
* Finish motionpath baking code
* RNA wrapping for the new types
* Hooking up all the new code into the operators, etc.
2010-01-01 12:24:16 +00:00
|
|
|
}
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
static void write_constraints(WriteData *wd, ListBase *conlist)
|
|
|
|
{
|
|
|
|
bConstraint *con;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
for (con = conlist->first; con; con = con->next) {
|
|
|
|
const bConstraintTypeInfo *cti = BKE_constraint_typeinfo_get(con);
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
/* Write the specific data */
|
== Constraints System - Recode 2 ==
Once again, I've recoded the constraints system. This time, the goals were:
* To make it more future-proof by 'modernising' the coding style. The long functions filled with switch statements, have given way to function-pointers with smaller functions for specific purposes.
* To make it support constraints which use multiple targets more readily that it did. In the past, it was assumed that constraints could only have at most one target.
As a result, a lot of code has been shuffled around, and modified. Also, the subversion number has been bumped up.
Known issues:
* PyConstraints, which were the main motivation for supporting multiple-targets, are currently broken. There are some bimport() error that keeps causing problems. I've also temporarily removed the doDriver support, although it may return in another form soon.
* Constraints BPy-API is currently has a few features which currently don't work yet
* Outliner currently only displays the names of the constraints instead of the fancy subtarget/target/constraint-name display it used to do. What gets displayed here needs further investigation, as the old way was certainly not that great (and is not compatible with the new system too)
2007-10-21 23:00:29 +00:00
|
|
|
if (cti && con->data) {
|
|
|
|
/* firstly, just write the plain con->data struct */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, cti->structName, 1, con->data);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
== Constraints System - Recode 2 ==
Once again, I've recoded the constraints system. This time, the goals were:
* To make it more future-proof by 'modernising' the coding style. The long functions filled with switch statements, have given way to function-pointers with smaller functions for specific purposes.
* To make it support constraints which use multiple targets more readily that it did. In the past, it was assumed that constraints could only have at most one target.
As a result, a lot of code has been shuffled around, and modified. Also, the subversion number has been bumped up.
Known issues:
* PyConstraints, which were the main motivation for supporting multiple-targets, are currently broken. There are some bimport() error that keeps causing problems. I've also temporarily removed the doDriver support, although it may return in another form soon.
* Constraints BPy-API is currently has a few features which currently don't work yet
* Outliner currently only displays the names of the constraints instead of the fancy subtarget/target/constraint-name display it used to do. What gets displayed here needs further investigation, as the old way was certainly not that great (and is not compatible with the new system too)
2007-10-21 23:00:29 +00:00
|
|
|
/* do any constraint specific stuff */
|
|
|
|
switch (con->type) {
|
|
|
|
case CONSTRAINT_TYPE_PYTHON:
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
bPythonConstraint *data = con->data;
|
2007-10-24 10:03:19 +00:00
|
|
|
bConstraintTarget *ct;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2007-10-24 10:03:19 +00:00
|
|
|
/* write targets */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (ct = data->targets.first; ct; ct = ct->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bConstraintTarget, 1, ct);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
== Constraints System - Recode 2 ==
Once again, I've recoded the constraints system. This time, the goals were:
* To make it more future-proof by 'modernising' the coding style. The long functions filled with switch statements, have given way to function-pointers with smaller functions for specific purposes.
* To make it support constraints which use multiple targets more readily that it did. In the past, it was assumed that constraints could only have at most one target.
As a result, a lot of code has been shuffled around, and modified. Also, the subversion number has been bumped up.
Known issues:
* PyConstraints, which were the main motivation for supporting multiple-targets, are currently broken. There are some bimport() error that keeps causing problems. I've also temporarily removed the doDriver support, although it may return in another form soon.
* Constraints BPy-API is currently has a few features which currently don't work yet
* Outliner currently only displays the names of the constraints instead of the fancy subtarget/target/constraint-name display it used to do. What gets displayed here needs further investigation, as the old way was certainly not that great (and is not compatible with the new system too)
2007-10-21 23:00:29 +00:00
|
|
|
/* Write ID Properties -- and copy this comment EXACTLY for easy finding
|
2012-04-22 11:54:53 +00:00
|
|
|
* of library blocks that implement this.*/
|
== Constraints System - Recode 2 ==
Once again, I've recoded the constraints system. This time, the goals were:
* To make it more future-proof by 'modernising' the coding style. The long functions filled with switch statements, have given way to function-pointers with smaller functions for specific purposes.
* To make it support constraints which use multiple targets more readily that it did. In the past, it was assumed that constraints could only have at most one target.
As a result, a lot of code has been shuffled around, and modified. Also, the subversion number has been bumped up.
Known issues:
* PyConstraints, which were the main motivation for supporting multiple-targets, are currently broken. There are some bimport() error that keeps causing problems. I've also temporarily removed the doDriver support, although it may return in another form soon.
* Constraints BPy-API is currently has a few features which currently don't work yet
* Outliner currently only displays the names of the constraints instead of the fancy subtarget/target/constraint-name display it used to do. What gets displayed here needs further investigation, as the old way was certainly not that great (and is not compatible with the new system too)
2007-10-21 23:00:29 +00:00
|
|
|
IDP_WriteProperty(data->prop, wd);
|
2015-07-18 19:02:39 +10:00
|
|
|
|
2009-11-01 11:29:40 +00:00
|
|
|
break;
|
2015-07-18 19:02:39 +10:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
case CONSTRAINT_TYPE_SPLINEIK:
|
2009-11-01 11:29:40 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
bSplineIKConstraint *data = con->data;
|
|
|
|
|
2009-11-01 11:29:40 +00:00
|
|
|
/* write points array */
|
2016-06-28 17:35:35 +10:00
|
|
|
writedata(wd, DATA, sizeof(float) * (data->numpoints), data->points);
|
2015-07-18 19:02:39 +10:00
|
|
|
|
2009-11-01 11:29:40 +00:00
|
|
|
break;
|
2015-07-18 19:02:39 +10:00
|
|
|
}
|
2007-06-18 07:41:21 +00:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
/* Write the constraint */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bConstraint, 1, con);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_pose(WriteData *wd, bPose *pose)
|
|
|
|
{
|
2007-07-04 07:07:12 +00:00
|
|
|
bPoseChannel *chan;
|
== Bone Groups ==
I'm committing some work-in-progress code for "bone groups" now, as I there have been are some major bugs caused by the timeoffset stuff (some of my test files were not loading, and other files were showing all sorts of weird problems).
Anyway, in this commit, the following things for "bone groups" have been done:
* Bone groups are stored per armature (internally, this is per bPose block)
* Added controls for editing bone-groups per armature - "add", "remove", "rename". These can be found in the "Links and Materials" panel in PoseMode, beside the settings for PoseLib.
* Reorganised buttons for editing selected bones in PoseMode. I've replaced the "dist" and "weight" buttons (they existed in EditMode anyway) with a menu to choose the bone-group and the custom-shape-ob field. In the place of the old custom-shape-ob field, I've restored the "Hide" button. This might break muscle-memory a bit, but there isn't a lot of space to play with there.
Some stuff I'd been originally planning to do before committing:
* When adding keyframes for bones, an action-group with the same name as the bone's group will be added to the action, and the action-channel will be made a member of that.
* New action/bone groups have unique names (renaming/adding new should check if name exists before assigning it)
* There's a setting under Bone-Groups stuff which sets which custom-colour set is used to colour that group's bones. Currently, this is non-functional, as the necessary drawing code for armatures is not in place yet.
2008-01-20 02:55:35 +00:00
|
|
|
bActionGroup *grp;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
/* Write each channel */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (pose == NULL) {
|
2002-10-12 11:37:38 +00:00
|
|
|
return;
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2007-07-04 07:07:12 +00:00
|
|
|
/* Write channels */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (chan = pose->chanbase.first; chan; chan = chan->next) {
|
2009-05-18 02:25:33 +00:00
|
|
|
/* Write ID Properties -- and copy this comment EXACTLY for easy finding
|
2012-04-22 11:54:53 +00:00
|
|
|
* of library blocks that implement this.*/
|
2016-06-28 17:35:35 +10:00
|
|
|
if (chan->prop) {
|
2009-05-18 02:25:33 +00:00
|
|
|
IDP_WriteProperty(chan->prop, wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
write_constraints(wd, &chan->constraints);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Cleanup of MotionPaths+Ghosts (AnimViz) - Part 1
This commit sets up some of the groundwork necessary to extend the animation visualisation capabilities, previously only available for bones in PoseMode, to Objects as well. Also, some of the other goals of this refactor is to make future visualisation goodies (i.e. editable paths) more feasible...
(There's really nothing to see here yet. The following log notes are really just for my own reference to keep track of things.)
Currently, the following things have been done:
* New datastructures + settings have been tidied up, ready for usage
* Added these new types into the Object and PoseBone code as necessary, with freeing/adding/copying accounted for
* File IO code for the new data, including version patching to convert the old system to the new one.
* Set up the drawing system for motionpaths based on the old armature path drawing code. Armatures still draw using the old system, since the two systems use different storage systems.
* Started setting up the motionpath 'baking' code, but the core of this still needs to be coded...
Next Steps (after some semi-urgent Durian Driver changes):
* Port the ghosting/onionskinning code over too
* Finish motionpath baking code
* RNA wrapping for the new types
* Hooking up all the new code into the operators, etc.
2010-01-01 12:24:16 +00:00
|
|
|
write_motionpath(wd, chan->mpath);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
/* prevent crashes with autosave,
|
|
|
|
* when a bone duplicated in editmode has not yet been assigned to its posechannel */
|
|
|
|
if (chan->bone) {
|
|
|
|
/* gets restored on read, for library armatures */
|
|
|
|
chan->selectflag = chan->bone->flag & BONE_SELECTED;
|
|
|
|
}
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bPoseChannel, 1, chan);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
== Bone Groups ==
I'm committing some work-in-progress code for "bone groups" now, as I there have been are some major bugs caused by the timeoffset stuff (some of my test files were not loading, and other files were showing all sorts of weird problems).
Anyway, in this commit, the following things for "bone groups" have been done:
* Bone groups are stored per armature (internally, this is per bPose block)
* Added controls for editing bone-groups per armature - "add", "remove", "rename". These can be found in the "Links and Materials" panel in PoseMode, beside the settings for PoseLib.
* Reorganised buttons for editing selected bones in PoseMode. I've replaced the "dist" and "weight" buttons (they existed in EditMode anyway) with a menu to choose the bone-group and the custom-shape-ob field. In the place of the old custom-shape-ob field, I've restored the "Hide" button. This might break muscle-memory a bit, but there isn't a lot of space to play with there.
Some stuff I'd been originally planning to do before committing:
* When adding keyframes for bones, an action-group with the same name as the bone's group will be added to the action, and the action-channel will be made a member of that.
* New action/bone groups have unique names (renaming/adding new should check if name exists before assigning it)
* There's a setting under Bone-Groups stuff which sets which custom-colour set is used to colour that group's bones. Currently, this is non-functional, as the necessary drawing code for armatures is not in place yet.
2008-01-20 02:55:35 +00:00
|
|
|
/* Write groups */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (grp = pose->agroups.first; grp; grp = grp->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bActionGroup, 1, grp);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2009-09-24 21:22:24 +00:00
|
|
|
/* write IK param */
|
|
|
|
if (pose->ikparam) {
|
2015-01-01 23:26:03 +11:00
|
|
|
const char *structname = BKE_pose_ikparam_get_name(pose);
|
2016-06-28 17:35:35 +10:00
|
|
|
if (structname) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, structname, 1, pose->ikparam);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2009-09-24 21:22:24 +00:00
|
|
|
}
|
|
|
|
|
2007-07-04 07:07:12 +00:00
|
|
|
/* Write this pose */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bPose, 1, pose);
|
2009-09-24 21:22:24 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void write_defgroups(WriteData *wd, ListBase *defbase)
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
for (bDeformGroup *defgroup = defbase->first; defgroup; defgroup = defgroup->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, bDeformGroup, 1, defgroup);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2017-05-30 17:58:24 +10:00
|
|
|
static void write_fmaps(WriteData *wd, ListBase *fbase)
|
|
|
|
{
|
|
|
|
for (bFaceMap *fmap = fbase->first; fmap; fmap = fmap->next) {
|
|
|
|
writestruct(wd, DATA, bFaceMap, 1, fmap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-08-19 16:49:21 +00:00
|
|
|
static void write_modifiers(WriteData *wd, ListBase *modbase)
|
2005-07-19 20:14:17 +00:00
|
|
|
{
|
|
|
|
ModifierData *md;
|
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (modbase == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (md = modbase->first; md; md = md->next) {
|
2015-03-30 21:17:07 +11:00
|
|
|
const ModifierTypeInfo *mti = modifierType_getInfo(md->type);
|
2016-06-28 17:35:35 +10:00
|
|
|
if (mti == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, mti->structName, 1, md);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
if (md->type == eModifierType_Hook) {
|
|
|
|
HookModifierData *hmd = (HookModifierData *)md;
|
|
|
|
|
2015-02-04 07:04:21 +11:00
|
|
|
if (hmd->curfalloff) {
|
|
|
|
write_curvemapping(wd, hmd->curfalloff);
|
|
|
|
}
|
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
writedata(wd, DATA, sizeof(int) * hmd->totindex, hmd->indexar);
|
- added eModifierTypeFlag_RequiresOriginalData for modifiers that
can only follow deform (for example, they store mesh vertex
indices)
- added ModifierType.foreachObjectLink for iterating over Object
links inside modifier data (used for file load, relinking, etc)
- switched various modifiers_ functions to take object argument
instead of ListBase
- added user editable name field to modifiers
- bug fix, duplicate and make single user didn't relink object
pointers in modifier data
- added modifiers to outliner, needs icon
- added armature, hook, and softbody modifiers (softbody doesn't
do anything atm). added conversion of old hooks to modifiers.
NOTE-THE-FIRST: User name field is not initialized on loading 2.38 files
so if you have saved stuff with a cvs blender you will see blank names.
NOTE-THE-SECOND: Since modifiers aren't evaluated yet for non-Mesh
objects, hooks for lattices and curves are broken. Don't updated if
you actually, say, *use* Blender.
NOTE-THE-THIRD: Old hooks used a quirky weighting system during
deformation which can't be extended to modifiers. On the upside,
I doubt anyone relied on the old quirky system and the new system
makes much more sense. (Although the way falloff works is still
quite stupid I think).
2005-08-10 22:05:52 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_Cloth) {
|
|
|
|
ClothModifierData *clmd = (ClothModifierData *)md;
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ClothSimSettings, 1, clmd->sim_parms);
|
|
|
|
writestruct(wd, DATA, ClothCollSettings, 1, clmd->coll_parms);
|
|
|
|
writestruct(wd, DATA, EffectorWeights, 1, clmd->sim_parms->effector_weights);
|
2016-12-28 17:30:58 +01:00
|
|
|
write_pointcaches(wd, &clmd->ptcaches);
|
2012-10-21 05:46:41 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_Smoke) {
|
|
|
|
SmokeModifierData *smd = (SmokeModifierData *)md;
|
|
|
|
|
2012-04-28 06:31:57 +00:00
|
|
|
if (smd->type & MOD_SMOKE_TYPE_DOMAIN) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, SmokeDomainSettings, 1, smd->domain);
|
2010-12-16 16:09:23 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (smd->domain) {
|
2016-12-28 17:30:58 +01:00
|
|
|
write_pointcaches(wd, &(smd->domain->ptcaches[0]));
|
|
|
|
|
|
|
|
/* create fake pointcache so that old blender versions can read it */
|
|
|
|
smd->domain->point_cache[1] = BKE_ptcache_add(&smd->domain->ptcaches[1]);
|
|
|
|
smd->domain->point_cache[1]->flag |= PTCACHE_DISK_CACHE | PTCACHE_FAKE_SMOKE;
|
|
|
|
smd->domain->point_cache[1]->step = 1;
|
|
|
|
|
|
|
|
write_pointcaches(wd, &(smd->domain->ptcaches[1]));
|
2016-10-30 12:29:05 +01:00
|
|
|
|
|
|
|
if (smd->domain->coba) {
|
|
|
|
writestruct(wd, DATA, ColorBand, 1, smd->domain->coba);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-12-28 17:30:58 +01:00
|
|
|
|
|
|
|
/* cleanup the fake pointcache */
|
|
|
|
BKE_ptcache_free_list(&smd->domain->ptcaches[1]);
|
|
|
|
smd->domain->point_cache[1] = NULL;
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, EffectorWeights, 1, smd->domain->effector_weights);
|
2010-12-16 16:09:23 +00:00
|
|
|
}
|
2009-10-08 10:18:14 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (smd->type & MOD_SMOKE_TYPE_FLOW) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, SmokeFlowSettings, 1, smd->flow);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
else if (smd->type & MOD_SMOKE_TYPE_COLL) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, SmokeCollSettings, 1, smd->coll);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2012-10-21 05:46:41 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_Fluidsim) {
|
|
|
|
FluidsimModifierData *fluidmd = (FluidsimModifierData *)md;
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, FluidsimSettings, 1, fluidmd->fss);
|
2011-05-24 07:08:58 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_DynamicPaint) {
|
|
|
|
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
|
|
|
|
|
2012-04-28 06:31:57 +00:00
|
|
|
if (pmd->canvas) {
|
2011-06-16 10:41:00 +00:00
|
|
|
DynamicPaintSurface *surface;
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, DynamicPaintCanvasSettings, 1, pmd->canvas);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2011-06-16 10:41:00 +00:00
|
|
|
/* write surfaces */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (surface = pmd->canvas->surfaces.first; surface; surface = surface->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, DynamicPaintSurface, 1, surface);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2011-06-27 07:30:58 +00:00
|
|
|
/* write caches and effector weights */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (surface = pmd->canvas->surfaces.first; surface; surface = surface->next) {
|
2016-12-28 17:30:58 +01:00
|
|
|
write_pointcaches(wd, &(surface->ptcaches));
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, EffectorWeights, 1, surface->effector_weights);
|
2011-06-27 07:30:58 +00:00
|
|
|
}
|
2011-05-24 07:08:58 +00:00
|
|
|
}
|
2012-04-28 06:31:57 +00:00
|
|
|
if (pmd->brush) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, DynamicPaintBrushSettings, 1, pmd->brush);
|
|
|
|
writestruct(wd, DATA, ColorBand, 1, pmd->brush->paint_ramp);
|
|
|
|
writestruct(wd, DATA, ColorBand, 1, pmd->brush->vel_ramp);
|
2011-05-24 07:08:58 +00:00
|
|
|
}
|
2012-10-21 05:46:41 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_Collision) {
|
|
|
|
|
2012-06-30 22:49:33 +00:00
|
|
|
#if 0
|
2016-06-28 17:35:35 +10:00
|
|
|
CollisionModifierData *collmd = (CollisionModifierData *)md;
|
|
|
|
// TODO: CollisionModifier should use pointcache
|
2008-01-29 21:01:12 +00:00
|
|
|
// + have proper reset events before enabling this
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MVert, collmd->numverts, collmd->x);
|
|
|
|
writestruct(wd, DATA, MVert, collmd->numverts, collmd->xnew);
|
|
|
|
writestruct(wd, DATA, MFace, collmd->numfaces, collmd->mfaces);
|
2012-06-30 22:49:33 +00:00
|
|
|
#endif
|
2008-01-29 21:01:12 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_MeshDeform) {
|
|
|
|
MeshDeformModifierData *mmd = (MeshDeformModifierData *)md;
|
2007-11-11 22:54:14 +00:00
|
|
|
int size = mmd->dyngridsize;
|
2007-11-04 22:00:24 +00:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MDefInfluence, mmd->totinfluence, mmd->bindinfluences);
|
2013-01-08 02:06:16 +00:00
|
|
|
writedata(wd, DATA, sizeof(int) * (mmd->totvert + 1), mmd->bindoffsets);
|
|
|
|
writedata(wd, DATA, sizeof(float) * 3 * mmd->totcagevert,
|
2016-06-28 17:35:35 +10:00
|
|
|
mmd->bindcagecos);
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MDefCell, size * size * size, mmd->dyngrid);
|
|
|
|
writestruct(wd, DATA, MDefInfluence, mmd->totinfluence, mmd->dyninfluences);
|
2016-06-28 17:35:35 +10:00
|
|
|
writedata(wd, DATA, sizeof(int) * mmd->totvert, mmd->dynverts);
|
2007-11-04 22:00:24 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_Warp) {
|
|
|
|
WarpModifierData *tmd = (WarpModifierData *)md;
|
2012-03-24 06:18:31 +00:00
|
|
|
if (tmd->curfalloff) {
|
2011-05-01 15:16:59 +00:00
|
|
|
write_curvemapping(wd, tmd->curfalloff);
|
|
|
|
}
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_WeightVGEdit) {
|
|
|
|
WeightVGEditModifierData *wmd = (WeightVGEditModifierData *)md;
|
2011-07-25 15:27:01 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (wmd->cmap_curve) {
|
2011-07-25 15:27:01 +00:00
|
|
|
write_curvemapping(wd, wmd->cmap_curve);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2011-07-25 15:27:01 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
else if (md->type == eModifierType_LaplacianDeform) {
|
|
|
|
LaplacianDeformModifierData *lmd = (LaplacianDeformModifierData *)md;
|
2013-11-24 07:00:49 +11:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
writedata(wd, DATA, sizeof(float) * lmd->total_verts * 3, lmd->vertexco);
|
2013-11-24 07:00:49 +11:00
|
|
|
}
|
2015-03-29 04:44:05 +11:00
|
|
|
else if (md->type == eModifierType_CorrectiveSmooth) {
|
|
|
|
CorrectiveSmoothModifierData *csmd = (CorrectiveSmoothModifierData *)md;
|
|
|
|
|
|
|
|
if (csmd->bind_coords) {
|
|
|
|
writedata(wd, DATA, sizeof(float[3]) * csmd->bind_coords_num, csmd->bind_coords);
|
|
|
|
}
|
|
|
|
}
|
2017-02-27 12:39:14 -03:00
|
|
|
else if (md->type == eModifierType_SurfaceDeform) {
|
|
|
|
SurfaceDeformModifierData *smd = (SurfaceDeformModifierData *)md;
|
|
|
|
|
|
|
|
writestruct(wd, DATA, SDefVert, smd->numverts, smd->verts);
|
|
|
|
|
|
|
|
if (smd->verts) {
|
|
|
|
for (int i = 0; i < smd->numverts; i++) {
|
|
|
|
writestruct(wd, DATA, SDefBind, smd->verts[i].numbinds, smd->verts[i].binds);
|
|
|
|
|
|
|
|
if (smd->verts[i].binds) {
|
|
|
|
for (int j = 0; j < smd->verts[i].numbinds; j++) {
|
|
|
|
writedata(wd, DATA, sizeof(int) * smd->verts[i].binds[j].numverts, smd->verts[i].binds[j].vert_inds);
|
|
|
|
|
|
|
|
if (smd->verts[i].binds[j].mode == MOD_SDEF_MODE_CENTROID ||
|
|
|
|
smd->verts[i].binds[j].mode == MOD_SDEF_MODE_LOOPTRI)
|
|
|
|
{
|
|
|
|
writedata(wd, DATA, sizeof(float) * 3, smd->verts[i].binds[j].vert_weights);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
writedata(wd, DATA, sizeof(float) * smd->verts[i].binds[j].numverts, smd->verts[i].binds[j].vert_weights);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2005-07-19 20:14:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_object(WriteData *wd, Object *ob)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (ob->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_OB, Object, 1, ob);
|
|
|
|
write_iddata(wd, &ob->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (ob->adt) {
|
|
|
|
write_animdata(wd, ob->adt);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
writedata(wd, DATA, sizeof(void *) * ob->totcol, ob->mat);
|
|
|
|
writedata(wd, DATA, sizeof(char) * ob->totcol, ob->matbits);
|
|
|
|
/* write_effects(wd, &ob->effect); */ /* not used anymore */
|
|
|
|
|
|
|
|
if (ob->type == OB_ARMATURE) {
|
|
|
|
bArmature *arm = ob->data;
|
|
|
|
if (arm && ob->pose && arm->act_bone) {
|
|
|
|
BLI_strncpy(ob->pose->proxy_act_bone, arm->act_bone->name, sizeof(ob->pose->proxy_act_bone));
|
2010-05-04 12:31:24 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2010-05-04 12:31:24 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_pose(wd, ob->pose);
|
|
|
|
write_defgroups(wd, &ob->defbase);
|
2017-05-30 17:58:24 +10:00
|
|
|
write_fmaps(wd, &ob->fmaps);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_constraints(wd, &ob->constraints);
|
|
|
|
write_motionpath(wd, ob->mpath);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, PartDeflect, 1, ob->pd);
|
|
|
|
if (ob->soft) {
|
2018-07-04 11:22:15 +02:00
|
|
|
/* Set deprecated pointers to prevent crashes of older Blenders */
|
|
|
|
ob->soft->pointcache = ob->soft->shared->pointcache;
|
|
|
|
ob->soft->ptcaches = ob->soft->shared->ptcaches;
|
|
|
|
writestruct(wd, DATA, SoftBody, 1, ob->soft);
|
|
|
|
writestruct(wd, DATA, SoftBody_Shared, 1, ob->soft->shared);
|
|
|
|
write_pointcaches(wd, &(ob->soft->shared->ptcaches));
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, EffectorWeights, 1, ob->soft->effector_weights);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (ob->rigidbody_object) {
|
|
|
|
/* TODO: if any extra data is added to handle duplis, will need separate function then */
|
|
|
|
writestruct(wd, DATA, RigidBodyOb, 1, ob->rigidbody_object);
|
|
|
|
}
|
|
|
|
if (ob->rigidbody_constraint) {
|
|
|
|
writestruct(wd, DATA, RigidBodyCon, 1, ob->rigidbody_constraint);
|
|
|
|
}
|
2013-01-23 05:56:56 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (ob->type == OB_EMPTY && ob->empty_drawtype == OB_EMPTY_IMAGE) {
|
|
|
|
writestruct(wd, DATA, ImageUser, 1, ob->iuser);
|
|
|
|
}
|
2014-01-13 21:57:05 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_particlesystems(wd, &ob->particlesystem);
|
|
|
|
write_modifiers(wd, &ob->modifiers);
|
2013-12-17 14:42:47 -08:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writelist(wd, DATA, LinkData, &ob->pc_ids);
|
|
|
|
writelist(wd, DATA, LodLevel, &ob->lodlevels);
|
2015-08-10 15:41:28 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_previews(wd, ob->preview);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_vfont(WriteData *wd, VFont *vf)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (vf->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_VF, VFont, 1, vf);
|
|
|
|
write_iddata(wd, &vf->id);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
if (vf->packedfile) {
|
|
|
|
PackedFile *pf = vf->packedfile;
|
|
|
|
writestruct(wd, DATA, PackedFile, 1, pf);
|
|
|
|
writedata(wd, DATA, pf->size, pf->data);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_key(WriteData *wd, Key *key)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (key->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_KE, Key, 1, key);
|
|
|
|
write_iddata(wd, &key->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (key->adt) {
|
|
|
|
write_animdata(wd, key->adt);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
for (KeyBlock *kb = key->block.first; kb; kb = kb->next) {
|
|
|
|
writestruct(wd, DATA, KeyBlock, 1, kb);
|
|
|
|
if (kb->data) {
|
|
|
|
writedata(wd, DATA, kb->totelem * key->elemsize, kb->data);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_camera(WriteData *wd, Camera *cam)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (cam->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_CA, Camera, 1, cam);
|
|
|
|
write_iddata(wd, &cam->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (cam->adt) {
|
|
|
|
write_animdata(wd, cam->adt);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2017-10-26 21:40:37 +11:00
|
|
|
|
|
|
|
for (CameraBGImage *bgpic = cam->bg_images.first; bgpic; bgpic = bgpic->next) {
|
|
|
|
writestruct(wd, DATA, CameraBGImage, 1, bgpic);
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_mball(WriteData *wd, MetaBall *mb)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (mb->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_MB, MetaBall, 1, mb);
|
|
|
|
write_iddata(wd, &mb->id);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
writedata(wd, DATA, sizeof(void *) * mb->totcol, mb->mat);
|
|
|
|
if (mb->adt) {
|
|
|
|
write_animdata(wd, mb->adt);
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (MetaElem *ml = mb->elems.first; ml; ml = ml->next) {
|
|
|
|
writestruct(wd, DATA, MetaElem, 1, ml);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_curve(WriteData *wd, Curve *cu)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (cu->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_CU, Curve, 1, cu);
|
|
|
|
write_iddata(wd, &cu->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
writedata(wd, DATA, sizeof(void *) * cu->totcol, cu->mat);
|
|
|
|
if (cu->adt) {
|
|
|
|
write_animdata(wd, cu->adt);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (cu->vfont) {
|
|
|
|
writedata(wd, DATA, cu->len + 1, cu->str);
|
|
|
|
writestruct(wd, DATA, CharInfo, cu->len_wchar + 1, cu->strinfo);
|
|
|
|
writestruct(wd, DATA, TextBox, cu->totbox, cu->tb);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* is also the order of reading */
|
|
|
|
for (Nurb *nu = cu->nurb.first; nu; nu = nu->next) {
|
|
|
|
writestruct(wd, DATA, Nurb, 1, nu);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (Nurb *nu = cu->nurb.first; nu; nu = nu->next) {
|
|
|
|
if (nu->type == CU_BEZIER) {
|
|
|
|
writestruct(wd, DATA, BezTriple, nu->pntsu, nu->bezt);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
else {
|
|
|
|
writestruct(wd, DATA, BPoint, nu->pntsu * nu->pntsv, nu->bp);
|
|
|
|
if (nu->knotsu) {
|
|
|
|
writedata(wd, DATA, KNOTSU(nu) * sizeof(float), nu->knotsu);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (nu->knotsv) {
|
|
|
|
writedata(wd, DATA, KNOTSV(nu) * sizeof(float), nu->knotsv);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_dverts(WriteData *wd, int count, MDeformVert *dvlist)
|
|
|
|
{
|
|
|
|
if (dvlist) {
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2006-09-03 12:16:14 +00:00
|
|
|
/* Write the dvert list */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MDeformVert, count, dvlist);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2006-09-03 12:16:14 +00:00
|
|
|
/* Write deformation data for each dvert */
|
2016-06-28 17:35:35 +10:00
|
|
|
for (int i = 0; i < count; i++) {
|
|
|
|
if (dvlist[i].dw) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MDeformWeight, dvlist[i].totweight, dvlist[i].dw);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-11-25 14:27:50 +00:00
|
|
|
static void write_mdisps(WriteData *wd, int count, MDisps *mdlist, int external)
|
2009-01-06 18:59:03 +00:00
|
|
|
{
|
2012-03-24 06:18:31 +00:00
|
|
|
if (mdlist) {
|
2009-01-06 18:59:03 +00:00
|
|
|
int i;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MDisps, count, mdlist);
|
2012-03-24 06:18:31 +00:00
|
|
|
for (i = 0; i < count; ++i) {
|
2012-03-14 06:31:38 +00:00
|
|
|
MDisps *md = &mdlist[i];
|
2012-03-24 06:18:31 +00:00
|
|
|
if (md->disps) {
|
2016-06-28 17:35:35 +10:00
|
|
|
if (!external) {
|
2013-01-08 02:06:16 +00:00
|
|
|
writedata(wd, DATA, sizeof(float) * 3 * md->totdisp, md->disps);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2009-11-25 14:27:50 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
if (md->hidden) {
|
2012-03-14 06:31:38 +00:00
|
|
|
writedata(wd, DATA, BLI_BITMAP_SIZE(md->totdisp), md->hidden);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2009-01-06 18:59:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-10 20:33:24 +00:00
|
|
|
static void write_grid_paint_mask(WriteData *wd, int count, GridPaintMask *grid_paint_mask)
|
|
|
|
{
|
2012-05-22 22:03:41 +00:00
|
|
|
if (grid_paint_mask) {
|
2012-05-10 20:33:24 +00:00
|
|
|
int i;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, GridPaintMask, count, grid_paint_mask);
|
2012-05-22 22:03:41 +00:00
|
|
|
for (i = 0; i < count; ++i) {
|
2012-05-10 20:33:24 +00:00
|
|
|
GridPaintMask *gpm = &grid_paint_mask[i];
|
2012-05-22 22:03:41 +00:00
|
|
|
if (gpm->data) {
|
2013-10-01 09:17:35 +00:00
|
|
|
const int gridsize = BKE_ccg_gridsize(gpm->level);
|
2012-05-10 20:33:24 +00:00
|
|
|
writedata(wd, DATA,
|
2012-05-22 22:03:41 +00:00
|
|
|
sizeof(*gpm->data) * gridsize * gridsize,
|
|
|
|
gpm->data);
|
2012-05-10 20:33:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-21 12:02:11 +02:00
|
|
|
static void write_customdata(
|
|
|
|
WriteData *wd, ID *id, int count, CustomData *data, CustomDataLayer *layers,
|
|
|
|
int partial_type, int partial_count)
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2009-12-10 14:26:06 +00:00
|
|
|
/* write external customdata (not for undo) */
|
2018-04-14 12:33:19 +02:00
|
|
|
if (data->external && (wd->use_memfile == false)) {
|
2015-04-23 20:43:29 +02:00
|
|
|
CustomData_external_write(data, id, CD_MASK_MESH, count, 0);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2009-11-25 14:27:50 +00:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_at_address(wd, DATA, CustomDataLayer, data->totlayer, data->layers, layers);
|
2009-11-25 14:27:50 +00:00
|
|
|
|
2015-04-23 20:43:29 +02:00
|
|
|
for (i = 0; i < data->totlayer; i++) {
|
2015-07-21 12:02:11 +02:00
|
|
|
CustomDataLayer *layer = &layers[i];
|
2010-12-03 17:05:21 +00:00
|
|
|
const char *structname;
|
2007-02-10 23:47:31 +00:00
|
|
|
int structnum, datasize;
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
|
|
|
|
if (layer->type == CD_MDEFORMVERT) {
|
|
|
|
/* layer types that allocate own memory need special handling */
|
|
|
|
write_dverts(wd, count, layer->data);
|
|
|
|
}
|
2009-01-06 18:59:03 +00:00
|
|
|
else if (layer->type == CD_MDISPS) {
|
2009-11-25 14:27:50 +00:00
|
|
|
write_mdisps(wd, count, layer->data, layer->flag & CD_FLAG_EXTERNAL);
|
2009-01-06 18:59:03 +00:00
|
|
|
}
|
2012-05-10 20:33:24 +00:00
|
|
|
else if (layer->type == CD_PAINT_MASK) {
|
2014-04-27 00:24:11 +10:00
|
|
|
const float *layer_data = layer->data;
|
2012-05-10 20:33:24 +00:00
|
|
|
writedata(wd, DATA, sizeof(*layer_data) * count, layer_data);
|
|
|
|
}
|
|
|
|
else if (layer->type == CD_GRID_PAINT_MASK) {
|
|
|
|
write_grid_paint_mask(wd, count, layer->data);
|
|
|
|
}
|
2017-05-30 17:58:24 +10:00
|
|
|
else if (layer->type == CD_FACEMAP) {
|
|
|
|
const int *layer_data = layer->data;
|
|
|
|
writedata(wd, DATA, sizeof(*layer_data) * count, layer_data);
|
|
|
|
}
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
else {
|
|
|
|
CustomData_file_write_info(layer->type, &structname, &structnum);
|
2007-02-10 23:47:31 +00:00
|
|
|
if (structnum) {
|
|
|
|
/* when using partial visibility, the MEdge and MFace layers
|
2012-04-22 11:54:53 +00:00
|
|
|
* are smaller than the original, so their type and count is
|
|
|
|
* passed to make this work */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (layer->type != partial_type) {
|
|
|
|
datasize = structnum * count;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
datasize = structnum * partial_count;
|
|
|
|
}
|
2007-02-10 23:47:31 +00:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, structname, datasize, layer->data);
|
2007-02-10 23:47:31 +00:00
|
|
|
}
|
2012-10-31 05:39:10 +00:00
|
|
|
else {
|
2011-11-26 13:11:55 +00:00
|
|
|
printf("%s error: layer '%s':%d - can't be written to file\n",
|
|
|
|
__func__, structname, layer->type);
|
2012-10-31 05:39:10 +00:00
|
|
|
}
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
}
|
|
|
|
}
|
2009-11-25 14:27:50 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (data->external) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, CustomDataExternal, 1, data->external);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_mesh(WriteData *wd, Mesh *mesh)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
CustomDataLayer *vlayers = NULL, vlayers_buff[CD_TEMP_CHUNK_SIZE];
|
|
|
|
CustomDataLayer *elayers = NULL, elayers_buff[CD_TEMP_CHUNK_SIZE];
|
|
|
|
CustomDataLayer *flayers = NULL, flayers_buff[CD_TEMP_CHUNK_SIZE];
|
|
|
|
CustomDataLayer *llayers = NULL, llayers_buff[CD_TEMP_CHUNK_SIZE];
|
|
|
|
CustomDataLayer *players = NULL, players_buff[CD_TEMP_CHUNK_SIZE];
|
|
|
|
|
2018-04-14 12:33:19 +02:00
|
|
|
if (mesh->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
2018-07-12 21:32:18 +02:00
|
|
|
{
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write a copy of the mesh, don't modify in place because it is
|
|
|
|
* not thread safe for threaded renders that are reading this */
|
|
|
|
Mesh *old_mesh = mesh;
|
|
|
|
Mesh copy_mesh = *mesh;
|
|
|
|
mesh = ©_mesh;
|
2013-04-12 15:33:09 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* cache only - don't write */
|
|
|
|
mesh->mface = NULL;
|
|
|
|
mesh->totface = 0;
|
|
|
|
memset(&mesh->fdata, 0, sizeof(mesh->fdata));
|
2015-04-23 20:43:29 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/**
|
|
|
|
* Those calls:
|
|
|
|
* - Reduce mesh->xdata.totlayer to number of layers to write.
|
|
|
|
* - Fill xlayers with those layers to be written.
|
|
|
|
* Note that mesh->xdata is from now on invalid for Blender, but this is why the whole mesh is
|
|
|
|
* a temp local copy!
|
|
|
|
*/
|
|
|
|
CustomData_file_write_prepare(&mesh->vdata, &vlayers, vlayers_buff, ARRAY_SIZE(vlayers_buff));
|
|
|
|
CustomData_file_write_prepare(&mesh->edata, &elayers, elayers_buff, ARRAY_SIZE(elayers_buff));
|
|
|
|
flayers = flayers_buff;
|
|
|
|
CustomData_file_write_prepare(&mesh->ldata, &llayers, llayers_buff, ARRAY_SIZE(llayers_buff));
|
|
|
|
CustomData_file_write_prepare(&mesh->pdata, &players, players_buff, ARRAY_SIZE(players_buff));
|
2012-01-02 12:37:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct_at_address(wd, ID_ME, Mesh, 1, old_mesh, mesh);
|
|
|
|
write_iddata(wd, &mesh->id);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
if (mesh->adt) {
|
|
|
|
write_animdata(wd, mesh->adt);
|
|
|
|
}
|
2006-11-17 06:14:15 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writedata(wd, DATA, sizeof(void *) * mesh->totcol, mesh->mat);
|
|
|
|
writedata(wd, DATA, sizeof(MSelect) * mesh->totselect, mesh->mselect);
|
2004-07-08 20:38:27 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_customdata(wd, &mesh->id, mesh->totvert, &mesh->vdata, vlayers, -1, 0);
|
|
|
|
write_customdata(wd, &mesh->id, mesh->totedge, &mesh->edata, elayers, -1, 0);
|
|
|
|
/* fdata is really a dummy - written so slots align */
|
|
|
|
write_customdata(wd, &mesh->id, mesh->totface, &mesh->fdata, flayers, -1, 0);
|
|
|
|
write_customdata(wd, &mesh->id, mesh->totloop, &mesh->ldata, llayers, -1, 0);
|
|
|
|
write_customdata(wd, &mesh->id, mesh->totpoly, &mesh->pdata, players, -1, 0);
|
2015-04-23 20:43:29 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* restore pointer */
|
|
|
|
mesh = old_mesh;
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-07-07 16:02:45 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (vlayers && vlayers != vlayers_buff) {
|
|
|
|
MEM_freeN(vlayers);
|
|
|
|
}
|
|
|
|
if (elayers && elayers != elayers_buff) {
|
|
|
|
MEM_freeN(elayers);
|
|
|
|
}
|
|
|
|
if (flayers && flayers != flayers_buff) {
|
|
|
|
MEM_freeN(flayers);
|
|
|
|
}
|
|
|
|
if (llayers && llayers != llayers_buff) {
|
|
|
|
MEM_freeN(llayers);
|
|
|
|
}
|
|
|
|
if (players && players != players_buff) {
|
|
|
|
MEM_freeN(players);
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_lattice(WriteData *wd, Lattice *lt)
|
2006-09-03 12:16:14 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (lt->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_LT, Lattice, 1, lt);
|
|
|
|
write_iddata(wd, <->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write animdata */
|
|
|
|
if (lt->adt) {
|
|
|
|
write_animdata(wd, lt->adt);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
writestruct(wd, DATA, BPoint, lt->pntsu * lt->pntsv * lt->pntsw, lt->def);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_dverts(wd, lt->pntsu * lt->pntsv * lt->pntsw, lt->dvert);
|
2006-09-03 12:16:14 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_image(WriteData *wd, Image *ima)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (ima->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
ImagePackedFile *imapf;
|
2017-02-06 20:42:00 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* Some trickery to keep forward compatibility of packed images. */
|
|
|
|
BLI_assert(ima->packedfile == NULL);
|
|
|
|
if (ima->packedfiles.first != NULL) {
|
|
|
|
imapf = ima->packedfiles.first;
|
|
|
|
ima->packedfile = imapf->packedfile;
|
|
|
|
}
|
2015-05-26 14:43:50 +05:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_IM, Image, 1, ima);
|
|
|
|
write_iddata(wd, &ima->id);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (imapf = ima->packedfiles.first; imapf; imapf = imapf->next) {
|
|
|
|
writestruct(wd, DATA, ImagePackedFile, 1, imapf);
|
|
|
|
if (imapf->packedfile) {
|
|
|
|
PackedFile *pf = imapf->packedfile;
|
|
|
|
writestruct(wd, DATA, PackedFile, 1, pf);
|
|
|
|
writedata(wd, DATA, pf->size, pf->data);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2006-06-05 11:07:15 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_previews(wd, ima->preview);
|
2015-04-06 10:40:12 -03:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (ImageView *iv = ima->views.first; iv; iv = iv->next) {
|
|
|
|
writestruct(wd, DATA, ImageView, 1, iv);
|
2009-07-10 16:55:49 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, Stereo3dFormat, 1, ima->stereo3d_format);
|
2016-07-07 16:02:45 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
ima->packedfile = NULL;
|
2018-06-19 16:07:10 +02:00
|
|
|
|
|
|
|
writelist(wd, DATA, RenderSlot, &ima->renderslots);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_texture(WriteData *wd, Tex *tex)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (tex->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_TE, Tex, 1, tex);
|
|
|
|
write_iddata(wd, &tex->id);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (tex->adt) {
|
|
|
|
write_animdata(wd, tex->adt);
|
|
|
|
}
|
2009-02-20 16:39:39 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
if (tex->coba) {
|
|
|
|
writestruct(wd, DATA, ColorBand, 1, tex->coba);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* nodetree is integral part of texture, no libdata */
|
|
|
|
if (tex->nodetree) {
|
|
|
|
writestruct(wd, DATA, bNodeTree, 1, tex->nodetree);
|
|
|
|
write_nodetree_nolib(wd, tex->nodetree);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2004-09-05 13:43:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_previews(wd, tex->preview);
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_material(WriteData *wd, Material *ma)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (ma->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_MA, Material, 1, ma);
|
|
|
|
write_iddata(wd, &ma->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (ma->adt) {
|
|
|
|
write_animdata(wd, ma->adt);
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* nodetree is integral part of material, no libdata */
|
|
|
|
if (ma->nodetree) {
|
|
|
|
writestruct(wd, DATA, bNodeTree, 1, ma->nodetree);
|
|
|
|
write_nodetree_nolib(wd, ma->nodetree);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2007-09-02 17:25:03 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_previews(wd, ma->preview);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_world(WriteData *wd, World *wrld)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (wrld->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_WO, World, 1, wrld);
|
|
|
|
write_iddata(wd, &wrld->id);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (wrld->adt) {
|
|
|
|
write_animdata(wd, wrld->adt);
|
|
|
|
}
|
2011-11-02 18:55:32 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* nodetree is integral part of world, no libdata */
|
|
|
|
if (wrld->nodetree) {
|
|
|
|
writestruct(wd, DATA, bNodeTree, 1, wrld->nodetree);
|
|
|
|
write_nodetree_nolib(wd, wrld->nodetree);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
|
|
|
write_previews(wd, wrld->preview);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_lamp(WriteData *wd, Lamp *la)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (la->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_LA, Lamp, 1, la);
|
|
|
|
write_iddata(wd, &la->id);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (la->adt) {
|
|
|
|
write_animdata(wd, la->adt);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (la->curfalloff) {
|
|
|
|
write_curvemapping(wd, la->curfalloff);
|
|
|
|
}
|
2011-11-02 18:55:32 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* nodetree is integral part of lamps, no libdata */
|
|
|
|
if (la->nodetree) {
|
|
|
|
writestruct(wd, DATA, bNodeTree, 1, la->nodetree);
|
|
|
|
write_nodetree_nolib(wd, la->nodetree);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-07-06 23:27:22 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_previews(wd, la->preview);
|
|
|
|
}
|
2002-10-12 11:37:38 +00: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 void write_collection_nolib(WriteData *wd, Collection *collection)
|
|
|
|
{
|
|
|
|
/* Shared function for collection datablocks and scene master collection. */
|
|
|
|
write_previews(wd, collection->preview);
|
|
|
|
|
|
|
|
for (CollectionObject *cob = collection->gobject.first; cob; cob = cob->next) {
|
|
|
|
writestruct(wd, DATA, CollectionObject, 1, cob);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (CollectionChild *child = collection->children.first; child; child = child->next) {
|
|
|
|
writestruct(wd, DATA, CollectionChild, 1, child);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_collection(WriteData *wd, Collection *collection)
|
|
|
|
{
|
|
|
|
if (collection->id.us > 0 || wd->use_memfile) {
|
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_GR, Collection, 1, collection);
|
|
|
|
write_iddata(wd, &collection->id);
|
|
|
|
|
|
|
|
write_collection_nolib(wd, collection);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-19 15:41:56 +00:00
|
|
|
static void write_sequence_modifiers(WriteData *wd, ListBase *modbase)
|
|
|
|
{
|
|
|
|
SequenceModifierData *smd;
|
|
|
|
|
|
|
|
for (smd = modbase->first; smd; smd = smd->next) {
|
2015-03-30 21:17:07 +11:00
|
|
|
const SequenceModifierTypeInfo *smti = BKE_sequence_modifier_type_info_get(smd->type);
|
2012-08-19 15:41:56 +00:00
|
|
|
|
|
|
|
if (smti) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_id(wd, DATA, smti->struct_name, 1, smd);
|
2012-08-19 15:41:56 +00:00
|
|
|
|
|
|
|
if (smd->type == seqModifierType_Curves) {
|
2016-06-28 17:35:35 +10:00
|
|
|
CurvesModifierData *cmd = (CurvesModifierData *)smd;
|
2012-08-19 15:41:56 +00:00
|
|
|
|
|
|
|
write_curvemapping(wd, &cmd->curve_mapping);
|
|
|
|
}
|
|
|
|
else if (smd->type == seqModifierType_HueCorrect) {
|
2016-06-28 17:35:35 +10:00
|
|
|
HueCorrectModifierData *hcmd = (HueCorrectModifierData *)smd;
|
2012-08-19 15:41:56 +00:00
|
|
|
|
|
|
|
write_curvemapping(wd, &hcmd->curve_mapping);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, SequenceModifierData, 1, smd);
|
2012-08-19 15:41:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 10:05:07 +00:00
|
|
|
static void write_view_settings(WriteData *wd, ColorManagedViewSettings *view_settings)
|
|
|
|
{
|
|
|
|
if (view_settings->curve_mapping) {
|
|
|
|
write_curvemapping(wd, view_settings->curve_mapping);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-11 15:07:04 +01:00
|
|
|
static void write_paint(WriteData *wd, Paint *p)
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
if (p->cavity_curve) {
|
2015-02-11 15:07:04 +01:00
|
|
|
write_curvemapping(wd, p->cavity_curve);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2015-02-11 15:07:04 +01:00
|
|
|
}
|
|
|
|
|
Render Layers and Collections (merge from render-layers)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
2017-02-07 10:18:38 +01:00
|
|
|
static void write_layer_collections(WriteData *wd, ListBase *lb)
|
|
|
|
{
|
|
|
|
for (LayerCollection *lc = lb->first; lc; lc = lc->next) {
|
|
|
|
writestruct(wd, DATA, LayerCollection, 1, lc);
|
|
|
|
|
|
|
|
write_layer_collections(wd, &lc->layer_collections);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-01 11:24:21 -02:00
|
|
|
static void write_view_layer(WriteData *wd, ViewLayer *view_layer)
|
|
|
|
{
|
|
|
|
writestruct(wd, DATA, ViewLayer, 1, view_layer);
|
|
|
|
writelist(wd, DATA, Base, &view_layer->object_bases);
|
|
|
|
|
|
|
|
if (view_layer->id_properties) {
|
|
|
|
IDP_WriteProperty(view_layer->id_properties, wd);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (FreestyleModuleConfig *fmc = view_layer->freestyle_config.modules.first; fmc; fmc = fmc->next) {
|
|
|
|
writestruct(wd, DATA, FreestyleModuleConfig, 1, fmc);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (FreestyleLineSet *fls = view_layer->freestyle_config.linesets.first; fls; fls = fls->next) {
|
|
|
|
writestruct(wd, DATA, FreestyleLineSet, 1, fls);
|
|
|
|
}
|
|
|
|
write_layer_collections(wd, &view_layer->layer_collections);
|
|
|
|
}
|
|
|
|
|
2018-07-10 15:02:25 +02:00
|
|
|
static void write_lightcache_texture(WriteData *wd, LightCacheTexture *tex)
|
|
|
|
{
|
|
|
|
if (tex->data) {
|
|
|
|
size_t data_size = tex->components * tex->tex_size[0] * tex->tex_size[1] * tex->tex_size[2];
|
|
|
|
if (tex->data_type == LIGHTCACHETEX_FLOAT) {
|
|
|
|
data_size *= sizeof(float);
|
|
|
|
}
|
|
|
|
else if (tex->data_type == LIGHTCACHETEX_UINT) {
|
|
|
|
data_size *= sizeof(unsigned int);
|
|
|
|
}
|
|
|
|
writedata(wd, DATA, data_size, tex->data);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_lightcache(WriteData *wd, LightCache *cache)
|
|
|
|
{
|
|
|
|
write_lightcache_texture(wd, &cache->grid_tx);
|
|
|
|
write_lightcache_texture(wd, &cache->cube_tx);
|
|
|
|
|
|
|
|
if (cache->cube_mips) {
|
|
|
|
writestruct(wd, DATA, LightCacheTexture, cache->mips_len, cache->cube_mips);
|
|
|
|
for (int i = 0; i < cache->mips_len; ++i) {
|
|
|
|
write_lightcache_texture(wd, &cache->cube_mips[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
writestruct(wd, DATA, LightGridCache, cache->grid_len, cache->grid_data);
|
|
|
|
writestruct(wd, DATA, LightProbeCache, cache->cube_len, cache->cube_data);
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_scene(WriteData *wd, Scene *sce)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_SCE, Scene, 1, sce);
|
|
|
|
write_iddata(wd, &sce->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (sce->adt) {
|
|
|
|
write_animdata(wd, sce->adt);
|
|
|
|
}
|
|
|
|
write_keyingsets(wd, &sce->keyingsets);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* direct data */
|
|
|
|
ToolSettings *tos = sce->toolsettings;
|
|
|
|
writestruct(wd, DATA, ToolSettings, 1, tos);
|
|
|
|
if (tos->vpaint) {
|
|
|
|
writestruct(wd, DATA, VPaint, 1, tos->vpaint);
|
|
|
|
write_paint(wd, &tos->vpaint->paint);
|
|
|
|
}
|
|
|
|
if (tos->wpaint) {
|
|
|
|
writestruct(wd, DATA, VPaint, 1, tos->wpaint);
|
|
|
|
write_paint(wd, &tos->wpaint->paint);
|
|
|
|
}
|
|
|
|
if (tos->sculpt) {
|
|
|
|
writestruct(wd, DATA, Sculpt, 1, tos->sculpt);
|
|
|
|
write_paint(wd, &tos->sculpt->paint);
|
|
|
|
}
|
|
|
|
if (tos->uvsculpt) {
|
|
|
|
writestruct(wd, DATA, UvSculpt, 1, tos->uvsculpt);
|
|
|
|
write_paint(wd, &tos->uvsculpt->paint);
|
|
|
|
}
|
|
|
|
/* write grease-pencil drawing brushes to file */
|
|
|
|
writelist(wd, DATA, bGPDbrush, &tos->gp_brushes);
|
|
|
|
for (bGPDbrush *brush = tos->gp_brushes.first; brush; brush = brush->next) {
|
|
|
|
if (brush->cur_sensitivity) {
|
|
|
|
write_curvemapping(wd, brush->cur_sensitivity);
|
2012-01-17 16:31:13 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (brush->cur_strength) {
|
|
|
|
write_curvemapping(wd, brush->cur_strength);
|
2016-08-03 23:31:48 +02:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (brush->cur_jitter) {
|
|
|
|
write_curvemapping(wd, brush->cur_jitter);
|
2017-01-18 19:00:17 +13:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
|
|
|
/* write grease-pencil custom ipo curve to file */
|
|
|
|
if (tos->gp_interpolate.custom_ipo) {
|
|
|
|
write_curvemapping(wd, tos->gp_interpolate.custom_ipo);
|
|
|
|
}
|
2006-11-06 01:08:26 +00:00
|
|
|
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_paint(wd, &tos->imapaint.paint);
|
2017-02-06 20:42:00 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
Editing *ed = sce->ed;
|
|
|
|
if (ed) {
|
|
|
|
Sequence *seq;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, Editing, 1, ed);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* reset write flags too */
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
SEQ_BEGIN(ed, seq)
|
|
|
|
{
|
|
|
|
if (seq->strip) {
|
|
|
|
seq->strip->done = false;
|
|
|
|
}
|
|
|
|
writestruct(wd, DATA, Sequence, 1, seq);
|
|
|
|
}
|
|
|
|
SEQ_END
|
2015-04-06 10:40:12 -03:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
SEQ_BEGIN(ed, seq)
|
|
|
|
{
|
|
|
|
if (seq->strip && seq->strip->done == 0) {
|
|
|
|
/* write strip with 'done' at 0 because readfile */
|
2015-04-06 10:40:12 -03:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (seq->effectdata) {
|
|
|
|
switch (seq->type) {
|
|
|
|
case SEQ_TYPE_COLOR:
|
|
|
|
writestruct(wd, DATA, SolidColorVars, 1, seq->effectdata);
|
|
|
|
break;
|
|
|
|
case SEQ_TYPE_SPEED:
|
|
|
|
writestruct(wd, DATA, SpeedControlVars, 1, seq->effectdata);
|
|
|
|
break;
|
|
|
|
case SEQ_TYPE_WIPE:
|
|
|
|
writestruct(wd, DATA, WipeVars, 1, seq->effectdata);
|
|
|
|
break;
|
|
|
|
case SEQ_TYPE_GLOW:
|
|
|
|
writestruct(wd, DATA, GlowVars, 1, seq->effectdata);
|
|
|
|
break;
|
|
|
|
case SEQ_TYPE_TRANSFORM:
|
|
|
|
writestruct(wd, DATA, TransformVars, 1, seq->effectdata);
|
|
|
|
break;
|
|
|
|
case SEQ_TYPE_GAUSSIAN_BLUR:
|
|
|
|
writestruct(wd, DATA, GaussianBlurVars, 1, seq->effectdata);
|
|
|
|
break;
|
|
|
|
case SEQ_TYPE_TEXT:
|
|
|
|
writestruct(wd, DATA, TextVars, 1, seq->effectdata);
|
|
|
|
break;
|
2017-11-27 23:33:08 +01:00
|
|
|
case SEQ_TYPE_COLORMIX:
|
|
|
|
writestruct(wd, DATA, ColorMixVars, 1, seq->effectdata);
|
|
|
|
break;
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2012-08-19 15:41:56 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, Stereo3dFormat, 1, seq->stereo3d_format);
|
|
|
|
|
|
|
|
Strip *strip = seq->strip;
|
|
|
|
writestruct(wd, DATA, Strip, 1, strip);
|
|
|
|
if (seq->flag & SEQ_USE_CROP && strip->crop) {
|
|
|
|
writestruct(wd, DATA, StripCrop, 1, strip->crop);
|
|
|
|
}
|
|
|
|
if (seq->flag & SEQ_USE_TRANSFORM && strip->transform) {
|
|
|
|
writestruct(wd, DATA, StripTransform, 1, strip->transform);
|
|
|
|
}
|
|
|
|
if (seq->flag & SEQ_USE_PROXY && strip->proxy) {
|
|
|
|
writestruct(wd, DATA, StripProxy, 1, strip->proxy);
|
|
|
|
}
|
|
|
|
if (seq->type == SEQ_TYPE_IMAGE) {
|
|
|
|
writestruct(wd, DATA, StripElem,
|
2017-04-24 21:58:28 +10:00
|
|
|
MEM_allocN_len(strip->stripdata) / sizeof(struct StripElem),
|
|
|
|
strip->stripdata);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
|
|
|
else if (ELEM(seq->type, SEQ_TYPE_MOVIE, SEQ_TYPE_SOUND_RAM, SEQ_TYPE_SOUND_HD)) {
|
|
|
|
writestruct(wd, DATA, StripElem, 1, strip->stripdata);
|
2015-04-02 21:05:12 +11:00
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
strip->done = true;
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (seq->prop) {
|
|
|
|
IDP_WriteProperty(seq->prop, wd);
|
2004-11-13 12:55:59 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
|
|
|
write_sequence_modifiers(wd, &seq->modifiers);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
SEQ_END
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* new; meta stack too, even when its nasty restore code */
|
|
|
|
for (MetaStack *ms = ed->metastack.first; ms; ms = ms->next) {
|
|
|
|
writestruct(wd, DATA, MetaStack, 1, ms);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (sce->r.avicodecdata) {
|
|
|
|
writestruct(wd, DATA, AviCodecData, 1, sce->r.avicodecdata);
|
|
|
|
if (sce->r.avicodecdata->lpFormat) {
|
|
|
|
writedata(wd, DATA, sce->r.avicodecdata->cbFormat, sce->r.avicodecdata->lpFormat);
|
2003-05-21 01:21:07 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (sce->r.avicodecdata->lpParms) {
|
|
|
|
writedata(wd, DATA, sce->r.avicodecdata->cbParms, sce->r.avicodecdata->lpParms);
|
2008-05-11 20:40:55 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
|
|
|
if (sce->r.ffcodecdata.properties) {
|
|
|
|
IDP_WriteProperty(sce->r.ffcodecdata.properties, wd);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* writing dynamic list of TimeMarkers to the blend file */
|
|
|
|
for (TimeMarker *marker = sce->markers.first; marker; marker = marker->next) {
|
|
|
|
writestruct(wd, DATA, TimeMarker, 1, marker);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-18 09:12:44 +02:00
|
|
|
/* writing dynamic list of TransformOrientations to the blend file */
|
|
|
|
for (TransformOrientation *ts = sce->transform_spaces.first; ts; ts = ts->next) {
|
|
|
|
writestruct(wd, DATA, TransformOrientation, 1, ts);
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* writing MultiView to the blend file */
|
|
|
|
for (SceneRenderView *srv = sce->r.views.first; srv; srv = srv->next) {
|
|
|
|
writestruct(wd, DATA, SceneRenderView, 1, srv);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (sce->nodetree) {
|
|
|
|
writestruct(wd, DATA, bNodeTree, 1, sce->nodetree);
|
|
|
|
write_nodetree_nolib(wd, sce->nodetree);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_view_settings(wd, &sce->view_settings);
|
Render Layers and Collections (merge from render-layers)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
2017-02-07 10:18:38 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* writing RigidBodyWorld data to the blend file */
|
|
|
|
if (sce->rigidbody_world) {
|
2018-06-27 17:08:58 +02:00
|
|
|
/* Set deprecated pointers to prevent crashes of older Blenders */
|
|
|
|
sce->rigidbody_world->pointcache = sce->rigidbody_world->shared->pointcache;
|
|
|
|
sce->rigidbody_world->ptcaches = sce->rigidbody_world->shared->ptcaches;
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, RigidBodyWorld, 1, sce->rigidbody_world);
|
2018-06-27 17:08:58 +02:00
|
|
|
|
|
|
|
writestruct(wd, DATA, RigidBodyWorld_Shared, 1, sce->rigidbody_world->shared);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, EffectorWeights, 1, sce->rigidbody_world->effector_weights);
|
2018-06-27 17:08:58 +02:00
|
|
|
write_pointcaches(wd, &(sce->rigidbody_world->shared->ptcaches));
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Render Layers and Collections (merge from render-layers)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
2017-02-07 10:18:38 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_previews(wd, sce->preview);
|
|
|
|
write_curvemapping_curves(wd, &sce->r.mblur_shutter_curve);
|
2017-02-07 11:20:15 +01:00
|
|
|
|
2017-11-22 10:52:39 -02:00
|
|
|
for (ViewLayer *view_layer = sce->view_layers.first; view_layer; view_layer = view_layer->next) {
|
2017-12-01 11:24:21 -02:00
|
|
|
write_view_layer(wd, view_layer);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-07-07 16:02:45 +10: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 (sce->master_collection) {
|
|
|
|
writestruct(wd, DATA, Collection, 1, sce->master_collection);
|
|
|
|
write_collection_nolib(wd, sce->master_collection);
|
|
|
|
}
|
|
|
|
|
2018-07-10 15:02:25 +02:00
|
|
|
/* Eevee Lightcache */
|
|
|
|
if (sce->eevee.light_cache && !wd->use_memfile) {
|
|
|
|
writestruct(wd, DATA, LightCache, 1, sce->eevee.light_cache);
|
|
|
|
write_lightcache(wd, sce->eevee.light_cache);
|
|
|
|
}
|
|
|
|
|
2018-05-16 21:40:05 +02:00
|
|
|
/* Freed on doversion. */
|
|
|
|
BLI_assert(sce->layer_properties == NULL);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_gpencil(WriteData *wd, bGPdata *gpd)
|
2008-07-22 09:53:25 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (gpd->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write gpd data block to file */
|
|
|
|
writestruct(wd, ID_GD, bGPdata, 1, gpd);
|
|
|
|
write_iddata(wd, &gpd->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (gpd->adt) {
|
|
|
|
write_animdata(wd, gpd->adt);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write grease-pencil layers to file */
|
|
|
|
writelist(wd, DATA, bGPDlayer, &gpd->layers);
|
|
|
|
for (bGPDlayer *gpl = gpd->layers.first; gpl; gpl = gpl->next) {
|
|
|
|
/* write this layer's frames to file */
|
|
|
|
writelist(wd, DATA, bGPDframe, &gpl->frames);
|
|
|
|
for (bGPDframe *gpf = gpl->frames.first; gpf; gpf = gpf->next) {
|
|
|
|
/* write strokes */
|
|
|
|
writelist(wd, DATA, bGPDstroke, &gpf->strokes);
|
|
|
|
for (bGPDstroke *gps = gpf->strokes.first; gps; gps = gps->next) {
|
|
|
|
writestruct(wd, DATA, bGPDspoint, gps->totpoints, gps->points);
|
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
|
|
|
}
|
2008-07-22 09:53:25 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2017-02-06 20:42:00 +01:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write grease-pencil palettes */
|
|
|
|
writelist(wd, DATA, bGPDpalette, &gpd->palettes);
|
|
|
|
for (bGPDpalette *palette = gpd->palettes.first; palette; palette = palette->next) {
|
|
|
|
writelist(wd, DATA, bGPDpalettecolor, &palette->colors);
|
2008-07-22 09:53:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2.5
View3D has been split now in a local part (RegionView3D) and a
per-area part (old View3D). Currently local is:
- view transform
- camera zoom/offset
- gpencil (todo)
- custom clipping planes
Rest is in Area still, like active camera, draw type, layers,
localview, custom centers, around-settings, transform widget,
gridlines, and so on (mostly stuff as available in header).
To see it work; also added new feature for region split,
press SHIFT+ALT+CTRL+S for four-split.
The idea is to make a preset 4-split, configured to stick
to top/right/front views for three views.
Another cool idea to explore is to then box-clip all drawing
based on these 3 views.
Note about the code:
- currently view3d still stores some depricated settings, to
convert from older files. Not all settings are copied over
though, like custom clip planes or the 'lock view to object'.
- since some view3d ops are now on area level, the operators
for it should keep track of that.
Bugfix in transform: quat initialize in operator-invoke missed
one zero.
Als brought back GE to compile for missing Ipos and channels.
2009-01-19 16:54:41 +00:00
|
|
|
static void write_region(WriteData *wd, ARegion *ar, int spacetype)
|
2016-06-28 17:35:35 +10:00
|
|
|
{
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ARegion, 1, ar);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (ar->regiondata) {
|
2018-06-14 22:27:58 +02:00
|
|
|
if (ar->flag & RGN_FLAG_TEMP_REGIONDATA) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-04-28 06:31:57 +00:00
|
|
|
switch (spacetype) {
|
2.5
View3D has been split now in a local part (RegionView3D) and a
per-area part (old View3D). Currently local is:
- view transform
- camera zoom/offset
- gpencil (todo)
- custom clipping planes
Rest is in Area still, like active camera, draw type, layers,
localview, custom centers, around-settings, transform widget,
gridlines, and so on (mostly stuff as available in header).
To see it work; also added new feature for region split,
press SHIFT+ALT+CTRL+S for four-split.
The idea is to make a preset 4-split, configured to stick
to top/right/front views for three views.
Another cool idea to explore is to then box-clip all drawing
based on these 3 views.
Note about the code:
- currently view3d still stores some depricated settings, to
convert from older files. Not all settings are copied over
though, like custom clip planes or the 'lock view to object'.
- since some view3d ops are now on area level, the operators
for it should keep track of that.
Bugfix in transform: quat initialize in operator-invoke missed
one zero.
Als brought back GE to compile for missing Ipos and channels.
2009-01-19 16:54:41 +00:00
|
|
|
case SPACE_VIEW3D:
|
2016-06-28 17:35:35 +10:00
|
|
|
if (ar->regiontype == RGN_TYPE_WINDOW) {
|
|
|
|
RegionView3D *rv3d = ar->regiondata;
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, RegionView3D, 1, rv3d);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
if (rv3d->localvd) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, RegionView3D, 1, rv3d->localvd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
if (rv3d->clipbb) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, BoundBox, 1, rv3d->clipbb);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2.5
View3D has been split now in a local part (RegionView3D) and a
per-area part (old View3D). Currently local is:
- view transform
- camera zoom/offset
- gpencil (todo)
- custom clipping planes
Rest is in Area still, like active camera, draw type, layers,
localview, custom centers, around-settings, transform widget,
gridlines, and so on (mostly stuff as available in header).
To see it work; also added new feature for region split,
press SHIFT+ALT+CTRL+S for four-split.
The idea is to make a preset 4-split, configured to stick
to top/right/front views for three views.
Another cool idea to explore is to then box-clip all drawing
based on these 3 views.
Note about the code:
- currently view3d still stores some depricated settings, to
convert from older files. Not all settings are copied over
though, like custom clip planes or the 'lock view to object'.
- since some view3d ops are now on area level, the operators
for it should keep track of that.
Bugfix in transform: quat initialize in operator-invoke missed
one zero.
Als brought back GE to compile for missing Ipos and channels.
2009-01-19 16:54:41 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
else
|
|
|
|
printf("regiondata write missing!\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("regiondata write missing!\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-29 12:55:31 +00:00
|
|
|
static void write_uilist(WriteData *wd, uiList *ui_list)
|
|
|
|
{
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, uiList, 1, ui_list);
|
2013-08-29 12:55:31 +00:00
|
|
|
|
|
|
|
if (ui_list->properties) {
|
|
|
|
IDP_WriteProperty(ui_list->properties, wd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-06 21:58:47 +10:00
|
|
|
static void write_soops(WriteData *wd, SpaceOops *so)
|
2013-08-03 11:35:09 +00:00
|
|
|
{
|
|
|
|
BLI_mempool *ts = so->treestore;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-08-03 11:35:09 +00:00
|
|
|
if (ts) {
|
2016-07-06 21:58:47 +10:00
|
|
|
SpaceOops so_flat = *so;
|
|
|
|
|
2018-02-15 23:36:11 +11:00
|
|
|
int elems = BLI_mempool_len(ts);
|
2013-08-03 11:35:09 +00:00
|
|
|
/* linearize mempool to array */
|
|
|
|
TreeStoreElem *data = elems ? BLI_mempool_as_arrayN(ts, "TreeStoreElem") : NULL;
|
2013-08-06 05:35:54 +00:00
|
|
|
|
2013-08-03 11:35:09 +00:00
|
|
|
if (data) {
|
2016-07-06 21:58:47 +10:00
|
|
|
/* In this block we use the memory location of the treestore
|
|
|
|
* but _not_ its data, the addresses in this case are UUID's,
|
|
|
|
* since we can't rely on malloc giving us different values each time.
|
|
|
|
*/
|
|
|
|
TreeStore ts_flat = {0};
|
2013-08-06 05:35:54 +00:00
|
|
|
|
2016-07-06 21:58:47 +10:00
|
|
|
/* we know the treestore is at least as big as a pointer,
|
|
|
|
* so offsetting works to give us a UUID. */
|
|
|
|
void *data_addr = (void *)POINTER_OFFSET(ts, sizeof(void *));
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-07-06 21:58:47 +10:00
|
|
|
ts_flat.usedelem = elems;
|
|
|
|
ts_flat.totelem = elems;
|
|
|
|
ts_flat.data = data_addr;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, SpaceOops, 1, so);
|
2013-08-06 05:35:54 +00:00
|
|
|
|
2016-07-06 21:58:47 +10:00
|
|
|
writestruct_at_address(wd, DATA, TreeStore, 1, ts, &ts_flat);
|
|
|
|
writestruct_at_address(wd, DATA, TreeStoreElem, elems, data_addr, data);
|
2013-08-06 05:35:54 +00:00
|
|
|
|
2016-07-06 14:45:06 +02:00
|
|
|
MEM_freeN(data);
|
2013-08-06 05:35:54 +00:00
|
|
|
}
|
|
|
|
else {
|
2016-07-06 21:58:47 +10:00
|
|
|
so_flat.treestore = NULL;
|
|
|
|
writestruct_at_address(wd, DATA, SpaceOops, 1, so, &so_flat);
|
2013-08-03 11:35:09 +00:00
|
|
|
}
|
2013-09-21 10:46:58 +00:00
|
|
|
}
|
|
|
|
else {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, SpaceOops, 1, so);
|
2013-08-03 11:35:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-03 13:32:36 +02:00
|
|
|
static void write_panel_list(WriteData *wd, ListBase *lb)
|
|
|
|
{
|
|
|
|
for (Panel *pa = lb->first; pa; pa = pa->next) {
|
|
|
|
writestruct(wd, DATA, Panel, 1, pa);
|
|
|
|
write_panel_list(wd, &pa->children);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
static void write_area_regions(WriteData *wd, ScrArea *area)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-13 20:29:16 +02:00
|
|
|
for (ARegion *region = area->regionbase.first; region; region = region->next) {
|
|
|
|
write_region(wd, region, area->spacetype);
|
2018-06-03 13:32:36 +02:00
|
|
|
write_panel_list(wd, ®ion->panels);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
for (PanelCategoryStack *pc_act = region->panels_category_active.first; pc_act; pc_act = pc_act->next) {
|
|
|
|
writestruct(wd, DATA, PanelCategoryStack, 1, pc_act);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
for (uiList *ui_list = region->ui_lists.first; ui_list; ui_list = ui_list->next) {
|
|
|
|
write_uilist(wd, ui_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (uiPreview *ui_preview = region->ui_previews.first; ui_preview; ui_preview = ui_preview->next) {
|
|
|
|
writestruct(wd, DATA, uiPreview, 1, ui_preview);
|
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
for (SpaceLink *sl = area->spacedata.first; sl; sl = sl->next) {
|
|
|
|
for (ARegion *region = sl->regionbase.first; region; region = region->next) {
|
|
|
|
write_region(wd, region, sl->spacetype);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
if (sl->spacetype == SPACE_VIEW3D) {
|
|
|
|
View3D *v3d = (View3D *)sl;
|
|
|
|
writestruct(wd, DATA, View3D, 1, v3d);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
if (v3d->localvd) {
|
|
|
|
writestruct(wd, DATA, View3D, 1, v3d->localvd);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
if (v3d->fx_settings.ssao) {
|
|
|
|
writestruct(wd, DATA, GPUSSAOSettings, 1, v3d->fx_settings.ssao);
|
|
|
|
}
|
|
|
|
if (v3d->fx_settings.dof) {
|
|
|
|
writestruct(wd, DATA, GPUDOFSettings, 1, v3d->fx_settings.dof);
|
2008-12-26 13:11:04 +00:00
|
|
|
}
|
2018-04-13 20:29:16 +02:00
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_IPO) {
|
|
|
|
SpaceIpo *sipo = (SpaceIpo *)sl;
|
|
|
|
ListBase tmpGhosts = sipo->ghostCurves;
|
|
|
|
|
|
|
|
/* temporarily disable ghost curves when saving */
|
|
|
|
sipo->ghostCurves.first = sipo->ghostCurves.last = NULL;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
writestruct(wd, DATA, SpaceIpo, 1, sl);
|
|
|
|
if (sipo->ads) {
|
|
|
|
writestruct(wd, DATA, bDopeSheet, 1, sipo->ads);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2015-02-12 18:54:41 +01:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
/* reenable ghost curves */
|
|
|
|
sipo->ghostCurves = tmpGhosts;
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_BUTS) {
|
|
|
|
writestruct(wd, DATA, SpaceButs, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_FILE) {
|
|
|
|
SpaceFile *sfile = (SpaceFile *)sl;
|
|
|
|
|
|
|
|
writestruct(wd, DATA, SpaceFile, 1, sl);
|
|
|
|
if (sfile->params) {
|
|
|
|
writestruct(wd, DATA, FileSelectParams, 1, sfile->params);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2018-04-13 20:29:16 +02:00
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_SEQ) {
|
|
|
|
writestruct(wd, DATA, SpaceSeq, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_OUTLINER) {
|
|
|
|
SpaceOops *so = (SpaceOops *)sl;
|
|
|
|
write_soops(wd, so);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_IMAGE) {
|
|
|
|
writestruct(wd, DATA, SpaceImage, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_TEXT) {
|
|
|
|
writestruct(wd, DATA, SpaceText, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_SCRIPT) {
|
|
|
|
SpaceScript *scr = (SpaceScript *)sl;
|
|
|
|
scr->but_refs = NULL;
|
|
|
|
writestruct(wd, DATA, SpaceScript, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_ACTION) {
|
|
|
|
writestruct(wd, DATA, SpaceAction, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_NLA) {
|
|
|
|
SpaceNla *snla = (SpaceNla *)sl;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
writestruct(wd, DATA, SpaceNla, 1, snla);
|
|
|
|
if (snla->ads) {
|
|
|
|
writestruct(wd, DATA, bDopeSheet, 1, snla->ads);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
|
|
|
}
|
2018-04-13 20:29:16 +02:00
|
|
|
else if (sl->spacetype == SPACE_NODE) {
|
|
|
|
SpaceNode *snode = (SpaceNode *)sl;
|
|
|
|
bNodeTreePath *path;
|
|
|
|
writestruct(wd, DATA, SpaceNode, 1, snode);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
for (path = snode->treepath.first; path; path = path->next) {
|
|
|
|
writestruct(wd, DATA, bNodeTreePath, 1, path);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2018-04-13 20:29:16 +02:00
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_CONSOLE) {
|
|
|
|
SpaceConsole *con = (SpaceConsole *)sl;
|
|
|
|
ConsoleLine *cl;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
for (cl = con->history.first; cl; cl = cl->next) {
|
|
|
|
/* 'len_alloc' is invalid on write, set from 'len' on read */
|
|
|
|
writestruct(wd, DATA, ConsoleLine, 1, cl);
|
|
|
|
writedata(wd, DATA, cl->len + 1, cl->line);
|
|
|
|
}
|
|
|
|
writestruct(wd, DATA, SpaceConsole, 1, sl);
|
|
|
|
}
|
2018-05-23 22:38:25 +02:00
|
|
|
#ifdef WITH_GLOBAL_AREA_WRITING
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
else if (sl->spacetype == SPACE_TOPBAR) {
|
|
|
|
writestruct(wd, DATA, SpaceTopBar, 1, sl);
|
|
|
|
}
|
2018-05-23 22:38:25 +02:00
|
|
|
else if (sl->spacetype == SPACE_STATUSBAR) {
|
|
|
|
writestruct(wd, DATA, SpaceStatusBar, 1, sl);
|
|
|
|
}
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
#endif
|
2018-04-13 20:29:16 +02:00
|
|
|
else if (sl->spacetype == SPACE_USERPREF) {
|
|
|
|
writestruct(wd, DATA, SpaceUserPref, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_CLIP) {
|
|
|
|
writestruct(wd, DATA, SpaceClip, 1, sl);
|
|
|
|
}
|
|
|
|
else if (sl->spacetype == SPACE_INFO) {
|
|
|
|
writestruct(wd, DATA, SpaceInfo, 1, sl);
|
|
|
|
}
|
|
|
|
}
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void write_area_map(WriteData *wd, ScrAreaMap *area_map)
|
|
|
|
{
|
|
|
|
writelist(wd, DATA, ScrVert, &area_map->vertbase);
|
|
|
|
writelist(wd, DATA, ScrEdge, &area_map->edgebase);
|
|
|
|
for (ScrArea *area = area_map->areabase.first; area; area = area->next) {
|
2018-04-22 19:58:27 +02:00
|
|
|
area->butspacetype = area->spacetype; /* Just for compatibility, will be reset below. */
|
|
|
|
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
writestruct(wd, DATA, ScrArea, 1, area);
|
|
|
|
|
2018-05-23 22:38:25 +02:00
|
|
|
#ifdef WITH_GLOBAL_AREA_WRITING
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
writestruct(wd, DATA, ScrGlobalAreaData, 1, area->global);
|
|
|
|
#endif
|
2011-07-08 12:22:48 +00:00
|
|
|
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
write_area_regions(wd, area);
|
2018-04-22 19:58:27 +02:00
|
|
|
|
|
|
|
area->butspacetype = SPACE_EMPTY; /* Unset again, was changed above. */
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
}
|
2018-04-13 20:29:16 +02:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
static void write_windowmanager(WriteData *wd, wmWindowManager *wm)
|
|
|
|
{
|
|
|
|
writestruct(wd, ID_WM, wmWindowManager, 1, wm);
|
|
|
|
write_iddata(wd, &wm->id);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
for (wmWindow *win = wm->windows.first; win; win = win->next) {
|
2018-05-23 22:38:25 +02:00
|
|
|
#ifndef WITH_GLOBAL_AREA_WRITING
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
/* Don't write global areas yet, while we make changes to them. */
|
|
|
|
ScrAreaMap global_areas = win->global_areas;
|
|
|
|
memset(&win->global_areas, 0, sizeof(win->global_areas));
|
|
|
|
#endif
|
2010-04-23 09:24:22 +00:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
/* update deprecated screen member (for so loading in 2.7x uses the correct screen) */
|
|
|
|
win->screen = BKE_workspace_active_screen_get(win->workspace_hook);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
writestruct(wd, DATA, wmWindow, 1, win);
|
|
|
|
writestruct(wd, DATA, WorkSpaceInstanceHook, 1, win->workspace_hook);
|
|
|
|
writestruct(wd, DATA, Stereo3dFormat, 1, win->stereo3d_format);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2018-05-23 22:38:25 +02:00
|
|
|
#ifdef WITH_GLOBAL_AREA_WRITING
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
write_area_map(wd, &win->global_areas);
|
|
|
|
#else
|
|
|
|
win->global_areas = global_areas;
|
|
|
|
#endif
|
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
/* data is written, clear deprecated data again */
|
|
|
|
win->screen = NULL;
|
|
|
|
}
|
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
static void write_screen(WriteData *wd, bScreen *sc)
|
|
|
|
{
|
|
|
|
/* write LibData */
|
|
|
|
/* in 2.50+ files, the file identifier for screens is patched, forward compatibility */
|
|
|
|
writestruct(wd, ID_SCRN, bScreen, 1, sc);
|
|
|
|
write_iddata(wd, &sc->id);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
write_previews(wd, sc->preview);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2018-04-13 20:29:16 +02:00
|
|
|
/* direct data */
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
write_area_map(wd, AREAMAP_FROM_SCREEN(sc));
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2012-08-26 11:35:43 +00:00
|
|
|
static void write_bone(WriteData *wd, Bone *bone)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
/* PATCH for upward compatibility after 2.37+ armature recode */
|
2012-10-22 08:15:51 +00:00
|
|
|
bone->size[0] = bone->size[1] = bone->size[2] = 1.0f;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
/* Write this bone */
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, Bone, 1, bone);
|
2009-10-28 15:33:45 +00:00
|
|
|
|
|
|
|
/* Write ID Properties -- and copy this comment EXACTLY for easy finding
|
2012-04-22 11:54:53 +00:00
|
|
|
* of library blocks that implement this.*/
|
2016-06-28 17:35:35 +10:00
|
|
|
if (bone->prop) {
|
2009-10-28 15:33:45 +00:00
|
|
|
IDP_WriteProperty(bone->prop, wd);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Write Children */
|
|
|
|
for (Bone *cbone = bone->childbase.first; cbone; cbone = cbone->next) {
|
2002-10-12 11:37:38 +00:00
|
|
|
write_bone(wd, cbone);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_armature(WriteData *wd, bArmature *arm)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (arm->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_AR, bArmature, 1, arm);
|
|
|
|
write_iddata(wd, &arm->id);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (arm->adt) {
|
|
|
|
write_animdata(wd, arm->adt);
|
|
|
|
}
|
2009-09-21 06:43:20 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* Direct data */
|
|
|
|
for (Bone *bone = arm->bonebase.first; bone; bone = bone->next) {
|
|
|
|
write_bone(wd, bone);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_text(WriteData *wd, Text *text)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if ((text->flags & TXT_ISMEM) && (text->flags & TXT_ISEXT)) {
|
|
|
|
text->flags &= ~TXT_ISEXT;
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_TXT, Text, 1, text);
|
|
|
|
write_iddata(wd, &text->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (text->name) {
|
|
|
|
writedata(wd, DATA, strlen(text->name) + 1, text->name);
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (!(text->flags & TXT_ISEXT)) {
|
|
|
|
/* now write the text data, in two steps for optimization in the readfunction */
|
|
|
|
for (TextLine *tmp = text->lines.first; tmp; tmp = tmp->next) {
|
|
|
|
writestruct(wd, DATA, TextLine, 1, tmp);
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (TextLine *tmp = text->lines.first; tmp; tmp = tmp->next) {
|
|
|
|
writedata(wd, DATA, tmp->len + 1, tmp->line);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_speaker(WriteData *wd, Speaker *spk)
|
2011-08-01 11:44:20 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (spk->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_SPK, Speaker, 1, spk);
|
|
|
|
write_iddata(wd, &spk->id);
|
2011-08-01 11:44:20 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (spk->adt) {
|
|
|
|
write_animdata(wd, spk->adt);
|
2011-08-01 11:44:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_sound(WriteData *wd, bSound *sound)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (sound->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
/* write LibData */
|
|
|
|
writestruct(wd, ID_SO, bSound, 1, sound);
|
|
|
|
write_iddata(wd, &sound->id);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (sound->packedfile) {
|
|
|
|
PackedFile *pf = sound->packedfile;
|
|
|
|
writestruct(wd, DATA, PackedFile, 1, pf);
|
|
|
|
writedata(wd, DATA, pf->size, pf->data);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-12 20:59:54 +10:00
|
|
|
static void write_probe(WriteData *wd, LightProbe *prb)
|
2017-06-06 22:47:41 +02:00
|
|
|
{
|
2018-04-14 14:04:24 +02:00
|
|
|
if (prb->id.us > 0 || wd->use_memfile) {
|
2017-06-06 22:47:41 +02:00
|
|
|
/* write LibData */
|
2017-06-12 20:59:54 +10:00
|
|
|
writestruct(wd, ID_LP, LightProbe, 1, prb);
|
2017-06-06 22:47:41 +02:00
|
|
|
write_iddata(wd, &prb->id);
|
|
|
|
|
|
|
|
if (prb->adt) {
|
|
|
|
write_animdata(wd, prb->adt);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_nodetree(WriteData *wd, bNodeTree *ntree)
|
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
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (ntree->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_NT, bNodeTree, 1, ntree);
|
|
|
|
/* Note that trees directly used by other IDs (materials etc.) are not 'real' ID, they cannot
|
|
|
|
* be linked, etc., so we write actual id data here only, for 'real' ID trees. */
|
|
|
|
write_iddata(wd, &ntree->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_nodetree_nolib(wd, ntree);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
#ifdef USE_NODE_COMPAT_CUSTOMNODES
|
2013-03-24 12:13:13 +00:00
|
|
|
static void customnodes_add_deprecated_data(Main *mainvar)
|
|
|
|
{
|
|
|
|
FOREACH_NODETREE(mainvar, ntree, id) {
|
|
|
|
bNodeLink *link, *last_link = ntree->links.last;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-24 12:13:13 +00:00
|
|
|
/* only do this for node groups */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (id != &ntree->id) {
|
2013-03-24 12:13:13 +00:00
|
|
|
continue;
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
|
|
|
|
2013-03-24 12:13:13 +00:00
|
|
|
/* Forward compatibility for group nodes: add links to node tree interface sockets.
|
|
|
|
* These links are invalid by new rules (missing node pointer)!
|
|
|
|
* They will be removed again in customnodes_free_deprecated_data,
|
|
|
|
* cannot do this directly lest bNodeLink pointer mapping becomes ambiguous.
|
|
|
|
* When loading files with such links in a new Blender version
|
|
|
|
* they will be removed as well.
|
|
|
|
*/
|
|
|
|
for (link = ntree->links.first; link; link = link->next) {
|
|
|
|
bNode *fromnode = link->fromnode, *tonode = link->tonode;
|
|
|
|
bNodeSocket *fromsock = link->fromsock, *tosock = link->tosock;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-24 12:13:13 +00:00
|
|
|
/* check both sides of the link, to handle direct input-to-output links */
|
|
|
|
if (fromnode->type == NODE_GROUP_INPUT) {
|
|
|
|
fromnode = NULL;
|
|
|
|
fromsock = ntreeFindSocketInterface(ntree, SOCK_IN, fromsock->identifier);
|
|
|
|
}
|
|
|
|
/* only the active output node defines links */
|
|
|
|
if (tonode->type == NODE_GROUP_OUTPUT && (tonode->flag & NODE_DO_OUTPUT)) {
|
|
|
|
tonode = NULL;
|
|
|
|
tosock = ntreeFindSocketInterface(ntree, SOCK_OUT, tosock->identifier);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-24 12:13:13 +00:00
|
|
|
if (!fromnode || !tonode) {
|
|
|
|
/* Note: not using nodeAddLink here, it asserts existing node pointers */
|
|
|
|
bNodeLink *tlink = MEM_callocN(sizeof(bNodeLink), "group node link");
|
|
|
|
tlink->fromnode = fromnode;
|
|
|
|
tlink->fromsock = fromsock;
|
|
|
|
tlink->tonode = tonode;
|
2016-06-28 17:35:35 +10:00
|
|
|
tlink->tosock = tosock;
|
2013-03-24 12:13:13 +00:00
|
|
|
tosock->link = tlink;
|
|
|
|
tlink->flag |= NODE_LINK_VALID;
|
|
|
|
BLI_addtail(&ntree->links, tlink);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-24 12:13:13 +00:00
|
|
|
/* don't check newly created compatibility links */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (link == last_link) {
|
2013-03-24 12:13:13 +00:00
|
|
|
break;
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2013-03-18 16:34:57 +00:00
|
|
|
}
|
|
|
|
}
|
2013-03-24 12:13:13 +00:00
|
|
|
FOREACH_NODETREE_END
|
2013-03-18 16:34:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void customnodes_free_deprecated_data(Main *mainvar)
|
|
|
|
{
|
2013-03-24 12:13:13 +00:00
|
|
|
FOREACH_NODETREE(mainvar, ntree, id) {
|
|
|
|
bNodeLink *link, *next_link;
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2013-03-24 12:13:13 +00:00
|
|
|
for (link = ntree->links.first; link; link = next_link) {
|
|
|
|
next_link = link->next;
|
2016-06-28 17:35:35 +10:00
|
|
|
if (link->fromnode == NULL || link->tonode == NULL) {
|
2013-03-24 12:13:13 +00:00
|
|
|
nodeRemLink(ntree, link);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2013-03-24 12:13:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
FOREACH_NODETREE_END
|
2013-03-18 16:34:57 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_brush(WriteData *wd, Brush *brush)
|
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
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (brush->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_BR, Brush, 1, brush);
|
|
|
|
write_iddata(wd, &brush->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (brush->curve) {
|
|
|
|
write_curvemapping(wd, brush->curve);
|
|
|
|
}
|
|
|
|
if (brush->gradient) {
|
|
|
|
writestruct(wd, DATA, ColorBand, 1, brush->gradient);
|
2014-07-21 12:02:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_palette(WriteData *wd, Palette *palette)
|
2014-07-21 12:02:05 +02:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (palette->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
PaletteColor *color;
|
|
|
|
writestruct(wd, ID_PAL, Palette, 1, palette);
|
|
|
|
write_iddata(wd, &palette->id);
|
2014-07-21 12:02:05 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (color = palette->colors.first; color; color = color->next) {
|
|
|
|
writestruct(wd, DATA, PaletteColor, 1, color);
|
2014-07-21 12:02:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_paintcurve(WriteData *wd, PaintCurve *pc)
|
2014-07-21 12:02:05 +02:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (pc->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_PC, PaintCurve, 1, pc);
|
|
|
|
write_iddata(wd, &pc->id);
|
2014-07-21 12:02:05 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, PaintCurvePoint, pc->tot_points, pc->points);
|
2006-07-31 15:53:03 +00:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2011-12-05 18:57:17 +00:00
|
|
|
static void write_movieTracks(WriteData *wd, ListBase *tracks)
|
|
|
|
{
|
|
|
|
MovieTrackingTrack *track;
|
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
track = tracks->first;
|
2012-03-24 07:52:14 +00:00
|
|
|
while (track) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MovieTrackingTrack, 1, track);
|
2011-12-05 18:57:17 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (track->markers) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MovieTrackingMarker, track->markersnr, track->markers);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2011-12-05 18:57:17 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
track = track->next;
|
2011-12-05 18:57:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Merge plane track feature from tomato branch
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
2013-08-16 09:46:30 +00:00
|
|
|
static void write_moviePlaneTracks(WriteData *wd, ListBase *plane_tracks_base)
|
|
|
|
{
|
|
|
|
MovieTrackingPlaneTrack *plane_track;
|
|
|
|
|
|
|
|
for (plane_track = plane_tracks_base->first;
|
|
|
|
plane_track;
|
|
|
|
plane_track = plane_track->next)
|
|
|
|
{
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MovieTrackingPlaneTrack, 1, plane_track);
|
Merge plane track feature from tomato branch
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
2013-08-16 09:46:30 +00:00
|
|
|
|
|
|
|
writedata(wd, DATA, sizeof(MovieTrackingTrack *) * plane_track->point_tracksnr, plane_track->point_tracks);
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MovieTrackingPlaneMarker, plane_track->markersnr, plane_track->markers);
|
Merge plane track feature from tomato branch
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
2013-08-16 09:46:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-05 18:57:17 +00:00
|
|
|
static void write_movieReconstruction(WriteData *wd, MovieTrackingReconstruction *reconstruction)
|
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
if (reconstruction->camnr) {
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, MovieReconstructedCamera, reconstruction->camnr, reconstruction->cameras);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2011-12-05 18:57:17 +00:00
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_movieclip(WriteData *wd, MovieClip *clip)
|
2011-11-07 12:55:18 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (clip->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
MovieTracking *tracking = &clip->tracking;
|
|
|
|
MovieTrackingObject *object;
|
2011-11-07 12:55:18 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_MC, MovieClip, 1, clip);
|
|
|
|
write_iddata(wd, &clip->id);
|
2012-05-08 07:31:02 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (clip->adt) {
|
|
|
|
write_animdata(wd, clip->adt);
|
|
|
|
}
|
2012-02-17 08:13:45 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_movieTracks(wd, &tracking->tracks);
|
|
|
|
write_moviePlaneTracks(wd, &tracking->plane_tracks);
|
|
|
|
write_movieReconstruction(wd, &tracking->reconstruction);
|
2011-11-07 12:55:18 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
object = tracking->objects.first;
|
|
|
|
while (object) {
|
|
|
|
writestruct(wd, DATA, MovieTrackingObject, 1, object);
|
2011-11-07 12:55:18 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_movieTracks(wd, &object->tracks);
|
|
|
|
write_moviePlaneTracks(wd, &object->plane_tracks);
|
|
|
|
write_movieReconstruction(wd, &object->reconstruction);
|
2011-11-07 12:55:18 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
object = object->next;
|
2011-11-07 12:55:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_mask(WriteData *wd, Mask *mask)
|
2012-06-04 16:42:58 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (mask->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
MaskLayer *masklay;
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_MSK, Mask, 1, mask);
|
|
|
|
write_iddata(wd, &mask->id);
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (mask->adt) {
|
|
|
|
write_animdata(wd, mask->adt);
|
|
|
|
}
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (masklay = mask->masklayers.first; masklay; masklay = masklay->next) {
|
|
|
|
MaskSpline *spline;
|
|
|
|
MaskLayerShape *masklay_shape;
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, MaskLayer, 1, masklay);
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (spline = masklay->splines.first; spline; spline = spline->next) {
|
|
|
|
int i;
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
void *points_deform = spline->points_deform;
|
|
|
|
spline->points_deform = NULL;
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, DATA, MaskSpline, 1, spline);
|
|
|
|
writestruct(wd, DATA, MaskSplinePoint, spline->tot_point, spline->points);
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
spline->points_deform = points_deform;
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (i = 0; i < spline->tot_point; i++) {
|
|
|
|
MaskSplinePoint *point = &spline->points[i];
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (point->tot_uw) {
|
|
|
|
writestruct(wd, DATA, MaskSplinePointUW, point->tot_uw, point->uw);
|
2012-06-04 16:42:58 +00:00
|
|
|
}
|
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2012-06-04 16:42:58 +00:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
for (masklay_shape = masklay->splines_shapes.first;
|
2017-04-24 21:58:28 +10:00
|
|
|
masklay_shape;
|
|
|
|
masklay_shape = masklay_shape->next)
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
{
|
|
|
|
writestruct(wd, DATA, MaskLayerShape, 1, masklay_shape);
|
|
|
|
writedata(wd, DATA,
|
2017-04-24 21:58:28 +10:00
|
|
|
masklay_shape->tot_vert * sizeof(float) * MASK_OBJECT_SHAPE_ELEM_SIZE,
|
|
|
|
masklay_shape->data);
|
2012-06-04 16:42:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-24 20:37:54 +00:00
|
|
|
static void write_linestyle_color_modifiers(WriteData *wd, ListBase *modifiers)
|
|
|
|
{
|
|
|
|
LineStyleModifier *m;
|
|
|
|
|
|
|
|
for (m = modifiers->first; m; m = m->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
int struct_nr;
|
2010-07-24 20:37:54 +00:00
|
|
|
switch (m->type) {
|
2016-06-28 17:35:35 +10:00
|
|
|
case LS_MODIFIER_ALONG_STROKE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_AlongStroke);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_CAMERA:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_DistanceFromCamera);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_OBJECT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_DistanceFromObject);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_MATERIAL:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_Material);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_TANGENT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_Tangent);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_NOISE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_Noise);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CREASE_ANGLE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_CreaseAngle);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CURVATURE_3D:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleColorModifier_Curvature_3D);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
default:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleModifier); /* this should not happen */
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_nr(wd, DATA, struct_nr, 1, m);
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
|
|
|
for (m = modifiers->first; m; m = m->next) {
|
|
|
|
switch (m->type) {
|
2016-06-28 17:35:35 +10:00
|
|
|
case LS_MODIFIER_ALONG_STROKE:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_AlongStroke *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_CAMERA:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_DistanceFromCamera *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_OBJECT:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_DistanceFromObject *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_MATERIAL:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_Material *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_TANGENT:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_Tangent *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_NOISE:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_Noise *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CREASE_ANGLE:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_CreaseAngle *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CURVATURE_3D:
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, ColorBand, 1, ((LineStyleColorModifier_Curvature_3D *)m)->color_ramp);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_linestyle_alpha_modifiers(WriteData *wd, ListBase *modifiers)
|
|
|
|
{
|
|
|
|
LineStyleModifier *m;
|
|
|
|
|
|
|
|
for (m = modifiers->first; m; m = m->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
int struct_nr;
|
2010-07-24 20:37:54 +00:00
|
|
|
switch (m->type) {
|
2016-06-28 17:35:35 +10:00
|
|
|
case LS_MODIFIER_ALONG_STROKE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_AlongStroke);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_CAMERA:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_DistanceFromCamera);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_OBJECT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_DistanceFromObject);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_MATERIAL:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_Material);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_TANGENT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_Tangent);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_NOISE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_Noise);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CREASE_ANGLE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_CreaseAngle);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CURVATURE_3D:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleAlphaModifier_Curvature_3D);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
default:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleModifier); /* this should not happen */
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_nr(wd, DATA, struct_nr, 1, m);
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
|
|
|
for (m = modifiers->first; m; m = m->next) {
|
|
|
|
switch (m->type) {
|
2016-06-28 17:35:35 +10:00
|
|
|
case LS_MODIFIER_ALONG_STROKE:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_AlongStroke *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_CAMERA:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_DistanceFromCamera *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_OBJECT:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_DistanceFromObject *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_MATERIAL:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_Material *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_TANGENT:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_Tangent *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_NOISE:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_Noise *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CREASE_ANGLE:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_CreaseAngle *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CURVATURE_3D:
|
|
|
|
write_curvemapping(wd, ((LineStyleAlphaModifier_Curvature_3D *)m)->curve);
|
|
|
|
break;
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_linestyle_thickness_modifiers(WriteData *wd, ListBase *modifiers)
|
|
|
|
{
|
|
|
|
LineStyleModifier *m;
|
|
|
|
|
|
|
|
for (m = modifiers->first; m; m = m->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
int struct_nr;
|
2010-07-24 20:37:54 +00:00
|
|
|
switch (m->type) {
|
2016-06-28 17:35:35 +10:00
|
|
|
case LS_MODIFIER_ALONG_STROKE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_AlongStroke);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_CAMERA:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_DistanceFromCamera);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_OBJECT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_DistanceFromObject);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_MATERIAL:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_Material);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CALLIGRAPHY:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_Calligraphy);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_TANGENT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_Tangent);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_NOISE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_Noise);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CREASE_ANGLE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_CreaseAngle);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CURVATURE_3D:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleThicknessModifier_Curvature_3D);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
default:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleModifier); /* this should not happen */
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_nr(wd, DATA, struct_nr, 1, m);
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
|
|
|
for (m = modifiers->first; m; m = m->next) {
|
|
|
|
switch (m->type) {
|
2016-06-28 17:35:35 +10:00
|
|
|
case LS_MODIFIER_ALONG_STROKE:
|
|
|
|
write_curvemapping(wd, ((LineStyleThicknessModifier_AlongStroke *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_CAMERA:
|
|
|
|
write_curvemapping(wd, ((LineStyleThicknessModifier_DistanceFromCamera *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_DISTANCE_FROM_OBJECT:
|
|
|
|
write_curvemapping(wd, ((LineStyleThicknessModifier_DistanceFromObject *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_MATERIAL:
|
|
|
|
write_curvemapping(wd, ((LineStyleThicknessModifier_Material *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_TANGENT:
|
|
|
|
write_curvemapping(wd, ((LineStyleThicknessModifier_Tangent *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CREASE_ANGLE:
|
|
|
|
write_curvemapping(wd, ((LineStyleThicknessModifier_CreaseAngle *)m)->curve);
|
|
|
|
break;
|
|
|
|
case LS_MODIFIER_CURVATURE_3D:
|
|
|
|
write_curvemapping(wd, ((LineStyleThicknessModifier_Curvature_3D *)m)->curve);
|
|
|
|
break;
|
2010-07-24 20:37:54 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-19 14:05:11 +00:00
|
|
|
static void write_linestyle_geometry_modifiers(WriteData *wd, ListBase *modifiers)
|
|
|
|
{
|
|
|
|
LineStyleModifier *m;
|
|
|
|
|
|
|
|
for (m = modifiers->first; m; m = m->next) {
|
2016-06-28 20:05:42 +10:00
|
|
|
int struct_nr;
|
2011-08-19 14:05:11 +00:00
|
|
|
switch (m->type) {
|
2016-06-28 17:35:35 +10:00
|
|
|
case LS_MODIFIER_SAMPLING:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_Sampling);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_BEZIER_CURVE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_BezierCurve);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_SINUS_DISPLACEMENT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_SinusDisplacement);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_SPATIAL_NOISE:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_SpatialNoise);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_PERLIN_NOISE_1D:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_PerlinNoise1D);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_PERLIN_NOISE_2D:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_PerlinNoise2D);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_BACKBONE_STRETCHER:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_BackboneStretcher);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_TIP_REMOVER:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_TipRemover);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_POLYGONIZATION:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_Polygonalization);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_GUIDING_LINES:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_GuidingLines);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_BLUEPRINT:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_Blueprint);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_2D_OFFSET:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_2DOffset);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_2D_TRANSFORM:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_2DTransform);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
case LS_MODIFIER_SIMPLIFICATION:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleGeometryModifier_Simplification);
|
2016-06-28 17:35:35 +10:00
|
|
|
break;
|
|
|
|
default:
|
2016-06-28 20:05:42 +10:00
|
|
|
struct_nr = SDNA_TYPE_FROM_STRUCT(LineStyleModifier); /* this should not happen */
|
2011-08-19 14:05:11 +00:00
|
|
|
}
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct_nr(wd, DATA, struct_nr, 1, m);
|
2011-08-19 14:05:11 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_linestyle(WriteData *wd, FreestyleLineStyle *linestyle)
|
2010-06-25 22:45:42 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (linestyle->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_LS, FreestyleLineStyle, 1, linestyle);
|
|
|
|
write_iddata(wd, &linestyle->id);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (linestyle->adt) {
|
|
|
|
write_animdata(wd, linestyle->adt);
|
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
write_linestyle_color_modifiers(wd, &linestyle->color_modifiers);
|
|
|
|
write_linestyle_alpha_modifiers(wd, &linestyle->alpha_modifiers);
|
|
|
|
write_linestyle_thickness_modifiers(wd, &linestyle->thickness_modifiers);
|
|
|
|
write_linestyle_geometry_modifiers(wd, &linestyle->geometry_modifiers);
|
|
|
|
for (int a = 0; a < MAX_MTEX; a++) {
|
|
|
|
if (linestyle->mtex[a]) {
|
|
|
|
writestruct(wd, DATA, MTex, 1, linestyle->mtex[a]);
|
2014-05-03 18:51:53 +09:00
|
|
|
}
|
2010-06-25 22:45:42 +00:00
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (linestyle->nodetree) {
|
|
|
|
writestruct(wd, DATA, bNodeTree, 1, linestyle->nodetree);
|
|
|
|
write_nodetree_nolib(wd, linestyle->nodetree);
|
|
|
|
}
|
2010-06-25 22:45:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
static void write_cachefile(WriteData *wd, CacheFile *cache_file)
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
if (cache_file->id.us > 0 || wd->use_memfile) {
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
writestruct(wd, ID_CF, CacheFile, 1, cache_file);
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
if (cache_file->adt) {
|
|
|
|
write_animdata(wd, cache_file->adt);
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
static void write_workspace(WriteData *wd, WorkSpace *workspace)
|
|
|
|
{
|
|
|
|
ListBase *layouts = BKE_workspace_layouts_get(workspace);
|
|
|
|
|
|
|
|
writestruct(wd, ID_WS, WorkSpace, 1, workspace);
|
|
|
|
writelist(wd, DATA, WorkSpaceLayout, layouts);
|
|
|
|
writelist(wd, DATA, WorkSpaceDataRelation, &workspace->hook_layout_relations);
|
2018-03-01 01:26:02 +11:00
|
|
|
writelist(wd, DATA, wmOwnerID, &workspace->owner_ids);
|
2018-05-16 18:41:11 +02:00
|
|
|
writelist(wd, DATA, bToolRef, &workspace->tools);
|
2018-05-22 14:00:44 +02:00
|
|
|
for (bToolRef *tref = workspace->tools.first; tref; tref = tref->next) {
|
|
|
|
if (tref->properties) {
|
|
|
|
IDP_WriteProperty(tref->properties, wd);
|
|
|
|
}
|
|
|
|
}
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
}
|
|
|
|
|
2016-06-14 14:53:39 +02:00
|
|
|
/* Keep it last of write_foodata functions. */
|
|
|
|
static void write_libraries(WriteData *wd, Main *main)
|
|
|
|
{
|
|
|
|
ListBase *lbarray[MAX_LIBARRAY];
|
|
|
|
ID *id;
|
|
|
|
int a, tot;
|
|
|
|
bool found_one;
|
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
for (; main; main = main->next) {
|
|
|
|
a = tot = set_listbasepointers(main, lbarray);
|
2016-06-14 14:53:39 +02:00
|
|
|
|
|
|
|
/* test: is lib being used */
|
2016-06-28 17:35:35 +10:00
|
|
|
if (main->curlib && main->curlib->packedfile) {
|
2016-06-14 14:53:39 +02:00
|
|
|
found_one = true;
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2016-06-14 14:53:39 +02:00
|
|
|
else {
|
|
|
|
found_one = false;
|
2017-02-06 20:42:00 +01:00
|
|
|
while (!found_one && tot--) {
|
2016-06-28 17:35:35 +10:00
|
|
|
for (id = lbarray[tot]->first; id; id = id->next) {
|
2016-06-14 14:53:39 +02:00
|
|
|
if (id->us > 0 && (id->tag & LIB_TAG_EXTERN)) {
|
|
|
|
found_one = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* to be able to restore quit.blend and temp saves, the packed blend has to be in undo buffers... */
|
|
|
|
/* XXX needs rethink, just like save UI in undo files now - would be nice to append things only for the]
|
|
|
|
* quit.blend and temp saves */
|
|
|
|
if (found_one) {
|
2017-11-29 15:05:03 +01:00
|
|
|
/* Not overridable. */
|
|
|
|
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, ID_LI, Library, 1, main->curlib);
|
2016-06-14 14:53:39 +02:00
|
|
|
write_iddata(wd, &main->curlib->id);
|
|
|
|
|
|
|
|
if (main->curlib->packedfile) {
|
|
|
|
PackedFile *pf = main->curlib->packedfile;
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, DATA, PackedFile, 1, pf);
|
2016-06-14 14:53:39 +02:00
|
|
|
writedata(wd, DATA, pf->size, pf->data);
|
2018-04-14 12:33:19 +02:00
|
|
|
if (wd->use_memfile == false) {
|
2016-06-14 14:53:39 +02:00
|
|
|
printf("write packed .blend: %s\n", main->curlib->name);
|
2016-06-28 17:35:35 +10:00
|
|
|
}
|
2016-06-14 14:53:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
while (a--) {
|
2016-06-28 17:35:35 +10:00
|
|
|
for (id = lbarray[a]->first; id; id = id->next) {
|
2016-06-14 14:53:39 +02:00
|
|
|
if (id->us > 0 && (id->tag & LIB_TAG_EXTERN)) {
|
|
|
|
if (!BKE_idcode_is_linkable(GS(id->name))) {
|
2016-09-19 16:46:20 +02:00
|
|
|
printf("ERROR: write file: data-block '%s' from lib '%s' is not linkable "
|
2016-06-14 14:53:39 +02:00
|
|
|
"but is flagged as directly linked", id->name, main->curlib->filepath);
|
|
|
|
BLI_assert(0);
|
|
|
|
}
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, ID_ID, ID, 1, id);
|
2016-06-14 14:53:39 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-07-06 23:27:22 +10:00
|
|
|
|
2016-07-07 16:02:45 +10:00
|
|
|
mywrite_flush(wd);
|
2016-06-14 14:53:39 +02:00
|
|
|
}
|
|
|
|
|
2007-12-24 18:53:37 +00:00
|
|
|
/* context is usually defined by WM, two cases where no WM is available:
|
Merge of trunk into blender 2.5:
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
2008-11-12 21:16:53 +00:00
|
|
|
* - for forward compatibility, curscreen has to be saved
|
|
|
|
* - for undofile, curscene needs to be saved */
|
2009-10-20 13:58:53 +00:00
|
|
|
static void write_global(WriteData *wd, int fileflags, Main *mainvar)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2018-04-14 12:33:19 +02:00
|
|
|
const bool is_undo = wd->use_memfile;
|
2002-10-12 11:37:38 +00:00
|
|
|
FileGlobal fg;
|
2008-12-19 16:36:15 +00:00
|
|
|
bScreen *screen;
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
Scene *scene;
|
2018-07-24 11:21:32 +02:00
|
|
|
ViewLayer *view_layer;
|
2007-01-08 12:31:53 +00:00
|
|
|
char subvstr[8];
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2011-01-16 21:12:38 +00:00
|
|
|
/* prevent mem checkers from complaining */
|
2015-01-20 01:07:12 +11:00
|
|
|
memset(fg.pad, 0, sizeof(fg.pad));
|
2011-01-16 21:12:38 +00:00
|
|
|
memset(fg.filename, 0, sizeof(fg.filename));
|
2014-01-22 16:23:55 +06:00
|
|
|
memset(fg.build_hash, 0, sizeof(fg.build_hash));
|
2018-01-23 17:11:13 +11:00
|
|
|
fg.pad1 = NULL;
|
2011-01-16 21:12:38 +00:00
|
|
|
|
2018-07-24 11:21:32 +02:00
|
|
|
current_screen_compat(mainvar, is_undo, &screen, &scene, &view_layer);
|
2008-12-19 16:36:15 +00:00
|
|
|
|
|
|
|
/* XXX still remap G */
|
2016-06-28 17:35:35 +10:00
|
|
|
fg.curscreen = screen;
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
fg.curscene = scene;
|
2018-07-24 11:21:32 +02:00
|
|
|
fg.cur_view_layer = view_layer;
|
2011-12-27 13:17:58 +00:00
|
|
|
|
|
|
|
/* prevent to save this, is not good convention, and feature with concerns... */
|
2016-06-28 17:35:35 +10:00
|
|
|
fg.fileflags = (fileflags & ~G_FILE_FLAGS_RUNTIME);
|
2011-12-27 13:17:58 +00:00
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
fg.globalf = G.f;
|
2009-10-20 13:58:53 +00:00
|
|
|
BLI_strncpy(fg.filename, mainvar->name, sizeof(fg.filename));
|
2007-01-08 12:31:53 +00:00
|
|
|
sprintf(subvstr, "%4d", BLENDER_SUBVERSION);
|
|
|
|
memcpy(fg.subvstr, subvstr, 4);
|
2016-06-28 17:35:35 +10:00
|
|
|
|
|
|
|
fg.subversion = BLENDER_SUBVERSION;
|
|
|
|
fg.minversion = BLENDER_MINVERSION;
|
|
|
|
fg.minsubversion = BLENDER_MINSUBVERSION;
|
2011-08-22 16:54:26 +00:00
|
|
|
#ifdef WITH_BUILDINFO
|
2011-01-02 13:33:32 +00:00
|
|
|
{
|
2013-11-15 17:11:59 +06:00
|
|
|
extern unsigned long build_commit_timestamp;
|
|
|
|
extern char build_hash[];
|
2013-11-04 13:21:39 +00:00
|
|
|
/* TODO(sergey): Add branch name to file as well? */
|
2013-11-15 17:11:59 +06:00
|
|
|
fg.build_commit_timestamp = build_commit_timestamp;
|
2013-11-04 13:21:39 +00:00
|
|
|
BLI_strncpy(fg.build_hash, build_hash, sizeof(fg.build_hash));
|
2011-01-02 13:33:32 +00:00
|
|
|
}
|
|
|
|
#else
|
2013-11-15 17:11:59 +06:00
|
|
|
fg.build_commit_timestamp = 0;
|
2013-11-04 13:21:39 +00:00
|
|
|
BLI_strncpy(fg.build_hash, "unknown", sizeof(fg.build_hash));
|
2011-01-02 13:33:32 +00:00
|
|
|
#endif
|
2016-06-28 20:05:42 +10:00
|
|
|
writestruct(wd, GLOB, FileGlobal, 1, &fg);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2010-05-24 21:52:18 +00:00
|
|
|
/* preview image, first 2 values are width and height
|
|
|
|
* second are an RGBA image (unsigned char)
|
|
|
|
* note, this uses 'TEST' since new types will segfault on file load for older blender versions.
|
|
|
|
*/
|
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
|
|
|
static void write_thumb(WriteData *wd, const BlendThumbnail *thumb)
|
2010-05-24 21:52:18 +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
|
|
|
if (thumb) {
|
2015-09-01 01:52:27 +10:00
|
|
|
writedata(wd, TEST, BLEN_THUMB_MEMSIZE_FILE(thumb->width, thumb->height), thumb);
|
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-05-24 21:52:18 +00:00
|
|
|
}
|
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name File Writing (Private)
|
|
|
|
* \{ */
|
|
|
|
|
2006-11-25 13:07:28 +00:00
|
|
|
/* if MemFile * there's filesave to memory */
|
2016-06-28 21:00:00 +10:00
|
|
|
static bool write_file_handle(
|
2014-09-04 21:48:36 +10:00
|
|
|
Main *mainvar,
|
|
|
|
WriteWrap *ww,
|
|
|
|
MemFile *compare, MemFile *current,
|
2016-06-28 21:00:00 +10:00
|
|
|
int write_flags, const BlendThumbnail *thumb)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2004-09-05 13:43:51 +00:00
|
|
|
BHead bhead;
|
2002-10-12 11:37:38 +00:00
|
|
|
ListBase mainlist;
|
2006-12-01 19:52:04 +00:00
|
|
|
char buf[16];
|
2002-10-12 11:37:38 +00:00
|
|
|
WriteData *wd;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2008-12-19 16:36:15 +00:00
|
|
|
blo_split_main(&mainlist, mainvar);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
wd = mywrite_begin(ww, compare, current);
|
2011-12-27 13:17:58 +00:00
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
#ifdef USE_NODE_COMPAT_CUSTOMNODES
|
2013-03-24 12:13:13 +00:00
|
|
|
/* don't write compatibility data on undo */
|
|
|
|
if (!current) {
|
|
|
|
/* deprecated forward compat data is freed again below */
|
|
|
|
customnodes_add_deprecated_data(mainvar);
|
|
|
|
}
|
2013-03-18 16:34:57 +00:00
|
|
|
#endif
|
|
|
|
|
2013-03-31 03:28:46 +00:00
|
|
|
sprintf(buf, "BLENDER%c%c%.3d",
|
|
|
|
(sizeof(void *) == 8) ? '-' : '_',
|
|
|
|
(ENDIAN_ORDER == B_ENDIAN) ? 'V' : 'v',
|
|
|
|
BLENDER_VERSION);
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
mywrite(wd, buf, 12);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2008-12-19 16:36:15 +00:00
|
|
|
write_renderinfo(wd, mainvar);
|
2010-05-24 21:52:18 +00:00
|
|
|
write_thumb(wd, thumb);
|
2009-10-20 13:58:53 +00:00
|
|
|
write_global(wd, write_flags, mainvar);
|
2006-11-26 21:17:15 +00:00
|
|
|
|
2016-07-06 22:23:50 +10:00
|
|
|
/* The windowmanager and screen often change,
|
|
|
|
* avoid thumbnail detecting changes because of this. */
|
2016-07-07 16:02:45 +10:00
|
|
|
mywrite_flush(wd);
|
2016-07-06 22:23:50 +10:00
|
|
|
|
2018-04-14 14:04:24 +02:00
|
|
|
OverrideStaticStorage *override_storage = wd->use_memfile ? NULL : BKE_override_static_operations_store_initialize();
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
/* This outer loop allows to save first datablocks from real mainvar, then the temp ones from override process,
|
|
|
|
* if needed, without duplicating whole code. */
|
|
|
|
Main *bmain = mainvar;
|
|
|
|
do {
|
|
|
|
ListBase *lbarray[MAX_LIBARRAY];
|
|
|
|
int a = set_listbasepointers(bmain, lbarray);
|
|
|
|
while (a--) {
|
|
|
|
ID *id = lbarray[a]->first;
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
if (id && GS(id->name) == ID_LI) {
|
|
|
|
continue; /* Libraries are handled separately below. */
|
|
|
|
}
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
for (; id; id = id->next) {
|
|
|
|
/* We should never attempt to write non-regular IDs (i.e. all kind of temp/runtime ones). */
|
|
|
|
BLI_assert((id->tag & (LIB_TAG_NO_MAIN | LIB_TAG_NO_USER_REFCOUNT | LIB_TAG_NOT_ALLOCATED)) == 0);
|
|
|
|
|
|
|
|
const bool do_override = !ELEM(override_storage, NULL, bmain) && id->override_static;
|
|
|
|
|
|
|
|
if (do_override) {
|
2018-06-29 12:46:54 +02:00
|
|
|
BKE_override_static_operations_store_start(bmain, override_storage, id);
|
2017-11-29 15:05:03 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
switch ((ID_Type)GS(id->name)) {
|
|
|
|
case ID_WM:
|
|
|
|
write_windowmanager(wd, (wmWindowManager *)id);
|
|
|
|
break;
|
|
|
|
case ID_WS:
|
|
|
|
write_workspace(wd, (WorkSpace *)id);
|
|
|
|
break;
|
|
|
|
case ID_SCR:
|
|
|
|
write_screen(wd, (bScreen *)id);
|
|
|
|
break;
|
|
|
|
case ID_MC:
|
|
|
|
write_movieclip(wd, (MovieClip *)id);
|
|
|
|
break;
|
|
|
|
case ID_MSK:
|
|
|
|
write_mask(wd, (Mask *)id);
|
|
|
|
break;
|
|
|
|
case ID_SCE:
|
|
|
|
write_scene(wd, (Scene *)id);
|
|
|
|
break;
|
|
|
|
case ID_CU:
|
2017-12-04 17:19:34 +11:00
|
|
|
write_curve(wd, (Curve *)id);
|
2017-11-29 15:05:03 +01:00
|
|
|
break;
|
|
|
|
case ID_MB:
|
|
|
|
write_mball(wd, (MetaBall *)id);
|
|
|
|
break;
|
|
|
|
case ID_IM:
|
|
|
|
write_image(wd, (Image *)id);
|
|
|
|
break;
|
|
|
|
case ID_CA:
|
|
|
|
write_camera(wd, (Camera *)id);
|
|
|
|
break;
|
|
|
|
case ID_LA:
|
|
|
|
write_lamp(wd, (Lamp *)id);
|
|
|
|
break;
|
|
|
|
case ID_LT:
|
|
|
|
write_lattice(wd, (Lattice *)id);
|
|
|
|
break;
|
|
|
|
case ID_VF:
|
|
|
|
write_vfont(wd, (VFont *)id);
|
|
|
|
break;
|
|
|
|
case ID_KE:
|
|
|
|
write_key(wd, (Key *)id);
|
|
|
|
break;
|
|
|
|
case ID_WO:
|
|
|
|
write_world(wd, (World *)id);
|
|
|
|
break;
|
|
|
|
case ID_TXT:
|
|
|
|
write_text(wd, (Text *)id);
|
|
|
|
break;
|
|
|
|
case ID_SPK:
|
|
|
|
write_speaker(wd, (Speaker *)id);
|
|
|
|
break;
|
|
|
|
case ID_LP:
|
|
|
|
write_probe(wd, (LightProbe *)id);
|
|
|
|
break;
|
|
|
|
case ID_SO:
|
|
|
|
write_sound(wd, (bSound *)id);
|
|
|
|
break;
|
|
|
|
case ID_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
|
|
|
write_collection(wd, (Collection *)id);
|
2017-11-29 15:05:03 +01:00
|
|
|
break;
|
|
|
|
case ID_AR:
|
|
|
|
write_armature(wd, (bArmature *)id);
|
|
|
|
break;
|
|
|
|
case ID_AC:
|
|
|
|
write_action(wd, (bAction *)id);
|
|
|
|
break;
|
|
|
|
case ID_OB:
|
|
|
|
write_object(wd, (Object *)id);
|
|
|
|
break;
|
|
|
|
case ID_MA:
|
|
|
|
write_material(wd, (Material *)id);
|
|
|
|
break;
|
|
|
|
case ID_TE:
|
|
|
|
write_texture(wd, (Tex *)id);
|
|
|
|
break;
|
|
|
|
case ID_ME:
|
|
|
|
write_mesh(wd, (Mesh *)id);
|
|
|
|
break;
|
|
|
|
case ID_PA:
|
|
|
|
write_particlesettings(wd, (ParticleSettings *)id);
|
|
|
|
break;
|
|
|
|
case ID_NT:
|
|
|
|
write_nodetree(wd, (bNodeTree *)id);
|
|
|
|
break;
|
|
|
|
case ID_BR:
|
|
|
|
write_brush(wd, (Brush *)id);
|
|
|
|
break;
|
|
|
|
case ID_PAL:
|
|
|
|
write_palette(wd, (Palette *)id);
|
|
|
|
break;
|
|
|
|
case ID_PC:
|
|
|
|
write_paintcurve(wd, (PaintCurve *)id);
|
|
|
|
break;
|
|
|
|
case ID_GD:
|
|
|
|
write_gpencil(wd, (bGPdata *)id);
|
|
|
|
break;
|
|
|
|
case ID_LS:
|
|
|
|
write_linestyle(wd, (FreestyleLineStyle *)id);
|
|
|
|
break;
|
|
|
|
case ID_CF:
|
|
|
|
write_cachefile(wd, (CacheFile *)id);
|
|
|
|
break;
|
|
|
|
case ID_LI:
|
|
|
|
/* Do nothing, handled below - and should never be reached. */
|
|
|
|
BLI_assert(0);
|
|
|
|
break;
|
|
|
|
case ID_IP:
|
|
|
|
/* Do nothing, deprecated. */
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* Should never be reached. */
|
|
|
|
BLI_assert(0);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (do_override) {
|
|
|
|
BKE_override_static_operations_store_end(override_storage, id);
|
|
|
|
}
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2017-11-29 15:05:03 +01:00
|
|
|
|
|
|
|
mywrite_flush(wd);
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
2017-11-29 15:05:03 +01:00
|
|
|
} while ((bmain != override_storage) && (bmain = override_storage));
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
|
2017-11-29 15:05:03 +01:00
|
|
|
if (override_storage) {
|
|
|
|
BKE_override_static_operations_store_finalize(override_storage);
|
|
|
|
override_storage = NULL;
|
Refactor writefile handling of data-blocks.
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
2017-03-17 10:02:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Special handling, operating over split Mains... */
|
2009-10-20 16:43:25 +00:00
|
|
|
write_libraries(wd, mainvar->next);
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2016-07-06 22:23:50 +10:00
|
|
|
/* So changes above don't cause a 'DNA1' to be detected as changed on undo. */
|
2016-07-07 16:02:45 +10:00
|
|
|
mywrite_flush(wd);
|
2016-07-06 22:23:50 +10:00
|
|
|
|
2016-06-28 21:00:00 +10:00
|
|
|
if (write_flags & G_FILE_USERPREFS) {
|
2018-02-01 15:16:36 +11:00
|
|
|
write_userdef(wd, &U);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
2016-06-28 17:35:35 +10:00
|
|
|
|
2016-07-06 22:23:50 +10:00
|
|
|
/* Write DNA last, because (to be implemented) test for which structs are written.
|
|
|
|
*
|
|
|
|
* Note that we *borrow* the pointer to 'DNAstr',
|
|
|
|
* so writing each time uses the same address and doesn't cause unnecessary undo overhead. */
|
2002-10-12 11:37:38 +00:00
|
|
|
writedata(wd, DNA1, wd->sdna->datalen, wd->sdna->data);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
#ifdef USE_NODE_COMPAT_CUSTOMNODES
|
2013-03-24 12:13:13 +00:00
|
|
|
/* compatibility data not created on undo */
|
|
|
|
if (!current) {
|
|
|
|
/* Ugly, forward compatibility code generates deprecated data during writing,
|
|
|
|
* this has to be freed again. Can not be done directly after writing, otherwise
|
|
|
|
* the data pointers could be reused and not be mapped correctly.
|
|
|
|
*/
|
|
|
|
customnodes_free_deprecated_data(mainvar);
|
|
|
|
}
|
2013-03-18 16:34:57 +00:00
|
|
|
#endif
|
|
|
|
|
2004-09-05 13:43:51 +00:00
|
|
|
/* end of file */
|
|
|
|
memset(&bhead, 0, sizeof(BHead));
|
2016-06-28 17:35:35 +10:00
|
|
|
bhead.code = ENDB;
|
2004-09-05 13:43:51 +00:00
|
|
|
mywrite(wd, &bhead, sizeof(BHead));
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
blo_join_main(&mainlist);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
return mywrite_end(wd);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
2011-06-02 12:44:59 +00:00
|
|
|
/* do reverse file history: .blend1 -> .blend2, .blend -> .blend1 */
|
|
|
|
/* return: success(0), failure(1) */
|
2014-02-03 18:55:59 +11:00
|
|
|
static bool do_history(const char *name, ReportList *reports)
|
2011-06-02 12:44:59 +00:00
|
|
|
{
|
2011-11-26 13:11:55 +00:00
|
|
|
char tempname1[FILE_MAX], tempname2[FILE_MAX];
|
2016-06-28 17:35:35 +10:00
|
|
|
int hisnr = U.versions;
|
|
|
|
|
|
|
|
if (U.versions == 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (strlen(name) < 2) {
|
2011-06-02 12:44:59 +00:00
|
|
|
BKE_report(reports, RPT_ERROR, "Unable to make version backup: filename too short");
|
|
|
|
return 1;
|
|
|
|
}
|
2016-02-03 17:06:42 +11:00
|
|
|
|
2012-03-24 07:52:14 +00:00
|
|
|
while (hisnr > 1) {
|
2016-06-28 17:35:35 +10:00
|
|
|
BLI_snprintf(tempname1, sizeof(tempname1), "%s%d", name, hisnr - 1);
|
2016-02-03 17:06:42 +11:00
|
|
|
if (BLI_exists(tempname1)) {
|
|
|
|
BLI_snprintf(tempname2, sizeof(tempname2), "%s%d", name, hisnr);
|
|
|
|
|
|
|
|
if (BLI_rename(tempname1, tempname2)) {
|
|
|
|
BKE_report(reports, RPT_ERROR, "Unable to make version backup");
|
|
|
|
return true;
|
|
|
|
}
|
2012-10-21 05:46:41 +00:00
|
|
|
}
|
2011-06-02 12:44:59 +00:00
|
|
|
hisnr--;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* is needed when hisnr==1 */
|
2016-02-03 17:06:42 +11:00
|
|
|
if (BLI_exists(name)) {
|
|
|
|
BLI_snprintf(tempname1, sizeof(tempname1), "%s%d", name, hisnr);
|
2011-06-02 12:44:59 +00:00
|
|
|
|
2016-02-03 17:06:42 +11:00
|
|
|
if (BLI_rename(name, tempname1)) {
|
|
|
|
BKE_report(reports, RPT_ERROR, "Unable to make version backup");
|
|
|
|
return true;
|
|
|
|
}
|
2011-06-02 12:44:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-04-14 13:17:11 +02:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name File Writing (Public)
|
|
|
|
* \{ */
|
|
|
|
|
2016-03-03 13:35:21 +11:00
|
|
|
/**
|
|
|
|
* \return Success.
|
|
|
|
*/
|
|
|
|
bool BLO_write_file(
|
|
|
|
Main *mainvar, const char *filepath, int write_flags,
|
|
|
|
ReportList *reports, const BlendThumbnail *thumb)
|
2002-10-12 11:37:38 +00:00
|
|
|
{
|
2016-06-28 17:35:35 +10:00
|
|
|
char tempname[FILE_MAX + 1];
|
2014-09-04 21:48:36 +10:00
|
|
|
eWriteWrapType ww_type;
|
|
|
|
WriteWrap ww;
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2012-11-07 04:13:03 +00:00
|
|
|
/* path backup/restore */
|
|
|
|
void *path_list_backup = NULL;
|
2012-12-15 15:31:50 +00:00
|
|
|
const int path_list_flag = (BKE_BPATH_TRAVERSE_SKIP_LIBRARY | BKE_BPATH_TRAVERSE_SKIP_MULTIFILE);
|
2012-11-07 04:13:03 +00:00
|
|
|
|
2018-04-18 18:22:18 +02:00
|
|
|
if (G.debug & G_DEBUG_IO && mainvar->lock != NULL) {
|
|
|
|
BKE_report(reports, RPT_INFO, "Checking sanity of current .blend file *BEFORE* save to disk.");
|
|
|
|
BLO_main_validate_libraries(mainvar, reports);
|
|
|
|
}
|
|
|
|
|
2010-01-29 11:26:17 +00:00
|
|
|
/* open temporary file, so we preserve the original in case we crash */
|
2011-05-18 06:27:32 +00:00
|
|
|
BLI_snprintf(tempname, sizeof(tempname), "%s@", filepath);
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2014-09-04 21:48:36 +10:00
|
|
|
if (write_flags & G_FILE_COMPRESS) {
|
|
|
|
ww_type = WW_WRAP_ZLIB;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
ww_type = WW_WRAP_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
ww_handle_init(ww_type, &ww);
|
|
|
|
|
|
|
|
if (ww.open(&ww, tempname) == false) {
|
2012-10-19 16:43:10 +00:00
|
|
|
BKE_reportf(reports, RPT_ERROR, "Cannot open file %s for writing: %s", tempname, strerror(errno));
|
2002-10-12 11:37:38 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2012-11-07 04:13:03 +00:00
|
|
|
/* check if we need to backup and restore paths */
|
|
|
|
if (UNLIKELY((write_flags & G_FILE_RELATIVE_REMAP) && (G_FILE_SAVE_COPY & write_flags))) {
|
2012-12-15 15:31:50 +00:00
|
|
|
path_list_backup = BKE_bpath_list_backup(mainvar, path_list_flag);
|
2012-11-07 04:13:03 +00:00
|
|
|
}
|
|
|
|
|
2010-01-29 11:26:17 +00:00
|
|
|
/* remapping of relative paths to new file location */
|
2012-03-24 06:18:31 +00:00
|
|
|
if (write_flags & G_FILE_RELATIVE_REMAP) {
|
2011-11-26 13:11:55 +00:00
|
|
|
char dir1[FILE_MAX];
|
|
|
|
char dir2[FILE_MAX];
|
2011-10-21 02:13:36 +00:00
|
|
|
BLI_split_dir_part(filepath, dir1, sizeof(dir1));
|
|
|
|
BLI_split_dir_part(mainvar->name, dir2, sizeof(dir2));
|
2010-01-08 17:50:55 +00:00
|
|
|
|
2012-03-09 00:41:09 +00:00
|
|
|
/* just in case there is some subtle difference */
|
2010-01-08 20:55:13 +00:00
|
|
|
BLI_cleanup_dir(mainvar->name, dir1);
|
|
|
|
BLI_cleanup_dir(mainvar->name, dir2);
|
2010-01-08 17:50:55 +00:00
|
|
|
|
2013-11-27 21:25:15 +11:00
|
|
|
if (G.relbase_valid && (BLI_path_cmp(dir1, dir2) == 0)) {
|
2010-01-08 17:50:55 +00:00
|
|
|
write_flags &= ~G_FILE_RELATIVE_REMAP;
|
2011-05-18 06:48:52 +00:00
|
|
|
}
|
|
|
|
else {
|
2012-03-24 06:18:31 +00:00
|
|
|
if (G.relbase_valid) {
|
2011-05-18 06:48:52 +00:00
|
|
|
/* blend may not have been saved before. Tn this case
|
|
|
|
* we should not have any relative paths, but if there
|
2018-06-13 16:29:12 +02:00
|
|
|
* is somehow, an invalid or empty G_MAIN->name it will
|
2012-03-18 07:38:51 +00:00
|
|
|
* print an error, don't try make the absolute in this case. */
|
2018-06-05 15:10:33 +02:00
|
|
|
BKE_bpath_absolute_convert(mainvar, BKE_main_blendfile_path_from_global(), NULL);
|
2011-05-18 06:48:52 +00:00
|
|
|
}
|
|
|
|
}
|
2010-01-08 17:50:55 +00:00
|
|
|
}
|
|
|
|
|
2016-06-28 17:35:35 +10:00
|
|
|
if (write_flags & G_FILE_RELATIVE_REMAP) {
|
2018-06-13 16:29:12 +02:00
|
|
|
/* note, making relative to something OTHER then G_MAIN->name */
|
2016-06-28 17:35:35 +10:00
|
|
|
BKE_bpath_relative_convert(mainvar, filepath, NULL);
|
|
|
|
}
|
2010-01-08 17:50:55 +00:00
|
|
|
|
2010-01-29 11:26:17 +00:00
|
|
|
/* actual file writing */
|
2016-06-28 21:00:00 +10:00
|
|
|
const bool err = write_file_handle(mainvar, &ww, NULL, NULL, write_flags, thumb);
|
2014-09-04 21:48:36 +10:00
|
|
|
|
|
|
|
ww.close(&ww);
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2012-11-07 04:13:03 +00:00
|
|
|
if (UNLIKELY(path_list_backup)) {
|
2012-12-15 15:31:50 +00:00
|
|
|
BKE_bpath_list_restore(mainvar, path_list_flag, path_list_backup);
|
|
|
|
BKE_bpath_list_free(path_list_backup);
|
2012-11-07 04:13:03 +00:00
|
|
|
}
|
|
|
|
|
2011-06-02 12:44:59 +00:00
|
|
|
if (err) {
|
|
|
|
BKE_report(reports, RPT_ERROR, strerror(errno));
|
|
|
|
remove(tempname);
|
2010-01-29 11:26:17 +00:00
|
|
|
|
2011-06-02 12:44:59 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2010-01-29 11:26:17 +00:00
|
|
|
|
2011-06-02 12:44:59 +00:00
|
|
|
/* file save to temporary file was successful */
|
|
|
|
/* now do reverse file history (move .blend1 -> .blend2, .blend -> .blend1) */
|
2012-10-21 05:46:41 +00:00
|
|
|
if (write_flags & G_FILE_HISTORY) {
|
2014-02-03 18:55:59 +11:00
|
|
|
const bool err_hist = do_history(filepath, reports);
|
2011-06-02 12:44:59 +00:00
|
|
|
if (err_hist) {
|
2012-10-13 15:44:50 +00:00
|
|
|
BKE_report(reports, RPT_ERROR, "Version backup failed (file saved with @)");
|
2011-06-02 12:44:59 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-04 21:48:36 +10:00
|
|
|
if (BLI_rename(tempname, filepath) != 0) {
|
2012-10-19 16:43:10 +00:00
|
|
|
BKE_report(reports, RPT_ERROR, "Cannot change old file (file saved with @)");
|
2002-10-12 11:37:38 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2004-06-23 18:22:51 +00:00
|
|
|
|
2018-04-18 18:22:18 +02:00
|
|
|
if (G.debug & G_DEBUG_IO && mainvar->lock != NULL) {
|
|
|
|
BKE_report(reports, RPT_INFO, "Checking sanity of current .blend file *AFTER* save to disk.");
|
|
|
|
BLO_main_validate_libraries(mainvar, reports);
|
|
|
|
}
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-03-03 13:35:21 +11:00
|
|
|
/**
|
|
|
|
* \return Success.
|
|
|
|
*/
|
|
|
|
bool BLO_write_file_mem(Main *mainvar, MemFile *compare, MemFile *current, int write_flags)
|
2004-09-05 13:43:51 +00:00
|
|
|
{
|
2016-06-28 21:00:00 +10:00
|
|
|
write_flags &= ~G_FILE_USERPREFS;
|
2004-09-05 13:43:51 +00:00
|
|
|
|
2016-06-28 21:00:00 +10:00
|
|
|
const bool err = write_file_handle(mainvar, NULL, compare, current, write_flags, NULL);
|
Holiday coding log :)
Nice formatted version (pictures soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability
Short list of main changes:
- Transparent region option (over main region), added code to blend in/out such panels.
- Min size window now 640 x 480
- Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake.
- Macbook retina support, use command line --no-native-pixels to disable it
- Timeline Marker label was drawing wrong
- Trackpad and magic mouse: supports zoom (hold ctrl)
- Fix for splash position: removed ghost function and made window size update after creation immediate
- Fast undo buffer save now adds UI as well. Could be checked for regular file save even...
Quit.blend and temp file saving use this now.
- Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)"
- New Userpref option "Keep Session" - this always saves quit.blend, and loads on start.
This allows keeping UI and data without actual saves, until you actually save.
When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header)
- Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v).
Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards.
- User preferences (themes, keymaps, user settings) now can be saved as a separate file.
Old option is called "Save Startup File" the new one "Save User Settings".
To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still.
- OSX: fixed bug that stopped giving mouse events outside window.
This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
|
|
|
|
2016-03-03 13:35:21 +11:00
|
|
|
return (err == 0);
|
|
|
|
}
|
2018-04-14 13:17:11 +02:00
|
|
|
|
|
|
|
/** \} */
|