2002-10-12 11:37:38 +00:00
|
|
|
/**
|
|
|
|
* $Id$
|
|
|
|
*
|
|
|
|
* ***** BEGIN GPL/BL DUAL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version. The Blender
|
|
|
|
* Foundation also sells licenses for use in proprietary software under
|
|
|
|
* the Blender License. See http://www.blender.org/BL/ for information
|
|
|
|
* about this.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
*
|
|
|
|
* Contributor(s): none yet.
|
|
|
|
*
|
|
|
|
* ***** END GPL/BL DUAL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* placed up here because of crappy
|
|
|
|
* winsock stuff.
|
|
|
|
*/
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
2002-11-25 12:02:15 +00:00
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
#include <config.h>
|
|
|
|
#endif
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
#ifdef WIN32
|
|
|
|
#include "BLI_winstuff.h"
|
2003-03-24 01:46:05 +00:00
|
|
|
#include <process.h> /* getpid */
|
2002-10-12 11:37:38 +00:00
|
|
|
#else
|
|
|
|
#include <unistd.h> /* getpid */
|
|
|
|
#endif
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
#include "BMF_Api.h"
|
2003-05-03 12:17:11 +00:00
|
|
|
#ifdef INTERNATIONAL
|
|
|
|
#include "BIF_language.h"
|
2004-01-23 16:02:10 +00:00
|
|
|
#include "FTF_Api.h"
|
2003-05-03 12:17:11 +00:00
|
|
|
#endif
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
#include "BLI_blenlib.h"
|
|
|
|
#include "BLI_arithb.h"
|
|
|
|
#include "BLI_linklist.h"
|
|
|
|
|
|
|
|
#include "IMB_imbuf_types.h"
|
|
|
|
#include "IMB_imbuf.h"
|
|
|
|
|
|
|
|
#include "DNA_object_types.h"
|
|
|
|
#include "DNA_space_types.h"
|
|
|
|
#include "DNA_userdef_types.h"
|
2004-04-21 13:38:54 +00:00
|
|
|
#include "DNA_sound_types.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
#include "BKE_blender.h"
|
|
|
|
#include "BKE_curve.h"
|
|
|
|
#include "BKE_displist.h"
|
|
|
|
#include "BKE_exotic.h"
|
|
|
|
#include "BKE_font.h"
|
|
|
|
#include "BKE_global.h"
|
|
|
|
#include "BKE_main.h"
|
|
|
|
#include "BKE_mball.h"
|
|
|
|
#include "BKE_packedFile.h"
|
2003-05-05 21:28:54 +00:00
|
|
|
#include "BKE_utildefines.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
#include "BIF_fsmenu.h"
|
|
|
|
#include "BIF_gl.h"
|
|
|
|
#include "BIF_interface.h"
|
|
|
|
#include "BIF_usiblender.h"
|
|
|
|
#include "BIF_drawtext.h"
|
|
|
|
#include "BIF_editarmature.h"
|
|
|
|
#include "BIF_editlattice.h"
|
|
|
|
#include "BIF_editfont.h"
|
|
|
|
#include "BIF_editmesh.h"
|
EditMesh refactory + undo recode
The changelog is very long... it's on the web too:
http://www.blender3d.org/cms/Mesh_editing_rewrite.425.0.html
EditMesh refactor notes (user)
**** New selection modes
When entering Edit Mode for a Mesh, you now have the choice for three selection modes. These are shown as icons in the 3D header (hotkey is being searched for!).
- Vertex Select
Select vertices as usual, fully compatible with how previous version work
- Edge Select
Vertices are not drawn anymore, and selections happen by default on the edges. It is a true edge select, meaning that you can select three out of four edges in a face, without automatic having the 4th edge selected.
- Face Select
Instead of vertices, now selection 'points' are drawn in the face centers. Selected faces also get a colored outline, like for edges. This also is true face select, for each face individual regardless selection status of its vertices or edges.
While holding SHIFT, and press a selection mode, you can also combine the above choices. Now selection becomes mixed, and will behave as expected.
For example; in Edge+Face select mode, selecting the 4 edges of a face will select the face too.
The selection modes and optional drawing modes (like transparant faces, normals, or solid drawing) all work together. All of Blender's mesh editing tools now react to the correct selection mode as well.
Most noticeable it's in:
**** Extrude
Extruding in Edge or Face Select mode allows much more precise control over what's extruded and what should be excluded. Try for example a checker pattern selection, and extrude it.
New is the fixed translation when faces are extruded. This always follows the (averaged) face normal(s) of the old face(s), enabling much easier working in 3D views . A single 'G' (Grab) or 'R' (Rotate) or 'S' (Scale) will change transform modus as usual.
**** Other things to note
- Hiding edges/faces will also behave different based on Select Mode.
- while editing, normals of faces are updated always now
- Border select (BKEY) has 2 different rules for edges; when one edge is fully inside of the border, it will only select edges that are fully inside. Otherwise it selects each edge intersecting with the border.
- in face mode, adding vertices, edges or a circle is invisible...
- "Add monkey" now works as a normal primitive (rotated and on 3d cursor)
- Mesh undo was fully recoded, hopefully solving issues now with Vertex Keys and Groups
- Going in and out of editmode was fully recoded. Especially on larger models you'll notice substantial speed gain.
**** Todo
Add 'FaceSelect mode' functionality in EditMode, including zbuffered selection, display and editing of UV texture.
EditMesh refactor notes (coder)
**** Usage of flags in general
The "->f" flags are reserved for the editmesh.c and editmesh_lib.c core functions. Actually only selection status is there now.
The "->f1" and "->f2" flags are free to use. They're available in vertex/edge/face structs. Since they're free, check carefully when calling other functions that use these flags... for example extrude() or subdivide() use them.
**** Selection flags
EditVert: eve->f & SELECT
EditEdge: eed->f & SELECT
EditFace: efa->f & SELECT
- Selection is only possible when not-hidden!
- Selection flags are always up-to-date, BUT:
if selection mode >= SELECT_EDGE vertex selection flags can be incorrect
if selection mode == SELECT_FACE vertex/edge selection flags can be incorrect
This because of shared vertices or edges.
- use for selecting vertices:
eve->f &= SELECT
- use for selecting edges always:
void EM_select_edge(eed, 1) // 1 = select, 0 = deselect
- use for selecting faces always:
void EM_select_face(efa, 1) // 1 = select, 0 = deselect
- To set the 'f' flags in all of the data:
void EM_set_flag_all(int flag);
void EM_clear_flag_all(int flag);
- the old faceselectedOR() and faceselectedAND() are still there, but only
to be used for evaluating its vertices
**** Code hints for handling selection
If the selectmode is 'face'; vertex or edge selections need to be flushed upward. Same is true for 'edge' selection mode. This means that you'll have to keep track of all selections while coding... selecting the four vertices in a face doesn't automatically select the face anymore.
However, by using the above calls, at least selections flush downward (to vertex level). You then can call:
void EM_selectmode_flush(void);
Which flushes selections back upward, based on the selectmode setting. This function does the following:
- if selectmode 'vertex': select edges/faces based on its selected vertices
- if selectmode 'edge': select faces based its selected edges
This works fine in nice controlled situations.
However, only changing the vertex selections then still doesn't select a face in face mode! If you really can't avoid only working with vertex selections, you can use this call:
void EM_select_flush(void);
Now selection is flushed upward regardless current selectmode. That can be destructive for special cases however, like checkerboard selected faces. So use this only when you know everything else was deselected (or deselect it). Example: adding primitives.
**** Hide flags
EditVert: eve->h
EditEdge: eed->h
EditFace: efa->h
- all hide flags are always up-to-date
- hidden vertices/edges/faces are always deselected. so when you operate on selection only, there's no need to check for hide flag.
**** Unified undo for editmode
New file: editmode_undo.h
A pretty nice function pointer handler style undo. Just code three functions, and your undo will fly! The c file has a good reference.
Also note that the old undo system has been replaced. It currently uses minimal dependencies on Meshes themselves (no abuse of going in/out editmode), and is restricted nicely to editmode functions.
**** Going in/out editmode
As speedup now all vertices/faces/edges are allocated in three big chunks. In vertices/faces/edges now tags are set to denote such data cannot be freed.
ALso the hashtable (lookup) for edges uses no mallocs at all anymore, but is part of the EditEdge itself.
2004-09-23 20:52:51 +00:00
|
|
|
#include "BIF_editmode_undo.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BIF_editsound.h"
|
|
|
|
#include "BIF_renderwin.h"
|
|
|
|
#include "BIF_resources.h"
|
|
|
|
#include "BIF_screen.h"
|
|
|
|
#include "BIF_space.h"
|
|
|
|
#include "BIF_toolbox.h"
|
2003-12-26 20:12:42 +00:00
|
|
|
#include "BIF_cursors.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
#include "BSE_drawview.h"
|
|
|
|
#include "BSE_headerbuttons.h"
|
|
|
|
#include "BSE_editipo.h"
|
|
|
|
#include "BSE_editaction.h"
|
|
|
|
#include "BSE_filesel.h"
|
2004-06-22 12:59:53 +00:00
|
|
|
#include "BSE_edit.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
#include "BLO_readfile.h"
|
|
|
|
#include "BLO_writefile.h"
|
|
|
|
|
|
|
|
#include "BDR_drawobject.h"
|
|
|
|
#include "BDR_editobject.h"
|
2004-08-31 13:43:18 +00:00
|
|
|
#include "BDR_editcurve.h"
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "BDR_vpaint.h"
|
|
|
|
|
2003-11-23 14:28:46 +00:00
|
|
|
#include "BPY_extern.h"
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "blendef.h"
|
|
|
|
|
|
|
|
#include "radio.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 "render.h" // RE_ free stuff
|
2002-10-12 11:37:38 +00:00
|
|
|
#include "datatoc.h"
|
|
|
|
|
|
|
|
#include "SYS_System.h"
|
|
|
|
|
|
|
|
#include "PIL_time.h"
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
2005-05-13 16:11:28 +00:00
|
|
|
/* define for setting colors in theme below */
|
|
|
|
#define SETCOL(col, r, g, b, a) col[0]=r; col[1]=g; col[2]= b; col[3]= a;
|
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
/* patching UserDef struct, set globals for UI stuff */
|
|
|
|
static void init_userdef_file(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
BIF_InitTheme(); // sets default again
|
|
|
|
|
|
|
|
mainwindow_set_filename_to_title(""); // empty string re-initializes title to "Blender"
|
|
|
|
countall();
|
|
|
|
G.save_over = 0; // start with save preference untitled.blend
|
|
|
|
|
|
|
|
/* disable autoplay in .B.blend... */
|
|
|
|
G.fileflags &= ~G_FILE_AUTOPLAY;
|
|
|
|
|
|
|
|
/* the UserDef struct is not corrected with do_versions() .... ugh! */
|
|
|
|
if(U.wheellinescroll == 0) U.wheellinescroll = 3;
|
|
|
|
if(U.menuthreshold1==0) {
|
|
|
|
U.menuthreshold1= 5;
|
|
|
|
U.menuthreshold2= 2;
|
|
|
|
}
|
|
|
|
if(U.tb_leftmouse==0) {
|
|
|
|
U.tb_leftmouse= 5;
|
|
|
|
U.tb_rightmouse= 5;
|
|
|
|
}
|
|
|
|
if(U.mixbufsize==0) U.mixbufsize= 2048;
|
|
|
|
if (BLI_streq(U.tempdir, "/")) {
|
|
|
|
char *tmp= getenv("TEMP");
|
|
|
|
|
|
|
|
strcpy(U.tempdir, tmp?tmp:"/tmp/");
|
|
|
|
}
|
|
|
|
if (U.savetime <= 0) {
|
|
|
|
U.savetime = 1;
|
|
|
|
error(".B.blend is buggy, please consider removing it.\n");
|
|
|
|
}
|
2005-03-21 14:20:04 +00:00
|
|
|
/* transform widget settings */
|
|
|
|
if(U.tw_hotspot==0) {
|
|
|
|
U.tw_hotspot= 14;
|
2005-04-02 13:57:23 +00:00
|
|
|
U.tw_size= 20; // percentage of window size
|
2005-04-24 13:22:24 +00:00
|
|
|
U.tw_handlesize= 16; // percentage of widget radius
|
2005-03-21 14:20:04 +00:00
|
|
|
}
|
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
if (G.main->versionfile <= 191) {
|
|
|
|
strcpy(U.plugtexdir, U.textudir);
|
|
|
|
strcpy(U.sounddir, "/");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* patch to set Dupli Armature */
|
|
|
|
if (G.main->versionfile < 220) {
|
|
|
|
U.dupflag |= USER_DUP_ARM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* userdef new option */
|
|
|
|
if (G.main->versionfile <= 222) {
|
|
|
|
U.vrmlflag= USER_VRML_LAYERS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* added seam, normal color, undo */
|
|
|
|
if (G.main->versionfile <= 234) {
|
|
|
|
bTheme *btheme;
|
|
|
|
|
|
|
|
U.uiflag |= USER_GLOBALUNDO;
|
|
|
|
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
if(btheme->tv3d.edge_seam[3]==0) {
|
2005-05-13 16:11:28 +00:00
|
|
|
SETCOL(btheme->tv3d.edge_seam, 230, 150, 50, 255);
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
}
|
|
|
|
if(btheme->tv3d.normal[3]==0) {
|
2005-05-13 16:11:28 +00:00
|
|
|
SETCOL(btheme->tv3d.normal, 0x22, 0xDD, 0xDD, 255);
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
}
|
|
|
|
if(btheme->tv3d.face_dot[3]==0) {
|
2005-05-13 16:11:28 +00:00
|
|
|
SETCOL(btheme->tv3d.face_dot, 255, 138, 48, 255);
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
btheme->tv3d.facedot_size= 4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (G.main->versionfile <= 235) {
|
|
|
|
/* illegal combo... */
|
|
|
|
if (U.flag & USER_LMOUSESELECT)
|
|
|
|
U.flag &= ~USER_TWOBUTTONMOUSE;
|
|
|
|
}
|
Added the new Timeline Window, copied from Tuhopuu, coded by Matt Ebb.
Main change is that it's an own Space type now, not part of the Audio
window... the audio window should restrict to own options. This way
functionality is nicely separated.
Since it's the first time I added a new space (since long!) I've made an
extensive tutorial as well. You can find that here:
http://www.blender3d.org/cms/Adding_new_Space_Window.557.0.html
Notes for using timewindow;
- Add time markers with MKey
- CTRL+M gives option to name Marker
- Markers cannot be moved yet...
- Pageup-Pagedown keys moves current frame to next-prev Marker
- Xkey removes Markers
- If an object has Ipos or an Action, it draws key lines
- CTRL+Pageup-Pagedown moves current frame to next-prev Key
- Press S or E to set start/end frame for playback
Notes about the implementation in Tuhopuu:
- Add new Marker now selects new, deselects others
- Selecting Marker didn't work like elsewhere in Blender, on click it
should deselect all, except the indicated Marker. Not when holding SHIFT
of course
- Not exported functions are static now
- Removed unused defines (MARKER_NONE NEXT_AVAIL)
- Drawing order was confusing, doing too many matrix calls
- Removed not needed scrollbar, added new function to draw time values.
(Has advantage the MMB scroll works not confusing on a scrollbar)
- Added proper support for 'frame mapping'
- The string button (name Marker) had a bug (checked str[64] while str
was only 64 long)
- String button itself didn't allow "OK on enter"
- Made frame buttons in header larger, the arrows overlapped
- Removed support for negative frame values, that won't work so simple!
2005-05-05 17:19:21 +00:00
|
|
|
if (G.main->versionfile <= 236) {
|
|
|
|
bTheme *btheme;
|
|
|
|
/* new space type */
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
if(btheme->ttime.back[3]==0) {
|
|
|
|
btheme->ttime = btheme->tsnd; // copy from sound
|
|
|
|
}
|
2005-05-13 16:11:28 +00:00
|
|
|
if(btheme->text.syntaxn[3]==0) {
|
|
|
|
SETCOL(btheme->text.syntaxn, 0, 0, 200, 255); /* Numbers Blue*/
|
|
|
|
SETCOL(btheme->text.syntaxl, 100, 0, 0, 255); /* Strings red */
|
|
|
|
SETCOL(btheme->text.syntaxc, 0, 100, 50, 255); /* Comments greenish */
|
|
|
|
SETCOL(btheme->text.syntaxv, 95, 95, 0, 255); /* Special */
|
|
|
|
SETCOL(btheme->text.syntaxb, 128, 0, 80, 255); /* Builtin, red-purple */
|
|
|
|
}
|
Added the new Timeline Window, copied from Tuhopuu, coded by Matt Ebb.
Main change is that it's an own Space type now, not part of the Audio
window... the audio window should restrict to own options. This way
functionality is nicely separated.
Since it's the first time I added a new space (since long!) I've made an
extensive tutorial as well. You can find that here:
http://www.blender3d.org/cms/Adding_new_Space_Window.557.0.html
Notes for using timewindow;
- Add time markers with MKey
- CTRL+M gives option to name Marker
- Markers cannot be moved yet...
- Pageup-Pagedown keys moves current frame to next-prev Marker
- Xkey removes Markers
- If an object has Ipos or an Action, it draws key lines
- CTRL+Pageup-Pagedown moves current frame to next-prev Key
- Press S or E to set start/end frame for playback
Notes about the implementation in Tuhopuu:
- Add new Marker now selects new, deselects others
- Selecting Marker didn't work like elsewhere in Blender, on click it
should deselect all, except the indicated Marker. Not when holding SHIFT
of course
- Not exported functions are static now
- Removed unused defines (MARKER_NONE NEXT_AVAIL)
- Drawing order was confusing, doing too many matrix calls
- Removed not needed scrollbar, added new function to draw time values.
(Has advantage the MMB scroll works not confusing on a scrollbar)
- Added proper support for 'frame mapping'
- The string button (name Marker) had a bug (checked str[64] while str
was only 64 long)
- String button itself didn't allow "OK on enter"
- Made frame buttons in header larger, the arrows overlapped
- Removed support for negative frame values, that won't work so simple!
2005-05-05 17:19:21 +00:00
|
|
|
}
|
|
|
|
}
|
2005-07-12 15:47:53 +00:00
|
|
|
if (G.main->versionfile <= 237) {
|
|
|
|
bTheme *btheme;
|
|
|
|
/* bone colors */
|
|
|
|
for(btheme= U.themes.first; btheme; btheme= btheme->next) {
|
|
|
|
/* check for alpha==0 is safe, then color was never set */
|
|
|
|
if(btheme->tv3d.bone_solid[3]==0) {
|
|
|
|
SETCOL(btheme->tv3d.bone_solid, 200, 200, 200, 255);
|
2005-07-16 19:07:02 +00:00
|
|
|
SETCOL(btheme->tv3d.bone_pose, 80, 200, 255, 80);
|
2005-07-12 15:47:53 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Added the new Timeline Window, copied from Tuhopuu, coded by Matt Ebb.
Main change is that it's an own Space type now, not part of the Audio
window... the audio window should restrict to own options. This way
functionality is nicely separated.
Since it's the first time I added a new space (since long!) I've made an
extensive tutorial as well. You can find that here:
http://www.blender3d.org/cms/Adding_new_Space_Window.557.0.html
Notes for using timewindow;
- Add time markers with MKey
- CTRL+M gives option to name Marker
- Markers cannot be moved yet...
- Pageup-Pagedown keys moves current frame to next-prev Marker
- Xkey removes Markers
- If an object has Ipos or an Action, it draws key lines
- CTRL+Pageup-Pagedown moves current frame to next-prev Key
- Press S or E to set start/end frame for playback
Notes about the implementation in Tuhopuu:
- Add new Marker now selects new, deselects others
- Selecting Marker didn't work like elsewhere in Blender, on click it
should deselect all, except the indicated Marker. Not when holding SHIFT
of course
- Not exported functions are static now
- Removed unused defines (MARKER_NONE NEXT_AVAIL)
- Drawing order was confusing, doing too many matrix calls
- Removed not needed scrollbar, added new function to draw time values.
(Has advantage the MMB scroll works not confusing on a scrollbar)
- Added proper support for 'frame mapping'
- The string button (name Marker) had a bug (checked str[64] while str
was only 64 long)
- String button itself didn't allow "OK on enter"
- Made frame buttons in header larger, the arrows overlapped
- Removed support for negative frame values, that won't work so simple!
2005-05-05 17:19:21 +00:00
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
if (U.undosteps==0) U.undosteps=32;
|
|
|
|
|
2005-07-14 12:44:33 +00:00
|
|
|
/* GL Texture Garbage Collection (variable abused above!) */
|
2005-07-27 07:50:28 +00:00
|
|
|
if (U.textimeout == 0) {
|
|
|
|
U.texcollectrate = 60;
|
|
|
|
U.textimeout = 120;
|
|
|
|
}
|
2005-07-14 12:44:33 +00:00
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
reset_autosave();
|
|
|
|
|
|
|
|
#ifdef INTERNATIONAL
|
|
|
|
read_languagefile();
|
|
|
|
|
2005-01-19 13:53:43 +00:00
|
|
|
refresh_interface_font();
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
#endif // INTERNATIONAL
|
2005-01-19 13:53:43 +00:00
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
}
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
void BIF_read_file(char *name)
|
|
|
|
{
|
|
|
|
extern short winqueue_break; /* editscreen.c */
|
2004-05-04 21:16:39 +00:00
|
|
|
|
2003-04-30 13:22:26 +00:00
|
|
|
//here?
|
2002-10-12 11:37:38 +00:00
|
|
|
//sound_end_all_sounds();
|
|
|
|
|
|
|
|
// first try to read exotic file formats...
|
|
|
|
if (BKE_read_exotic(name) == 0) { /* throws first error box */
|
2003-05-22 17:16:41 +00:00
|
|
|
/* we didn't succeed, now try to read Blender file
|
2004-01-04 22:10:36 +00:00
|
|
|
calls readfile, calls toolbox, throws one more,
|
2003-05-22 17:16:41 +00:00
|
|
|
on failure calls the stream, and that is stubbed.... */
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
int retval= BKE_read_file(name, NULL);
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2004-11-07 16:49:46 +00:00
|
|
|
mainwindow_set_filename_to_title(G.main->name);
|
|
|
|
countall();
|
|
|
|
sound_initialize_sounds();
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2004-11-07 16:49:46 +00:00
|
|
|
winqueue_break= 1; /* leave queues everywhere */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
if(retval==2) init_userdef_file(); // in case a userdef is read from regular .blend
|
|
|
|
|
2004-11-07 16:49:46 +00:00
|
|
|
undo_editmode_clear();
|
|
|
|
BKE_reset_undo();
|
|
|
|
BKE_write_undo("original"); /* save current state */
|
2005-01-19 13:53:43 +00:00
|
|
|
refresh_interface_font();
|
2004-11-07 16:49:46 +00:00
|
|
|
}
|
|
|
|
else BIF_undo_push("Import file");
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
/* only here settings for fullscreen */
|
2002-10-12 11:37:38 +00:00
|
|
|
int BIF_read_homefile(void)
|
|
|
|
{
|
|
|
|
char tstr[FILE_MAXDIR+FILE_MAXFILE], scestr[FILE_MAXDIR];
|
|
|
|
char *home= BLI_gethome();
|
2003-05-09 12:48:21 +00:00
|
|
|
int success;
|
2005-06-10 13:12:59 +00:00
|
|
|
|
|
|
|
BLI_clean(home);
|
|
|
|
|
2005-03-23 21:10:03 +00:00
|
|
|
#if 0
|
|
|
|
//#ifdef _WIN32 // FULLSCREEN
|
2003-05-12 14:23:03 +00:00
|
|
|
static int screenmode = -1;
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
|
2004-01-13 14:50:45 +00:00
|
|
|
screenmode = U.uiflag & USER_FLIPFULLSCREEN;
|
2003-05-12 14:23:03 +00:00
|
|
|
#endif
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
BLI_make_file_string(G.sce, tstr, home, ".B.blend");
|
2003-04-30 13:22:26 +00:00
|
|
|
strcpy(scestr, G.sce); /* temporal store */
|
2004-12-04 17:52:44 +00:00
|
|
|
|
|
|
|
/* prevent loading no UI */
|
|
|
|
G.fileflags &= ~G_FILE_NO_UI;
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
if (BLI_exists(tstr)) {
|
|
|
|
success = BKE_read_file(tstr, NULL);
|
|
|
|
} else {
|
|
|
|
success = BKE_read_file_from_memory(datatoc_B_blend, datatoc_B_blend_size, NULL);
|
|
|
|
}
|
2005-06-10 13:12:59 +00:00
|
|
|
BLI_clean(scestr);
|
2002-10-12 11:37:38 +00:00
|
|
|
strcpy(G.sce, scestr);
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
|
2005-03-23 21:10:03 +00:00
|
|
|
#if 0
|
|
|
|
//#ifdef _WIN32 // FULLSCREEN
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
/* choose window startmode */
|
|
|
|
switch (G.windowstate){
|
|
|
|
case G_WINDOWSTATE_USERDEF: /* use the usersetting */
|
|
|
|
break;
|
|
|
|
case G_WINDOWSTATE_FULLSCREEN: /* force fullscreen */
|
|
|
|
U.uiflag |= USER_FLIPFULLSCREEN;
|
|
|
|
break;
|
|
|
|
case G_WINDOWSTATE_BORDER: /* force with borders */
|
|
|
|
U.uiflag &= ~USER_FLIPFULLSCREEN;
|
|
|
|
}
|
2004-04-09 13:51:48 +00:00
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
if(screenmode != (U.uiflag & USER_FLIPFULLSCREEN)) {
|
|
|
|
mainwindow_toggle_fullscreen ((U.uiflag & USER_FLIPFULLSCREEN));
|
|
|
|
screenmode = (U.uiflag & USER_FLIPFULLSCREEN);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
space_set_commmandline_options();
|
|
|
|
|
|
|
|
init_userdef_file();
|
2002-10-12 11:37:38 +00:00
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
undo_editmode_clear();
|
|
|
|
BKE_reset_undo();
|
|
|
|
BKE_write_undo("original"); /* save current state */
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
Essential cleanup for mess involved with reading files, initializing UI and
patching versions for UI settings.
Currently four different levels of routines for .blend file reading exist;
/* interface level */
1) BIF_init() -> calls 3
2) BIF_read_file() -> calls 11, optional 4
3) BIF_read_homefile() -> calls 11 or 12, and then 4
4) init_userdef_file()
/* kernel level */
11) BKE_read_file() -> calls 21, and then 14
12) BKE_read_file_from_memory() -> calls 22, and then 14
13) BKE_read_file_from_memfile() -> calls 23, and then 14
14) setup_app_data()
/* loader module level */
21) BLO_read_from_file() -> calls 24
22) BLO_read_from_memory() -> calls 24
23) BLO_read_from_memfile() -> calls 24
/* loader module, internal */
24) blo_read_file_internal()
Note:
- BIF_read_homefile() has additional UI initialize calls, like windows fullscreen and executing commandline options
- Reading from memory (12) only happens for the compiled-in .B.blend
- The "memfile" here is a name I gave to the undo "file" structure. Which is constructed out of memory chunks with basic compression features.
- the kernel function setup_app_data() sets globals like "current screen" and "current scene".
So far, so good. The levels as mentioned here clearly distinguish UI from kernel, and should enable for example game loading (runtime) or background (no UI) loading. In the past years however, 'bad level' dependencies were added, and especially the patches for 'file versions' were added in too many places. The latter is evidently a result of the problem that the "UserDef" struct cannot be initialized/patched if there's not a need for a UI.
Here's how the flow goes in four different cases:
----- Starting up Blender, in foreground with UI --------------------
- creator/creator.c, main() -> calls 1
- If the commandline contains a filename, it calls 11
----- Starting up Blender, in background without UI --------------------
- creator/creator.c, main() -> calls 11 if the commandline has a filename
Note: no Userdef is read, nor initialized. Please note that this was already an existing problem for using Yafray, not setting proper file paths in background mode. The Yafray paths don't belong in the User menu.
----- Starting up Blender as a runtime executable --------------------
This only has calls to 22
----- Loading a file from within the UI (with F1, CTRL+O, using pulldowns) -----
Only calls allowed to 2. It detects if a UserDef has been read too, and in that case the init_userdef_file() will be executed.
Hope this is understandable :)
-Ton-
2004-12-08 14:12:47 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
static void get_autosave_location(char buf[FILE_MAXDIR+FILE_MAXFILE])
|
|
|
|
{
|
|
|
|
char pidstr[32];
|
|
|
|
|
|
|
|
sprintf(pidstr, "%d.blend", abs(getpid()));
|
|
|
|
BLI_make_file_string("/", buf, U.tempdir, pidstr);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BIF_read_autosavefile(void)
|
|
|
|
{
|
|
|
|
char tstr[FILE_MAXDIR+FILE_MAXFILE], scestr[FILE_MAXDIR];
|
|
|
|
int save_over;
|
|
|
|
|
2003-04-30 13:22:26 +00:00
|
|
|
strcpy(scestr, G.sce); /* temporal store */
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
get_autosave_location(tstr);
|
|
|
|
|
|
|
|
save_over = G.save_over;
|
|
|
|
BKE_read_file(tstr, NULL);
|
|
|
|
G.save_over = save_over;
|
|
|
|
strcpy(G.sce, scestr);
|
|
|
|
}
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
static void readBlog(void)
|
|
|
|
{
|
2005-01-07 14:51:55 +00:00
|
|
|
char name[FILE_MAXDIR+FILE_MAXFILE], filename[FILE_MAXFILE];
|
2002-10-12 11:37:38 +00:00
|
|
|
LinkNode *l, *lines;
|
|
|
|
|
|
|
|
BLI_make_file_string("/", name, BLI_gethome(), ".Blog");
|
|
|
|
lines= BLI_read_file_as_lines(name);
|
|
|
|
|
|
|
|
if (lines && !BLI_streq(lines->link, "")) {
|
|
|
|
strcpy(G.sce, lines->link);
|
|
|
|
} else {
|
|
|
|
BLI_make_file_string("/", G.sce, BLI_gethome(), "untitled.blend");
|
|
|
|
}
|
|
|
|
|
|
|
|
BLI_free_file_lines(lines);
|
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
/* Add the drive names to the listing */
|
|
|
|
{
|
|
|
|
__int64 tmp;
|
|
|
|
char tmps[4];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
tmp= GetLogicalDrives();
|
|
|
|
|
|
|
|
for (i=2; i < 26; i++) {
|
|
|
|
if ((tmp>>i) & 1) {
|
|
|
|
tmps[0]='a'+i;
|
|
|
|
tmps[1]=':';
|
|
|
|
tmps[2]='\\';
|
|
|
|
tmps[3]=0;
|
|
|
|
|
|
|
|
fsmenu_insert_entry(tmps, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fsmenu_append_seperator();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
BLI_make_file_string(G.sce, name, BLI_gethome(), ".Bfs");
|
|
|
|
lines= BLI_read_file_as_lines(name);
|
|
|
|
|
|
|
|
for (l= lines; l; l= l->next) {
|
|
|
|
char *line= l->link;
|
|
|
|
|
|
|
|
if (!BLI_streq(line, "")) {
|
|
|
|
fsmenu_insert_entry(line, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fsmenu_append_seperator();
|
2005-01-07 14:51:55 +00:00
|
|
|
|
|
|
|
/* add last saved file */
|
|
|
|
BLI_split_dirfile(G.sce, name, filename);
|
|
|
|
|
|
|
|
fsmenu_insert_entry(name, 0);
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
BLI_free_file_lines(lines);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void writeBlog(void)
|
|
|
|
{
|
|
|
|
char name[FILE_MAXDIR+FILE_MAXFILE];
|
|
|
|
FILE *fp;
|
|
|
|
|
|
|
|
BLI_make_file_string("/", name, BLI_gethome(), ".Blog");
|
|
|
|
|
|
|
|
fp= fopen(name, "w");
|
|
|
|
if (fp) {
|
|
|
|
fprintf(fp, G.sce);
|
|
|
|
fclose(fp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void do_history(char *name)
|
|
|
|
{
|
|
|
|
char tempname1[FILE_MAXDIR+FILE_MAXFILE], tempname2[FILE_MAXDIR+FILE_MAXFILE];
|
|
|
|
int hisnr= U.versions;
|
|
|
|
|
|
|
|
if(U.versions==0) return;
|
|
|
|
if(strlen(name)<2) return;
|
|
|
|
|
|
|
|
while( hisnr > 1) {
|
|
|
|
sprintf(tempname1, "%s%d", name, hisnr-1);
|
|
|
|
sprintf(tempname2, "%s%d", name, hisnr);
|
|
|
|
|
|
|
|
if(BLI_rename(tempname1, tempname2))
|
|
|
|
error("Unable to make version backup");
|
|
|
|
|
|
|
|
hisnr--;
|
|
|
|
}
|
|
|
|
|
2003-04-30 13:22:26 +00:00
|
|
|
/* is needed when hisnr==1 */
|
2002-10-12 11:37:38 +00:00
|
|
|
sprintf(tempname1, "%s%d", name, hisnr);
|
|
|
|
|
|
|
|
if(BLI_rename(name, tempname1))
|
|
|
|
error("Unable to make version backup");
|
|
|
|
}
|
|
|
|
|
|
|
|
void BIF_write_file(char *target)
|
|
|
|
{
|
|
|
|
Library *li;
|
|
|
|
char di[FILE_MAXDIR];
|
|
|
|
char *err;
|
|
|
|
|
|
|
|
if (BLI_streq(target, "")) return;
|
2004-08-17 04:26:00 +00:00
|
|
|
|
BPython:
- Made Blender.event var (previously only used by script links) hold ascii value -- where it applies -- of current event during events callback registered with Draw.Register(gui, events, button_events). Useful for gui scripts like Campbell's Python console. No problem using this var to hold the value, since in gui scripts it was not used (always None).
- Updated Window and Window.Theme with new theme vars and the Time space.
- Script links:
-- Added "Render" event for script links (runs twice, second time as "PostEvent", for clean-up actions). Now FrameChanged links don't run when a single pic is rendered.
-- Added "Enable Script Links" button in the script buttons tab. Now this bit gets saved in .blends along with the rest of G.f, so users can define per .blend if they are on or off by default. "blender -y" also disables all slinks as happened before with OnLoad ones only.
-- Other small changes in the script buttons tab:
When a link is added (button "new"), it becomes the active one for the window, no need to press a button to reach it.
Also, a pupmenu showing all available texts is shown when "new" is pressed, so users can choose a text w/o having to type. Cancel the popup to leave the string button empty (link exists, but has no script assigned). A pulldown would be better UI-wise, but it's kinda weird to show both scripts and normal texts (Blender doesn't differentiate them) in a script links pulldown. With a popup we can show only texts ending in ".py" (not done in this commit, need opinions) and if the script has no or another extension, case of many in old and current .blend's, there's still the string box for writing its name.
-- Implemented Ton's space handler script links:
Right now only for the 3d View, but it's trivial to add for others. There are two types: EVENT, to receive 3d View events from a chosen window and DRAW, to draw on the window. Ton's idea was to give scripts a controlled way to integrate better within Blender.
Here's how it works:
- scripts must have a proper header, like:
# SPACEHANDLER.VIEW3D.EVENT
and then they are shown in 3d View's View menu, "Space Handler Scripts" submenu. Check (mark, click on it) a script to make it active.
EVENT handlers should consult the Blender.event var to get the current event, which can be compared with values from the Draw module:
import Blender
from Blender import Draw
evt = Blender.event
if evt == Draw.AKEY:
print "a"
elif evt == Draw.LEFTMOUSE:
print "left mouse button"
else:
return # ignore, pass event back to Blender
Blender.event = None # tell Blender not to process itself the event
DRAW handlers are free to draw to their owner 3D View. OpenGL attributes and modelview and projection matrices are pushed before running the handler and poped when it finishes.
To communicate between EVENT and DRAW handler scripts we have the Blender.Registry module, as always.
Still need to code some nice example, which should also serve to test properly space handlers. Simple tests went fine.
- doc updates about the additions.
=======
Note: the UI part of the space handlers and script links is of course open for changes, I just tried to make it understandable. Probably we won't use the scriptlinks icon for "None Available" (check 3d View -> View -> Space Handler Scripts), though it hints at what space handlers are. The tooltips may not be accepted either, since other menus don't use them. Opinions welcomed.
2005-05-08 21:20:34 +00:00
|
|
|
/* send the OnSave event */
|
|
|
|
if (G.f & G_DOSCRIPTLINKS) BPY_do_pyscript(&G.scene->id, SCRIPT_ONSAVE);
|
2004-08-17 04:26:00 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
for (li= G.main->library.first; li; li= li->id.next) {
|
|
|
|
if (BLI_streq(li->name, target)) {
|
|
|
|
error("Cannot overwrite used library");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!BLO_has_bfile_extension(target)) {
|
|
|
|
sprintf(di, "%s.blend", target);
|
|
|
|
} else {
|
|
|
|
strcpy(di, target);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (BLI_exists(di)) {
|
|
|
|
if(!saveover(di))
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(G.obedit) {
|
2003-04-30 13:22:26 +00:00
|
|
|
exit_editmode(0); /* 0 = no free data */
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
if (G.fileflags & G_AUTOPACK) {
|
|
|
|
packAll();
|
|
|
|
}
|
2005-07-25 10:58:21 +00:00
|
|
|
|
|
|
|
waitcursor(1); // exit_editmode sets cursor too
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
do_history(di);
|
|
|
|
|
|
|
|
if (BLO_write_file(di, G.fileflags, &err)) {
|
|
|
|
strcpy(G.sce, di);
|
2003-12-08 13:08:24 +00:00
|
|
|
strcpy(G.main->name, di); /* is guaranteed current file */
|
|
|
|
|
|
|
|
mainwindow_set_filename_to_title(G.main->name);
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
G.save_over = 1;
|
|
|
|
|
|
|
|
writeBlog();
|
|
|
|
} else {
|
|
|
|
error("%s", err);
|
|
|
|
}
|
|
|
|
|
|
|
|
waitcursor(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BIF_write_homefile(void)
|
|
|
|
{
|
|
|
|
char *err, tstr[FILE_MAXDIR+FILE_MAXFILE];
|
|
|
|
int write_flags;
|
|
|
|
|
|
|
|
BLI_make_file_string("/", tstr, BLI_gethome(), ".B.blend");
|
|
|
|
|
2004-04-20 19:12:48 +00:00
|
|
|
/* force save as regular blend file */
|
2002-10-12 11:37:38 +00:00
|
|
|
write_flags = G.fileflags & ~(G_FILE_COMPRESS | G_FILE_LOCK | G_FILE_SIGN);
|
|
|
|
BLO_write_file(tstr, write_flags, &err);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BIF_write_autosave(void)
|
|
|
|
{
|
|
|
|
char *err, tstr[FILE_MAXDIR+FILE_MAXFILE];
|
|
|
|
int write_flags;
|
|
|
|
|
|
|
|
get_autosave_location(tstr);
|
|
|
|
|
|
|
|
/* force save as regular blend file */
|
|
|
|
write_flags = G.fileflags & ~(G_FILE_COMPRESS | G_FILE_LOCK | G_FILE_SIGN);
|
|
|
|
BLO_write_file(tstr, write_flags, &err);
|
|
|
|
}
|
|
|
|
|
Another step in the undo evolution.
- Made unified API for undo calls, to be found in space.c
BIF_undo_push(char *str)
BIF_undo(void)
BIF_redo(void)
These calls will do all undo levels, including editmode and vpaint.
The transition is work in progress, because mesh undo needs recode.
- New global hotkey CTR+Z for undo
Note: 'shaded draw mode' still is SHIFT+Z, the old CTRL+Z was to recalc
the lighting in shaded mode, which already became much more interactive,
like during/after any transform().
Recalc hotkey now is SHIFT+ALT+Z
CTRL+<any modifier>+Z is redo.
- For OSX users; the Apple-key ("Command") now maps to CTRL as well. This
disables the one-mouse-button hack for rightmouse btw, will be fixed in
next commit. At least we can use Apple-Z :)
- Old Ukey for undo is still there, as a training period... my preference is
to restore Ukey to "reload original data" as in past, and only use new
CTRL+Z for undo.
- Added undo_push() for all of editobject.c and editview.c. Meaning we can
start using/testing global undo in the 3d window. Please dont comment on
missing parts for now, first I want someone to volunteer to tackle all of
that.
- Since the global undo has a full 'file' in memory, it can save extremely
fast on exit to <temp dir>/quit.blend. That's default now when global undo
is enabled. It prints "Saved session recovery to ..." in console then.
- In file menu, a new option is added "Recover Last Session". Note that this
reads the undo-save, which is without UI.
- With such nice new features we then can also kill the disputed
Cancel/Confirm menu on Q-KEY.
- Added fix which initializes seam/normal theme color on saved themes.
They showed black now.... (Note: that's in usiblender.c!)
2004-09-18 12:12:45 +00:00
|
|
|
/* if global undo; remove tempsave, otherwise rename */
|
2002-10-12 11:37:38 +00:00
|
|
|
static void delete_autosave(void)
|
|
|
|
{
|
2003-11-25 17:36:37 +00:00
|
|
|
char tstr[FILE_MAXDIR+FILE_MAXFILE];
|
2002-10-12 11:37:38 +00:00
|
|
|
|
2003-11-25 17:36:37 +00:00
|
|
|
get_autosave_location(tstr);
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
if (BLI_exists(tstr)) {
|
|
|
|
char str[FILE_MAXDIR+FILE_MAXFILE];
|
|
|
|
BLI_make_file_string("/", str, U.tempdir, "quit.blend");
|
Another step in the undo evolution.
- Made unified API for undo calls, to be found in space.c
BIF_undo_push(char *str)
BIF_undo(void)
BIF_redo(void)
These calls will do all undo levels, including editmode and vpaint.
The transition is work in progress, because mesh undo needs recode.
- New global hotkey CTR+Z for undo
Note: 'shaded draw mode' still is SHIFT+Z, the old CTRL+Z was to recalc
the lighting in shaded mode, which already became much more interactive,
like during/after any transform().
Recalc hotkey now is SHIFT+ALT+Z
CTRL+<any modifier>+Z is redo.
- For OSX users; the Apple-key ("Command") now maps to CTRL as well. This
disables the one-mouse-button hack for rightmouse btw, will be fixed in
next commit. At least we can use Apple-Z :)
- Old Ukey for undo is still there, as a training period... my preference is
to restore Ukey to "reload original data" as in past, and only use new
CTRL+Z for undo.
- Added undo_push() for all of editobject.c and editview.c. Meaning we can
start using/testing global undo in the 3d window. Please dont comment on
missing parts for now, first I want someone to volunteer to tackle all of
that.
- Since the global undo has a full 'file' in memory, it can save extremely
fast on exit to <temp dir>/quit.blend. That's default now when global undo
is enabled. It prints "Saved session recovery to ..." in console then.
- In file menu, a new option is added "Recover Last Session". Note that this
reads the undo-save, which is without UI.
- With such nice new features we then can also kill the disputed
Cancel/Confirm menu on Q-KEY.
- Added fix which initializes seam/normal theme color on saved themes.
They showed black now.... (Note: that's in usiblender.c!)
2004-09-18 12:12:45 +00:00
|
|
|
|
|
|
|
if(U.uiflag & USER_GLOBALUNDO) BLI_delete(tstr, 0, 0);
|
|
|
|
else BLI_rename(tstr, str);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
static void initbuttons(void)
|
|
|
|
{
|
|
|
|
uiDefFont(UI_HELVB,
|
|
|
|
BMF_GetFont(BMF_kHelveticaBold14),
|
|
|
|
BMF_GetFont(BMF_kHelveticaBold12),
|
|
|
|
BMF_GetFont(BMF_kHelveticaBold10),
|
|
|
|
BMF_GetFont(BMF_kHelveticaBold8));
|
|
|
|
uiDefFont(UI_HELV,
|
|
|
|
BMF_GetFont(BMF_kHelvetica12),
|
|
|
|
BMF_GetFont(BMF_kHelvetica12),
|
|
|
|
BMF_GetFont(BMF_kHelvetica10),
|
|
|
|
BMF_GetFont(BMF_kHelveticaBold8));
|
|
|
|
|
|
|
|
BIF_resources_init();
|
|
|
|
|
|
|
|
glClearColor(.7, .7, .6, 0.0);
|
|
|
|
|
|
|
|
G.font= BMF_GetFont(BMF_kHelvetica12);
|
|
|
|
G.fonts= BMF_GetFont(BMF_kHelvetica10);
|
|
|
|
G.fontss= BMF_GetFont(BMF_kHelveticaBold8);
|
|
|
|
|
|
|
|
clear_matcopybuf();
|
|
|
|
}
|
|
|
|
|
2004-04-21 13:38:54 +00:00
|
|
|
|
|
|
|
static void sound_init_listener(void)
|
|
|
|
{
|
|
|
|
G.listener = MEM_callocN(sizeof(bSoundListener), "soundlistener");
|
|
|
|
G.listener->gain = 1.0;
|
|
|
|
G.listener->dopplerfactor = 1.0;
|
2004-12-29 01:27:09 +00:00
|
|
|
G.listener->dopplervelocity = 340.29f;
|
2004-04-21 13:38:54 +00:00
|
|
|
}
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
void BIF_init(void)
|
|
|
|
{
|
|
|
|
|
2003-04-30 13:22:26 +00:00
|
|
|
initscreen(); /* for (visuele) speed, this first, then setscreen */
|
2002-10-12 11:37:38 +00:00
|
|
|
initbuttons();
|
2003-12-26 20:12:42 +00:00
|
|
|
InitCursorData();
|
2004-04-21 13:38:54 +00:00
|
|
|
sound_init_listener();
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
init_draw_rects(); /* drawobject.c */
|
2004-01-04 22:10:36 +00:00
|
|
|
BIF_read_homefile();
|
2003-10-25 16:53:50 +00:00
|
|
|
init_gl_stuff(); /* drawview.c, after homefile */
|
2002-10-12 11:37:38 +00:00
|
|
|
readBlog();
|
|
|
|
strcpy(G.lib, G.sce);
|
2003-05-09 12:48:21 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
extern ListBase editNurb;
|
|
|
|
extern ListBase editelems;
|
|
|
|
|
|
|
|
void exit_usiblender(void)
|
|
|
|
{
|
|
|
|
freeAllRad();
|
|
|
|
BKE_freecubetable();
|
|
|
|
|
|
|
|
if (G.background == 0)
|
|
|
|
sound_end_all_sounds();
|
|
|
|
|
|
|
|
if(G.obedit) {
|
|
|
|
if(G.obedit->type==OB_FONT) {
|
|
|
|
free_editText();
|
|
|
|
}
|
|
|
|
else if(G.obedit->type==OB_MBALL) BLI_freelistN(&editelems);
|
EditMesh refactory + undo recode
The changelog is very long... it's on the web too:
http://www.blender3d.org/cms/Mesh_editing_rewrite.425.0.html
EditMesh refactor notes (user)
**** New selection modes
When entering Edit Mode for a Mesh, you now have the choice for three selection modes. These are shown as icons in the 3D header (hotkey is being searched for!).
- Vertex Select
Select vertices as usual, fully compatible with how previous version work
- Edge Select
Vertices are not drawn anymore, and selections happen by default on the edges. It is a true edge select, meaning that you can select three out of four edges in a face, without automatic having the 4th edge selected.
- Face Select
Instead of vertices, now selection 'points' are drawn in the face centers. Selected faces also get a colored outline, like for edges. This also is true face select, for each face individual regardless selection status of its vertices or edges.
While holding SHIFT, and press a selection mode, you can also combine the above choices. Now selection becomes mixed, and will behave as expected.
For example; in Edge+Face select mode, selecting the 4 edges of a face will select the face too.
The selection modes and optional drawing modes (like transparant faces, normals, or solid drawing) all work together. All of Blender's mesh editing tools now react to the correct selection mode as well.
Most noticeable it's in:
**** Extrude
Extruding in Edge or Face Select mode allows much more precise control over what's extruded and what should be excluded. Try for example a checker pattern selection, and extrude it.
New is the fixed translation when faces are extruded. This always follows the (averaged) face normal(s) of the old face(s), enabling much easier working in 3D views . A single 'G' (Grab) or 'R' (Rotate) or 'S' (Scale) will change transform modus as usual.
**** Other things to note
- Hiding edges/faces will also behave different based on Select Mode.
- while editing, normals of faces are updated always now
- Border select (BKEY) has 2 different rules for edges; when one edge is fully inside of the border, it will only select edges that are fully inside. Otherwise it selects each edge intersecting with the border.
- in face mode, adding vertices, edges or a circle is invisible...
- "Add monkey" now works as a normal primitive (rotated and on 3d cursor)
- Mesh undo was fully recoded, hopefully solving issues now with Vertex Keys and Groups
- Going in and out of editmode was fully recoded. Especially on larger models you'll notice substantial speed gain.
**** Todo
Add 'FaceSelect mode' functionality in EditMode, including zbuffered selection, display and editing of UV texture.
EditMesh refactor notes (coder)
**** Usage of flags in general
The "->f" flags are reserved for the editmesh.c and editmesh_lib.c core functions. Actually only selection status is there now.
The "->f1" and "->f2" flags are free to use. They're available in vertex/edge/face structs. Since they're free, check carefully when calling other functions that use these flags... for example extrude() or subdivide() use them.
**** Selection flags
EditVert: eve->f & SELECT
EditEdge: eed->f & SELECT
EditFace: efa->f & SELECT
- Selection is only possible when not-hidden!
- Selection flags are always up-to-date, BUT:
if selection mode >= SELECT_EDGE vertex selection flags can be incorrect
if selection mode == SELECT_FACE vertex/edge selection flags can be incorrect
This because of shared vertices or edges.
- use for selecting vertices:
eve->f &= SELECT
- use for selecting edges always:
void EM_select_edge(eed, 1) // 1 = select, 0 = deselect
- use for selecting faces always:
void EM_select_face(efa, 1) // 1 = select, 0 = deselect
- To set the 'f' flags in all of the data:
void EM_set_flag_all(int flag);
void EM_clear_flag_all(int flag);
- the old faceselectedOR() and faceselectedAND() are still there, but only
to be used for evaluating its vertices
**** Code hints for handling selection
If the selectmode is 'face'; vertex or edge selections need to be flushed upward. Same is true for 'edge' selection mode. This means that you'll have to keep track of all selections while coding... selecting the four vertices in a face doesn't automatically select the face anymore.
However, by using the above calls, at least selections flush downward (to vertex level). You then can call:
void EM_selectmode_flush(void);
Which flushes selections back upward, based on the selectmode setting. This function does the following:
- if selectmode 'vertex': select edges/faces based on its selected vertices
- if selectmode 'edge': select faces based its selected edges
This works fine in nice controlled situations.
However, only changing the vertex selections then still doesn't select a face in face mode! If you really can't avoid only working with vertex selections, you can use this call:
void EM_select_flush(void);
Now selection is flushed upward regardless current selectmode. That can be destructive for special cases however, like checkerboard selected faces. So use this only when you know everything else was deselected (or deselect it). Example: adding primitives.
**** Hide flags
EditVert: eve->h
EditEdge: eed->h
EditFace: efa->h
- all hide flags are always up-to-date
- hidden vertices/edges/faces are always deselected. so when you operate on selection only, there's no need to check for hide flag.
**** Unified undo for editmode
New file: editmode_undo.h
A pretty nice function pointer handler style undo. Just code three functions, and your undo will fly! The c file has a good reference.
Also note that the old undo system has been replaced. It currently uses minimal dependencies on Meshes themselves (no abuse of going in/out editmode), and is restricted nicely to editmode functions.
**** Going in/out editmode
As speedup now all vertices/faces/edges are allocated in three big chunks. In vertices/faces/edges now tags are set to denote such data cannot be freed.
ALso the hashtable (lookup) for edges uses no mallocs at all anymore, but is part of the EditEdge itself.
2004-09-23 20:52:51 +00:00
|
|
|
free_editMesh(G.editMesh);
|
2002-10-12 11:37:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
free_editLatt();
|
|
|
|
free_editArmature();
|
|
|
|
free_posebuf();
|
|
|
|
|
2003-04-30 13:22:26 +00:00
|
|
|
free_blender(); /* blender.c, does entire library */
|
2002-10-12 11:37:38 +00:00
|
|
|
free_matcopybuf();
|
|
|
|
free_ipocopybuf();
|
|
|
|
freefastshade();
|
|
|
|
free_vertexpaint();
|
|
|
|
|
2003-04-30 13:22:26 +00:00
|
|
|
/* editnurb can remain to exist outside editmode */
|
2002-10-12 11:37:38 +00:00
|
|
|
freeNurblist(&editNurb);
|
|
|
|
|
|
|
|
fsmenu_free();
|
2003-05-03 12:17:11 +00:00
|
|
|
#ifdef INTERNATIONAL
|
2003-05-09 12:48:21 +00:00
|
|
|
free_languagemenu();
|
2003-05-03 12:17:11 +00:00
|
|
|
#endif
|
2002-10-12 11:37:38 +00:00
|
|
|
|
|
|
|
RE_free_render_data();
|
|
|
|
|
|
|
|
free_txt_data();
|
|
|
|
|
|
|
|
sound_exit_audio();
|
2004-04-24 12:02:39 +00:00
|
|
|
if(G.listener) MEM_freeN(G.listener);
|
2003-04-28 02:15:46 +00:00
|
|
|
|
2003-09-18 12:27:43 +00:00
|
|
|
#ifdef WITH_QUICKTIME
|
2003-09-18 11:41:50 +00:00
|
|
|
quicktime_exit();
|
2003-09-18 12:27:43 +00:00
|
|
|
#endif
|
2003-09-18 11:41:50 +00:00
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
BPY_end_python();
|
|
|
|
|
|
|
|
if (!G.background) {
|
|
|
|
BIF_resources_free();
|
|
|
|
|
|
|
|
BIF_close_render_display();
|
|
|
|
mainwindow_close();
|
|
|
|
}
|
|
|
|
|
2004-01-23 16:02:10 +00:00
|
|
|
#ifdef INTERNATIONAL
|
2004-01-23 14:19:44 +00:00
|
|
|
FTF_End();
|
2004-01-23 16:02:10 +00:00
|
|
|
#endif
|
2004-01-23 14:19:44 +00:00
|
|
|
|
2005-06-21 13:52:29 +00:00
|
|
|
if (copybuf) MEM_freeN(copybuf);
|
|
|
|
if (copybufinfo) MEM_freeN(copybufinfo);
|
|
|
|
|
EditMesh refactory + undo recode
The changelog is very long... it's on the web too:
http://www.blender3d.org/cms/Mesh_editing_rewrite.425.0.html
EditMesh refactor notes (user)
**** New selection modes
When entering Edit Mode for a Mesh, you now have the choice for three selection modes. These are shown as icons in the 3D header (hotkey is being searched for!).
- Vertex Select
Select vertices as usual, fully compatible with how previous version work
- Edge Select
Vertices are not drawn anymore, and selections happen by default on the edges. It is a true edge select, meaning that you can select three out of four edges in a face, without automatic having the 4th edge selected.
- Face Select
Instead of vertices, now selection 'points' are drawn in the face centers. Selected faces also get a colored outline, like for edges. This also is true face select, for each face individual regardless selection status of its vertices or edges.
While holding SHIFT, and press a selection mode, you can also combine the above choices. Now selection becomes mixed, and will behave as expected.
For example; in Edge+Face select mode, selecting the 4 edges of a face will select the face too.
The selection modes and optional drawing modes (like transparant faces, normals, or solid drawing) all work together. All of Blender's mesh editing tools now react to the correct selection mode as well.
Most noticeable it's in:
**** Extrude
Extruding in Edge or Face Select mode allows much more precise control over what's extruded and what should be excluded. Try for example a checker pattern selection, and extrude it.
New is the fixed translation when faces are extruded. This always follows the (averaged) face normal(s) of the old face(s), enabling much easier working in 3D views . A single 'G' (Grab) or 'R' (Rotate) or 'S' (Scale) will change transform modus as usual.
**** Other things to note
- Hiding edges/faces will also behave different based on Select Mode.
- while editing, normals of faces are updated always now
- Border select (BKEY) has 2 different rules for edges; when one edge is fully inside of the border, it will only select edges that are fully inside. Otherwise it selects each edge intersecting with the border.
- in face mode, adding vertices, edges or a circle is invisible...
- "Add monkey" now works as a normal primitive (rotated and on 3d cursor)
- Mesh undo was fully recoded, hopefully solving issues now with Vertex Keys and Groups
- Going in and out of editmode was fully recoded. Especially on larger models you'll notice substantial speed gain.
**** Todo
Add 'FaceSelect mode' functionality in EditMode, including zbuffered selection, display and editing of UV texture.
EditMesh refactor notes (coder)
**** Usage of flags in general
The "->f" flags are reserved for the editmesh.c and editmesh_lib.c core functions. Actually only selection status is there now.
The "->f1" and "->f2" flags are free to use. They're available in vertex/edge/face structs. Since they're free, check carefully when calling other functions that use these flags... for example extrude() or subdivide() use them.
**** Selection flags
EditVert: eve->f & SELECT
EditEdge: eed->f & SELECT
EditFace: efa->f & SELECT
- Selection is only possible when not-hidden!
- Selection flags are always up-to-date, BUT:
if selection mode >= SELECT_EDGE vertex selection flags can be incorrect
if selection mode == SELECT_FACE vertex/edge selection flags can be incorrect
This because of shared vertices or edges.
- use for selecting vertices:
eve->f &= SELECT
- use for selecting edges always:
void EM_select_edge(eed, 1) // 1 = select, 0 = deselect
- use for selecting faces always:
void EM_select_face(efa, 1) // 1 = select, 0 = deselect
- To set the 'f' flags in all of the data:
void EM_set_flag_all(int flag);
void EM_clear_flag_all(int flag);
- the old faceselectedOR() and faceselectedAND() are still there, but only
to be used for evaluating its vertices
**** Code hints for handling selection
If the selectmode is 'face'; vertex or edge selections need to be flushed upward. Same is true for 'edge' selection mode. This means that you'll have to keep track of all selections while coding... selecting the four vertices in a face doesn't automatically select the face anymore.
However, by using the above calls, at least selections flush downward (to vertex level). You then can call:
void EM_selectmode_flush(void);
Which flushes selections back upward, based on the selectmode setting. This function does the following:
- if selectmode 'vertex': select edges/faces based on its selected vertices
- if selectmode 'edge': select faces based its selected edges
This works fine in nice controlled situations.
However, only changing the vertex selections then still doesn't select a face in face mode! If you really can't avoid only working with vertex selections, you can use this call:
void EM_select_flush(void);
Now selection is flushed upward regardless current selectmode. That can be destructive for special cases however, like checkerboard selected faces. So use this only when you know everything else was deselected (or deselect it). Example: adding primitives.
**** Hide flags
EditVert: eve->h
EditEdge: eed->h
EditFace: efa->h
- all hide flags are always up-to-date
- hidden vertices/edges/faces are always deselected. so when you operate on selection only, there's no need to check for hide flag.
**** Unified undo for editmode
New file: editmode_undo.h
A pretty nice function pointer handler style undo. Just code three functions, and your undo will fly! The c file has a good reference.
Also note that the old undo system has been replaced. It currently uses minimal dependencies on Meshes themselves (no abuse of going in/out editmode), and is restricted nicely to editmode functions.
**** Going in/out editmode
As speedup now all vertices/faces/edges are allocated in three big chunks. In vertices/faces/edges now tags are set to denote such data cannot be freed.
ALso the hashtable (lookup) for edges uses no mallocs at all anymore, but is part of the EditEdge itself.
2004-09-23 20:52:51 +00:00
|
|
|
/* undo free stuff */
|
|
|
|
undo_editmode_clear();
|
Another step in the undo evolution.
- Made unified API for undo calls, to be found in space.c
BIF_undo_push(char *str)
BIF_undo(void)
BIF_redo(void)
These calls will do all undo levels, including editmode and vpaint.
The transition is work in progress, because mesh undo needs recode.
- New global hotkey CTR+Z for undo
Note: 'shaded draw mode' still is SHIFT+Z, the old CTRL+Z was to recalc
the lighting in shaded mode, which already became much more interactive,
like during/after any transform().
Recalc hotkey now is SHIFT+ALT+Z
CTRL+<any modifier>+Z is redo.
- For OSX users; the Apple-key ("Command") now maps to CTRL as well. This
disables the one-mouse-button hack for rightmouse btw, will be fixed in
next commit. At least we can use Apple-Z :)
- Old Ukey for undo is still there, as a training period... my preference is
to restore Ukey to "reload original data" as in past, and only use new
CTRL+Z for undo.
- Added undo_push() for all of editobject.c and editview.c. Meaning we can
start using/testing global undo in the 3d window. Please dont comment on
missing parts for now, first I want someone to volunteer to tackle all of
that.
- Since the global undo has a full 'file' in memory, it can save extremely
fast on exit to <temp dir>/quit.blend. That's default now when global undo
is enabled. It prints "Saved session recovery to ..." in console then.
- In file menu, a new option is added "Recover Last Session". Note that this
reads the undo-save, which is without UI.
- With such nice new features we then can also kill the disputed
Cancel/Confirm menu on Q-KEY.
- Added fix which initializes seam/normal theme color on saved themes.
They showed black now.... (Note: that's in usiblender.c!)
2004-09-18 12:12:45 +00:00
|
|
|
|
|
|
|
BKE_undo_save_quit(); // saves quit.blend if global undo is on
|
|
|
|
BKE_reset_undo();
|
2004-08-31 13:43:18 +00: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
|
|
|
BLI_freelistN(&U.themes);
|
|
|
|
|
2002-10-12 11:37:38 +00:00
|
|
|
if(totblock!=0) {
|
- 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
|
|
|
printf("Error Totblock: %d\n",totblock);
|
2002-10-12 11:37:38 +00:00
|
|
|
MEM_printmemlist();
|
|
|
|
}
|
|
|
|
delete_autosave();
|
|
|
|
|
|
|
|
printf("\nBlender quit\n");
|
|
|
|
|
|
|
|
#ifdef WIN32
|
2004-03-06 13:08:36 +00:00
|
|
|
/* ask user to press enter when in debug mode */
|
|
|
|
if(G.f & G_DEBUG) {
|
|
|
|
printf("press enter key to exit...\n\n");
|
|
|
|
getchar();
|
|
|
|
}
|
2002-10-12 11:37:38 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
SYS_DeleteSystem(SYS_GetSystem());
|
|
|
|
|
|
|
|
exit(G.afbreek==1);
|
|
|
|
}
|