Topic: [Blender 2.62] issues, problems and changes

[ratty redemption]

is the current version of it buggy? it doesn't behave as i'm used to with 2.4x, i can't find where to set it's threshold.

it often seems to collasps verts that are adjacent to the dragged (selected) verts although several minor grid units away and not close enough for me to want them merged.

3d view > edit mode > mesh menu > automerge editing

[kat]

I can't find any settings either so I wonder if it's sensitivity is determined by the "Scale" being used (in "Display:" properties, "N") in the main 3DView - I just tried it and had to pretty much drop the verts on top of each other before they would join together, this is using "Scale: 1.000".

[ratty redemption]

thanks kat and i'll test that report back, might be tomorrow though as i'm rendering something at the moment.

[ratty redemption]

hmm, i've done some more tests with the automerge at various grid scale settings and it doesn't appear to make any difference, which is good imo. it also seems only one of my current meshes has the weird snapping/merging behavior of collapsing nearby unselected verts to the dragged ones. the only difference i can think of is that mesh used to have shape keys (morph targets) so maybe that causes the bug?

[kat]

If you 'clean' the mesh of any shape keys or influence therein, does the problem still happen?

[ratty redemption]

i'll have to do more tests but yes i think the bug persists. last night i quickly created a similar new mesh in the same location but without any modifiers or shape keys, the vertex snapping/merging worked as i would expect.

overall i am really enjoying working with 2.62 and have no intentions of going back to 2.49b except for converting older .blend files over to the newer versions, it's just some of these bugs are wasting a lot of time which i would perfer to be spending on other things.

[ratty redemption]

i think i've tracked down this bug from a user's perspective, it seems not related to shape keys as i had previously thought, but rather if a mesh has been scaled in object mode and not then had the scale applied with 3d view > ctrl a > scale

the bug doesn't always happen under those conditions, but if it does then applying scale in object mode seems to fix it.

[ratty redemption]

has anyone here manged to successfully change it from the default select to tag seam?

when i then try to use alt rmb blender still selects an edge loop. iirc in 2.4x it would allow the closest edge under the mouse cursor to be toggled with seam or crease etc.

3d view > edit mode > tool shelf > mesh options > edge select mode

[kat]

I can confirm that not doing what you want because I've been looking for that as well; it was a really handy tool in 2.49 that I think (don't quote me on that) was removed in the 2.5 series. Not entirely sure why (I've not read or seen anything concerning it), but at a guess it'll be something to do with the switch made to the way the 3DView renders objects I bet. Note that the ability may still be there, just hidden as some obscure shortcut or something.

[ratty redemption]

thanks kat and damn, that was a great time saving feature, i really hope they oneday implement it again.

[ratty redemption]

i'm trying to remove some redundant data from my blend files, using the outliner window > display mode > datablocks and current scene.

with certain types of data, for example meshes, textures and materials, we can unlink them and they will then turn to orphans which will then be purged from the blend file next time it is saved and reopened, although apparently only if the data types start off with being linked to objects etc, or have fake users?

i've noticed some data blocks, even without the fake users ticked will stay in the blend file, specifically the actions data.

does anyone know how to purge all redundant data or even just the actions?

[kat]

Yeah I've had that happen a few times, the only way to remove them is to open a brand new file and Append the data you want to keep. Doing this usually only brings in the required blocks leaving the 'corrupted' info where it is.

[ratty redemption]

thanks kat and i started using that workaround earlier today. so really this is the same problem we've always had with blender, and not even the new outliner tools can clean up our blend files? *sigh*

[ratty redemption]

during the process of starting with a new clean blend file, with no user data other than ui preferences, and then appending objects and all their linked data into the clean blend, i noticed what might be a gamma bug. if you compare these two images, the 2nd one has a lighter grey background to the 3d window, but the world values defined for both blend files are the same.

if this isn't a bug, any idea how to fix this so the 2nd file has the darker gamma? to clarify i don't want to simply give the world a different value, i want it to be consistant across all my projects i do with 2.6x if possible.

[kat]

In word 'yes'. It's not a surprise really due to the way Blender uses 'blocks' of data and 'links' therein.. it means these isolated bits of data exist quite legitimately in the files structure even though they may not be used at any given time; ideally you'd want to be able to delete them from the OOPS (Outliner) but that's never really been possible (as you know), probably as a preventative measure to stop Users accidentally deleting blocks that are linked to other elements.