Skip to content

Prevent schematic traces from being drawn through net labels#60

Merged
seveibar merged 12 commits intotscircuit:mainfrom
0hmX:net-labels
Sep 16, 2025
Merged

Prevent schematic traces from being drawn through net labels#60
seveibar merged 12 commits intotscircuit:mainfrom
0hmX:net-labels

Conversation

@0hmX
Copy link
Copy Markdown
Contributor

@0hmX 0hmX commented Sep 12, 2025

ref: #1264

introduce a new solver that will run at the end and adjust the labels

@vercel
Copy link
Copy Markdown

vercel bot commented Sep 12, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
schematic-trace-solver Ready Ready Preview Comment Sep 16, 2025 0:11am

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idk this seems a bit weird, both the traces are overlapping on the same trace to avoid the collision which is incorrect.

cc @seveibar

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@imrishabh18 Please take a look at the new exmaple16.snap.svg file! I have added logic to handle the overlap! If its good, please mark this conversation as resolved!

Here is how it looks after the new update in logic
image

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc: @seveibar

Copy link
Copy Markdown
Contributor

@seveibar seveibar Sep 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still pretty messy, it's not helping that one of the traces is invalid (diagonal, not your fault but makes evaluating this annoying)

The thing about schematic lines is they're supposed to be readably separated, but the tight wrapping around the net labels makes it hard to read

image

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will work right!

example16 snap

@@ -809,7 +809,7 @@ y-" data-x="-2.025" data-y="-2.7" cx="318.5204755614267" cy="526.0237780713342"
<polyline data-points="-1.1099999999999999,2.600000000000002 -1.3099999999999998,2.600000000000002 -1.3099999999999998,2.8000000000000016 -1.1099999999999999,2.8000000000000016" data-type="line" data-label="" points="363.6459709379128,264.64112725671504 353.7824746807574,264.64112725671504 353.7824746807574,254.77763099955962 363.6459709379128,254.77763099955962" fill="none" stroke="purple" stroke-width="1" />
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea this isn't the right answer, it looks weird

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0hmX do you see the bug here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bug is because of the bun!

I added logs to every line! And for some reason, createElbow returns different amounts of segments! and some checks which get marked as false in browser (both chorm and firefox) is marked as true in bun!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it may be a floating point issue- you may be able to copy the input and reproduce in calculate-elbow https://github.com/tscircuit/calculate-elbow

I've never really seen a bun specific issue that didn't occur on the browser, maybe the example15 test input differs from the page input? I'm not sure, but I would try to get this reproduced in the browser as well-

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have opened an issues for this tscircuit/calculate-elbow#15 for now! will keep working on this

Copy link
Copy Markdown
Contributor

@seveibar seveibar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, some of the examples look pretty good but others have major problems, we don't want to have any regressions, especially because other people won't be as good at debugging this code

one thing i would say, try to git checkout origin/main -- all the snap.svg files and regenerate so we're only seeing changed files

@seveibar
Copy link
Copy Markdown
Contributor

@0hmX it's a very good attempt, the best so far, could probably be accepted if you find a way to improve the two examples we're commenting on here

/tip $50

@algora-pbc
Copy link
Copy Markdown

algora-pbc bot commented Sep 12, 2025

Please visit Algora to complete your tip via Stripe.

@algora-pbc
Copy link
Copy Markdown

algora-pbc bot commented Sep 12, 2025

🎉🎈 @0hmX has been awarded $50 by tscircuit! 🎈🎊

@0hmX
Copy link
Copy Markdown
Contributor Author

0hmX commented Sep 15, 2025

  • Added new logic to make the turn smoother!
  • More padding so more clean

example16 snap

example25 snap

@@ -0,0 +1,157 @@
<svg width="640" height="640" viewBox="0 0 640 640" xmlns="http://www.w3.org/2000/svg">
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the behavior of this snapshot is a regression i believe, calculate-elbow shouldn't generate a path like this

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is! I totally ignored it!

@@ -0,0 +1,25 @@
import type { Point } from "@tscircuit/math-utils"

export const findTraceViolationZone = (
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rename file to match function name

@@ -66,10 +66,10 @@ x-" data-x="1.6" data-y="1.7049999999999998" cx="353.6" cy="230.12" r="3" fill="
<polyline data-points="1.2000000000000002,0.30000000000000004 1.6,2.105" data-type="line" data-label="" points="308.80000000000007,387.47999999999996 353.6,185.32" fill="none" stroke="hsl(190, 100%, 50%, 0.8)" stroke-width="1" stroke-dasharray="4 2" />
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new regression from last review, there is now no margin between the net label and the trace

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not 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!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok we can go with it, but what i'm saying is that in one of my reviews the behavior was better, it's an improvement from the main branch however

Copy link
Copy Markdown
Contributor

@seveibar seveibar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's one regression and some minor code quality stuff, we're very close

instance.netLabelPlacementSolver
) {
const { netLabelPlacements } =
instance.traceLabelOverlapAvoidanceSolver.getOutput()
Copy link
Copy Markdown
Contributor

@seveibar seveibar Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getOutput is supposed to be on the SchematicTracePipelineSolver, although you can keep the function on the traceLabelOverlapAvoidanceSolver solver. But it's VERY IMPORTANT that users just do solver.solve() and solver.getOutput() where the solver is the SchematicTracePipelineSolver

Copy link
Copy Markdown
Contributor

@seveibar seveibar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can do the getOutput() for SchematicTraceSolver in the next PR, this is good enough to merge

@seveibar
Copy link
Copy Markdown
Contributor

/tip $25 don't forget to update to add getOutput() to the main pipeline solver as per my comment

@seveibar seveibar merged commit 6cbd97a into tscircuit:main Sep 16, 2025
5 checks passed
@algora-pbc
Copy link
Copy Markdown

algora-pbc bot commented Sep 16, 2025

🎉🎈 @0hmX has been awarded $25 by tscircuit! 🎈🎊

@algora-pbc
Copy link
Copy Markdown

algora-pbc bot commented Sep 16, 2025

Please visit Algora to complete your tip via Stripe.

@0hmX 0hmX mentioned this pull request Sep 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants