This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/source/blender/src/usiblender.c

672 lines
14 KiB
C
Raw Normal View History

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>
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
2002-10-12 11:37:38 +00:00
#ifdef WIN32
#include "BLI_winstuff.h"
#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"
#ifdef INTERNATIONAL
#include "BIF_language.h"
#include "FTF_Api.h"
#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"
#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"
#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"
#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"
#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"
#include "BDR_editcurve.h"
2002-10-12 11:37:38 +00:00
#include "BDR_vpaint.h"
#include "BPY_extern.h"
2002-10-12 11:37:38 +00:00
#include "blendef.h"
#include "radio.h"
#include "render.h"
#include "datatoc.h"
#include "SYS_System.h"
#include "PIL_time.h"
/***/
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");
}
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) {
btheme->tv3d.edge_seam[0]= 230;
btheme->tv3d.edge_seam[1]= 150;
btheme->tv3d.edge_seam[2]= 50;
btheme->tv3d.edge_seam[3]= 255;
}
if(btheme->tv3d.normal[3]==0) {
btheme->tv3d.normal[0]= 0x22;
btheme->tv3d.normal[1]= 0xDD;
btheme->tv3d.normal[2]= 0xDD;
btheme->tv3d.normal[3]= 255;
}
if(btheme->tv3d.face_dot[3]==0) {
btheme->tv3d.face_dot[0]= 255;
btheme->tv3d.face_dot[1]= 138;
btheme->tv3d.face_dot[2]= 48;
btheme->tv3d.face_dot[3]= 255;
btheme->tv3d.facedot_size= 4;
}
}
}
if (G.main->versionfile <= 235) {
/* illegal combo... */
if (U.flag & USER_LMOUSESELECT)
U.flag &= ~USER_TWOBUTTONMOUSE;
}
if (U.undosteps==0) U.undosteps=32;
reset_autosave();
#ifdef INTERNATIONAL
read_languagefile();
if(U.transopts & USER_DOTRANSLATE)
start_interface_font();
else
G.ui_international = FALSE;
#endif // INTERNATIONAL
}
2002-10-12 11:37:38 +00:00
void BIF_read_file(char *name)
{
extern short winqueue_break; /* editscreen.c */
//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 */
/* we didn't succeed, now try to read Blender file
calls readfile, calls toolbox, throws one more,
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
mainwindow_set_filename_to_title(G.main->name);
countall();
sound_initialize_sounds();
2002-10-12 11:37:38 +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
undo_editmode_clear();
BKE_reset_undo();
BKE_write_undo("original"); /* save current state */
}
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();
int success;
#ifdef _WIN32 // FULLSCREEN
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
screenmode = U.uiflag & USER_FLIPFULLSCREEN;
#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");
strcpy(scestr, G.sce); /* temporal store */
/* 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);
}
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
#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;
}
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;
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)
{
char name[FILE_MAXDIR+FILE_MAXFILE];
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();
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--;
}
/* 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;
/*Send the OnSave event*/
if (G.f & G_SCENESCRIPT) {
BPY_do_pyscript(&G.scene->id, SCRIPT_ONSAVE);
}
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;
}
waitcursor(1);
if(G.obedit) {
exit_editmode(0); /* 0 = no free data */
2002-10-12 11:37:38 +00:00
}
if (G.fileflags & G_AUTOPACK) {
packAll();
}
do_history(di);
if (BLO_write_file(di, G.fileflags, &err)) {
strcpy(G.sce, di);
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");
/* 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)
{
char tstr[FILE_MAXDIR+FILE_MAXFILE];
2002-10-12 11:37:38 +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();
}
static void sound_init_listener(void)
{
G.listener = MEM_callocN(sizeof(bSoundListener), "soundlistener");
G.listener->gain = 1.0;
G.listener->dopplerfactor = 1.0;
G.listener->dopplervelocity = 1.0;
}
2002-10-12 11:37:38 +00:00
void BIF_init(void)
{
initscreen(); /* for (visuele) speed, this first, then setscreen */
2002-10-12 11:37:38 +00:00
initbuttons();
InitCursorData();
sound_init_listener();
2002-10-12 11:37:38 +00:00
init_draw_rects(); /* drawobject.c */
BIF_read_homefile();
init_gl_stuff(); /* drawview.c, after homefile */
2002-10-12 11:37:38 +00:00
readBlog();
strcpy(G.lib, G.sce);
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();
free_blender(); /* blender.c, does entire library */
2002-10-12 11:37:38 +00:00
free_matcopybuf();
free_ipocopybuf();
freefastshade();
free_vertexpaint();
/* editnurb can remain to exist outside editmode */
2002-10-12 11:37:38 +00:00
freeNurblist(&editNurb);
fsmenu_free();
#ifdef INTERNATIONAL
free_languagemenu();
#endif
2002-10-12 11:37:38 +00:00
RE_free_render_data();
RE_free_filt_mask();
free_txt_data();
sound_exit_audio();
if(G.listener) MEM_freeN(G.listener);
#ifdef WITH_QUICKTIME
quicktime_exit();
#endif
2002-10-12 11:37:38 +00:00
BPY_end_python();
if (!G.background) {
BIF_resources_free();
BIF_close_render_display();
mainwindow_close();
}
#ifdef INTERNATIONAL
FTF_End();
#endif
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();
BLI_freelistN(&U.themes);
2002-10-12 11:37:38 +00:00
if(totblock!=0) {
printf("Error Totblock: %d\n",totblock);
2002-10-12 11:37:38 +00:00
MEM_printmemlist();
}
delete_autosave();
printf("\nBlender quit\n");
#ifdef WIN32
/* 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);
}