I would like to add the loose part method to other modifiers. What is the best/fastest way to get lists of vertices by loose parts so that it can be multi-threaded and use intrinsics? I mean, there should be no collision risk with loose parts and every loose part should get the same transformation on all its vertices. Campbell, maybe you could provide a little code snippet?

Just tested the patch. Works really great :) But for consistency, a scale of 1 should do nothing and 0 should make the mesh flat. At the moment -1 makes mesh flat and 0 makes no changes.

@mathieu menuet (bliblubli): Yes, I spent much time pondering this question. The thing is all other settings are DELTAs, zero meaning no change, so I figured why would this one be different ? Anyway, it's easy to change it back to 1 being the neutral point.

@Patrice Bertrand (PatB) many reasons lead me to that. In the property panel, and object panel, scales of 1 are for "nothing changed" 0 for flat, -1 for inverse.
Second reason is that scale is a factor (*)while translation is an offset(+) mathematically, neutral for * is 1, neutral for + is 0.
The most important for user is consistency. If they have to enter -1 in your modifier and 0 in viewport or 0 for 1, etc... they will get messy in their head ^^

@mathieu menuet (bliblubli): Yes, now I fully agree: scale is a multiplier thus 1 is neutral. I'll wait for (hopefully) more feedbacks, then fix this.

Another improvement could be to add the option to scale relative to the min or max and not only mid ( bounding box center ). When someone use it on leaves/stone/whatever on the ground scaling relative to centre makes them float in the air. Having the possibility to scale relative to their lowest vertex would allow realist use of the modifier.

Some suggestion:

adding
extern StructRNA RNA_NoiseModifier; //at line ~70
in source/blender/makesrna/RNA_access.h
could maybe be good?

