Skip to content
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

Fix: issues with rapture gallery #3027

Merged
merged 14 commits into from
Jan 8, 2025
Merged

Conversation

fcolarich
Copy link
Contributor

@fcolarich fcolarich commented Dec 20, 2024

What does this PR change?

This relates to this ticket: #2875
This fixes this too: #3039

The issues fixed here are:

  • Video caching: related to the videos showing a frame of the previous video when we reuse the texture. I fixed this by replacing the reused texture with a black 1x1 texture. This will show that black texture instead of a ghost image of the previous video.

  • UI in theory this should work correctly, as the scene was using the PBUiCanvasInformation to get the canvas size to properly size the UI and retrying several times also.
    The issue here was that we were calling UpdateUICanvasInformationComponent from the Initialize method, isntead of waiting for the proper ECS loop to do it. This meant that when the time came for the ECS to do it, the condition if (lastViewportResolutionWidth == Screen.width && lastScreenRealResolutionWidth == Screen.mainWindowDisplayInfo.width) would be true and we would skip writting the data to the CRDT. Not sure why that call was there, but removing it fixes the issue and causes no apparent problem. It should fix other UI issues we were facing with scenes that expected the data to be there when it wasn't...

  • This also fixes an issue happening when hovering over some buttons that were configured with input type of IA_ANY, upon on pointer enter and exit events we should be sending IA_PRIMARY (according to old renderer implementation) so the scene was not registering properly the hover...

  • I also fixed a random crash that would happen on the 2nd floor when the scene tried to load a wearable as an emote (?).

...

Please go to the scene in GC (-88,-64) and check that all the videos load correctly (not all pictures are videos, there is one in the first floor next to the elevator and then in the second floor there are several ones). You should see first a black square and then the video should start playing. No ghost frames from the previous videos should be seen.
Also you should see on the bottom right corner a button with a sound icon that enables or disables the sound in the scene.
Please check also that you dont experience any screen tearing (usually fixed by enabling Vsync) and that all the dummy avatars appear dancing or doing stuff correctly in the 1st, 2nd and 3rd floor.

Thank you!!!

Issues NOT fixed here because they are scene side issues that need to be addressed by the creator
Exterior posters: There were posters on the vertical panels outside the building, they're gone now, this is caused by faulty scene code. If you teleport to a nearby parcel and run to the gallery, you will see the posters until you enter it. Then they will disappear.

Disappearing DJ: There is an issue with the scene code that causes the DJ to disappear once you leave the 3rd floor once, so you will only see it the first time you enter the 3rd floor and once you leave it, it will disappear and wont appear again.

Custom Emote: scene emotes have a couple of scene code issues that cause them to break when the user moves right after triggering them, also issues related with timers that are never cleared and keep adding up as the user stays on the scene..

@fcolarich fcolarich self-assigned this Dec 20, 2024
@nearnshaw
Copy link
Member

nearnshaw commented Dec 21, 2024

The part about delaying the CanvasInformation message worries me, it could break other existing content
From the point of view of a creator, you should be able to read that info on the first frame, it's not something you expect to change over time, so it should be reasonable to check it once when the scene loads and not have to do continuous adjustments.

What if instead of delaying the message, we repeat it? Is that possible?

@fcolarich
Copy link
Contributor Author

fcolarich commented Dec 21, 2024

The part about delaying the CanvasInformation message worries me, it could break other existing content From the point of view of a creator, you should be able to read that info on the first frame, it's not something you expect to change over time, so it should be reasonable to check it once when the scene loads and not have to do continuous adjustments.

What if instead of delaying the message, we repeat it? Is that possible?

@nearnshaw
Tbh, sending it a couple of times was my first approach. I just reverted the last commit which introduced the delay, so right now it is sending it several times. It seemed more clean but you are right, although the issue seems to be that even if we send it in the first frame, the scene could not read it anyway (it would read a null value).
So there is an underlying problem there that is not directly related to this specific issue, but is forcing us to send it repeated times. I think it might be related with uncoupled update loops on scenes and ECS where messages from ECS -> scene get lost (although the CRDT should keep the changes, somehow they are lost 🤷). But this is totally out of scope of these fixes. At least for now this will guarantee that the canvas size is correctly received in the scene.
Just for example, this Rapture scene retries to get the canvas size several times and I would guess that it already faced this issue in the previous explorer as well (canvas info not being in the CRDT when they tried to check it in the first frame)...

Copy link
Collaborator

@AnsisMalins AnsisMalins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@Ludmilafantaniella Ludmilafantaniella self-requested a review January 2, 2025 19:41
@Ludmilafantaniella
Copy link

Ludmilafantaniella commented Jan 2, 2025

This fix was tested on both Windows and Mac.

Results:

  • Video Caching: Videos load correctly. A black square appears initially, followed by the video playback. No ghost frames from previous videos are visible.
    -✅ UI: All tested UI components function as expected, including proper scaling and interaction.
  • Button Hover (IA_ANY): Buttons respond correctly to hover events, as per the old renderer implementation.
  • Random Crash on Second Floor:
    Windows: No crashes were observed.
    Mac: The Explorer crashes occasionally when going to the second floor (approximately 3 out of 6 attempts).

General Testing in GC (-88, -64):

  • Videos on all floors play as described.
  • The sound toggle button works as expected.
  • Dummy avatars perform animations correctly on all floors.
  • No screen tearing was observed.

Known Issues (Scene-Specific):

  • Exterior Posters: Posters disappear due to faulty scene code.
  • Disappearing DJ: The DJ disappears after leaving the 3rd floor.
  • Sit Emote Issues: Emotes break when the user moves right after triggering them.

Copy link

@Ludmilafantaniella Ludmilafantaniella left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Re-test performed on windows and Mac. Approved by QA. Take into account the pevious comment with the known issues/problems.

Thread for reference

@fcolarich fcolarich merged commit 25f3cb9 into dev Jan 8, 2025
5 checks passed
@fcolarich fcolarich deleted the fix/issues_with_rapture_gallery branch January 8, 2025 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants