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
2008-12-312.5Ton Roosendaal
So, editmode mesh is back! :) At the moment only TABkey works and mouse select, 1 vertex at a time. More will follow of course. Note for the devs: - G.editMesh has been removed, be careful with old code. - EditMesh now is property of Mesh itself Although it means unlimited editmodes, for migration purposes we better stick to 1 "obedit" per scene, which is in Context too - G.obedit will get removed soon, so use CTX_data_edit_object(C) Or if you can't, just scene->obedit for now - Also removed the CTX_data_edit_mesh(), this has no meaning anymore. EditMesh is not context senstitive anymore, only the edit-object for time being is. - Martin: I've already tucked some EditMesh pointer in T and removed all G.editMesh there.
2008-09-05svn merge -r 16320:16369 ↵Daniel Genrich
https://svn.blender.org/svnroot/bf-blender/trunk/blender
2008-09-05Merge of first part of changes from the apricot branch, especiallyBrecht Van Lommel
the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-08-05svn merge -r 15800:15973 ↵Daniel Genrich
https://svn.blender.org/svnroot/bf-blender/trunk/blender
2008-07-29Game Engine: alpha blending and sortingBrecht Van Lommel
======================================= Alpha blending + sorting was revised, to fix bugs and get it to work more predictable. * A new per texture face "Sort" setting defines if the face is alpha sorted or not, instead of abusing the "ZTransp" setting as it did before. * Existing files are converted to hopefully match the old behavior as much as possible with a version patch. * On new meshes the Sort flag is disabled by the default, to avoid unexpected and hard to find slowdowns. * Alpha sorting for faces was incredibly slow. Sorting faces in a mesh with 600 faces lowered the framerate from 200 to 70 fps in my test.. the sorting there case goes about 15x faster now, but it is still advised to use Clip Alpha if possible instead of regular Alpha. * There still various limitations in the alpha sorting code, I've added some comments to the code about this. Some docs at the bottom of the page: http://www.blender.org/development/current-projects/changes-since-246/realtime-glsl-materials/ Merged some fixes from the apricot branch, most important change is that tangents are now exactly the same as the rest of Blender, instead of being computed in the game engine with a different algorithm. Also, the subversion was bumped to 1.
2008-07-28Phase1: fluidsim obstacles/control objects are grabbed from the specific ↵Daniel Genrich
position in modifier stack now (introducing new funciton in DerivedMesh.c), fixed some UI glitches.
2008-04-17Patch from GSR that a) fixes a whole bunch of GPL/BL licenseChris Want
blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-03-26made editmode face copy menu appier with when there is no active face ↵Campbell Barton
(without options that required an active face) active face drawing didnt always work since it used the last selected element for drawing. moved stipple into glutil.c rather then using 128 bytes in the stack for each stipple draw.
2007-11-27ParticlesBrecht Van Lommel
========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-10-31New feature:Ton Roosendaal
Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-09-25made active vert/edge/face draw properly with modifiers applied and made ↵Campbell Barton
their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-07-29Armature CrazySpace ImprovementBrecht Van Lommel
=============================== An improved CrazySpace correction is now used for Armature modifiers that use vertex groups, and that are the first enabled modifiers in the stack. This is a a specific case, but also a common one. http://www.blender.org/development/current-projects/changes-since-244/skinning/ Implementation Notes: - The quaternion crazyspace correction is still used for modifiers other than the armature modifier. - Modifiers can now provide a deform matrix per vertex to be used for crazyspace correction, only the armature modifier implements this now.
2006-12-13Multiple UV and vertex color layers: (still work in progress)Brecht Van Lommel
These can be created and deleted in the Mesh panel in the same place as before. There is always one active UV and vertex color layer, that is edited and displayed. Important things to do: - Render engine, material support - Multires and NMesh now lose non active layers Also CustomData changes to support muliple layers of the same type, and changes to layer allocation, updated documentation is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
2006-12-05Modifier Stack: Limit calculation to required data.Ben Batt
This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
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-11-11Added custom face data support in edit mode. The code used to do this isBrecht Van Lommel
the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-09-17added mesh_create_derived_view(ob) to DerivedMesh.cCampbell Barton
exactly the same as mesh_create_derived_render(ob) except it uses the view modifier settings. Added an optional arg to getFromObject to 'render' so you can choose to get the mesh displayed in the 3d view or generate one with render settings. Solved bug 4612 getFromObject now works with soft body meshes (error was caused by getting the derived mesh from a copy of the object) removed workaround for softbody bug in object_apply_def.py
2006-09-03Animation department feature request: support for vertex groups in LatticesTon Roosendaal
In a quick glance: (temp image) http://www.blender.org/bf/rt.png Main reason is that Lattices are useful a lot for Armature deformation. Lattices just provide much more precise and interesting control. However, with only bone envelopes it's very hard to use. Working with Lattice vertex groups is nearly identical to Mesh: - on CTRL+P 'make parent' you can choose the deform option now - In editmode, the buttons to control vertex groups are available - In outliner you can select vertexgroups too - Deforming Lattices with Armatures has all options as for Mesh now. Note: - No WeightPaint has been added yet. To compensate, the editmode drawing for a Lattice with vertex group shows weight values for the active vertex group. - Lattice editmode doesn't undo/redo weight editing yet. - Softbody for Lattice still uses own vertex weights Implementation notes: - derivedmesh weight_to_rgb() is now exported to drawobject.c - been doing cleanups in code (order of includes, var declarations, etc) - weightpaint button handling now is generic I've checked on Brecht's proposal for Custom Element data; http://mediawiki.blender.org/index.php/BlenderDev/CustomElementData It could have been used, but that would mean the existing code for vertexgroup handling and armature deform couldn't be re-used. I guess this is really a later todo.
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)
2006-03-11Fix for bug #3802: Display problems with modifiers and uv face selectBrecht Van Lommel
The bug reported here was already fixed some weeks ago, but there were more issues. Modifier display in face select and paint modes was never properly finished. This fixes some small drawing update glitches, and only allows modifiers that preserve a mapping to the original mesh to be applied. Otherwise selection and painting isn't even possible.
2006-02-09Seam Cutting in Faceselect Mode:Brecht Van Lommel
- Mark Border Seam: mark edges on the border of face selection as seam. - Clear Seam: clears seams in selected faces. Hotkey: Ctrl+E - Alt+RMB Click: mark/clear edge as seam - Alt+Shift+RMB Click: mark/clear seams along the shortest/straightest path from last marked seam. The cost of the path also includes some measure of 'straightness' next to the typical distance to make things work more predicatble and edgeloop friendly. Note that this cuts a path from edge to edge, not vertex to vertex. That gives some nice control over the direction of the seam. Also includes: - Removed old LSCM code. - Fix updates glitches with DerivedMesh/Subsurf drawing in FaceSelect mode. Now there's a drawMappedFacesTex instead of drawFacesTex. - Minimize Stretch menu entry called Limit Stitch. - Removed the lasttface global, was being set before it was used anyway, so might as wel return from a function. - Moved some backbuf sampling code to drawview.c from editmesh, so it can be used by Faceselect and VPaint. - Use BLI_heap in parametrizer.c.
2005-12-07Orange request; Bones in Armature now have own layer settings.Ton Roosendaal
Works like for Object layers, but local within Armature itself. Each Bone can be in (16 now) any layer, and the Armature layer defines what is visible or not. Also note that hiding will still work too. Since the Blender code is *stuffed* with Bone options now, this commit requires a good test if all tools we got now comply to layers... (I counted 130 cases for checking for selected Bones in code!) In PoseMode; hotkey M will show 'movetolayer' menu. Not in editmode... then its the mirror menu. Todo: make action/nla drawing comply to Armature layer settings.
2005-11-12Particles now are generated from subsurfed coordinates.Ton Roosendaal
Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-08-24 - add option to drawMappedFaces to draw with colors (from tface or mcol)Daniel Dunbar
- convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-22 - sillyness... added drawMappedEdges for meshDaniel Dunbar
- revert to drawLooseEdges instead of general drawEdgesFlag - ditched TFace edge flags, done dynamically now which also means don't need to recalc surface on flag changes - added BLI_edgehash, guess what it does
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-18 - added DerivedMesh.drawUVEdges function & implementationsDaniel Dunbar
- removed DerivedMesh.drawLooseEdges and replaced with much more general drawEdgesFlag function that draws based edge flags. - switch DerivedMesh.drawFacesTex to give user control over which faces are drawn - added object_uvs_changed and object_tface_flags_changed functions to do object recalc flag flush/redraw queueing and added calls in appropriate places - added various edge flags to mark TFace information. This is used by the drawEdgesFlag routine and was the best way I could come up with to deal with drawing TFace information from modifier stack. Unfortunate side effects are (1) uses a lot of MEdge flags (although not needed in file so thats fine) and (2) requires recalculation of modifier stack on UV selection changes. #2 is disappointing but I could not find a better solution. - update UV mesh shadow drawing to use modifier result. At the moment just uses the final result but probably should be integrated with the editmode cage option. - convert draw_tfaces3D to use drawEdgesFlag routine which cleaned up the code quite a bit. - convert draw_tface_mesh to draw using result of modifier stack. Same comment about which result actually gets draw in FACESELECT mode as for UV editor shadow drawing applies. There is a still a bug in that selection is using the wrong mesh to draw.
2005-08-14 - cleaned up edge drawing a tad, there were issues with mesh'sDaniel Dunbar
with "loose" edges (edges without a face) and drawing in solid mode. they would either not draw, or draw with a nasty selection outline. Added a ME_LOOSEEDGE flag to mark such edges in displists/mesh and editmode sets it. - changed DerivedMesh drawEdges to take an argument whether it should draw loose edges or not
2005-08-13 - readded Subsurf "optimal" edge drawing/renderingDaniel Dunbar
- added ME_EDGERENDER flag, barely changes things atm except makes sure plain meshes with FasterDraw/etc set still render all edges. The edge drawing system needs a bit of a revamping - it is a cool feature but could use several improvements: (1) The algorithm could be better in choosing the best edges to draw. (2) The drawflags should interact well with modifiers. It is wierd to have a large grid with a deformer that draws no edges because flags are only calculated based on base mesh. (3) Drawflags should not be destroyed by editmode. Better design would be a "Draw % of edges" button. Of course, could also be the feature is not worth it and we should just drop. Feel free to comment if you have an opinion.
2005-08-09Big commit, had to rework lots of selection stuff so that thingsDaniel Dunbar
worked properly with modifiers. Needs more testing I am sure. No, honestly, I wasn't just cleaning for the hell of it, it was *necessary* (I would never do such a thing). Selection should work completely with cage options of modifiers now. - added DerivedMesh foreach functions to iterate over mapped verts/edges/face centers. These replaced some of the drawing functions and are more general anyway. Special edge drawing functions remain for performance reasons. - removed EditFace xs, ys fields - added general functions to iterate over screen coordinates of mesh/curve/lattice objects - removed all calc_*verts* functions that were used for storing screen coordinates in objects. they were recalc'd on the fly for most situations anyway, so now we just always do that. calc_*verts_ext was one of those calls that did dirty things deep down in the callstack (changing curarea and poking at matrices) - rewrote all vertex level selection routines (circle, lasso, bbox) and closest vertex routines (rightmouse select) to use the new system. This cleaned up the selection code a lot and the structure of selection is much easier to see now. This is good for future work on allowing modifiers to completely override the selection system. It also points out some discrepancies in the way selection is handled that might be nice to resolve (mesh vertex selection has fancy stuff to try to help with selecting overlapping, but it only works w/o bbuf select, and curves/lattices don't have at all). - had to remove ton's code to move Manipulator to cage location, this is not reliable (can come up with a different method if requested) - as it happens BezTriple.s and BPoint.s are basically available to be removed, just need to rewrite editipo code that still does background calc of screen coordinates - MVert.{xs,ys} are still around because they are abused in some places for other info (not sure if this is safe actually, since they are short's and the mvert limit went up). And did I mention this commit is comes out to -305 lines? Well it does.
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-08-07 - add allowShared argument to DerivedMesh.convertToDispListMesh to allow ↵Daniel Dunbar
returned DLM to share data from DerivedMesh (reduces some copying/memory allocation) - added displistmesh_copyShared function to copy a DLM but not duplicate any internal data - changed crease drawing to use DerivedMesh functions... this means varying edge width style of creases had to go, I replaced by using varying color to show crease weight instead. Don't think this is a big loss since the subsurf result gives you a much better indication of the crease weight anyway. - bug fix in mirror modifier, didn't copy edge creases from editmesh correctly
2005-08-07 - added editmhes_get_derived_base, used when a mesh with multiple usersDaniel Dunbar
is in editmode. current bevahaior is to display the object that is actually in editmode with its modifiers, and all other objects that share the mesh using just the base editmesh data. this is not 100% consistent but no architecture at the moment to display all objects that have mesh in editmode with each individual modifier stack.
2005-07-26 - added apply button for individual modifiersDaniel Dunbar
2005-07-23 - added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EMDaniel Dunbar
functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
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 - add comments to BKE_DerivedMesh.h about which functions are called in ↵Daniel Dunbar
editmode - gcc warning fixes - start work to make CCGDerivedMesh able to run in object mode (hint: more speed improvements) - fix modifier move down tooltip
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 - for some reason mesh_create_derived_no_deform took the raw data (notDaniel Dunbar
an object) but this is not going to work... I can't remember the reason I did it this way in the first place either! oops! regardless, switch to all mesh_ derived accessors taking object argument. there is still a bug in render orco calculation though. (hunt hunt) - removed python files that should have been ditched in previous commit
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-07-17 - added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices)Daniel Dunbar
- static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 - added DirectMesh.getVert{Co,No} functionsDaniel Dunbar
- added mesh_get_derived_deform function (always returns a DerivedMesh corresponding to deformed (but not subdivided) mesh). used in places where original mesh is to be displayed but with deformed coordinates (vpaint for example). - added DirectMesh.getVert{Co,No} implementations for MeshDerivedMesh - updated vpaint to use mesh_get_derived_deform
2005-07-17 - switch M_NMesh_GetRawFromObject to always get mesh data fromDaniel Dunbar
DerivedMesh (needs testing) - added needsFree argument to mesh_get_derived_final
2005-07-17 - added dontFreeNors flag to DispListMesh as wellDaniel Dunbar
- changed mesh_get_derived_render to always return a DerivedMesh (even if no subsurf) - changed init_render_mesh to always get the mesh data through a DerivedMesh
2005-07-14 - Change DerivedMesh.drawSolidFaces setMaterial argument to returnDaniel Dunbar
boolean value indicating whether faces with that material should be drawn or not.
2005-04-04 - removed DispListMesh.{editedge,editface}Daniel Dunbar
- removed displistmesh_from_{mesh,editmesh} - removed EditVert.ssco - removed unused functions for DispListMesh DerivedMesh Still need lots more testing for this stuff.
2005-03-30 - fix silly bug in mesh DerivedMesh tex drawing func (only was drawingDaniel Dunbar
first face. - change DerivedMesh callback prototypes to help eliminate errors
2005-03-30 - made some DerivedMesh drawing functions more generic (take callbackDaniel Dunbar
to determine if element should be drawn and to set draw options), which meant some could be combined - eases implementation of new DerivedMesh types and keeps more app specific logic out of DerivedMesh implementations.