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

Polyline Materials #578

Merged
merged 140 commits into from
Apr 11, 2013
Merged

Polyline Materials #578

merged 140 commits into from
Apr 11, 2013

Conversation

bagnell
Copy link
Contributor

@bagnell bagnell commented Mar 20, 2013

I don't expect this pull request to be merged for a while, but I wanted to get feedback from @pjcozzi and anyone else who is interested. This branch contains wide polylines and a few new materials like outlines and arrows. Volumetric lines and a few other materials that are specific to polylines are still experimental and in different branches that are not a part of this pull request.

Any CZML polylines/paths will have the default red color material. @mramato is looking into what needs to be done there.

…rical to cartesian coordinates to built-in functions.
…h color components of 1.0, but not less than 1.0.
@pjcozzi
Copy link
Contributor

pjcozzi commented Apr 9, 2013

Performance numbers aren't ideal, but they are tolerable. We'll continue to work on new abstractions for users to optimization specific use cases.

@pjcozzi
Copy link
Contributor

pjcozzi commented Apr 9, 2013

@bagnell can you add the new materials to the Fabric wiki page?

* vec4 currentColor = mix(bottomColor, topColor, step(0.5, textureCoordinates.t));
* vec4 color = czm_antialias(bottomColor, topColor, currentColor, dist, 0.1);
*/
vec4 czm_antialias(vec4 color1, vec4 color2, vec4 currentColor, float dist, float fuzzFactor)
Copy link
Contributor

Choose a reason for hiding this comment

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

Add a test for this, even if it is coarse-grained.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can the new grid material use this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think the grid material can use this, but I believe @emackey did his own anti-aliasing by blurring the area at the edges of the grid line.

@bagnell
Copy link
Contributor Author

bagnell commented Apr 10, 2013

@pjcozzi The precision problem is fixed in this branch by subdividing the lines and uses only 8 vertex attributes. It is also fixed in the polyline16Attribs branch, but uses 14 vertex attributes. I'm having a hard time finding the maximum number of vertex attributes for different mobile GPUs so I can't justify using only the version with 14 attributes except for the drop in performance for the extra positions.

@mramato
Copy link
Contributor

mramato commented Apr 10, 2013

As far as I know, every mobile GPU under the sun has 16. I know @kring is also convinced that we should treat 16 as the maximum. http://webglstats.com/ backs up this claim statis that 99.9% of devices support 16.

@pjcozzi
Copy link
Contributor

pjcozzi commented Apr 10, 2013

@bagnell how many subdivisions does an access line from a satellite to a facility need?

@mramato webglstats.com says 87.8% of mobile have 16 attributes. If we know what the 12.2% is that doesn't (it's mostly Android devices), I am happy to assume we always have 16, especially considering that I expect @bagnell's answer to the above question will be scary. Worse case, we will have two rendering paths. I also pointed @bagnell to these stats from unity, but it sounds like he couldn't determine which GPUs only have 8 attributes.

@mramato
Copy link
Contributor

mramato commented Apr 10, 2013

I should have looked more closely at webglstats, so I apologize for the 99% partial truth. I still think 16 is a reasonable maximum to expect, what are the chances that a device with 8 would really be able to run Cesium anyway (for other reasons, not just graphics chipset)? Anyway, I know I'm not an expert, so I'll leave you guys alone now.

@bagnell
Copy link
Contributor Author

bagnell commented Apr 10, 2013

@pjcozzi The problem seems to occur between 90k and 95k meters. so a new position will be added every 90k meters.

In simple.czml, the first access line between the ISS and Geoeye 1 at 3/15/2012 10:32:06 is 50 points.

@bagnell
Copy link
Contributor Author

bagnell commented Apr 11, 2013

@pjcozzi I wasn't able to reproduce the the issue with the PolylineArrowMaterial. It may be an AMD specific problem.

@bagnell
Copy link
Contributor Author

bagnell commented Apr 11, 2013

New performance numbers (master vs. polylineMaterials):

Static data with the same material:

ModeBefore (FPS)After (FPS)
3D142131
2D8771

Static data with the unique materials:

ModeBefore (FPS)After (FPS)
3D14061
2D8645

Dynamic data with the same material:

ModeBefore (FPS)After (FPS)
3D7649
2D4434

Dynamic data with the unique materials:

ModeBefore (FPS)After (FPS)
3D7535
2D4327

@bagnell
Copy link
Contributor Author

bagnell commented Apr 11, 2013

@pjcozzi I think this is ready again. I still have to update the wiki.

@pjcozzi
Copy link
Contributor

pjcozzi commented Apr 11, 2013

Merging. Will write issues for remaining minor problems.

Please update the materials wiki and email cesium-dev as there will be a lot of interest in this.

pjcozzi added a commit that referenced this pull request Apr 11, 2013
@pjcozzi pjcozzi merged commit 183605c into master Apr 11, 2013
@pjcozzi pjcozzi deleted the polylineMaterials branch April 11, 2013 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants