Hi!
Could anyone be interested joint effort in trying to implement webgl2 framebuffer multisampling antialias for Cesium JS? This is a really long time request but I have seen no efforts being made on it in official repo.
Cesium JS currently fails in comparison to visual quality of engines like ThreeJS because of bad antialias quality and this would be a great thing to be fixed in order to produce first class quality out of the engine.
Love the initiative! I’m not a deep 3D / math guy so won’t be much help, apart from cheering, testing and more testing. I’ll keep an eye out for it.
Cheers,
A;ex
Great to hear from you! I guess any activity from your side as well would help, but it’s true that this is a very advanced tech task as well.
Altough I am not 100% sure about the challenge level yet as I have spent only maybe 4 hours on this. But many things in Cesium nowadays have a bit of package from history already: implementations need 2-3 different branches as there are modes like logarithmicDepth, which might need very different algorithm than linear depth for example.
If one would start this antialias implementation it could make sense to choose only one “rendering path” first to support and try to implement for that. I would choose non-hdr and logarithmicDepth without any postprocess first.
Finally something is happening 
@eli: This is great work! I tested the MSAA branch and it gives very nice results - it is something we have waited since 2016 for Cesium. =)
One thing we would desparately need though: To be able to pick depth… it is now disabled in the branch and thats why we cannot deploy it right away…
@v12424124_34 Thanks for the interest! The branch is just a hacky prototype to see how MSAA could look in CesiumJS and we’re working on getting it ready for a proper release - we’ll keep the issue you linked updated as we make progress 
That’s awesome news, I’m excited to see what can be gained from this!
Cheers,
Alex
From my perspective the MSAA is the only real deal out of these techniques. We use line-graphics a lot and FXAA etc. do not provide any added value with them. So my vote goes for prioritizing MSAA first. 
It would be nice to see the line scene with MSAA also in the issue example images. Now MSAA was omitted from those.
@eli: Hi again! Would it be possible to tell about the status of this task? I have tried the framebuffer merge and also the msaa_wrapper branch and as before, MSAA works great already!
But there is a showstopper: depth picking does not work! Is there any estimate when this would be fixed?
Issue can be reprocuced by opening this:
… and trying to rotate model by picking from tall “chimney”. With MSAA branch, it does not rotate around the picked point.
Thanks for the work on this!
Hi @v12424124_34 - thanks for the interest! I’ve just opened the pull request to add MSAA to CesiumJS - there are a bunch of new changes and picking should be working now (among other bugfixes). If you have some time we’d greatly appreciate it if you were interested in testing the new branch. There are instructions in the PR description; let us know if you have any feedback!
Great! I can confirm that picking depth works now with multisampling also. I will test more later on.
About performance: I have numSamples:4 now and framerate drops about 90% : o
I tested by running public production Cesium Sandcastle “3d tiles bim” and same sandcastle from your PR. So to me at least it seems that something is still very wrong performance-wise… I will investigate more… The public producation sandcastle runs way over 60 fps even full screen.
I tested this a bit more: the MSAA slow down occurs already with an empty sandcastle. As soon as the MSAA is toggled on, GPU starts working very hard:
Same scene without MSAA (“MSAA off” from @Eli 's sandcastle patch menu):
@v12424124_34 I’ve opened another thread here for more visibility - MSAA in CesiumJS! - I’ve since made some changes to improve performance with picking, so the frame drops should be less noticeable. With that said, MSAA does take up more GPU resources so some performance drop is expected. We’re still making sure everything is working as expected so please let us know on the new thread if you run into more issues, thank you!
Hi! I tried the newest commit also and even an empty globe with no models runs only 25fps on Nvidia rtx 3090 gpu. There could be some pretty bad performance issue still… Penalty is worst on fullscreen, seems to be fill rate type bottleneck…
I will test more and report to other thread later on.
