Issues getting image to show up in ADT

PG that is having issue: PG1
PG that is working correctly: PG2

I could use some help determining why the images in the PG1 are not showing up in scene, even though they do show up if you inspect the ADT, and they are showing up correctly in PG2. Things I have tried/ruled out.

  1. Problems with the SVG - I copied the SVG from PG2 that works to PG2 and it had no effect. I also tried the reverse and the images showed up correctly.
  2. An issue with the PR - The PR just prevents material cloning from making multiple copies of the emissive and diffuse textures. I tried PG1 in the normal playground url and it made no difference.
  3. I tried just adding the images to the ADT directly instead of the ellipse. This caused them to appear, but they appeared in black. Interestingly, when I do the same thing in PG2, they appear white. So I suspect that the images are black on the black ellipse background for some reason; however, they are white on the black ellipse background when the ADT is inspected and in the GU editor.
  4. Thinking maybe the issue is that I am removing emissive textures for perf reasons, I commented that out. This caused the images to show, but very faintly compared to PG2, so this isn’t the entire answer.
  5. I exported the GUI for both PGs to json. The only difference is the SVG.
  6. Following up on the idea that the images are black on a black background, I made the eliipse background white. This had no effect. The ellipses still showed as black and there was no image even though inspecting the ADT showed that the ellipse was white. So there is something very strange going on with my PG where the inspector is not reflecting how the UI appears in scene or vice versa. I even tried reloading to rule out a cache problem.

Can anybody think of any other things to test/rule out or see what the cause of the issue is?

@carolhmj Any thoughts on why the images seem to be black even though the svg fill is white and the images in the inspector and GUI editor look correct?

Pinging @carolhmj

A question - i couldn’t see it in your original message (and sorry if I missed it) - what is the difference between PG1 and PG2 (apart from the fact that it is working in 2)?

Taking a look now

2 Likes

It’s hard to say what the key difference might be. PG2 was the original work I did. PG1 added pointer actions and reorganized the code better to be a little more production ready. It also addressed some duplicate textures (removing emissive).

As a general tip for development in any situation, whenever you make changes to something that you know is working, do the changes incrementally, so you can know for certain what has changed. This helps VERY MUCH whenever things stop working :stuck_out_tongue: And try to simplify your playground whenever this happens, by slowly taking things out I found that the problem was that you were nulling the emissiveTexture: ADT Avatar UI | Babylon.js Playground (babylonjs.com). Whenever you work with UI on a mesh, it’s better to use the emissive instead of the diffuse, because the former is not affected by lighting :slight_smile:

2 Likes

Thanks. The issue was I went a completely different route and then went back to UI and had to stick it in the new framework. I did try not nulling emissive (step 4 in my original post) but even in your PG the image is fainter than it is in PG2. Can you see why the image is fainter than in PG2?

If you compare the materials, you’ll see that PG1 uses emissive+opacity
image

while PG2 uses diffuse+emissive:
image

Ah. I see that you get emissive and opacity when you specify onlyAlphaTesting. I assumed I should enable that for better perf so it isn’t alpha blending my UI mesh. What is the best way to get a clean image in this case?

Hmmm I don’t think there’s a way besides going with the alpha blending. @Evgeni_Popov might have a better idea? :thinking:

I’m not sure I understand which image is not clean?

If I set onlyAlphaTesting to true when creating the ADT (which uses emissive and diffuse textures), then the images are barely visible.

Ok, I see it now.

I don’t think that can be fixed, alpha blending provides additional anti-aliasing that you don’t get with simple alpha testing. Anyway, I’m not sure you’d lose that much performance by opting for alpha blending (?)

Thanks for the response. I’m not seeing a significant perf difference so you’re confirming my observations.