diff --git a/CMakeLists.txt b/CMakeLists.txt index 25ed193b266..189e4ad5665 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -124,7 +124,7 @@ mark_as_advanced(WITH_PYTHON) # dont want people disabling this unless they rea mark_as_advanced(WITH_PYTHON_SECURITY) # some distrobutions see this as a security issue, rather than have them patch it, make a build option. option(WITH_PYTHON_SAFETY "Enable internal API error checking to track invalid data to prevent crash on access (at the expense of some effeciency, only enable for development)." OFF) -option(WITH_PYTHON_MODULE "Enable building as a python module (experemental, only enable for development)" OFF) +option(WITH_PYTHON_MODULE "Enable building as a python module (experimental, only enable for development)" OFF) option(WITH_BUILDINFO "Include extra build details (only disable for development & faster builds)" ON) option(WITH_IK_ITASC "Enable ITASC IK solver (only disable for development & for incompatible C++ compilers)" ON) option(WITH_FFTW3 "Enable FFTW3 support (Used for smoke and audio effects)" OFF) @@ -176,7 +176,7 @@ option(WITH_MOD_SMOKE "Enable Smoke Modifier (Smoke Simulation)" ON) option(WITH_MOD_DECIMATE "Enable Decimate Modifier" ON) option(WITH_MOD_BOOLEAN "Enable Boolean Modifier" ON) option(WITH_MOD_REMESH "Enable Remesh Modifier" ON) -option(WITH_MOD_CLOTH_ELTOPO "Enable Experemental cloth solver" OFF) +option(WITH_MOD_CLOTH_ELTOPO "Enable Experimental cloth solver" OFF) mark_as_advanced(WITH_MOD_CLOTH_ELTOPO) option(WITH_MOD_OCEANSIM "Enable Ocean Modifier" OFF) @@ -262,25 +262,23 @@ if(APPLE) endif() message(STATUS "Detected system-version: " ${OSX_SYSTEM}) - if(${OSX_SYSTEM} GREATER 10.6) - set(CMAKE_OSX_DEPLOYMENT_TARGET "10.6" CACHE STRING "" FORCE) # 10.7 does not have 10.5sdk !!! - else() - set(CMAKE_OSX_DEPLOYMENT_TARGET "10.5" CACHE STRING "" FORCE) # 10.5 is our minimum target + if(NOT CMAKE_OSX_DEPLOYMENT_TARGET) + set(CMAKE_OSX_DEPLOYMENT_TARGET "10.5" CACHE STRING "" FORCE) # 10.5 is our minimum target, if you have higher sdk, weak linking happens endif() if(${CMAKE_GENERATOR} MATCHES "Xcode") - if(${XCODE_VERSION} VERSION_EQUAL 4 OR ${XCODE_VERSION} VERSION_GREATER 4) + + ##### workaround for actual official cmake incompatibility with xcode 4.3 ##### + if(${XCODE_VERSION} MATCHES '') # cmake fails due looking for xcode in the wrong path, thus will be empty var + message("Official cmake does not yet support Xcode 4.3, get a patched version here: http://www.jensverwiebe.de/Blender/CMake%202.8-7patched.zip") + endif() + ### end workaround for actual official cmake incompatibility with xcode 4.3 ### + + if(${XCODE_VERSION} VERSION_EQUAL 4 OR ${XCODE_VERSION} VERSION_GREATER 4 AND ${XCODE_VERSION} VERSION_LESS 4.3) # Xcode 4 defaults to the Apple LLVM Compiler. - # Override the default compiler selection because Blender only compiles with gcc + # Override the default compiler selection because Blender only compiles with gcc up to xcode 4.2 set(CMAKE_XCODE_ATTRIBUTE_GCC_VERSION "com.apple.compilers.llvmgcc42") message(STATUS "Setting compiler to: " ${CMAKE_XCODE_ATTRIBUTE_GCC_VERSION}) - - ##### workaround for actual official cmake incompatibility with xcode 4.3 ##### - if(${XCODE_VERSION} MATCHES '') # cmake fails due looking for xcode in the wrong path, thus will be empty var - message("Official cmake does not yet support Xcode 4.3, get a patched version here: http://www.jensverwiebe.de/Blender/CMake%202.8-7patched.zip") - endif() - ##### end workaround for actual official cmake incompatibility with xcode 4.3 ##### - endif() else() # unix makefile generator does not fill XCODE_VERSION var, so we get it with a command execute_process(COMMAND xcodebuild -version OUTPUT_VARIABLE XCODE_VERS_BUILDNR ) @@ -294,6 +292,7 @@ if(APPLE) option(WITH_LIBS10.5 "Use 10.5 libs (needed for 64bit builds)" OFF) endif() + #----------------------------------------------------------------------------- # Check for conflicting/unsupported configurations @@ -353,13 +352,39 @@ if(WITH_CYCLES OR WITH_CARVE) set(WITH_BOOST ON) endif() -TEST_SSE_SUPPORT(COMPILER_SSE_FLAG COMPILER_SSE2_FLAG) - # don't store paths to libs for portable distrobution if(WITH_INSTALL_PORTABLE) set(CMAKE_SKIP_BUILD_RPATH TRUE) endif() +if(WITH_GHOST_SDL OR WITH_HEADLESS) + set(WITH_GHOST_XDND OFF) +endif() + +TEST_SSE_SUPPORT(COMPILER_SSE_FLAG COMPILER_SSE2_FLAG) + + +#----------------------------------------------------------------------------- +# Check for valid directories +# ... svn extern paths can be missing because of svn-git. + +if(WITH_INTERNATIONAL) + if(NOT EXISTS "${CMAKE_SOURCE_DIR}/release/datafiles/locale") + message(WARNING "Translation path '${CMAKE_SOURCE_DIR}/release/datafiles/locale' is missing, " + "This is an 'svn external', which are known not to work with bridges to other version " + "control systems, disabling 'WITH_INTERNATIONAL'.") + set(WITH_INTERNATIONAL OFF) + endif() +endif() + +if(WITH_PYTHON) + if(NOT EXISTS "${CMAKE_SOURCE_DIR}/release/scripts/addons") + message(WARNING "Addons path '${CMAKE_SOURCE_DIR}/release/scripts/addons' is missing, " + "This is an 'svn external', which are known not to work with bridges to other version " + "control systems: * CONTINUING WITHOUT ADDONS *") + endif() +endif() + #----------------------------------------------------------------------------- # Initialize un-cached vars, avoid unused warning @@ -1097,12 +1122,12 @@ elseif(APPLE) endif() if(${XCODE_VERSION} LESS 4.3) - SET(CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX${CMAKE_OSX_DEPLOYMENT_TARGET}.sdk CACHE PATH "" FORCE ) + SET(CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX${OSX_SYSTEM}.sdk CACHE PATH "" FORCE ) # use guaranteed existing sdk else() # note: i don't use xcode-select path on purpose, cause also /Applications/Xcode.app would be allowed # absolute pathes are more foolproof here ! SET(OSX_SYSROOT_PREFIX /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform) - SET(OSX_DEVELOPER_PREFIX /Developer/SDKs/MacOSX${CMAKE_OSX_DEPLOYMENT_TARGET}.sdk) + SET(OSX_DEVELOPER_PREFIX /Developer/SDKs/MacOSX${OSX_SYSTEM}.sdk) # use guaranteed existing sdk SET(CMAKE_OSX_SYSROOT ${OSX_SYSROOT_PREFIX}/${OSX_DEVELOPER_PREFIX} CACHE PATH "" FORCE) endif() @@ -1533,14 +1558,6 @@ if(MSVC10) endif() endif() -if(CMAKE_CXX_COMPILER_ID MATCHES "Clang") - if(WITH_LIBMV) - message(WARNING "Using Clang as CXX compiler: disabling WITH_LIBMV, this feature will be missing.") - set(WITH_LIBMV OFF) - endif() -endif() - - # ensure python header is found since detection can fail, this could happen # with _any_ library but since we used a fixed python version this tends to # be most problematic. diff --git a/build_files/scons/config/darwin-config.py b/build_files/scons/config/darwin-config.py index e9c7fb2aca8..621b5f3a11c 100644 --- a/build_files/scons/config/darwin-config.py +++ b/build_files/scons/config/darwin-config.py @@ -95,7 +95,7 @@ if XCODE_CUR_VER >= '4.3': ## since version 4.3, XCode and developer dir are bu #Defaults openMP to true if compiler handles it ( only gcc 4.6.1 and newer ) # if your compiler does not have accurate suffix you may have to enable it by hand ! -if CC.endswith('4.6.1'): +if CC[:-2].endswith('4.6'): WITH_BF_OPENMP = True # multithreading for fluids, cloth, sculpt and smoke else: WITH_BF_OPENMP = False diff --git a/build_files/scons/tools/Blender.py b/build_files/scons/tools/Blender.py index 9e67ccca62e..50848b5fced 100644 --- a/build_files/scons/tools/Blender.py +++ b/build_files/scons/tools/Blender.py @@ -340,6 +340,7 @@ def creator(env): if env['OURPLATFORM'] in ('win32-vc', 'win32-mingw', 'linuxcross', 'win64-vc'): incs.append(env['BF_PTHREADS_INC']) + incs.append('#/intern/utfconv') env.Append(CPPDEFINES=defs) env.Append(CPPPATH=incs) @@ -617,7 +618,7 @@ def AppIt(target=None, source=None, env=None): commands.getoutput(cmd) cmd = 'find %s/%s.app -name __MACOSX -exec rm -rf {} \;'%(installdir, binary) commands.getoutput(cmd) - if env['CC'].endswith('4.6.1'): # for correct errorhandling with gcc 4.6.1 we need the gcc.dylib to link, thus distribute in app-bundle + if env['CC'][:-2].endswith('4.6'): # for correct errorhandling with gcc 4.6.x we need the gcc.dylib to link, thus distribute in app-bundle cmd = 'mkdir %s/%s.app/Contents/MacOS/lib'%(installdir, binary) commands.getoutput(cmd) instname = env['BF_CXX'] diff --git a/doc/python_api/rst/bge.types.rst b/doc/python_api/rst/bge.types.rst index 3c15362a4ec..bcef816dc9d 100644 --- a/doc/python_api/rst/bge.types.rst +++ b/doc/python_api/rst/bge.types.rst @@ -1806,9 +1806,9 @@ Game Types (bge.types) object = cont.owner for mesh in object.meshes: - for material in mesh.materials: - for v_index in range(mesh.getVertexArrayLength(mat)): - vertex = mesh.getVertex(mat, v_index) + for m_index in range(len(mesh.materials)): + for v_index in range(mesh.getVertexArrayLength(m_index)): + vertex = mesh.getVertex(m_index, v_index) # Do something with vertex here... # ... eg: colour the vertex red. vertex.colour = [1.0, 0.0, 0.0, 1.0] diff --git a/doc/python_api/rst/include__bmesh.rst b/doc/python_api/rst/include__bmesh.rst new file mode 100644 index 00000000000..a8d299a5894 --- /dev/null +++ b/doc/python_api/rst/include__bmesh.rst @@ -0,0 +1,134 @@ +.. + This document is appended to the auto generated bmesh api doc to avoid clogging up the C files with details. + to test this run: + ./blender.bin -b -noaudio -P doc/python_api/sphinx_doc_gen.py -- --partial bmesh* ; cd doc/python_api ; sphinx-build sphinx-in sphinx-out ; cd ../../ + + +Intro +----- + +This API gives access the blenders internal mesh editing api, featuring geometry connectivity data and +access to editing operations such as split, separate, collapse and dissolve. + +The features exposed closely follow the C API, +giving python access to the functions used by blenders own mesh editing tools. + +For an overview of BMesh data types and how they reference each other see: +`BMesh Design Document `_ . + + +.. note:: + + **Disk** and **Radial** data is not exposed by the python api since this is for internal use only. + + +.. warning:: + + This API is still in development and experimental, while we don't expect to see large changes, + many areas are not well tested yet and so its possible changes will be made that break scripts. + + *Campbell Barton, 13, March 2012* + + +.. warning:: + + TODO Items Are + + * add access to BMesh **walkers** + * add a way to re-tessellate an editmode bmesh. + * add deform vert custom-data access. + + +Example Script +-------------- + +.. literalinclude:: ../../../release/scripts/templates/bmesh_simple.py + + +Stand-Alone Module +^^^^^^^^^^^^^^^^^^ + +The bmesh module is written to be standalone except for :mod:`mathutils` +which is used for vertex locations and normals. + +The only other exception to this are when converting mesh data to and from :class:`bpy.types.Mesh`. + + +Mesh Access +----------- + +There are 2 ways to access BMesh data, you can create a new BMesh by converting a mesh from +:class:`bpy.types.BlendData.meshes` or by accessing the current edit mode mesh. +see: :class:`bmesh.types.BMesh.from_mesh` and :mod:`bmesh.from_edit_mesh` respectively. + +When explicitly converting from mesh data python **owns** the data, that is to say - that the mesh only exists while +python holds a reference to it, and the script is responsible for putting it back into a mesh data-block when the edits +are done. + +Note that unlike :mod:`bpy`, a BMesh does not necessarily correspond to data in the currently open blend file, +a BMesh can be created, edited and freed without the user ever seeing or having access to it. +Unlike edit mode, the bmesh module can use multiple BMesh instances at once. + +Take care when dealing with multiple BMesh instances since the mesh data can use a lot of memory, while a mesh that +python owns will be freed in when the script holds no references to it, +its good practice to call :class:`bmesh.types.BMesh.free` which will remove all the mesh data immediately and disable +further access. + + +CustomData Access +----------------- + +BMesh has a unified way to access mesh attributes such as UV's vertex colors, shape keys, edge crease etc. + +This works by having a **layers** property on bmesh data sequences to access the custom data layers which can then be +used to access the actual data on each vert/edge/face/loop. + +Here are some examples ... + +.. code-block:: python + + uv_lay = bm.loops.layers.uv.active + + for face in bm.faces: + for loop in f.loops: + uv = loop[uv_lay] + print("Loop UV: %f, %f" % (uv.x, uv.y)) + + +.. code-block:: python + + shape_lay = bm.verts.layers.shape["Key.001"] + + for vert in bm.verts: + shape = vert[shape_lay] + print("Vert Shape: %f, %f, %f" % (shape.x, shape.y, shape.z)) + + +Keeping a Correct State +----------------------- + +When modeling in blender there are certain assumptions made about the state of the mesh. + +* hidden geometry isn't selected. +* when an edge is selected, its vertices are selected too. +* when a face is selected, its edges and vertices are selected. +* duplicate edges / faces don't exist. +* faces have at least 3 vertices. + +To give developers flexibility these conventions are not enforced, +however tools must leave the mesh in a valid state else other tools may behave incorrectly. + +Any errors that arise from not following these conventions is considered a bug in the script, +not a bug in blender. + + +Selection / Flushing +^^^^^^^^^^^^^^^^^^^^ + +As mentioned above, it is possible to create an invalid selection state +(by selecting a state and then de-selecting one of its vertices's for example), mostly the best way to solve this is to +flush the selection after performing a series of edits. this validates the selection state. + + +Module Functions +---------------- diff --git a/doc/python_api/rst/info_best_practice.rst b/doc/python_api/rst/info_best_practice.rst index 1f0f81f7d14..481555d412a 100644 --- a/doc/python_api/rst/info_best_practice.rst +++ b/doc/python_api/rst/info_best_practice.rst @@ -268,7 +268,7 @@ The **try** statement is useful to save time writing error checking code. However **try** is significantly slower then an **if** since an exception has to be set each time, so avoid using **try** in areas of your code that execute in a loop and runs many times. -There are cases where using **try** is faster than checking weather the condition will raise an error, so it is worth experimenting. +There are cases where using **try** is faster than checking whether the condition will raise an error, so it is worth experimenting. Value Comparison diff --git a/doc/python_api/rst/info_gotcha.rst b/doc/python_api/rst/info_gotcha.rst index be11e88b2fa..25ef5175976 100644 --- a/doc/python_api/rst/info_gotcha.rst +++ b/doc/python_api/rst/info_gotcha.rst @@ -132,6 +132,91 @@ write useful tools in python which are also fast to execute while in edit-mode. For the time being this limitation just has to be worked around but we're aware its frustrating needs to be addressed. +NGons and Tessellation Faces +============================ + +Since 2.63 NGons are supported, this adds some complexity since in some cases you need to access triangles still (some exporters for example). + +There are now 3 ways to access faces: + +* :class:`bpy.types.MeshPolygon` - this is the data stricture which now stores faces in object mode (access as ``mesh.polygons`` rather then ``mesh.faces``). +* :class:`bpy.types.MeshTessFace` - the result of triangulating (tessellated) polygons, the main method of face access in 2.62 or older (access as ``mesh.tessfaces``). +* :class:`bmesh.types.BMFace` - the polygons as used in editmode. + +For the purpose of the following documentation, these will be referred to as polygons, tessfaces and bmesh-faces respectively. + +5+ sided faces will be referred to as ``ngons``. + +Support Overview +---------------- + ++--------------+------------------------------+--------------------------------+--------------------------------+ +|Usage |:class:`bpy.types.MeshPolygon`|:class:`bpy.types.MeshTessFace` |:class:`bmesh.types.BMFace` | ++==============+==============================+================================+================================+ +|Import/Create |Bad (inflexible) |Fine (supported as upgrade path)|Best | ++--------------+------------------------------+--------------------------------+--------------------------------+ +|Manipulate |Bad (inflexible) |Bad (loses ngons) |Best | ++--------------+------------------------------+--------------------------------+--------------------------------+ +|Export/Output |Good (ngons) |Good (When ngons can't be used) |Good (ngons, memory overhead) | ++--------------+------------------------------+--------------------------------+--------------------------------+ + + +.. note:: + + Using the :mod:`bmesh` api is completely separate api from :mod:`bpy`, typically you would would use one or the other based on the level of editing needed, not simply for a different way to access faces. + + +Creating +-------- + +All 3 datatypes can be used for face creation. + +* polygons are the most efficient way to create faces but the data structure is _very_ rigid and inflexible, you must have all your vertes and faces ready and create them all at once. This is further complicated by the fact that each polygon does not store its own verts (as with tessfaces), rather they reference an index and size in :class:`bpy.types.Mesh.loops` which are a fixed array too. +* tessfaces ideally should not be used for creating faces since they are really only tessellation cache of polygons, however for scripts upgrading from 2.62 this is by far the most straightforward option. This works by creating tessfaces and when finished - they can be converted into polygons by calling :class:`bpy.types.Mesh.update`. The obvious limitation is ngons can't be created this way. +* bmesh-faces are most likely the easiest way for new scripts to create faces, since faces can be added one by one and the api has features intended for mesh manipulation. While :class:`bmesh.types.BMesh` uses more memory it can be managed by only operating on one mesh at a time. + + +Editing +------- + +Editing is where the 3 data types vary most. + +* polygons are very limited for editing, changing materials and options like smooth works but for anything else they are too inflexible and are only intended for storage. +* tessfaces should not be used for editing geometry because doing so will cause existing ngons to be tessellated. +* bmesh-faces are by far the best way to manipulate geometry. + +Exporting +--------- + +All 3 data types can be used for exporting, the choice mostly depends on whether the target format supports ngons or not. + +* polygons are the most direct & efficient way to export providing they convert into the output format easily enough. +* tessfaces work well for exporting to formats which dont support ngons, in fact this is the only place where their use is encouraged. +* bmesh-faces can work for exporting too but may not be necessary if polygons can be used since using bmesh gives some overhead because its not the native storage format in object mode. + + +Upgrading Importers from 2.62 +----------------------------- + +Importers can be upgraded to work with only minor changes. + +The main change to be made is used the tessellation versions of each attribute. + +* mesh.faces --> :class:`bpy.types.Mesh.tessfaces` +* mesh.uv_textures --> :class:`bpy.types.Mesh.tessface_uv_textures` +* mesh.vertex_colors --> :class:`bpy.types.Mesh.tessface_vertex_colors` + +Once the data is created call :class:`bpy.types.Mesh.update` to convert the tessfaces into polygons. + + +Upgrading Exporters from 2.62 +----------------------------- + +For exporters the most direct way to upgrade is to use tessfaces as with importing however its important to know that tessfaces may **not** exist for a mesh, the array will be empty as if there are no faces. + +So before accessing tessface data call: :class:`bpy.types.Mesh.update` ``(calc_tessface=True)``. + + EditBones, PoseBones, Bone... Bones =================================== diff --git a/doc/python_api/sphinx_doc_gen.py b/doc/python_api/sphinx_doc_gen.py index b9444f35e12..7cc605fc6e7 100644 --- a/doc/python_api/sphinx_doc_gen.py +++ b/doc/python_api/sphinx_doc_gen.py @@ -26,16 +26,17 @@ API dump in RST files --------------------- Run this script from blenders root path once you have compiled blender - ./blender.bin -b -noaudio -P doc/python_api/sphinx_doc_gen.py + ./blender.bin --background -noaudio --python doc/python_api/sphinx_doc_gen.py This will generate python files in doc/python_api/sphinx-in/ providing ./blender.bin is or links to the blender executable To choose sphinx-in directory: - ./blender.bin -b -P doc/python_api/sphinx_doc_gen.py -- -o ../python_api + ./blender.bin --background --python doc/python_api/sphinx_doc_gen.py -- --output ../python_api For quick builds: - ./blender.bin -b -P doc/python_api/sphinx_doc_gen.py -- -q + ./blender.bin --background --python doc/python_api/sphinx_doc_gen.py -- --partial + Sphinx: HTML generation ----------------------- @@ -47,6 +48,7 @@ Sphinx: HTML generation This requires sphinx 1.0.7 to be installed. + Sphinx: PDF generation ---------------------- After you have built doc/python_api/sphinx-in (see above), @@ -73,6 +75,7 @@ import os import sys import inspect import shutil +import logging from platform import platform PLATFORM = platform().split('-')[0].lower() # 'linux', 'darwin', 'windows' @@ -93,6 +96,30 @@ def handle_args(): ) # optional arguments + parser.add_argument("-p", "--partial", + dest="partial", + type=str, + default="", + help="Use a wildcard to only build specific module(s)\n" + "Example: --partial bmesh*\n", + required=False) + + parser.add_argument("-f", "--fullrebuild", + dest="full_rebuild", + default=False, + action='store_true', + help="Rewrite all rst files in sphinx-in/ " + "(default=False)", + required=False) + + parser.add_argument("-b", "--bpy", + dest="bpy", + default=False, + action='store_true', + help="Write the rst file of the bpy module " + "(default=False)", + required=False) + parser.add_argument("-o", "--output", dest="output_dir", type=str, @@ -100,25 +127,11 @@ def handle_args(): help="Path of the API docs (default=