-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
boost lane marker hovering #626
boost lane marker hovering #626
Conversation
removed unnecessary setter for SubTool.Hovered*Id tested and works
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't fix anything regards raycasting, it makes marker selection weird in some cases, not to mention it makes detection a bit slower (~40-50%)
- before:
Benchmark#MaybeCreateBenchmark#DetermineHoveredElements: avg. 0.06269605ms
- after:
Benchmark#MaybeCreateBenchmark#DetermineHoveredElements: avg. 0.09171094ms
Benchmark#MaybeCreateBenchmark#DetermineHoveredElements: avg. 0.1039268ms
There was a rendering issue and there was a raycasting issue. I changed the raycasting to use all the lane area rather than only marker. I have a feeling that when you say fix raycasting you mean something else.
Yeah I was worried about the performance. other pull requests I created reduce performance even more. There are ways to increase performance but should I? I mean 0.1ms is not much is it? If it is then we should create an issue and I can work on some ideas I have. |
This is really bad with bridges. I need to fix this. |
Lane marker raycast should not target the ground level but the road plane, at the height where the marker is located. Then it will always look correct, at any height on or under any bridge. If that is done, then also render depth can be reduced to only cover range from slightly under the road level to slightly above the tallest car or train-car level. |
|
what is the expected behavior?
|
This still doesn't work when there is a bridge passing over selected markers. |
testing... |
Overall I like where this is heading; when it works, it works really well - much easier to pick and place the connector lines. However, there are still some issues. You're probably aware of these, but I'll go through each one I found just in case... Roads under bridges are cumbersome to work with
Tunnels are also cumbersome to work with
Road bridges can be cubersome to work with
Rail bridges are more cumbersome to work with
Nodeless junctions make some markers inaccessible
Things I didn't test:
|
I liked the premise of the idea; in the places where it worked, it worked really well and made it easier to interact with the lane markers; sadly it just made other places much more difficult. |
fixes #625
added
DetermineHoveredLane()
toDetermineHoveredElements()
. Then I use this to find the correct lane marker.declared
HoveredLaneID
inTrafficMangerTool
andSubTool
.Additionally I took the opportunity and removed setters from
SubTool.HoveredNodeID
andSubTool.HoveredSegmentID
. Such setters are unused, unnecessary and using them can cause bugs.