sluggish loading of tiles & "shadow" artifacts

  • I'll start by stating that I'm very happy to see the release of KrPano 1.22. I upgraded my license this morning and tested updating one of my tours to 1.22.
    I'm running into what seems to be some sluggishness in rendering the tiles. When traversing the hotspots I keep seeing "shadow" tiles from other scenes - These "shadow" tiles appear temporarly, and after loading they disappear. This makes things very disorienting. I do have stl depthmaps behind the scenes on the tour in question if that matters.

    I've attached two photos showing the phenomena I'm trying to describe. These photos are taken with a few seconds interval without changing the view at all.

    First we have the view immidately after I've "entered" the scene:

    A few seconds later the correct scene loads and the tour looks normal:

    This seems to happen both in chrome and firefox. I am serving the tour from the KrPano local test server. It seems to me that it gets worse as you click through more and more hotspots.

    Come to think of it, it might be an issue with my "loadscene" action:

    Code
    <action name="tour3d_loadscene" scope="local" args="scenename"> loadscene(get(scenename), null, MERGE|KEEPVIEW|KEEPMOVING, BLEND(1.0)); if (global.customtransition != 'SKIP', if(global.customtransition !== null, global.customtransition(); , tween(view.tx|view.ty|view.tz, calc(image.ox + '|' + image.oy + '|' + image.oz), 2.0, easeinoutsine); ); ); delete(global.customtransition); delete(global.customtransitiontime); </action>

    Edited 3 times, last by dfhjartarson (December 18, 2024 at 10:26 AM).

  • You are right Klaus. "Tiles" is not the correct term, it's a problem with blending between scenes.
    I'm not comfortable with sharing the vr tour publicly, as it contains images of a private property. But if you contact me directly I can share the tour with you, if you give send me an email or direct message.

    Edited once, last by dfhjartarson (December 18, 2024 at 4:24 PM).

  • Hi,

    I think the problem has been found: There was a texture caching issue (only for 3D model cubemaps) where a texture was reused but with the wrong mipmap filter state, and this caused mipmap levels to be temporarily used with incorrect/old texture data.

    As workaround try adding this line anywhere in your xml:

    Code
    <display mipmapping="off" />


    In the next release 1.22.4 this bug will be fixed.

    Best regards,
    Klaus

  • klaus.krpano January 1, 2025 at 10:48 AM

    Added the label Bug
  • klaus.krpano January 1, 2025 at 10:48 AM

    Added the label Fixed

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!