Hi, I'm playing around with the new release and started with just moving what I have from B16 over.
However when running it now I get some weird artifacts on the world globe, is there something I've missed?
attached an image of the issue as well as the html/js.
http://pastebin.com/VzT3kS58
https://dl.dropboxusercontent.com/u/10187043/artifacting.JPG
Do you see this in the apps that come with Cesium as well, such as Cesium Viewer? Or only in your own app? What OS and GPU are you running on?
Kevin
Yes I got it on the examples as well(cesium viewer and hello world) when updating to the new version, I guess I should’ve just skipped my own stuff =).
Anyway, all the people I’ve asked to look at it (3 so far) , not sure about their systems, report the same issue.
I’m running windows 7 64 bit with a gtx 670, looks the same in both firefox and chrome.
Strange, I’m running NVidia hardware (older than yours, though) on Windows 7 as well, and haven’t seen that. Can you try two things for me:
Thanks,
Kevin
That’s interesting, I get the same thing on the Cesium page as well now, didn’t earlier this week. Is it now running b17 as well?
Clear browser cache is SOP for me when playing around with my server, didn’t affect it.
Thanks for the suggestion though.
You might want to know that trying out b16 on my own server does not give me this issue.
Regards Axel
Yes, cesium.agi.com is running b17 at this point. So it sounds like something broke, but I’m not sure what. Are you video drivers fairly recent?
Is anyone else (other than Axel and the other folks he has had try it) seeing this problem?
If you don’t mind investing a little time in this, the best way to track down the source of the problem is with “git bisect”. Have you used it before?
Kevin
I was running 320.14, updating to 320.18 (basically the same but release instead of beta) changed nothing.
I’m fairly new to git and haven’t heard or used git bisect. Reading about it, it seems like its a way to step through commits. I’ll try to make some time tomorrow and give it a shot.
/Axel
Yep, it lets you very efficiently find the commit that introduced a bug by binary searching through commits. First, checkout the Cesium repository from GitHub if you haven’t already:
git clone git://github.com/AnalyticalGraphicsInc/cesium.git
cd cesium
In a separate window, run the server that comes with Cesium:
./Tools/apache-ant-1.8.2/bin/ant runServer
Back in your main window, start a bisect:
git bisect start
Then checkout the b16 release:
git checkout b16
Build Cesium:
./Tools/apache-ant-1.8.2/bin/ant build
Then launch a browser on http://localhost:8080/Apps/CesiumViewer/index.html and see if the bug occurs. If it does, run:
git bisect bad
If it does not occur, run:
git bisect good
Then checkout the b17 release, build, and mark it good/bad (presumably bad):
git checkout b17
./Tools/apache-ant-1.8.2/bin/ant build
git checkout bad
Git will automatically checkout the next commit to test. Build again, check for the bug again, and then tell Git whether or not the bug occurred
./Tools/apache-ant-1.8.2/bin/ant build
git bisect good OR git bisect bad
You’ll have to repeat this cycle (build, test, git good/bad) about 7 times, and then Git will tell you the first commit in which the bug occurred.
When you’re done, reset your repo to where you were before with:
git bisect reset
Thanks for doing this, and let me know if you have any questions.
Kevin
Thanks for the thorough guide, this is the commit introducing the issue:
$ git bisect bad
8f47354872b0aa76031fd02f7111beb2d338ba5d is the first bad commit
commit 8f47354872b0aa76031fd02f7111beb2d338ba5d
Author: Kevin Ring kevin@kotachrome.com
Date: Wed May 1 15:56:21 2013 -0400
Improvements to CentralBody fragment shader.
Use an if statement instead of the crazy two-step-alpha-zeroing for
excluding a texture outside its extent of applicability. Avoiding ifs is
sometimes good, but here it just overcomplicates the shader. In theory,
with dynamic branching, the if could be faster, too. I wasn’t able to
measure any performance difference one way or the other from this change.
Treat alpha like the other properties (hue, gamma, etc.). Only apply it
if it is not 1.0.
Removing debugging feature of showing texture boundaries.
TileCoordinatesImageryProvider does a better job of that anyway.
:040000 040000 ed52d630af43f17adca24713dce6274b34fe3505 33a31d04f2ca6059c7aba38ded3972f90bbc9bfb M Source
Some more details, I’m running this off a windows machine acting as a webserver with apache 2.2. I didn’t see the problem when looking at the localhost adress using that computer through rdp with the server included in cesium. I used my other computer(as detailed above) to find the problematic commit. The webserver is running a gt620 gpu.
Great, thanks for tracking it down. We saw some artifacts (not anywhere near as bad as the ones you’re seeing) with that same commit on Mac OS X earlier today. I’m pretty confused about it, but I’ll look into it and revert the commit if need be.
Kevin
No problem, I’d like you to solve my issues with it ;).
Thanks for doing a great job with Cesium!
/Axel
Hi Axel,
I just committed a change that would fix this problem to the “tileEdgeArtifacts” branch. Can you try it out and confirm that it works for you? If so, it will be in master soon, and in an official release at the beginning of July. If you have no files edited in the git repo you checked out previously, you can switch to the branch with these commands:
git pull --rebase
git checkout tileEdgeArtifacts
./Tools/apache-ant-1.8.2/bin/ant build
Thanks,
Kevin
Hi Kevin,
Awesome, that seems to have fixed it. No more artifacting on the examples or my own stuff.
Thanks!
/Axel
Good to hear! By the way, I was eventually able to track down a GTX 650, and was able to reproduce the problem with that GPU. The fix is in master, now, and will be in the b18 release at the beginning of July.
Kevin