Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2006-11-20Added custom vertex/edge/face data for meshes:Brecht Van Lommel
All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-08-28Integration of the Google Summer of Code Modifier Stack Upgrade project. TheBen Batt
main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2005-08-20 - convert all DerivedMesh map functions to use index basedDaniel Dunbar
mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-07 - got rid of DerivedMesh.drawMappedEdgeEM function, can be implemented withDaniel Dunbar
drawMappedEdges - added DerivedMesh.convertToDispListMeshMapped function which converts and also returns mapping information for use in editmode - updated DispListMesh derivedmesh to be able to function in editmode - update mirror modifier to support use as a cage - update mirror & subsurf modifiers to properly pass mapping information down modifier stack It is now possible to have a mesh with mirror/subsurf modifiers where you can edit with both as cage. Selecting the mirror'd part works, but of course transform is flipped so it is a bit weird. Not the cleanest code in the world and I can't say I am really happy with the architecture but it works for now and supports the existing feature set.
2005-07-22 - added data arguments to deformer modifiers, in case someone wantsDaniel Dunbar
to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 - shuffled editmesh derived function name/functionDaniel Dunbar
- added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-20 - split {curve,lattice,armature}_deform_verts out of mesh_deformDaniel Dunbar
- removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 - change mesh_get_derived_render to mesh_create_derived_render (alwaysDaniel Dunbar
builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-18 - added DerivedMesh.getVertCos function and implementationsDaniel Dunbar
- added mesh_create_derived_no_deform[_render] - mesh_create_orco now always goes through a DerivedMesh, some redundant copying atm but can be fixed (and orco generation is not a big bottleneck) New feature: TexMesh (texcomesh) works with subsurf now (are you listening rob?)
2005-07-17 - convert mesh_modifier to return deformed verts instead ofDaniel Dunbar
leaving in a DL_VERTS type displist (and modifying mesh) - removed DL_VERTS displist type (woot woot) - makeDispListMesh now puts deformed verts in object->derivedDeform - switch over other system parts to new deformed vert storage, still kinda hacky and maybe some inconsistencies... will be sorted out soon enough. - moved build_particle_system to makeDispListMesh... this may have adverse side effects, needs to be sorted out with depgraph system
2005-04-04 - work-in-progress: subsurf level 0 now just acts like a regular mesh,Daniel Dunbar
before it would follow subsurf code path by creating fake displistmesh, etc... kinda fun for testing but just annoying now. - change to creasing behavior, to make sure that with full creasing effect is just simple subdivision.
2005-04-04 - kinda crazy, but replaced old ME_SIMPLE_SUBDIV method with justDaniel Dunbar
using regular ccgsubsurf but with crease set to full.
2005-03-31 - removed USE_CCGSUBSURF define (always on now)Daniel Dunbar
- added G.editMesh->derived pointer... idea is to use this for mesh derived from editmesh instead of Mesh->derived (as the derived mesh tends to vary depending on what it came from). This part could be cleaner, also there may problems with it not being invalidated correctly. - And most importantly: In case people were beginning to worry all these edits were just crazy zr stuff, the big point comes about: Incremental subsurf calculation is now enabled. This gives massive speed improvements when editing a large mesh. For the eye-candy happy: try setting G.rt==52 before entering editmode and the edges and vertices (in optimal mode) will switch to displaying visually the age since a region has last been calculated. Lots of fun!
2005-03-30 - initial commit of a real (as in not just copying the DispListMesh)Daniel Dunbar
DerivedMesh implementation of CCGSubSurf. Only used in editmode at the moment, and does not draw smooth normals correctly. - Just in its own this brings a rather large speedup for editing subsurfs.
2005-03-29 - removed dlm->flagDaniel Dunbar
2005-03-29 - added Mesh->derived and Mesh->decimated DerivedMesh pointersDaniel Dunbar
- removed DL_MESH displist type!!!! Now store a DerivedMesh directly. - May still be some issues left having to do with releasing this at the right time (old code just splashed free_displist all over the place).
2005-03-28 - subsurf creation no longer needs extverts argument... removedDaniel Dunbar
2005-03-27 - everyone loves prototypesDaniel Dunbar
2004-03-28 - replaced G.{edve,eded,edvl} with G.editMesh, atm just a structure toDaniel Dunbar
hold the three lists, nothing major, but gives a place to hang data off of and a single "mesh" structure to pass around for editing functions.
2004-01-10 -Changed "Simple" button to pulldown menu or subsurf type.Robert Wenzlaff
Paves way for additional subsurf types, and avoids confusion where Simple is on, but Subsurf is off.
2004-01-07 - removed some old cruft from init_render_displist_mesh (for smeshes-RIP)Daniel Dunbar
- reduced main subsurf interface to two functions to make DispListMesh structures from an editmesh or a regular mesh. for the most part this means that to implement a geometry modifier you only need to write these two functions (not very plugable yet however). - added displistmesh_from_mesh and displistmesh_from_editmesh functions which allow simple support of subdivLevel(0) subsurfs, somewhat handy for testing things (like why orco doesn't work for subsurf).
2003-04-24Support for auto-skinning when parenting a mesh to an armature.Chris Want
Applies to bones that do not have a boneclass of unskinnable (set per bone in editmode in the button window).
2002-12-27Removed the config.h thing from the .h's in the source dir.Kent Mein
So we should be all set now :) Kent -- mein@cs.umn.edu
2002-11-25Did all of the .h's in sourceKent Mein
(adding) #ifdef HAVE_CONFIG_H #include <config.h> #endif also the Makefile.in's were from previous patch adding the system depend stuff to configure.ac Kent -- mein@cs.umn.edu
2002-10-30fixed spacing in the headers to get rid of some warnings and some otherKent Mein
little minor spacing issues.
2002-10-12Initial revisionv2.25Hans Lambermont