and
case eModifierType_Bisect: //at line ~920
in source/blender/editors/space_outliner/outliner_draw.c
too (add an the appropriate Icon in the outliner?

See https://developer.blender.org/D184 for an example

this is an excellent modifier!
can i suggest adding the ability to easily seed the random number generator by the current frame number?
this would be extremely useful for animations!
thanks!

@tommy ob3lisk (ob3lisk) I don't have my compiled version at hand, but it should "magically" work if you just enter #frame in the "seed" field...it should create a driver automatically that alters it's value with every frame change...

Greetings, Thomas

@mathieu menuet (bliblubli): regarding the option to scale relative to the min or max, maybe something more generic would be to allow another vertex group to define pivot point. Vertex groups are copied correctly when array modifier generates meshes. Pivot point would be the center of the vertices in the loose part that belong to the said group, which in most cases would be a one-vertex group.

@tommy ob3lisk (ob3lisk): Yes it does work magically, just like Thomas says.

@campbell: I'm currently working on a version that will not use BMesh, as you suggested, with possibly a performance gain. For that purpose, I have coded a BKE_mesh_loosepart_vertex_map_create within mesh_mapping.c. Will post it soon, together with some performance figures.

@Patrice Bertrand (PatB) it would force the pivot point to be one of the vertices. For the ground, we sometime use geometry with a hole beneath (helps a lot to save 10 triangle when you instantiate an objects a million times = - 10 000 000 of triangles.), in such a case, the pivot couldn't be in the centre of the bottom part. It would also limit your modifier to geometry generated with the array modifier. Using you modifier for some time now, I use it a lot on imported objects for which we can't manually set a pivot for every loose parts in reasonable amount of time.
Maybe giving both possibilities for different usage ? Generated pivot and manual pivot through vertex group ?

@mathieu menuet (bliblubli) : I think the pivot point vertex group, as implemented in the RC2 version should fit all needs. The vertex group used for pivot point may be a single vertex, but for example if you want to scale up from the lowest point you can just define a group that contains vertices at the bottom of the object. The pivot will be the center of bounding box of vertices in the group, so it is quite possible that there is no actual vertex at this point, say if the bottom face is a 10 vertices ngon circle, the pivot point will be the center of the circle.

Other than that, I think I must stop adding features now, else users will get disturbed, or lost.

Very nice new version. I did some test on very heavy scene (millions of polygons in about 20 objects all having the same plane to cut. It rotates, with real time bisect on an I5 3450 :) Thanks a lot as well for making part of your code easily reusable, really kind of you. For the options I need, I can add them myself, no problem if it doesn't go in trunk.

I just realized that since I am isolating loose parts starting with polys then going through all connected polys, I am missing loose parts that do not include any polys, that is to say either unconnected vertices, floating edges, or even loops of edges without an actual face. This is wrong, I need to scan all vertices, and follow not polys but edges. I had figured working on the basis of polys could be more efficient, but actually there is not much difference. I will fix this quickly.

Hi PatB,
Some fine tuning:

• When Object offset is chosen, "translation", "rotation" and "scales" are displayed also with plus/minus (should be hidden in release/scripts/startup/bl_ui/properties_data_modifier.py)
• When I choose Object Id as seed, changing the seed value changes the noise. Is that a wanted behaviour ?
• Most people will use your modifier for the "looseparts" option ("whole mesh" mode can be replaced by a driver, "vertex" is more like displace modifier), making that mode default would save many clicks.

Not sure about this modifier, it seems to be a catch-all for moving mesh data about... which is ok.

but the whole mesh option seems a bit odd (you could use warp modifier already for this),
loose parts seems to be the most useful feature but the way it works by calculating loose parts every time - Im not so happy with either

PatB or someone who used the "Whole mesh" mode could maybe tell us why it's good (drivers and/or particles are much more memory efficient to randomise instances). I couldn't find a usefull case to use the that mode either.
For the per vertex mode, for me it's like displace, so it could be removed as well.
The loose part option could be added to all modifiers needing this. Reading post from other on Blenderartists and based on my work, Shrinkwrap and displace would have a great benefit of it. Maybe other members of the community could tell us where they would use it?

PatB or someone who used the "Whole mesh" mode could maybe tell us why it's good (drivers and/or particles are much more memory efficient to randomise instances). I couldn't find a usefull case to use the that mode either.
For the per vertex mode, for me it's like displace, so it could be removed as well.
The loose part option could be added to all modifiers needing this. Reading post from other on Blenderartists and based on my work, Shrinkwrap and displace would have a great benefit of it. Maybe other members of the community could tell us where they would use it?

@mathieu menuet (bliblubli): whole mesh really makes sense together with the "Use ID as seed" option checked. When this option is checked, the unique name of the object is used to alter the seed (hash of the name, then xor with seed). The effect of this is that you can then copy the object with either Shift-D or Alt-D, and each of the copied object will be affected by noise differently. For example you could place trees on a landscape, and with a single mesh object you would have your trees with random sizes and random Z-axis rotation. I don't see any other modifier that would do this, but maybe I'm wrong.

I do agree that vertex mode is very much similar to what the displacement modifier does.

I added a reusable BKE_mesh_loosepart_vertex_map_create function into mesh_mapping.c, which hopefully can be used by other modifiers needing looseparts. I will try to add openmp support to it, although it is a bit more difficult than for simple for loops.

As suggested by Campbell, I will work on integrating the loose parts mode alone into the displacement modifier, and work on adding openmp support on both which seems quite straightforward. Campbell also suggests caching the looseparts map data. I will look into this as well.

Actually having to calculate loose parts after an array modifier is a work-around. Array modifier produces a single mesh object with multiple loose parts. But what we really want is not so much working on loose parts as working on the multiple objects that the array modifier has produced. In other words, whereas modifiers take a mesh as input, and produce a mesh as output, it might help to have modifiers that output a set of meshes, and the next modifier on the stack would be called separately for each mesh. Could be an option of the array modifier, and the overall modifier manager would be altered to handle this. But this might be getting too complicated, for a relatively minor need. Dealing with loose parts is very simple in comparision.

@Patrice Bertrand (PatB) I didn't mean a modifier, but drivers : http://wiki.blender.org/index.php/Doc:2.6/Manual/Animation/Basics/Drivers . They also allow randomising scale and rotation while keeping only one mesh in memory (instancing), thus saving huge amount of memory. Your whole mesh option doesn't allow instancing as it produces new meshes for every objects. The good part of your idea was to take the object Id as seed, which can be really usefull to have a randomisation that is constant relative to time and space. Someone is looking for a solution like that for drivers on Stackexchange http://blender.stackexchange.com/questions/7758/how-can-i-get-a-random-number-that-is-constant-per-object-in-a-driver . If someone has the answer :) From a user POV, it's much easier for sure, but it leads to bad memory management. It's in no way a critic, I'm really happy you did that modifier, it's just some options are redundant and can be done better with existing tools.

Did not review code at all, but feature is interesting imho. However, it should be merged with Displace modifier, those two share many things (would then have two main modes, Texture and Random). Would be a good way to review UI of Displace as well, kinda odd currently (with tex mapping at the opposite of texture selector… tst).

As for cache, using number of vertices and number of edges as key would tackle 99% of situations imho, I do not see having a small "Refresh" button for the few cases that may break as an issue (and if we want to be 100% sure, we can make some kind of hashsum of all vertices used by all edges… do not think it would be worth it though).

So, those comments were done while refactoring the patch, they highlight issues I found on the process.

I’ll now commandeer the rev, update the patch, and make comments on points that still need discussion imho…

Tsst… I still forgot some cleaning… :P

Btw, @Patrice Bertrand (PatB), feel free to comandeer the rev again if you want. :)

