We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.

[SOLVED/Update] Questions regarding MP4 compression breaking Puzzles UI behavior

Home Forums General Questions [SOLVED/Update] Questions regarding MP4 compression breaking Puzzles UI behavior

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #87311
    gee_lau2000
    Customer

    [SOLVED] Update: It was a silly Puzzles bug(Missing puzles), not related to MP4 compression!

    Hi everyone,

    I am developing an interactive app and recently encountered a strange behavior after replacing my video assets. I would appreciate some insights on the following three questions regarding video compression, Puzzles behavior, and the publishing workflow:

    1. Why does replacing compressed MP4s cause erratic UI/Object visibility issues when Puzzles remain unchanged?
    I have an interactive layout where clicking a button triggers a video playback and simultaneously changes the text/visibility of a UI object (a text strip named “3M Tape”).

    When using my original, uncompressed MP4 files (total folder size ~96MB), the app works perfectly every time.

    However, after compressing the videos into smaller files (using HandBrake) and overwriting the old files with the exact same filenames, some objects/text on the “3M Tape” start behaving erratically—sometimes they show up, and sometimes they don’t (randomly appearing and disappearing for specific characters).

    The Puzzles logic was not modified at all. If I swap back to the 96MB original files, everything instantly works fine again. What could cause the compression characteristics of an MP4 file to affect the execution or responsiveness of subsequent object/UI logic in Puzzles?

    2. What are the recommended HandBrake export settings for Verge3D web applications?
    To avoid compatibility or decoding issues that might be causing the problem above, what is the officially recommended video configuration when using HandBrake? Specifically, which combinations of the following settings are considered standard and safest for a flawless WebGL/Verge3D experience:

    Format & Extension: MP4 vs M4V (and whether to check “iPod/iTunes friendly”)

    Video Codec: H.264 (x264 / Hardware Accelerated) vs H.265 (x265)

    3. Is there a way to selectively upload individual files to Soft8Soft App Manager instead of re-uploading the entire project folder?
    Currently, every time I make a minor update or compress a few assets, publishing requires uploading the entire application folder through the App Manager interface. Is there an efficient method or workflow to only upload/update specific, individual files to the Soft8Soft network server instead of transferring the whole folder every single time?

    Thank you very much for your time and help!

    #87313
    bigmike814
    Participant

    Sounds like a race condition. If your mp4 is smaller than it was it will load faster and cause the stuff you are describing. I’d console log the path and see if the stack changes between the compressed and original. This will help you find where to make the fix.

    #87316
    gee_lau2000
    Customer

    [SOLVED] Update: It was a silly Puzzles bug (Missing puzzles), not related to MP4 compression!

    Hi everyone,

    I wanted to follow up on this thread and share the solution in case anyone encounters a similar “mysterious” issue in the future.

    It turns out that the problem had absolutely nothing to do with HandBrake’s video compression or encoding characteristics! The compressed, lightweight MP4 files are actually working flawlessly now.

    What the issue really was:
    After a deep dive into my Puzzles setup, I discovered a silly mistake of my own making: inside another function block, I had inadvertently left a hide [UI_Base_Object] block running in the background.

    When I was using the old 96MB files, the large file size caused a very slight asset loading latency in the browser WebGL container, which coincidentally masked this hidden hide logic. However, when I swapped in the ultra-lightweight, compressed MP4 files, the loading speed became so fast and instantaneous that it triggered the subsequent Puzzles blocks in a fraction of a second—making the UI object vanish immediately.

    After removing that rogue hide block and re-exporting the clean glTF from Blender, the app’s total file size successfully dropped from 6xxMB down to 245MB, and the object displays perfectly every single time!

    Thank you so much to anyone who read or considered my questions. Lesson learned: always double-check the visibility/hide logic tree before blaming the media assets!

    Cheers!

    #87317

    glad you worked it out! :good:

    Chief 3D Verger | LinkedIn | X

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.