"Kick" only when the current tile is renderable #1042
Conversation
Unless the loadingDescendantLimit is exceeded.
|
I've fixed the test failures and this is ready for review now. |
|
|
||
| // root's children don't have content loading right now, so only root get | ||
| // rendered | ||
| // root's child is done loading and rendered, too. |
There was a problem hiding this comment.
| // root's child is done loading and rendered, too. | |
| // root's children are done loading and rendered, too. |
There was a problem hiding this comment.
There's only one in this case though, right?
There was a problem hiding this comment.
Oh sorry, I got confused by the lines below this (REQUIRE(parentB3DM.getChildren().size() == 4);) and thought the comment was referring to this check. Nevermind 🙂
| // 1st frame. Root, its child, and its four grandchildren will all be | ||
| // rendered because they meet SSE, even though they're not loaded yet. |
There was a problem hiding this comment.
I see "render" getting used even when tiles aren't loaded in yet -- would it be more accurate to say tiles get "selected" vs. "rendered"?
Though, it seems like this verbiage is built into the API already (tilesToRenderThisFrame), so maybe it's better to stick with "render". But I hope our documentation clarifies that render ~= selection, and render != content show up on screen 🙂
There was a problem hiding this comment.
Yeah this is a good point. It's a bit of a quirk of this whole system. Arguably, tiles that are not renderable should never be selected/rendered, in general. That would make sense, and be least likely to surprise people. My thought process when I went the other way was that - just maybe! - it could be useful to know which tiles would be rendered if they were loaded. For example, maybe you could render a grey cloudy thing in the space of their bounding box, and that would be better than a hole.
So whether this is a good idea or not, Cesium Native currently refers to selection as "rendering", and the rendered tiles aren't necessarily actually renderable. Changing this might be an excellent idea, but I think it's outside the scope of this PR.
There was a problem hiding this comment.
But I hope our documentation clarifies that render ~= selection, and render != content show up on screen
I think it probably makes that apparent, but doesn't say so explicitly.
Co-authored-by: Janine Liu <[email protected]>
Co-authored-by: Janine Liu <[email protected]>
Co-authored-by: Janine Liu <[email protected]>
|
Thanks @j9liu! I think I've addressed your comments, or at least responded to them. |
|
Thanks @kring ! |
This is a PR into #1032 so merge that first.
Fixes #1033
This is a draft because they are some test failures. I think it's just tests asserting conditions that are purposely changed here, but I need to think through it more thoroughly.