Search Unity

  1. Unity 2019.1 is now released.
    Dismiss Notice

[RELEASED] SplitScenes - additive scenes workflow enhancement

Discussion in 'Assets and Asset Store' started by jhughes2112, Feb 5, 2019.

  1. jhughes2112

    jhughes2112

    Joined:
    Nov 20, 2014
    Posts:
    43


    I'm super excited to bring this out on the asset store! While working on a replacement light probe system for Unity (look for that in a few months), I had to use the additive scene loading function to verify that my light probe system worked the way an additive light probe system should--with chunks in different scenes that you can add or remove at any time. That's not how Unity's works, by the way. Which is why I'm working on one that does. Anyway, I found that the additive scene system is great as a foundational piece, but the interface was very lacking. So I built a better one.

    Here's what mine can do:
    • Place my script on an empty object in a scene. I call this the "Root" scene. This one keeps the list of scenes it manages, which is where the data is stored. You load this scene and it in turn loads the rest for you.
    • There's a SplitScenes Window that you can keep up all the time and dock someplace convenient.
    • The SplitScenes window can handle multiple root scenes at one time being loaded! You can reorganize very easily this way, if you want.
    • Drag and drop scenes into the Root (or Roots) it should load with.
    • Check boxes for each scene to indicate whether you want it to be open in the Editor or not. If you check it, it immediately loads. Uncheck to unload. Super simple.
    • Check boxes for each scene to indicate whether you want it to load when the Root scene starts or not. So, you can have helper scenes that are just for concept art that are just for reference, or an "old" scene that you sometimes want to see while you rebuild a cleaner version, etc. Or even a baked lights scene that has static non-shadow casting lights only, which never gets loaded except in the editor. Or a scene full of tools scripts that you want to keep separate from the game. Whatever you think of, you can do it!
    • The list of Build-time scenes that you can control more easily than the Build window. For one, you need all your runtime scenes listed in the Build, or it won't work. That's inconveniently located in Unity anyway. But more importantly, if you want to strip something out, just click the trash can icon to remove it from the build. This list is exactly the same list as in the Unity Build window, just more convenient.
    And the most awesome feature:
    • A lock button to prevent accidental saving of scenes. So often, if I'm doing something specific, it may be in one scene and I know I don't want to mess up what my teammates are doing, I just click the Lock icon on their scenes and I won't be able to save them. Even if I hit Control-S. SplitScenes hooks the save events and knows if you aren't supposed to be changing stuff, and prevents it. Super helpful, because it prevents bad merges when we really didn't mean to change things anyway... sometimes it's hard to know you've even changed something until you check in your files, and boom! Merge conflict.

    Well, I hope some of you out there find this useful. It's made a huge difference in our workflow already, and I expect more features to be added in the future. If you have any requests, I'm happy to listen and see if there's a way to work it in.

    Best regards,
    JH
    Reachable Games
     
    Last edited: Mar 7, 2019
    christoph_r and guycalledfrank like this.
  2. guycalledfrank

    guycalledfrank

    Joined:
    May 13, 2013
    Posts:
    990
    Oh, this is super intriguing! I was also going to do that. How do you send light probe data to shaders? Is it MaterialPropertyBlock, or the whole lookup is performed 100% on the GPU? How's batching working with it? :)
     
  3. jhughes2112

    jhughes2112

    Joined:
    Nov 20, 2014
    Posts:
    43
    Although this is really a forum about SplitScenes, I will mention that Unity supports a custom light probe type. Beyond that, you're on your own. I haven't implemented that part yet myself, but I did look it up in the documentation enough to satisfy my curiosity. However, the easy part is feeding shaders the right data. The hard part is managing the light probe data and interpolating it properly, which is what I've been focusing on so far.