LineBuffered spreaded problem

here again with some bin size problem. At least this is what I think it is.

It’s quite simple patch for visualize connections between two set: select a point on the slider, press the button and some connections are displayed with a number of lines. Once showed, I need to keep memory of the last x number of connections made and make them fade in time.
My problem is, the connection stored are not displayed correctly on the screen. Even if my numbers seems to be right, the lines stored are displayed wrong and I don’t get what the problem in my thinking is.

I’ve attached the patch with some comments to better explain. (8.8 KB)

Don’t think there is binsize on that patch
Maybe try to add zero size line in between

@antokhio what do you mean by there’s no binsize?
Also, without a binsize how am I supposed to get the distinction between each groups of lines? Because I need to make them disappear by group not Individually

The LineBuffered is binsized actually. I had a very quick look at your patch and I’m pretty sure you have some issues with the logic upstream. But maybe try to simplify + clarify your problem a bit. Maybe you’ll get lucky and someone will want to debug it as is for you, but woudln’t count on it…

Hey, @everyoneishappy well, to put it simple, my main problem is: the group of lines that I store with the queue node are not displayed (or grouped) in the correct order by LineBuffered.
This is my main concern.
In my patch I create the binsize by multiplying, with select node, the number of segment that compose a single line by the number of lines that I have stored, divided into groups. I think this is a pretty logic way to do it but apparently I’m wrong. I’m not waiting for others to solve the problem, as I can find other ways to somehow do the work, I just really want to understand what is the correct way to solve this.

I’ve tried other solutions and I found a constant number which works when used to do the afore mentioned operation, but I don’t see any correlation between this number and my math so far.

I’ve also found out that this problem doesn’t occur with the standard LineDX11 node, which confuses me even more.

I modified the previous patch with other examples, you can switch between the standard Line and the buffered version to see what my problem is. (9.3 KB)

Does this help? (10.4 KB)

@everyoneishappy this definitely solve the problem of showing the right number of lines, but I think it doesn’t solve the problem of repetition and overlap of lines, am I right?
Because giving the lines an alpha it seems to me that some of them remain darker, meaning that they are overlapped. Maybe is my screen maybe I’m hallucinating because of too many lines, there are other ways to debug this?
Anyway, thank you for your time and help!

You can try dissble drpthbuffer, youll see libes in order drawen

@ectrome yes you are quite right. It just means that you now have the same logic going to the Line and LineBuffered now. For what’s going in to that I can only suggest to simplify. Not just as a communication thing, but best way to troubleshoot yourself.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.