Search Unity

[RELEASED] SECTR COMPLETE: Spaces, and the Connections Between Them

Discussion in 'Assets and Asset Store' started by MakeCodeNow, Feb 21, 2014.

  1. PWPeter

    PWPeter

    Joined:
    Dec 16, 2018
    Posts:
    386
    I have not fully analyzed it yet, but I noticed that if the gameobject is disabled before the game / scene starts, the effect you are describing occurs, if the gameObject is disabled after the scene has been initialized, you can disable / re-enable the gameObject and the renderers should be re-enabled accordingly as well.
    I assume this has to do with how the Sector collects its Members & Childs.
    Would it be a possible workaround to deactivate the gameObjects only after the scene has started?
     
  2. zornor90

    zornor90

    Joined:
    Sep 16, 2015
    Posts:
    163
    This is what is currently happening; we only use one scene and use prefabs for everything, so the gameobjects are only being deactivated after the scene is loaded
     
  3. PWPeter

    PWPeter

    Joined:
    Dec 16, 2018
    Posts:
    386
    That is weird, because that was certainly working for me in that constellation. Does the deactivation happen immediately on scene load in such an event as OnEnable, Start, etc.?
    If you find the time, could you please check if it works or does not work for you when you run the VIS advanced culling demo scene and deactivate / reactivate the stack of boxes during runtime? (That is what I did when trying to reproduce this)
     
  4. zornor90

    zornor90

    Joined:
    Sep 16, 2015
    Posts:
    163
    So I went ahead and enabled / disabled those objects in the demo scene. Most of the objects kept working correctly after that, but there were some weird bugs and inconsistencies with lights enabling / disabling incorrectly

    What I'm really hoping for is a method that loops through all children and resets their state, it doesn't even have to be called automatically.
    What I assume is happening is that a mesh is disabled by the culling engine; then the game object is disabled; then when the game object is re-enabled, the mesh is considered to be starting disabled so it's never re-enabled by the culling engine

    EDIT: If it helps, these objects aren't children of any sectors, but are instead members that are between sectors (They are doors between rooms, where rooms are sectors and these doors are siblings of those sectors)

    EDIT AGAIN: I was able to workaround this by adding the following code to my between-room doors:

    Code (CSharp):
    1.     MeshRenderer[] renderers = GetComponentsInChildren<MeshRenderer>();
    2.     for (int i = 0; i < renderers.Length; i++) {
    3.       renderers[i].enabled = true;
    4.     }
    5.     Light[] lights = GetComponentsInChildren<Light>();
    6.     for (int i = 0; i < lights.Length; i++) {
    7.       lights[i].enabled = true;
    8.     }
    9. sectrMember.ForceUpdate(true);
    10.  
     
    Last edited: Aug 24, 2019
  5. SoloHonk75

    SoloHonk75

    Joined:
    Mar 27, 2016
    Posts:
    18
    Unity version 2019.3.0b3:

    Assets\Procedural Worlds\SECTR\Scripts\Vis\SECTR_CullingCamera.cs(369,13): error CS0103: The name 'RenderPipeline' does not exist in the current context

    There is also no SECTR menu entry...
     
  6. PWPeter

    PWPeter

    Joined:
    Dec 16, 2018
    Posts:
    386
    2019.3 is still a beta version of Unity, and we don't support alpha and beta versions for our products: The alpha and betas can show issues of their own (as expected for an alpha / beta) which then are wrongly attributed to our products and they also tend to change every couple of days, which makes it difficult to track down & permanently fix issues.
    Please use Sectr in Unity 2019.2, you should not run into these issues there.
     
  7. bigdaddio

    bigdaddio

    Joined:
    May 18, 2009
    Posts:
    215
    So we wait for the final release of the 2019.3 and then wait for you to fix this? You cannot tell me that you are not working on it already. This is a real cop out answer.
     
    f1chris likes this.
  8. PWPeter

    PWPeter

    Joined:
    Dec 16, 2018
    Posts:
    386
    Yes, this is how we handle alpha / beta versions for all our products.

    This has nothing to do with "copping out" but is a business decision to make best use of our development resources. Supporting alpha and beta versions would mean we need to invest a lot of time of fixing issues that might immediately break again with the next alpha / beta patch and chasing issues that ultimatively might turn out to be "unfixable" (from our position) Unity bugs.
    The public visible part of the unity issue tracker currently shows close to 2000 bugs for the 2019.3 beta, each with the potential to generate a support request wrongly attributed to our assets. (A not entirely fair picture - you would not bring every bug reported there in association with our assets, but the takeaway is the potential for something like this happening is definitetly there, and has indeed happened in the past)
    All this creates a significant overhead of development time for the benefit of "being able to use our assets earlier in an unstable environment unsuitable for actual development". We think the development time is invested better in improving our assets and adding new features which creates lasting value instead.
     
    Shturmovik, hopeful and AdamGoodrich like this.