-
Notifications
You must be signed in to change notification settings - Fork 240
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
[wip] Tile label placement #749
Conversation
48106bd
to
5945236
Compare
b565b48
to
78dc184
Compare
Starting to look over the details of this, looks really good so far! |
|
||
// Note: This causes non-deterministic placement, i.e. depending on | ||
// navigation history. | ||
if (l1->occludedLastFrame() != l2->occludedLastFrame()) { |
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.
Is this needed as a sorting rule? So we base the sorting only on things not related to label state.
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's not 'needed' to do this. It's a matter of preference of less flickering vs having always the same set of labels shown for a viewport - This is the behavior we had before so I kept it and added the Note.
4e091ed
to
e48a48f
Compare
@@ -169,187 +174,135 @@ void Labels::skipTransitions(const std::vector<std::unique_ptr<Style>>& _styles, | |||
} | |||
} | |||
|
|||
void Labels::checkRepeatGroups(std::vector<Label*>& _visibleSet) const { | |||
bool Labels::labelComparator(const LabelEntry& _a, const LabelEntry& _b) { |
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.
As the discussion we had in the meeting, we could use the depth (ground distance from camera, or perspective factor already available when projecting to screen) to sort labels within the same priority level.
Probably to consider out of this PR.
e438ec3
to
483e2dd
Compare
e40e1ce
to
19bbcce
Compare
|
||
void SpriteLabel::align(glm::vec2& _screenPosition, const glm::vec2& _ap1, const glm::vec2& _ap2) { | ||
if (m_occludedLastFrame) { dim += 2; } |
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.
Is that for debug?
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.
This should reduce flickering. The idea was to increase the OBB of occluded labels so that they can only become active when there is some buffer to other labels and thereby are less likely to get occluded again immediately by minimal map movements. - Yes, needs a comment and the value should have a name.
ef535cb
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.
I see, it's a good idea but I think this value should also be scaled by the pixel scale.
2e03461
to
a3f7c6c
Compare
was exp: ignore out_of_screen labels - this caused way too many labels in isect2d buckets
- having it inlined should give the compiler some options to optimize - todo: test if compiler is smart enough to omit 2 divisions
a3f7c6c
to
d70dbc5
Compare
Seems like a good time to consider merging this - it's lingered for a long time now. |
@blair1618 yes we talked about merging this yesterday and I did a last review, it seems ready to go to me if @hjanetzek doesn't have any blockers on it. |
yeah, ready to merge. ♫just wait-ing for travis♫ |
LGTM 👍 |
- major speedup compared to collecting all possible collisions first
- allows easier perf tracing for each phase
squashed: tweak: connect up to four line segments squash: line labels candidates
- add Scene::m_pixelScale member
d70dbc5
to
51c484d
Compare
rot += M_PI; | ||
} else { | ||
std::swap(p1, p2); | ||
if (_testVisibility && length < minLength) { |
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.
No need to test _testVisibility
here, already done above.
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.
The name _testVisibility may not be the best choice. It is used to return false and return early when the label is not renderable. In this case when the line segment is too short for the label.
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.
Ohh I just mean, to do if (length < minLength)
. _testVisibility
must be true
here before of if (_testVisibility && clipped)
check before.
Determine initial label placement during tile generation.
Positions tested during initial placements (discarded labels in purple)
All labels in final tiles
TODO: