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

Terrain #510

Merged
merged 308 commits into from
Feb 15, 2013
Merged

Terrain #510

merged 308 commits into from
Feb 15, 2013

Conversation

kring
Copy link
Member

@kring kring commented Feb 9, 2013

There are three major parts to this:

  • A significant refactoring of the terrain/imagery loading system, making it easier to understand, easier to add terrain providers, and probably less buggy.
  • Lots of changes in ShaderProgram and UniformState and the like to support lighting 2D and Columbus View as if they're 3D. The overall goal is to make 2D and Columbus View look just like 3D, except the Earth is a plane instead of a globe. The water rendering is part of this, sort of.
  • Terrain providers, so we can get real, actual terrain in Cesium.

kring and others added 30 commits November 6, 2012 09:55
Previously, the base layer would not be mapped to tiles that didn't
overlap it at all.
This is very hacked up at the moment.
It should now be usable in normal material and as used by the central body
where the water color is supplied as a parameter instead of a uniform.
It went away back the water material's normalMap uniform lost its default.
Conflicts:
	Source/Scene/CentralBody.js
	Source/Shaders/CentralBodyFS.glsl
@kring
Copy link
Member Author

kring commented Feb 13, 2013

Ok, this is ready for another (final?) look.

@mramato
Copy link
Contributor

mramato commented Feb 13, 2013

Okay, I'll do a quick review since I haven't really looked at this yet.

@mramato
Copy link
Contributor

mramato commented Feb 13, 2013

The Sandcastle example still throws an exception when you hit one of the zoom buttons in 2D.

