Seve - @0hmx RE: Schematic Trace Avoiding Net L...
@0hmx RE: Schematic Trace Avoiding Net Labels
33 Replies
Your approach is good, but it still looks bad, to achieve this result you may be able to apply a post-processing step where you run a "simplification" on the traces. e.g. you can see the first bend is unnecessary, so you could identify unnnecessary bends
Alternatively, i do think an alternate approach is possible that extends the first segment beyond the netlabel, the calls out to calculate-elbow to draw to the next desired point. This would solve the issue perfectly without hacks I think
GitHub
Prevent schematic traces from being drawn through net labels by 0hm...
ref: #1264
introduce a new solver that will run at the end and adjust the labels
Added post-processing logic to remove the extra points
this is much better, but i think your post processing logic could catch this, there's this sort of unnecessary bend that you can probably detect and remove
same for this one, i've also annotated this one to show the optimal layout,
it is good though, i like that you're adding lots of cases
will need one more filter + fix to the currnet one! its should be good then
yes- btw RE: that second point. You may find that if you use calculate-elbow from point 1 to point 2 that it creates the optimal path, so that might be worth exploring
whenever changing paths you also have to do a confirmation that it doesn't run through any obstacles ofc
GitHub
Prevent schematic traces from being drawn through net labels by 0hm...
ref: #1264
introduce a new solver that will run at the end and adjust the labels
made an function that will make a perfect Z shape even on both ends!
@Seve This is not a regression; the label is making a 90-degree turn! Look at the original image; it was having a diagonal, due to my cleanup logic to have a minimal number of segments; it removes the point that was making the diagonal (not a special logic to remove diagonal, but luck), which caused it to look like that! the labels padding logic is skiped for the labels that are attached to the current line! Or else we could have cases where the labels block the exit path and such
it's not a regression from the main branch, what i'm saying is that when i reviewed your code in the past IIRC you had a better version where the trace was spaced further from the bottom net label. But it's not a big deal
i could be wrong, let's ignore it
although this is a problem right? There's a new net label overlap due to the trace movement, we may need to recompute netlabels that have overlap...
This is also because of the same logic! This is the original label of the second path, because of which the collision is disabled! I guess we could figure something out!
i think after your new solver moves a trace, it could run the SingleNetLabelPlacementSolver to re-solve for the net label position. That might not be too difficult?
GitHub
schematic-trace-solver/lib/solvers/NetLabelPlacementSolver/SingleNe...
A schematic trace routing and net label placement algorithm with Minimum Spanning Tree - tscircuit/schematic-trace-solver
yes look good will give it a try
btw RE: the output function, let's do
getOutput(): { traceMap, netLabelPlacements } ? That way we have one function that returns all the latest
cheers thanksThe results are much better with the rerun
GitHub
Prevent schematic traces from being drawn through net labels by 0hm...
ref: #1264
introduce a new solver that will run at the end and adjust the labels
awesome
@Seve I am on the latest of core/main, and I am running the bun test. I am seeing the following test fail by default
is this normal?
it's passing on CI, sometimes the CI is more reliable than local testing, so if you only have a few errors you can try pushing up
The coordinates are getting messed up. Examine the location of labels and their positions; there are numerous unwanted shifts occurring. Going to work on this next. Any ideas?
Here is what I can see - The size of the labels/ the area they take is much, much more than what we expected - The size of the chips is also not correct Most of the problems are occurring because our last PR did not solve much. Only 4 tests broke in the core, which is lower because there are a lot of overlaps in other tests,so I expected them to break! Not updating the core for now
Here is what I can see - The size of the labels/ the area they take is much, much more than what we expected - The size of the chips is also not correct Most of the problems are occurring because our last PR did not solve much. Only 4 tests broke in the core, which is lower because there are a lot of overlaps in other tests,so I expected them to break! Not updating the core for now
Can you open a pr with the snapshots updated? It will help me visually see the differences
Maybe the net label sizing is wrong in the input- you should use DEBUG=Group_doInitialSchematicTraceRender bun test path/to/test.ts to try to get the relevant input problem json files for debugging
The good news is there isn’t a major regression, but also no fixes :/
yes this also made me sad
will do it! have to get the dimension rights, the core and solver looks very diffrent
This guide on getting input for algorithms can help you https://github.com/tscircuit/core/blob/main/docs/DEVELOPMENT.md#getting-inputs-for-algorithms
GitHub
core/docs/DEVELOPMENT.md at main · tscircuit/core
Create electronics with Typescript and React. Compile Typescript to Circuit JSON - tscircuit/core
Yes may be a core issue with dimensions
There are two kinds of label solvers in the core
applyNetLabelPlacements (this one processes the labels from the solver output) and insertNetLabelsForPortsMissingTrace. I am not sure why we need this, but this is the one that is drawing labels that are overlapping our line segments
These are in lib/components/primitive-components/Group/Group_doInitialSchematicTraceRender/insertNetLabelsForPortsMissingTrace.ts file in core. My idea is to just try to pass this 2nd type also into the solver; This will mean we will add some new item in InputProblem.
I will drop this @Seve I am 100% the problem is with us running insertNetLabelsForMissingTrace which creates labels outside of Solver pipeline, but there is not good solution to moving this step into the solver itself which is also the only solution.👋 sorry just reading this...
Oh interesting, yes we could move it into the solver i think... yes lots of work though 😭
yea generally core really shouldn't be doing any kind of placement logic ideally