Thanks for the thorough review and improvements. I will try to remember for my next Blender endeavor ! There is just the stack thing that I'm not convinced about, but I'll look into it a little more.

and I hope I get to see my name in the header section ? This is really the reward that one gets as a contributor, that your efforts be remembered.

Well, I find stack simpler to read/follow than the kind of "sliding window" you used, but that may be matter of personal tastes.

Did a few checks, with a single cube subdivided 6 times (about 24k vertices), max stack size is 3635. With about the same number of vertices, but in 32 different loose parts, max stack size is 383.

With same mono-block cube subdivided 9 times to get about 1.5 millions of vertices, max stack size is 83839. With about the same number of vertices, but in same 32 different pieces, max stack size if 7344.

With a 2M vertices subdivided Suzanne, max stack size if 57715.

TBH, the main issue I see in smallstack is that it allocates one element after the other - not sure how much 57k calls to alloca() weight in the final time…

Hi thanks for integrating the modifier,
-Scaling of 0 doesn't make flat like in all other parts of Blender. For consistency, it was better with scale of 1 for not scaling and scale of 0 to make flat. Follows math rules too, so more logical.
-Allowing to use textures for the "loose part" mode could also be great. As displace value for each loose part, let the user choose between max/min/mean would allow precise positioning like the old displace, but without deforming the loose parts. It would also save space to only have "Vertices" and "Loose part" modes with a choice for each between texture or noise for the displace values.
-Is there really a use case for the whole mesh mode ?

@mathieu menuet (bliblubli) I disagree about scale, these are factors, and imho it makes much more sense for a factor to have no effect at 0.0 than at 1.0 (and it also makes it consistent with the other factors).

As for texture, you can already get undeformed displacement of looseparts, just assign the same color to a whole UVs of a loosepart, and you’ll get it.

About whole mesh, yep, I said it would be better as a constraint imho.

Hmmm, in the N panel, scale factor of 0 makes the object flat and scale of 1 does nothing (object is same as mesh).
In the Displace modifier, a Strength factor of 1 displace exactly like the Bump data defines it (100m if the height data is 100m at that point), a strength factor of 0 makes the mesh flat.
In math, 0*x=0(flat) and 1*x=x (nothing)

For the solution regarding texture with UV, it requires manual positioning of all the UVs, really long on a many thousands vertices mesh and, if the mesh is changed during the project, you have to unwrap it again. This modifier I think is more to rapidly displace huge quantities of "objects" in a single mesh. Imagine an artists made a nice city, the other one a nice terrain modelling, you want to put every building/house on the terrain, the height-map texture would allow it dynamically (both artists can modify their work and the final result is always good without intervention).

Hi @Patrice Bertrand (PatB),
is there anything left to do before this should got to master? I would really like to see it in 2.72, as it's providing much needed functionality in the mograph field - especially the separation of loose parts is important there.

Greetings, Thomas

@Thomas Beck (plasmasolutions), @Bastien Montagne (mont29): Hello Thomas. I would love to see it in 2.72 as well. Last time I worked on it was to merge it into the displace modifier. In April, the revision was commandeered by Bastien. He did some cleanup and it seemed ready for release. Maybe Bastien can tell if it's possible to get it into 2.72..

