-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Added PointGeometry and PointAppearance #3203
Conversation
Primitive, | ||
createScene) { | ||
"use strict"; | ||
/*global jasmine,describe,xdescribe,it,xit,expect,beforeEach,afterEach,beforeAll,afterAll,spyOn*/ |
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 is no longer needed once you merge in master, delete this line.
I know 3D Tiles is the ultimate answer, but is there a reason we are keeping |
Yes, because we are still working on the points 3D Tiles format and we don't want to have a breaking change if we need to add a fast path. This will become public when ready. |
Thanks, this is useful cleanup. It is fine where it is, but it can't be public as is since it takes a |
That makes sense, thanks for the clarification. We might want to use this eventually for static Entity points as well. |
👍. It will scream compared to the current point collection. |
@@ -0,0 +1,139 @@ | |||
/*global defineSuite*/ | |||
defineSuite([ |
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 how the other geometry/appearance specs are organized? I feel like we could combine the point geometry/appearance tests into one file.
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.
Yeah they are usually split up this way. The geometry specs are simpler just checking default values and helper functions, and the appearance spec does the rendering.
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.
OK, keep it like this if you prefer.
I'm fine with this approach for now. Once we have a second use case, e.g., billboards or something else sized in pixels, we can add an explicit property to all appearances that needs to be implemented (the default would be to "increase" the bounding volume by zero pixels) so You're also welcome to do this now if you want since I'm pretty confident it would not require a breaking change later. |
Just those comments. This looks good. |
c9d6cf8
to
12451a3
Compare
Updated. I held off on adding a |
Looks great, thanks @lilleyse. Can you merge |
…pearance Added PointGeometry and PointAppearance
Sure I can do that. |
Awesome, thanks! |
For #3177
Added
PointGeometry
andPointAppearance
from3d-tiles
and added tests.In order to update the bounding spheres correctly for points, I added a function to
Primitive
calledupdateBoundingVolumes
. It is specific toPointAppearance
though, so it seems a little out of place.I noticed that a lot of other files were doing the same point size calculations, so I created a common function
Camera.getPixelSize
. Maybe this function belongs in a different file.