Mesh generators and objects

[Durman]

2647

The situation is that most of generators don't take parameters on object level. Only parameters of first object are taking in account. It's logically not correct. I can't claim that it is useful for all generators but for some of them it should be. For example line generator I found useful for generation edges. On the picture I tried to recreate edges of NGon but instead got separate edges.

It would be nice to achieve some convention about what is proper way for mesh generation.

[zeffii]

i'm not sure I share the concern. Generators do generally have a 'expected usage scenario', and that's what helps shape how the input handling is implemented. I think convention is difficult to define here, certainly a convention that generalizes without "pain" somewhere.

perhaps what you really want is to separate the output of the NGon before passing it to listshift / line

[zeffii]

[zeffii]

maybe i am not understanding the essence..

[Durman]

Well it will be probably more clear if I will try to explain on real example where I faces with the problem.

In example I generate 4 random polygon each in separate object. I try to split the polygons into several parts by creating extra edges and feeding them into edges to faces node. Edges to faces node requires that all mesh which should be merged should be in one object. I try create extra edges by line node but I can't distribute them between objects properly.

If line generator would work according my description there won't be the problem.))

https://gist.github.com/270a4953d57ce6ddc6d7186775909424

[Durman]

I try to think example why current behavior of generator nodes is unexpected. Imagine function which multiplies any given value on two. For example 10*2 return 20. Which result will be expected if the function get array of values like [1,2,3]. I'm expecting that result will be [2,4,6] but if the function would have generators logic the result will be [[2],[4],[6]].

I think it will be probably fair to have such rules: if a node change given data the node should not change the shape of it; if node change the shape of given data it should not change values of data.

[zeffii]

I think the hard part is to communicate the scheme that the node will use to the end-user, it's not clear to me if there is one desirable way to always enforce the input's effect on the internals, indeed each node is developed with the author's desired behaviour and conveniences in mind. The vectorizing of nodes is tricky business as you've come to appreciate, and you have to make choices.

this is the ugly side of wrapping algorithms with UI's , we make choices that determine how complicated the user experience will be. If we didn't allow Vectorization of generators, that would also be a choice that some end users (including myself) would soon wish to develop a solution for.

[Durman]

I actually does not see nothing complicated in vectorizing generator nodes.

The generators can be compared with primitive meshes of Blender like plane, box or circle. In Blender we can add them to existing objects or generate new objects for them. In this manner generators should work and in Sverchok.

If we put one value to any parameter it cause generation of primitive.

If several values will be put into one parameters all other parameters will be filled with default values and several primitives will be generated in one object.

If You have the need in generation each primitive in different object just split your values into different objects in Sverchok according Sverchok data structure.

Is it too complicated? If yes then probably we should to think how to change our data structure (if such change is possible at all) for simplification of the process.

[Durman]

I think I know why we have this situation with generators nodes. Let's consider box generator node.

Why it can't create multiple boxes in one object as and other generators? Because it does not have any sense. Sverchok does not even have tools for moving generated boxes in this way.

Second factor is that generate bunch of values like this [[0,1,2,3]] is easier then like this [[0],[1],[2],[3]].

So, if there is no need in generation multiple primitives inside one object the most simple solution is to take in accoun only values of first object and igonre others [[0,1,2],~[3,4,5],[6,7,8]]~. This approach is inconsistent with other vectorized nodes.

[Durman]

Option which can switch node behavior between generation mesh in one mesh or separate is most convenient at least for now. But as practice shows on example of line generator adding such option can be quite painful process.

[nortikin]

I think I know why we have this situation with generators nodes. Let's consider box generator node.

Why it can't create multiple boxes in one object as and other generators? Because it does not have any sense. Sverchok does not even have tools for moving generated boxes in this way.

Second factor is that generate bunch of values like this [[0,1,2,3]] is easier then like this [[0],[1],[2],[3]].

So, if there is no need in generation multiple primitives inside one object the most simple solution is to take in accoun only values of first object and igonre others [[0,1,2],~[3,4,5],[6,7,8]]~. This approach is inconsistent with other vectorized nodes.

initially, i proposed we can use nested data, so subgroup in one object can be handled for transformations. but my approach seems to be failed (not in uvconnect and scale/move anyway, they can handle)