I’m OK with the patch (wouldn’t have spent hours on it otherwise ;) ), but we need final yes or no from Campbell, he’s maintainer of this area.

Hi @Campbell Barton (campbellbarton), what's your opinion on this? Functionality wise I am absolutely for an include. You simply can't do certain things without this modifier (like moving & animating individual chars from a converted text object). Is it ok for you if this goes into master?

From IRC:

Issue I have with this modifier is its in effect trying to make modifiers able to manipulate a single mesh as many, thats not bad in its self but its not how modifier system works currently and its clumsy to do it in the current modifier stack

Current code hashed object name and attempts to find if input changes, so it works around the fact that our API isnt well suited to the task.

if we have some improved modifier stack - nodal, for example, we could have a node that splits a mesh into many, then all operations after could be applied onto each, but IMHO this should be supported in a general way. Not everyone having to write own mesh-split-caching.

It seems useful to be able to take a mesh. convert each loose part into a triangle (for example), sent that through the modifier stack deformations etc... then apply the result back to the loose parts.

Hello @Campbell Barton (campbellbarton),

The nodal modifier design seems to be the holy grail. And yet it could take years to come, and we should not, in the meantime, give up on interresting features just because they would fit so much better with nodes. I think new features can be added within the current model when relevant, and may be then replaced by their nodal equivalent in the future.

Actually, I don't see a huge number of modifier features that would draw great benefits from a nodal model. In most cases, the current, linear, one-dimensionnal or stack model is exactly what one needs: do this, then do that, then that. In most cases, in a nodal modifier model, one would just layout nodes in a straight line, and join them with noodles.

Where would the nodal model really make a difference ? Where a given node is the parent of two or more child nodes, or where many nodes are joined as input into a single node. When would this happen ? Indeed, we could have a "Join" Node, that would take two meshes and perform a dynamic Join operation. We could have a Mix Node, that would take two displace-only deformations of a given mesh, and yield a weighed mix of the two, where each vertex is the weighed average position of its two deformed instances.

A nodal model would not handle only "deformed meshes", but should handle both "deformed meshes" and "mesh objects", so we would have two array nodes (or one with two outputs), one that yields a mesh with loose parts as today, and one that outputs as many mesh objects as there are items.

In a nodal model, a "Split loose parts" Node would take a mesh as input, and output many single mesh objects. But what would it mean for downstream nodes ? They should process each loose part chunk independently. The same with the array modifier Node: it could either yield a single mesh object as it does today, or yield as many independent mesh objects as array items. Before any coding, it seems there are some conceptual issues to be pondered here.

Let me get back to the Noise Modifier, now integrated as a new behaviour of the Displace Modifier.

Of the 3 modes:

• I agree that vertex mode brings little added value as compared to the texture based displace. It could be trashed altogether. But then again it would have its use cases I'm sure.
• Loose parts mode is the most specific, and really brings possibilities that do not exist otherwise. Acting separately on each item following one or several array modifiers is the most typical case, and it would justify the modifier by itself. There are other use cases. As Thomas mentions, moving & animating individual chars from a converted text object is another one.
• Whole Mesh mode also brings in unique possibilities. Being able to copy objects, either by shift-D or alt-D, and yet have each copy be a little different is something that many would find very helpful. For example you place trees in a park, using a single model mesh object, and you would then modify each of them one by one, making some a little larger, some smaller, then turning them around their Z axis so they don't look alike. All of this would become automatic.

Cheers,

Patrice.

@Campbell Barton (campbellbarton) is there a plan for the new modifier stack? Will it be released this year? If not, it would be better to offer the solution to work on loose parts as it is now.
If I remember correctly, particle nodes were started in 2011 and we still don't have them. I sincerely that the money from gooseberry will help prevent projects stretching on so many years but as an artist, I see that it's working now, even if from a developer point of view it may not be perfect.
By the way, not everyone has to implement it's own loosepart algorithm, the code was made to be reusable.

Hi,
Just saw the video, very interesting development.
If loose part is the problem, there might be a workaround if the vertex numero can be used:
1/ we select the 'stack depth': the number of stacked modifiers we used.
For example, if we want the modifier to be applied for 2 two last (array) modifiers, just before the noise modifier, the 'stack depth' will be 2.

