Topic: blender 2.6x reordering a mesh's build structure?

[ratty redemption]

i've been using an array modifier in 2.61 with a gap between each child object. ideally after i've applied the modifier, then separated all of the child meshes into their own objects, their internal build order would be the same, ie a build modifier when animated on each object would start and end on the same vert. it appears the array child meshes have random order although without build modifiers they look and render the same.

does anyone here know of a way to reorder all objects from the array to match the parent/original mesh?

hope that makes sense?

[kat]

Can you post some pictures of what it's doing (compared to what it should be doing), I'm having a hard time trying to visualise what's going on.

[ratty redemption]

i've been doing some more tweaking and i suspect it was a randam bug as my blend file is now working in both 2.61 and 2.62, i'm not sure what i did to get it working, and i've got to test a few other things, but will post an image or two later.

if i can get this stable these tests will become part of my rock wall tutorial.

[ratty redemption]

here's some images to demonstrate what i'm trying to do.

image 001 shows my uv test pattern texture on a parent object/mesh (top left) and it's child sub meshes created with array and curve modifiers, so far so good.

image 002 shows a build modifier added to the stack, with an animation range of 1-100, and the current frame being 10. here's the first indication the modifiers don't behave as i would of expected. imo the number of faces rendered in the preview window should be the same for each child mesh. it seems over the course of the animation the build modifier drops a few frames on certain sub meshes. maybe this is a hard coded feature rather than a bug?

image 003 shows the dropped frames in the form of missing faces by the end of the animation.

[ratty redemption]

image 004 shows the effects of the array and curve modifiers after they have been applied to the parent mesh. the only modifier left in this example is a build and it's results here look reasonably ok.

image 005 shows the parent mesh (top left) separated from the child sub meshes. this is where things really start to screw up, in that the order of the faces rendered using a build modifier on each new object/mesh is reversed from the previous image, except the last mesh (highlighted in yellow) which is in the correct order.

image 006 shows the intended purpose of these meshes, in that a medium poly mesh, again with my uv test texture mapped to it, has been deformed to the shape of the control cage (bottom left) made out of the previous parant and child meshes.

[ratty redemption]

image 007 shows (top left) what happens when the control cages have their internal build order rearranged by either the hard coded features or bugs found here.

to summarize, i'm trying to find a way to use array and curve modifiers to quickly produce a series of control cages, to then be used for deform sections of a tiling rock wall. in theory it should be quicker than manually duplicating and placing every control cage needed.

[kat]

It might be worth posting this on Blender Artists to see if anyone else has come across this; to be honest I'm not familiar enough with arrays and their use to know if this is a bug or not - it doesn't 'look' right but you never know.

[ratty redemption]

thanks kat. i recently registered over at the blender newbies forums, and posted the same original question. i've updated them with a link to the posts i made here today. they also recommended i asked the blender artist guys, so i'll register there as well.

http://forums.blendernewbies.com/viewtopic.php?f=17&t=6315&sid=6897e26e3d0c6ef6e079f7dcb89af641&p=45235#p45235

[kat]

Walsh makes a valid point about checking you've used "Apply" before adding the modifiers; remember that Blender treats the objects original properties as the data is should be using so if your originals are scaled or rotated (as he suggested), that will translate into misalignment's etc. when the changed through the addition of a (modifier) stack.

[ratty redemption]

thanks kat and by apply i assume you mean ctrl a?

after doing a few more tests, it seems the biggest culprit is the p key mesh separate tool, what ever i do, it seems to be randomizing the direction of the build order, although it will i think always start on the top left corner or bottom right corner of the child meshes. i'm wondering if this could have anything to do with tri souping? i recently read an article you had posted on your main site about that.

[ratty redemption]

image 008 shows the build order changes again if i use the ctrl j keys to join all the child and parent meshes. this time two of the child meshes would finish being built during the test animation, before the others would even start.

to clarify, i'm only using the build modifier to test the internal data order of the meshes. it wouldn't be used in the final workflow of what i'm planning.

[kat]

thanks kat and by apply i assume you mean ctrl a?...

Sorry, yes, "Ctrl+A" ("Apply > Location/Rotation").

If I understand what you're doing correctly, if you try and change the 'build' whilst effectively in the middle of doing something, i.e. you try to change something without first collapsing the stack to 'make real' what's going on, then it's likely going to cause problems (using "P" to separate is effectively forcing 'make real' on a specific element whilst its in the middle of being deformed for example) - so far as I'm aware those types of shape manipulations don't behave properly when you try and alter something in a mode you didn't set the tools in place on... if you add one in Edit mode then try and do something in Object mode, or visa-versa, it may cause problems.

[ratty redemption]

thanks kat and i too have discovered those restrictions in the past with several different modifiers. so in this case, when i'm wanting to separate parts of a mesh, like for example the child meshes, i do apply the modifiers, hopefully in the correct order, before entering edit mode.

the build modifier doesn't appear to affect the mesh data itself during animation, i think it's just a type of render/preview culling. similar to the mask modifier, although both of those can at any point be applied to the stack, thus making their effects real.

to clarify, if i join several meshes together, whether they were originally generated from an array or just duplicates of say a subdivided plane, then separate them and add a build modifier, the results can be somewhat random, although in the case of plane type meshes, they always start at one of the corners, and not for example, in the middle of the meshes.

i'll do some tests with non planar meshes, like suzanne (the monkey prefab) and report back.

[ratty redemption]

it appears that the mesh separate tool is causing the build order direction to be randomally swapped. i've since done several more tests on various meshes including suzanne and the results are consistant. hopefully if i post about this on the blender artists forum, someone familiar with scripting or coding could either fix this or create a work around.

[kat]

That's looking more like you've found a bona fide bug (or at the very least 'abhorrent behavior') and not something that's necessarily going to be fixable through hacks. I'd get this one submitted to the bug tracker.