[BUG] Object Instancer does not work correctly with For Loop

[mifth]

Problem statement

Object Instancer does not work correctly with For Loop nodes. I've got only one Suzanne but there must be 10 copies.

My file: tmp1.zip

Steps to reproduce

Open my file

Master branch.

[mifth]

As I can assume that all instances have the same name. Maybe that's a problem?

[Durman]

Using viewer nodes inside loops is similar to using print functions like in this example: Print function does not generate new string during each loop but rewrites the same one. The same viewer nodes do.

But you can just generate list of matrixes and Object instanser will be able to generate objects for all of them.

[mifth]

Thanks for the reply. But I think this limits creativity. As a user I expect to use objects and instances inside of loops like I do it in houdini and animation nodes. Is it possible to improve?

[Durman]

Can you show how it looks in AN or Houdini?

[mifth]

I was wrong. It's not possible to create an object in AN inside of a loop. It will write error.

In houdini I do it like this. I pack geometry. It's like in GN.

If you feel that it's not possible to add such a feature then we can close it. Thanks.

[vicdoval]

Maybe you are using the Loop nodes 'too much'?, I mean usually the Sverchok nodes are can handle many object simultaneously

In this example you do the same as the one you present in the thread but there is no need for loop nodes at all:

The Loop nodes are meant for complex cases, that why they have some particular behaviours

[mifth]

I came from houdini. In houdini i even don't think about it. I can do any operation in any loop.

And i don't think that objects creation is such a complex thing especially in one loop.

[mifth]

I believe that any modern procedural system should have no limitations for creativity.

[mifth]

I did that report as I already had a case where I wanted to create objects in a loop. I had 3 loops.

Sure I had to rework my idea and I put objects creation behind the loops but I was very sad about this.

[vicdoval]

I believe that any modern procedural system should have no limitations for creativity.

I agree, I mean that every program has it own ways and in most of the cases you wont need the loop nodes

[mifth]

I believe that any modern procedural system should have no limitations for creativity.

I agree, I mean that every program has it own ways and in most of the cases you wont need the loop nodes

It depends on a tesk. In game development i oftenly have to use loops. For example, i got an input of objects from the engine. I parse all objects(1 loop), then i need to parse every uv shell and do some manipulations with it (2 loop), etc.

Loops are commonly used in gamedev and vfx as much data needs to be parsed.

[vicdoval]

Loops are all around, in Sverchok in every node there is a for-loop.

But if you can avoid the 'Loop nodes' your nodetree will also be faster Check this example: The output is the same, in one case 800 miliseconds and in the other 33

[Durman]

I've checked Houdini loops and they works the same if a viewer node is inside loop.

[mifth]

I've checked Houdini loops and they works the same if a viewer node is inside loop.

You can change settings in the foreach-begin node as far as i remember

[mifth]

Loops are all around, in Sverchok in every node there is a for-loop.

But if you can avoid the 'Loop nodes' your nodetree will also be faster Check this example: The output is the same, in one case 800 miliseconds and in the other 33

Yes, there is sense of using less for loops. In c++ there would be not such a big difference i think.

[mifth]

I've checked Houdini loops and they works the same if a viewer node is inside loop.

I also used hscript in the transform node to transform each piece. Hscript looked like this: detail('./foreach_count', iteration'', 0)

That was related to the node on the right

[zeffii]

@mifth it might help to accept that Sverchok does not intend to emulate any other node-system. We don't come from Houdini as users. We therefor aren't privileged or limited by its conventions. We established our own ways of thinking about iterations and loops to address our common goals.

The example offered by @vicdoval is typical of how we take care of iteration. It's a different approach than you are used to, We implement loops inside a node to save ourselves from having to construct explicit loops in the tree.

I had to rework my idea and I put objects creation behind the loops but I was very sad about this.

maybe if you can describe such a scenario, offer a demo blend with the objects and the uvs - it may be possible to show you how to construct a tree "our way". Maybe we learn, maybe you learn. Don't be sad, there is too much bullshit on earth.

[mifth]

@zeffii thank you for answering. I don't compare Sverchok with other system. I'm looking at it as a procedural system. I don't want to make bulling or make you hurt I just point out the issue of proceduralism.

Let's answer some questions:

• Is it nice to use any node inside of a loop and outside of a loop to have full proceduralism without limits? -> Yes.
• Is it hard to add this feature?
• Do you agree to add this feature?

[zeffii]

I appreciate that you are accustomed to thinking a certain way about proceduralism. you have a framework in your mind. We all have a framework.. a map. The question is, is that framework immutable/adaptive. Will you spend time with the way we have evolved sverchok as a procedural tool in its own right?

Sverchok happens to be powered a lot by implicit loops, can you give a concrete example of where our implicit loops / vectorizations actively impede creativity? Over the 8+ years i've been doing this i've seen a lot of questions devolve into this form

• User: help i am trying to do this but it's not working
• Dev: what are your goals, describe what you have and what you want to turn it into, then i can judge if your current approach is suitable for our tool
• User: this is what i want to achieve
• Dev: then no, we have a different approach to that. it might be easier a different way.

Often our solutions to problems are guided by Blender limitations, and current Sverchok limitations - but often also by conveniences that we've evolved over time. Doesn't mean we are infallible, but currently we consider nodes like the Object Viewer nodes as "nodes with sideffects", and the convention is to keep such nodes outside of explicit loops. This is because ultimately we treat explicit loops as a construct that produces final values. Like each iteration of the loop appends a different matrix to the output of a loop-out node, all you eventually want is the list of matrices to use further downstream of the loop.

concrete examples are important.

[mifth]

Thank you such an answer. But there is no limitation in blender to create an object with python, right? I created objects with python million times and it's easy as 123. I assume this is the Devs convention.

Also, you did not answer the questions above. )

Sure if you don't want to add this feature or you see no sense in it I will not argue with you. But as a user I see only benefits from it.

[Durman]

As to me it's not clear what is the proposal exactly? Should the instancer node generate new mesh each time it is called? I don't think so otherwise the scene will be flooded with object copies.

[mifth]

As to me it's not clear what is the proposal exactly? Should the instancer node generate new mesh each time it is called? I don't think so otherwise the scene will be flooded with object copies.

My proposal is simple. Yeah, just a possibility to add objects inside of a loop like we can add primitives.

[Durman]

I don't think this is just about adding objects. If so it would be quite simple to implement but the result would be satisfying only after first call. Second call would work the same as previous one and it would add 10 copies of objects (if loop has 10 iterations) but the previous copies will remain to be in the scene.

A node with such functionality could not be called a viewer. The proper name would be Object generator I think. And I don't see too much sence in having such node. It will pollute a scene with objects quite rapidly.

[mifth]

That's the point to populate objects.

Sure it's possible to do after all loops using matrices as @zeffii stated. But it would be nice to have no limits.

[portnov]

Let's start with example of nodes setup which requires loop-nodes and can not be reproduced without them. Then we can discuss, how much efforts it would take to lift a limitation in this case and will the result worth this effort.

[mifth]

It could be any generic example. Parse lots of meshes, parse UV shells, parse anything complicated which is composed of pieces.

[portnov]

For "any generic example", we can show you a number of examples which are possible without loop-nodes...

[portnov]

Although there are cases when loop-nodes are necessary:

• applying some procedure to objects repeatedly: apply nodes, then apply nodes to the result, and so on
• vectorizing of nodes that are not vectorized by themeselves for some reason (although it's usually a bug)
• creating a list of objects with nesting level more than 2