2/ we count the number of vertices BEFORE the last stack depth' modifiers are applied.
Example: 10 vertices (0 to 9).

3/ we use DIV operation to apply the noise to the vertices:
Example: apply the noise to vertices 0 to 9, then 10 to 19, ...

@Boris Fruhauf (bofzevampire),

I don't think working on loose parts was the actual blocking factor. Determining loose parts is actually pretty fast, and I had implemented caching of loose parts, so it was not a performance issue. The very notion of loose parts may have been a workaround for finding the original object (in most cases) after array modifiers have been applied. But actually loose parts do have a topological meaning of their own, and so it is not strange or dirty to have something act on loose parts. Many people had suggested that other modifiers could benefit from some loose parts setting.

From what I understand, loose parts put aside, the idea is that nothing that adds to modifiers is welcome at the moment.

It is true that it would be great to have more atomic modifiers : one that separates loose parts, and a different one to act on loose parts provided by the first one, and maybe another one doing a 'join' later on. This is the idea of a 'node based modifier', but it does not seem to be in the priorities.

As for what you propose, relying on vertex numbering to find the original object after an array modifier, that seems ugly to me ! There is nothing to say that modifiers will not change vertex numbering, event deform-only modifiers, even though for deform-only it is the case. Still, what about an array modifier, followed by bevel, followed by modifier working on loose parts ?

Is there a chance that this will be accepted into master?

I have applied this against HEAD and found that the rotation and scale failed with Loose parts, it always uses object centre as pivot point. The following patch fixes this for me.

diff --git a/source/blender/modifiers/intern/MOD_displace.c b/source/blender/modifiers/intern/MOD_displace.c
index 8d5c303..3749bbc 100644
--- a/source/blender/modifiers/intern/MOD_displace.c
+++ b/source/blender/modifiers/intern/MOD_displace.c
@@ -323,15 +323,14 @@ void static noise_displace_mesh_part(DisplaceModifierData *dmd, float (*vertexCo
                }
 
                /* Now prepare transform mat4 for this loose part. */
-               /* Since we are going to change the pivot point, we do not want any translation for now! */
-               loc_eul_size_to_mat4(mat, zero_v, rot, scale);
+               loc_eul_size_to_mat4(mat, trans, rot, scale);
                transform_pivot_set_m4(mat, pivot);
        }
        else {
                /* Loose part is affected but only with translation, much simpler. */
                unit_m4(mat);
+               copy_v3_v3(mat[3], trans);
        }