* instance should be created.
* @returns {Ellipsoid} The cloned Ellipsoid.
*/
Ellipsoid.clone = function(ellipsoid, result) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it make sense for this to be a "static" function? Everything else in this file is on the prototype. At the very least we should provide a prototype version (and my vote would be to get rid of the static version). Also, we usually treat Ellipsoid as an immutable type (obviously it can't really be one in javascript), does providing a result parameter here break that paradigm? Don't we have a bunch of baked in assumptions that Ellipsoids don't change?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm using this to reconstitute an ellipsoid after passing it to a web worker. All the functions get stripped away and only the fields are left. By taking this neutered Ellipsoid and passing it through Ellipsoid.clone, I get back an actual Ellipsoid that is equivalent to the original. A prototype method won't work for that.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good enough for me.

@kring
Copy link
Member Author

kring commented Feb 13, 2013

The Sandcastle example still throws an exception when you hit one of the zoom buttons in 2D.

Fixed. It's ridiculous the hoops we have to jump through to create a similar view in all 3 modes, of course.

*
* @type Number
*/
this.tileCacheSize = 100;
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm more curious than anything else, did we do any testing to pick this number?

Copy link
Member Author

Choose a reason for hiding this comment

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

Cozzi asked the same thing. The answer is no, I totally made it up. Most of the time we "need" more than 100 tiles for rendering anyway, so the value of 100 basically means unload everything you don't need right now. A higher number would keep tiles in memory when you, say, zoom out and then back in, which would be nice. On the other than, having memory usage drop when you zoom out is a nice feature, too. I don't know the right answer.

Copy link
Contributor

Choose a reason for hiding this comment

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

Then the question is simple, do we care more about visual quality or memory? I think quality comes first so I would opt for a higher number by default. If people raise concerns over memory usage, we can always change the default.

@mramato
Copy link
Contributor

mramato commented Feb 13, 2013

I completely agree about the camera. We need to make sure that at the "highest" programmatic level, all functionality is exposed in world-space and the difference between 2D/3D/Columbus are completely hidden.

@mramato
Copy link
Contributor

mramato commented Feb 13, 2013

I still have a race condition of some sort where if I start with an empty cache, switch to 2D, and zoom all the way in, I get major culling issues and half the screen just goes black. However, I just tried master and it appears to happen there too, so it shouldn't hold this up.

/**
* A {@link TerrainProvider} that produces geometry by tessellating height maps
* retrieved from a Cesium terrain server. The format of the terrain tiles is described on the
* {@link https://github.com/AnalyticalGraphicsInc/cesium/wiki/Cesium-Terrain-Server Cesium wiki}.
Copy link
Contributor

Choose a reason for hiding this comment

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

This link is formatted incorrectly and leads to creating new wiki page.

@mramato
Copy link
Contributor

mramato commented Feb 13, 2013

I didn't review it as closely as @pjcozzi did, but I looked over the code and did our "release" testing so confirm everything works. Other than the 2 doc issues, this is fine with me.

@mramato
Copy link
Contributor

mramato commented Feb 13, 2013

Also; I tried mobile

Tegra 3: water looks pretty bad, and it's slow; but everything seems to work. I don't think we made anything on mobile worse (which is the low bar I was setting when I tried it out).

Adreno 225: Looks freakin' awesome, everything works.

@pjcozzi
Copy link
Contributor

pjcozzi commented Feb 14, 2013

@kring tests look good. Looks like you used the WebGL category accordingly. As @mramato said, they pass in Chrome and Firefox.

Coverage is reasonable enough. I'd probably at least add tests for the DeveloperError in TilingScheme.createRectangleOfLevelZeroTiles. All the imagery/terrain providers don't cover their "must not be called before the imagery provider is ready." I'm not sure how hard that is to test. We can say that it's outside the scope of this pull request though.

Let me know when the doc fixes are in, and we'll merge this. In the meantime, I'll get the tutorial ready to go - just need to update the date.

@kring
Copy link
Member Author

kring commented Feb 14, 2013

I'd probably at least add tests for the DeveloperError in TilingScheme.createRectangleOfLevelZeroTiles.

Ha, that's some serious bike shedding. I'll add it tomorrow if this isn't already merged by then.

@pjcozzi
Copy link
Contributor

pjcozzi commented Feb 14, 2013

Ha, that's some serious bike shedding. I'll add it tomorrow if this isn't already merged by then.

Sorry, there's actually 3 developer errors there. We should really cover all developer errors. I'm not sure that I ever opened a pull request that did not cover reasonable ones to test like these.

@kring
Copy link
Member Author

kring commented Feb 15, 2013

Sorry, there's actually 3 developer errors there. We should really cover all developer errors. I'm not sure that I ever opened a pull request that did not cover reasonable ones to test like these.

Ok, this is taken care of. Just for the record, this code was added with the imagery_layers merge, and wasn't touched here.

Also, we clearly disagree on the importance of these DeveloperErrors. I was just making the case to Scott the other day that, in most cases, adding these undefined checks is a waste of time (developer time and a tiny bit of run time), and adding tests for them is even more so a waste of developer time.

Meanwhile, this pull request includes some very "tricky" tests of the tile load pipeline. Feedback on those would be valuable, as would another pair of eyes looking at what important aspects I may have missed (even though the coverage is good). Looking at coverage numbers of trivial code without looking at the hard stuff is classic bike shedding. I understand why it happens, and it's likely I'd do the same thing while reviewing someone else's pull request. So I probably sounded like an ass above, but we shouldn't kid ourselves.

@pjcozzi
Copy link
Contributor

pjcozzi commented Feb 15, 2013

Looks good. Merging. Email the dev list once we get the tutorial up.

As for getting rid of developer error, I'm all ears. I talked about doing this in limited cases - for optimized release builds - a really long time ago. If you think it's pressing, bring it up on the dev list.

pjcozzi added a commit that referenced this pull request Feb 15, 2013
@pjcozzi pjcozzi merged commit 1c45e05 into master Feb 15, 2013
@pjcozzi pjcozzi deleted the terrain branch February 15, 2013 15:31
@pjcozzi pjcozzi mentioned this pull request Nov 13, 2015
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.

7 participants