| Age | Commit message (Collapse) | Author |
|---|
|
ported to bmesh, also remove main editmesh header.
|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
into account that some tools use normals for things other than display. Now
we properly initialize vertex normals at flat faces too.
Also fixed a normal refresh issue, and deduplicated CDDM/mesh normal
calculation code.
|
|
|
|
|
|
|
|
Active shape key can now be changed while in edit mode. This is based
on exit/enter editmode again in the background, which is not ideal,
as that loses the undo history. But that already happened anyway when
you did exit/change-active/enter manually.
|
|
* Objects now support up to 32767 material slots. It's easy to
increase this further, but I prefer not to increase the memory
usage of mesh faces, it seems unlikely that someone would
create 32767 distinct materials?
* Forward compatibility: the only thing you can potentially lose
reading a 2.5 file in 2.4 is object linking (instead of default
data), though usually that will go fine too. Reading files with
> 32 material slots in 2.4 can start giving issues.
* The ob->colbits variable is deprecated by the array ob->matbits
but I didn't remove the ob->colbits updates in very few places
it is set.
* I hope I changed all the relevant things, various places just
hardcoded the number 16 instead of using the MAXMAT define.
* Join Objects operator back. This is using the version from the
animsys2 branch coded by Joshua, which means it now supports
joining of shape keys.
* Fix for crash reading file saved during render.
|
|
- Depricated another bunch of globals; all the totobj,
totmesh, totvert, and so on.
- All code that needs such totals now count it themselves,
these stats were not supposed to be reliable
- Editmesh now stores and manages own totals.
- Todo: make a scene->stats that tracks notifiers.
Bugfix: selecting failed in editmesh, backbuffer stuff was
too late, already using index ranges before it was set.
|
|
- remove Verse support. This will be brought back in The Future (probably jiri + me)
This means 5k lines less in blenkernel.
- fix two small errors for global cleanup, now compiles properly with FFMPEG enabled too.
|
|
From the anti-globalization department:
G.obedit terminated!
Wherever possible, use CTX_data_edit_object(C) to get this
now. It's stored in scene now, and the screen context has
it defined.
|
|
- Put back vertex/edge/face select
- Mode menu allows going in/out editmode
- Tested some tweak event stuff in WM, made tweak event follow
user preset for 'action' or 'select' mouse.
(Wanted to try this for transform, but better get advise from
Martin first :)
|
|
Editmesh code cleaned and compiling/linking. A whopping
20k lines back! :)
Not that it does stuff... editmode in/out has to be done,
and loads of operators. Also linking/exporting editmesh
calls has to be reviewed.
Also: added a blender_test_break() mechanism in BKE.
|
|
since no additional crashes were reported!
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
The following is a commit of Levi Schooley's bevel code and
the bmesh library it depends on. The current editmode bevel has
been replaced with a new per edge bevel function. Vertex beveling is
also availible.
To set weights for the modifier to use, use the ctrl-shift-e shortcut on either edges
or vertices.
Recursive beveling is turned of for the time being.
|
|
EditVert had "float *fp" while the others had "float p".
changed to "float p" and made all code using the float pointer use the already existing tmp.p (void*) instead.
|
|
because the TFace flag was not always easy to access from editmode.
using the last selected face was almost good enough however when selecting verts and edges the last selected face would become inactive and the space image would flicker about too much.
The active face is used for getting the space image at the moment and keeps scripts that use this flag working also.
This has 2 commands to get and set, so the variable is not accessed directly.
all "UV Calculate" scripts work now
last commit crashed when in solid draw mode, it seems subsurf modifier is ignoring the displayMask since MTFACE is available. just made it do a null check for now.
uvcalc_follow_active_coords.py - should be done inC and put in the snap menu.
|
|
In order to give import/export script authors the ability to add properties
to inidividual faces, vertices and edges in the same manner as they are able
to do with ID structures three new custom data types have been added to blender
for floats, integers and strings.
Things to note:
-Since property Layers are custom data, they are added to all verts, edges
or faces at once.
-Only one property layer for each unique property name may exist. In other
words, you cannot have a float layer as well as an integer layer
both with the same name.
-No user interface for this exists at the moment.
The following methods and attributes have been added to the Blender.Mesh
Python module and it's object types:
->MVert/Edge/FaceSeq:
addPropertyLayer(name, type)
removePropertyLayer(name)
renamePropertyLayer(original name, new name)
properties(readonly list.)
->MVert/Edge/Face
getProperty(name)
setProperty(name, value)
->Mesh module
PropertyTypes (readonly dictionary)
|
|
Fixed bug #5829, Exiting editmode with TAB key toggles RETOPO
* Moved the retopo_mode setting to ToolSettings.
* Renamed the other retopo_mode to the (more accurate) retopo_paint_tool
|
|
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.
|
|
now, others can be added later (sticky, shape keys). Beside one small fix
for knife exact vertex group interpolation, is intended to work the same
as before.
Also fixes bug #5200, related to editmode undo and vertex groups. And
corrects the editmode to faceselect mode selection conversion, that was
broken in a previous commit.
|
|
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.
|
|
From the tracker:
https://projects.blender.org/tracker/index.php?func=detail&aid=5018&group_id=9&atid=127
|
|
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)
|
|
- All code is in #ifdef ... #endif
- Only make build system is supported and you have to add:
export WITH_VERSE=true
to user-def.mk file
- Blender can share only mesh objects and bitmaps now
- More informations can be found at wiki:
http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender
http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc
I hope, that I didn't forget at anything
|
|
Previously Blender did not store the order in which vertices, edges
or faces were selected in edit mode. In many cases it is useful to
have this data, however it is not desirable to store every selection
made. Now blender stores selections in the order in which they were
made in a linked list called 'selected' in EditMesh. EditSelection structs
are created whenever 'EM_store_selection' from editmesh_lib.c is called
(currently only on user selection with mouse). There are several cases
in which they might be deallocated by calling the 'EM_remove_selection'
function however:
-When the user deselects something with the mouse ('mouse_mesh' in
editmesh_mods.c)
-When switching selection modes stored selections that are not relevant
to the new mode are removed by the 'EM_strip_selections' function
(multi-select mode is supported)
-When the vertex, edge or face pointed to by a certain stored selection is
deallocated
-When EM_clear_flag_all is called and where the flag passed to the function
contains the 'SELECT' bitmask.
-When leaving edit mode (making stored selection data persistent across
editing sessions will require modifications to mesh DNA later)
Todo:
There are a few cases still where you can temporarily end up with a stored
selection that points to an element that is no longer selected
(edge loop de-select can cause this for instance). The solution to this is to
add a call to EM_remove_selection from 'EM_select_edge' and 'EM_select_face' when
these functions are being used to deselect elements. For the sake of completeness
however this will also require that an 'EM_select_vert' function be coded and
called at all appropriate parts of the editmesh code. I will look into this
later in the week.
For now there are two tools that already take advantage of the stored selections.
The first one is 'merge at first or last vertex' in the merge menu (the 'firstvert' and
'lastvert' pointers are gone from EditMesh). The second tool is path select, which builds
a path between the last vert selected and the second to last vert selected. This allows you
to build complex path selections in a short amount of time like this
'select A, select B, path select. select C, path select. select D...'
|
|
face/vert/edge)
so you can select 2 faces and then get all coplaner faces around both.
Added fp to face and edge edit data so as to store edge length and face area/perimeter. (in the union so minimal overhead)
current implimentation is fairly optimized.
Change to arithb.c was just to command Inpf as being the dot producr.
|
|
source/blender/blenlib/BLI_editVert.h
source/blender/include/BIF_editmesh.h
source/blender/src/edit.c source/blender/src/editmesh.c
source/blender/src/editmesh_lib.c
source/blender/src/editmesh_mods.c
source/blender/src/editmesh_tools.c
source/blender/src/header_view3d.c
Log:
Commit of the 'upgraded merge tools' (Patch #3345) and 'inclusive selection mode conversion' (Patch #3768).
|
|
guitargeek), this commit enhances the support for temporary storage
for the structs EditVert, EditEdge, and EditFace. The field
"EditVert *vn" has been removed and replaced by a union called
"tmp" that can hold:
v, an EditVert pointer;
e, an EditEdge pointer;
f, an EditFace pointer;
fp, a float pointer;
p, a void pointer;
l, a long;
Please see the mailing list post here for more information about
this:
http://projects.blender.org/pipermail/bf-committers/2005-December/012877.html
|
|
editmode selection tools. The documentation can (currently) be
found here:
http://mediawiki.blender.org/index.php/Requests/SharpFlatSelect
|
|
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.
|
|
and this is better left to user (whee this was a fun commit! so
much deleting!)
- removed mesh_calculate_vertex_normals (replaced by mesh_calc_normals)
|
|
- 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).
|
|
- removed displistmesh_from_{mesh,editmesh}
- removed EditVert.ssco
- removed unused functions for DispListMesh DerivedMesh
Still need lots more testing for this stuff.
|
|
- 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!
|
|
actually, adding vertices and edges to displist.
Now the subsurfer gives editvertices a pointer to the subsurfed vertex
location; allowing not only vertices in 'optimal' draw to show correct, but
also gives proper handling of borderselect and lasso for edges. :)
|
|
Just select a bunch of faces (selection should be valid flat poly) and
press FKEY. Works in fact as selection-group optimizing. Nice in solid
drawmode!
Further some small additional fixes in the whole debugging process.
Found old error in loopselect for triangles, subdivision code, and
selection still.
NOTE: subdivide still works on vertex level only.
|
|
- hide flags now save correctly in mesh, to restore after going in/out
editmode
- after an extrude, faces/edges could have wrong select flags
(only in vertex select mode)
- new rule for addfacelist(); this now copies edges too, if an example
is provided. That prevents a lot of awkward code, still testing if it
goes as desired though...
|
|
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.
|
|
- EditVlak -> EditFace
- variables called 'evl' -> 'efa'
- functions with 'vlak' in it now have 'face'
Just thought was nice starter for editmesh recode...
|
|
http://www.loria.fr/~levy/Galleries/LSCM/index.html
http://www.loria.fr/~levy/Papers/2002/s2002_lscm.pdf
Implementation Least Squares Conformal Maps parameterization, based on
chapter 2 of:
Bruno Levy, Sylvain Petitjean, Nicolas Ray, Jerome Maillot. Least Squares
Conformal Maps for Automatic Texture Atlas Generation. In Siggraph 2002,
July 2002.
Seams: Stored as a flag (ME_SEAM) in the new MEdge struct, these seams define
where a mesh will be cut when executing LSCM unwrapping. Seams can be marked
and cleared in Edit Mode. Ctrl+EKEY will pop up a menu allowing to Clear or Mark
the selected edges as seams.
Select Linked in Face Select Mode now only selects linked faces if no seams
separate them. So if seams are defined, this will now select the 'face group'
defined by the seams. Hotkey is still LKEY.
LSCM Unwrap: unwrap UV's by calculating a conformal mapping (preserving local
angles). Based on seams, the selected faces will be 'cut'. If multiple
'face groups' are selected, they will be unwrapped separately and packed in
the image rectangle in the UV Editor. Packing uses a simple and fast
algorithm, only designed to avoid having overlapping faces.
LSCM can be found in the Unwrap menu (UKEY), and the UV Calculation panel.
Pinning: UV's can be pinned in the UV Editor. When LSCM Unwrap is then
executed, these UV's will stay in place, allowing to tweak the solution.
PKEY and ALT+PKEY will respectively pin and unpin selected UV's.
Face Select Mode Drawing Changes:
- Draw Seams option to enable disable drawing of seams
- Draw Faces option to enable drawing of selected faces in transparent purple
- Draw Hidden Edges option to enable drawing of edges of hidden faces
- Draw Edges option to enable drawing of edges of visible faces
The colors for these seams, faces and edges are themeable.
|
|
Edges in Mesh
- adds automatic when you use creases. For other situations; call the
void make_edges(Mesh *me) in mesh.c. Of course, once in editmode the
edges are automatically recreated.
- in F9 buttons you can add/remove edges too
- both for Mesh and DisplistMesh, so it speeds up drawing quite some in
wireframe
- render for edges can't work... edges have no material nor tface nor col..
so here still the faces are rendered in wire
Creases in Subsurf
- based on the code by Chris McFarlen
- main changes is that now edges are used, saving quite some data in file
- use SHIFT+E in editmode to set edges-sharpness. values go from 0-1
- in F9 buttons you can set draw-crease mode. It draws now blended from
wire color to edge-select color (as provided in Theme)
Known issue: setting sharpness on 1 cube (subdiv 2) gives weird results
with some values... Chris, can you check?
Further; code cleanups, changing 0 in NULL when needed, no warnings, etc etc
|
|
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.
|
|
in editmode without damaging the mesh. Please test.
|
|
colors. This because of the pretty weird (ab)use of load & make editmesh...
For each added undo step, the load_editmesh was fed with an empty mesh
to assign data to, without knowledge of what was in the original mesh.
That way UV and color data got lost.
Solved it in 2 steps:
1. removing the ->tface pointer from EditVlak, and make TFace a builtin
struct inside EditVlak. This didnt cost much extra mem, since it already
stored UV and color. This enabled some pretty cleanup in editmesh.c as
well, storing tface pointers was cumbersome.
2. for each undo step, it then generates always a tface and mcol block to
link to the undo Mesh.
Even when it wasn't in the actual Mesh, at exit editmode the original
Mesh is used as reference anyway, and undo-meshes are freed correctly.
The enormous commit is because I had to change the BLI_editVert.h file, and
found it was included in about every file unnecessary. I removed it there.
ALso found out that subsurf has code ready (unfinished) to make UV coords for
the displaylist in EditMode as well, nice to know for later...
|
|
So we should be all set now :)
Kent
--
mein@cs.umn.edu
|