-       copy_v3_v3(mat[3], trans);
 
        for (i = 0; i < vcount; i++) {
                const int iv = vmap ? vmap->indices[i] : i;

Hello Shane,

I'm happy to see one more person interrested.

The answer is No: from what I understand, there is no chance that this will go into master. Which is sad and of course disappointing to me because a lot of work was wasted here, both by myself, and later by Bastien. But mostly it's disappointing because it really filled a need, and as a standalone modifier it is hard to see how it could have had any negative impact.

I have given up contributing to Blender, so I cannot give you feedback on your patch, because I don't have a dev environment ready anymore. I do find the reported bug surprising though, because the development was, at the time, thoroughly tested by many persons and various use-cases. Maybe a side-effect of some change in master ?

Best regards, Patrice ( & Charlie)

I've been eagerly awaiting this for a while so it's very disheartening to hear this isn't going in just because sometime in the future there MAY be a new modifier system. This really fulfills a need now and as you say is a standalone modifier so doesn't seem to be a downside. It would be sooo useful - please reconsider.

In D320#16020, @Patrice Bertrand (PatB) wrote:

The answer is No: from what I understand, there is no chance that this will go into master. Which is sad and of course disappointing to me because a lot of work was wasted here, both by myself, and later by Bastien. But mostly it's disappointing because it really filled a need, and as a standalone modifier it is hard to see how it could have had any negative impact.

I would love to see this in blender as well. Why is a great work from the community not being honored and made compliant to be accepted? And this seems to be from a theoretical hindering reason.
Anyways, can this functionality just be converted into an AddOn? Or must it be maintained then continuously?

It's great work and really fills in a lack of functionality right now.

This is an absolute must have and it will solve many limitations that Blender has now for Motion Graphics. Just to give an example the E3D has very similar system that gives pretty cool results.

Just as Ton says is better a piece code that is not technically perfect but solves a problem than having that problem unsolved (more or less)

@Patrice Bertrand (PatB) I know it can be disheartening to have your work scrapped, you should put this down to an exercise in learning your way around blender's code and find another task to work on, maybe go with modifier nodes ;-)

@Mark Titchener (swmo) - this started as a standalone modifier but was merged into the displace modifier.

@Johannes Thomas Meyer (Samoth)

Anyways, can this functionality just be converted into an AddOn?

There is now an addon in the blender market - Random Object Array, while it isn't free it fills the gap, unless someone else creates a free version as well.

Before this was AMA - The advanced modifier array which added similar randomness only to the array modifier, it was developed after a funding drive so users voted by paying for it's development - that was also scrapped. So two attempts at getting this functionality into the main source code and now an addon has been made to do similar functionality. For reference the addon has had 25 sales in less than a month, the more popular addons have had several months head start to get ahead of it. This should give some indication that this functionality is wanted/needed in blender.

@Shane Ambler (sambler),

It's ok, I did get the re-engineering of the array modifier into the 2.72, so I will have left a tiny little trace into Blender source code.

I'm not disgruntled, and yet I think there is much to be done in order to avoid such huge wastes of energies. Indeed, I'm not the only one who's work was trashed, we see it happening every other day on the developpers' list. I'm not suggesting of course that whatever is proposed should be taken in, no matter the interest or the quality. Obviously, strenious filtering is necessary.

It's not the filtering that is a problem, what's missing is a known and open decision process. For the moment, only the final step of the process is known: the module owner is the one who says Yes or No. That's ok with me, since the product owner is also the one who will have to deal with the proposed feature and its impact on the whole module. It's only natural that he/she can say what is going in.

What is missing, however is an open process starting at earlier stages. Except for the mailing list, and some revision comments, there is no known way of proposing a feature and collect opinions and ideas, then hold an open discussion, with many participating, on how relevant it is, and whether it's worth doing it, and finally reaching a decision that: "if you work on this feature and your code is good, then it will be accepted, so from now on you can start working on it, you are not wasting your time". I don't think that this exists. It is likely that some developpers in an informal inner circle can trust that their work will be accepted or can get assurance from the module owner whom they know well, but first time developpers will have to work for weeks or months, then hope.

This is an important issue really, because what is wasted ultimately is not just the weeks of work that could have made Blender better, what is wasted is far bigger, it is the many contributions, over the many years to come, that these new contributors could have brought had they not been driven away.

Every day, we witness new would-be contributors knocking at the door, asking how they can get into Blender development. Out of these, probably less than one in 5 will ever submit usable code, but they of course must all be welcome because of this one in 5 that will emerge. But the developers that have already passed this 1 in 5 filter and have already shown their ability to submit good enough code, those represent an incredible potential for Blender. It is a small population of developpers that have climbed up the learning curve on their own, have demonstrated they have the IT knowledge, the time and the will to do useful things. Those should be identified better, should be cherished and should feel they matter, should even be called upon to work on new projects.

These are my thoughts on the matter. I hope it starts a fruitful discussion within the Blender community. As for me, I am using my time and energy elsewhere now.

Patrice.

It feels as such a basic feature for me. It's actually quicker for me to open up Max and apply a noise modifier, than to find a noise map, then do the Displace maneuver on the mesh, and then I don't have the flexibility. I can't believe I have to open up a $2500 software for such a basic op. Is there a way to bump this feature request so that it gets more attention from the devs?

In D320#177230, @Steffen Balle (AlphaSilverback) wrote:

It feels as such a basic feature for me. It's actually quicker for me to open up Max and apply a noise modifier, than to find a noise map, then do the Displace maneuver on the mesh, and then I don't have the flexibility. I can't believe I have to open up a $2500 software for such a basic op. Is there a way to bump this feature request so that it gets more attention from the devs?

Actually you have A LOT of flexibility with the displacement modifier, just combine it with a weight edit that uses a texture (that may be neccessary for some effects, similar to what Midge Sinnaeve does often). Its also really fast to setup. If thats too slow for you create a python script to do the job for you (there is some great tutorials by Sybren on the Blender Youtube channel). Also modifiers like this will probably be available (or simple to create) when Modifier Nodes come around.