As seen in attached patch, memory never goes down after it has been up.
For repro, set Levels to 11 (~850MB) and then back to 4.
Sierpinski.vl (41.6 KB)
1 Like
kudos for the patch!
hehe, thanks.
regarding the recursive patching, i have to say, it also produces massive memory leaks in my brain. it’s kind of crazy to see pins of recursive nodes appear and disappear all the time while patching. btw. reordering pins in that patch also seems to confuse the hde.
i totally don’t get how to accumulate over such a recursive structure. i tried several approaches, but no success at all…
patching challenge:
modify the following patch, so that the SirepinskiTriangle only outputs the 729 selected triangles from the last iteration and the select is unnecessary.
SierpinskiChallenge.vl (52.8 KB)
you could pass a state/context object to the recursive calls and read/write to it.
SierpinskiChallenge_with_Context.vl (58.1 KB)
1 Like
here is another way to model the recursive structure. I left some comments, but there might be more elegant ways to model it or more to discuss about this approach. So let’s do that here and not in the patch. Sierpinski 2.vl (97.8 KB)
1 Like
yes, that way you have a proper tree structure data type, but building the tree is about 25x slower than sebls approach. i wonder what makes it so slow and whether it can be improved.
having a look at IReadOnlyTree…
is it enough to just implement the interface? no methods needed to override?
the visual representation of interfaces could or should be improved to my liking.
again, some filtering on the iteration, but with @gregsn s approach.
the composition/traverse approach is easy extendable i have to say. so, once such a structure is set up, it makes it easy to extend. CompositionIterationLayer was done in a minute, but i couldn’t figure out how to do it with GetIterationLayer in the datatype.
SierpinskiTree.vl (139.9 KB)
hey!
I found a way how to do the GetIterationLayer in the type, but there are maybe better ways to do it, as it currently builds a deeply nested structure of groups of layers. Currently, we output a one layer, but we could probably also output several (and do one spectral group outside), or we output the corners, as you did in your first patch and build some skia path out of it. So there are just too many options. :D
Regarding IReadOnlyTree. I can see that this is very confusing. Some nodes are in the category IReadOnlyTree, but they are not part of the interface, they are just working with the interface. That needs to be cleaned up on the treenode library API side or we need to visualize better what is part of the interface and what not. So here is what you have to implement: one operation called Children that outputs Children of type MyType, which is something you typically have anyways.
Note: These interfaces allow to traverse any custom implementation of the interface and those were crafted as a workaround as it wasn’t possible to do recursive calls otherwise. It’s nice to see that sometimes those still are of some use. The big difference basically is that you don’t have to encode the traversing over and over again in each of your instance operations by calling yourself, but you can just implement Children, IsHit or GetLayer and do everything else outside. Outside you can now traverse the structure in a depth first or breadth first manner depending on your use case. The data type doesn’t need to know how you want to traverse it.
SierpinskiTree.vl (137.0 KB)
nice, thanks!
that could be the variant with groupspectral:
looks a bit faster, but i didn’t compare it.
that would be great. also in patched interfaced, it is sometimes not ideal to grasp. for example in- and outboxes loo same and one has to hover them to see if it’s in or out.
even more offtopic on interfaces:
as i’ve read it, there’s now the possibility to create default implementations for interfaces (from c#8 on). i have the feeling, that this could be embraced by vl!
like so:
- interfaces must have a default implementation
- so, there’s a lot of cases, where as patcher you mustn’t do anything but add interface in topleft menu
- as a bonus, interfaces and how to use them will be much more readable when having a look at the patch
ofcourse lot of questions would arise then. like how does the default interface for the Children of IReadOnlyTree look like? maybe just a generic default node connected to an output called Children? i certainly didn’t think this through, but could imagine nice uses :)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.