Hi! Im uploading a photogrammetry scan from reality capture. The built in upload functionality crashes, so I exported fbx (export vertex normals: yes).
It uploads to Cesium Ion fine, but when I look at the model there are black stripes along all the edges, its probably something with the LOD generation I would think. Zoomed all the way in they dissappear.
I’ve also tried with larger texture gutter up to 16px, but I get the same artifacts.
Hope someone knows anything about this
Screenshots (Last one is reference from RC):
My apologies for the delay in getting back to you on this. I see your support message as well—thank you for the information there. You have an interesting project here, and I hope we can improve the artifact problem you are seeing.
One thing I noticed about your data is that it is very large—some number of times bigger than world scale. This user recently had a problem that seems somewhat similar, and they were able to work around it by changing the scale of their model. (Although, in their case, the scale had to be increased instead of decreased.)
Which option did you select for What kind of data is this? when uploading? I would recommend trying 3D Capture, if previously you selected a different option.
You could also try disabling Draco compression and/or reducing the maximumScreenSpaceError of the tileset (which, while probably not a real solution due to the performance hit it would cause, could help us diagnose the problem).
I am testing these options out on my end and will let you know if any of them is successful in improving the visual quality of the asset. Please let us know if you try any of them and have any findings to share.
Hi Matt! Thanks for your reply.
I’ve tried rescaling the model now, but with the same results. ID 673295
I have tried uploading with many different settings, I usually turn off Draco, but use WebP. I always upload as 3Dcapture. I have tried 3d model, but it breaks the model and loading as a complete gltf leads to performance issues.
My guess is that it has to do with the low polycount of the model and the high number of textures. We have done a lot of work repairing geo and textures, but it was done for a different goal and the polycount is under 200K… I guess that results in some problems when making the LODs, but there are no options to set when converting as far as I can see.
Let me know if you have any other ideas
I consulted with some colleagues on my end, and their guess was that either the texture coordinates aren’t correct or the texture atlas doesn’t have enough padding around the pixels. It sounds like you’ve already done some experimentation in those areas, though. It would be useful to see the UV map in Blender to see if the texture coordinates are sampling from black pixels. Is that possible?
Apologies for the late answer, I’ve been away for over a week in a remote place, so that’s why you haven’t heard anything. But I’m very glad to get help with this, and I’ll be available every day from now on
Heres a screenshot from Blender:
I can send you the files also, if you provide me with somewhere to upload it.
Have a great week!
@Steffen_Aaland This is a public forum. I think there are ways to share that with the Cesium staff only but right now, it is visible for everybody.
Thank you for letting me know, I thought I was replying to an email…
Thanks for the screenshot and sorry about the confusion. If you send us your email address in our support conversation (the email thread with email@example.com), I can share a private Drive folder to which you can upload your data. If you can’t find that thread, you can start a new one or just email me directly at firstname.lastname@example.org. Alternatively, you can use one of those options to just send me a link to your data privately.
Ok, I just sent a link to your email
Received, thank you! We’re taking a look.
Thanks again for sending the data. We see the problem you mentioned, and we’re working to better understand its source.
One thing I tried is replacing all of the textures with the one below, which is light enough so that black lines will still be obvious but still patterned so that the shape of the model isn’t completely lost.
As you saw in one of my earlier comments, previously I wasn’t sure whether the black lines we’re seeing are a texture-sampling problem or an issue where the background is incorrectly visible through the tileset at certain LODs. Looking at the texture-swapped model, so far it does seem like the problem could be related to texture sampling. (One additional test I need to do is to replace each texture with a copy of this pattern instead, so that the number of textures and materials remains the same. Perhaps that complexity is an issue.)
I’ll send you two Sandcastles to you via private email, so you can examine and compare. Please let me know if you notice anything or have any additional thoughts when you look at them.
I know you mentioned you tried boosting the texture gutter to 16px. I’m wondering if, as an experiment, it would be worth boosting the gutter to something much larger, like 64px. (And perhaps also try going the other way and reducing it to a very small value.) This may not necessarily give us more insights, but maybe it would help us rule something out. Let me know if you give it a try.
Hi Matt, thanks for that. I checked the two out and can’t see any black lines on the one that you swapped the textures on. The issue with 64px gutter is that the texture count gets very high so I would like to try without it first. What if I exported the textures with alpha? I could send them as png with transparency, maybe it won’t sample from black? What do you think?
That’s an interesting idea and seems worth a try. Let us know how it turns out—might narrow down the possibilities at least.
Hi again, I’ve sent an email with two new versions, one with 64px gutter (I had to change to 8K resolution to make it work, so if the textures are downsampled to 2K there will be a large drop in resolution…). The other one is the same as the first one, but have transparency in the textures.
I also wondered which settings you can tweak during tiling?
Can you adjust the number of LOD’s? These models have quite a low polycount, so I’m not sure we need them. (The textures would have to be streamed, though.)
I hope you had a great weekend. We did some more testing with this data, and I wanted to update you on our progress. The 64px gutter didn’t make a difference, which is good to know.
I took the original data and, without changing the model, I replaced the 353 .jpg textures with 4096x4096 copies of that two-color pattern I shared above. This time, I saw the same black lines we noticed with the original textures, even though there shouldn’t be any black pixels from which the tiler could be erroneously sampling.
So, as opposed to the two-color example I shared previously, this one has numerous texture files (like the original data) instead of just one. Based on this, I’m trying to determine if there is a problem with texture atlasing or something else.
To your question about tiler settings, here are the settings that can be adjusted if the tiler is being used on-premises: Model Tiler On-Premises – Cesium
Hi Matt, that’s interesting.
I had a look at the settings for the tiler, I don’t know what you’ve tried yet, but It would be interesting to see what happened if there was no Draco compression and no texture compression (or set to max quality). Perhaps we can narrow it down to that part of the process?
Exited to see what you come up with
Happy New Year—hope you enjoyed the holidays. I wanted to give you a brief update on our efforts with this. We tried the settings you suggested above (no Draco compression and max-quality texture compression), but it unfortunately didn’t remove the black lines. At the moment, we still don’t have a solution available for your case.
That said, we’re continuing to work on substantial changes to the photogrammetry tiler, and we have your case in mind along with all of the findings from this thread, so I do hope that we’ll be able to solve this in the future. We’ll announce when those improvements are available. Please feel free to let us know if you have any other ideas or things we should consider as we work on this.