-
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
Terrain #510
Conversation
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
Ok, this is ready for another (final?) look. |
Okay, I'll do a quick review since I haven't really looked at this yet. |
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) { |
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.
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?
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.
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.
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.
Good enough for me.
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; |
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.
I'm more curious than anything else, did we do any testing to pick this number?
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.
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.
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.
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.
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. |
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 |
/** | ||
* 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}. |
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 link is formatted incorrectly and leads to creating new wiki page.
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. |
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. |
@kring tests look good. Looks like you used the Coverage is reasonable enough. I'd probably at least add tests for the 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. |
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. |
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 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. |
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. |
There are three major parts to this: