Skip to content
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

Merged
merged 38 commits into from
Jul 14, 2016
Merged

[wip] Tile label placement #749

merged 38 commits into from
Jul 14, 2016

Conversation

hjanetzek
Copy link
Member

@hjanetzek hjanetzek commented May 24, 2016

Determine initial label placement during tile generation.

shot-2016-06-03_15-32-00
Positions tested during initial placements (discarded labels in purple)

shot-2016-06-03_15-31-50
All labels in final tiles

TODO:

  • Improve line-label candidate positions

@hjanetzek hjanetzek force-pushed the tile-label-placement branch 4 times, most recently from 48106bd to 5945236 Compare May 27, 2016 12:47
@hjanetzek hjanetzek force-pushed the tile-label-placement branch 9 times, most recently from b565b48 to 78dc184 Compare June 6, 2016 10:38
@karimnaaji
Copy link
Member

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()) {
Copy link
Member

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.

Copy link
Member Author

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.

@@ -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) {
Copy link
Member

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.

@hjanetzek hjanetzek force-pushed the tile-label-placement branch 2 times, most recently from e438ec3 to 483e2dd Compare June 23, 2016 15:32
@karimnaaji karimnaaji mentioned this pull request Jun 24, 2016
1 task
@hjanetzek hjanetzek force-pushed the tile-label-placement branch 2 times, most recently from e40e1ce to 19bbcce Compare July 12, 2016 13:44
@karimnaaji karimnaaji self-assigned this Jul 12, 2016

void SpriteLabel::align(glm::vec2& _screenPosition, const glm::vec2& _ap1, const glm::vec2& _ap2) {
if (m_occludedLastFrame) { dim += 2; }
Copy link
Member

Choose a reason for hiding this comment

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

Is that for debug?

Copy link
Member Author

@hjanetzek hjanetzek Jul 13, 2016

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

Copy link
Member

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.

@hjanetzek hjanetzek force-pushed the tile-label-placement branch 2 times, most recently from 2e03461 to a3f7c6c Compare July 13, 2016 14:43
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
@matteblair
Copy link
Member

Seems like a good time to consider merging this - it's lingered for a long time now.

@karimnaaji
Copy link
Member

@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.

@hjanetzek
Copy link
Member Author

yeah, ready to merge.

♫just wait-ing for travis♫

@matteblair
Copy link
Member

LGTM 👍

@hjanetzek hjanetzek merged commit 14d8d52 into master Jul 14, 2016
@karimnaaji karimnaaji deleted the tile-label-placement branch July 14, 2016 14:09
rot += M_PI;
} else {
std::swap(p1, p2);
if (_testVisibility && length < minLength) {
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

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.

4 participants