[RELEASED] SECTR STREAM: Seamless Scene Streaming

We're very happy to announce the release of SECTR STREAM on the Unity Asset Store. SECTR STREAM makes it easy to save memory, increase performance, and decrease load times by splitting your scene into multiple chunks and streaming them in realtime.

• Streams anything you can place in the editor.
• Setup a scene for streaming in minutes.
• Lightmaps stream individually.
• Correctly handles nav meshes and light probes.
• Simple, powerful import/export GUI.
• Ideal for huge scenes and mobile devices.

If you want to know more, check out the short video below, post a question here, check out our online demos, or email info@makecodenow.com.

[video=youtube_share;EGmxZkC1FdI]http://youtu.be/EGmxZkC1FdI

 

Looks very interesting. What's the advantage of this over occlusion culling? Also, is it as expensive as occlusion culling can tend to be?

 

Thanks for the interest!

STREAM splits up your scene into pieces, and loads those pieces as you move through the level. The primary benefits are much lower memory usage and shorter/fewer loading screens since you need to load less data to get started. Because much of the level is unloaded, it does serve as a kind of gross occlusion culling, too, as there's nothing to render in unloaded Sectors.

You can also have occlusion culling and streaming running at the same time. Unity's built in Umbra OC doesn't handle streaming at all, but SECTR Vis does. If you use STREAM and VIS, stream will handle loading the big chunks, and then VIS will do more fine-grained culling based on what is actually visible.

Make sense? Happy to answer any other questions you have.

PS - Streaming requires very little CPU. There is a bit of a hit when new objects are loaded (the hit is bigger in Free and smaller in Pro) but most of the time STREAM takes very close to 0 CPU.

 

interesting indeeeeed .

I have a few nooby questions:

SECTR STREAM: when the scenes are unloaded, are all the variable data in that scene lost? or there an option?

SECTR VIS: I plan on having a third person character that has the option to switch to first person. The 3ps character will have many animations and I don't want to make a fps prefab with another set of animations (hands and stuff) and switch between them. So do you think VIS will occlude the 3ps mesh whilst in fps? also not to occlude the hands of the character when in view?

Kind Regards
MoHoe

 

Those questions aren't nooby at all. Happy to answer them.

Yes, when STREAM unload a Chunk, the data is lost. However, SECTR STREAM has a hibernator component, so you can have dynamic "global" objects that automatically shut down when their part of the world is unloaded.and wake up when it's reloaded. The Chunk component also has Events for load and unload that you can hook into. You can write a component that uses those hooks to save any data you want to persist and then restore it when the chunk loads again.

VIS is totally under your control. If you don't want the player to cull, simply add a Culler component to them and then mark that culler as disabled. That will tell VIS to ignore that game object and its children as far as culling is concerned.

PS - if you are interested in SECTR STREAM and SECTR VIS, check out SECTR COMPLETE. You'll pay the same as STREAM + VIS and get AUDIO (and some neat demo assets) for free.

 

Thanks for answering my questions. I'm currently in a bind, trying to get my mobile game RedShift optimized enough to run on the iPhone4, and I'm curious if this might be a good solution for it. The game is very corridor oriented so this seems like it would be a good fit in that regard, but I'm still a little concerned about stuttery hitches. Have you tested this much on iPhone4/Touch4?

 

Man, iPhone 4 and iPod Touch 4 are *the worst*. Retina res screens and underpowered GPUs, plus only 256 MB of RAM in the Touch. I've shipped several iPhone 4 compatible games, but I haven't tested SECTR on it much. I have tested SECTR a on a Nexus 7 (which is similarly underwhelming hardware wise), but my tests aren't with your game so I don't think that my tests really tell you much one way or the other.

To your question of good a fit SECTR is for Red Shift, here's my best analysis. Overall, SECTR does super well with fully interior games like yours. If your main problem is memory or loading times, then STREAM is your only and best weapon, though as you say you may pay for it in small hitching depending on how big your stream chunks are. If your problem is CPU or batch count/overdraw on the GPU, then STREAM will help by acting as a kind of very coarse culling. However, if what you want is to just really quickly coarsely cull your scene, VIS is probably a better solution. You can easily set it up to cull whole Sectors at a time, and because it's not loading or unloading anything, there will not be any hitching.

In the end, it's really hard to know what will work best until you try it in your game. To that end, feel free to email info@makecodenow.com, reference your game and this thread, and I can send you an eval copy that you can to see for yourself how effective it is. We can also setup a Skype or Google hangout to talk through specifics once you've tried the eval (or purchased a copy).

Hope that's helpful. Good luck with Red Shift!!

 

Oh cool, that sounds like a great idea. I'll send you an email shortly. =]

 

Looks great but is it possible to get a watermarked free version so I can test it out on my project before purchase? It's definitely has my attention but I'm strapped for cash at the moment. If it's not possible I understand, but you know... "Don't know if you don't ask" and all that.
- R

 

Definitely! Email info@makecodenow.com and tell me a bit about your game/project, or send me a link to a webpage or whatever. I definitely understand that cash is tight for a lot of people. We can also talk more about the specifics of your game and which SECTR modules would be most useful to you.

 

Sounds like you've created some great tools! I am having memory issues in my game so this will probably be very useful (doesn't currently build for iPhone 4S, barely got it working on an iPad 2). I wanted to confirm this would be helpful for an outdoor scene. The player has limited visibility so I could dynamically load parts of the scene without them noticing. Is it safe to assume that previously pieces are also unloaded to save memory?

I'm also interested in hearing more about how this may stutter on unity free and suggestions for minimizing it. I assume loading smaller chunks (possible for me due to the limited visibility in the scene) would be the most helpful?

 

Hi, loadexfa. Good questions.

STREAM will definitely save you memory. That's it's number one job. It will work fine with outdoor games, but depending on the structure, you may need to be more hands on with the Sector and Portal creation, maybe even writing a script that auto creates a grid of Sectors and Portals for your scene. Several people have actually expressed interest in using SECTR STREAM on Terrain based games, so I'm going to write a new GUI that auto-sectorizes heightfields. If you want an early preview of that, or want to discuss the specifics of your game more, feel free to email support@makecodenow.com.

Regarding hitching, the best way to hide it is with a quick fade to black (think Resident Evil). This can work great in games with doorways, but is probably totally unworkable for you. Depending on the art direction and fiction of your game, you could also use a "glitch" effect on the screen before or after the load, turning the pause into part of a cool effect. Whether that works or not totally depends on the specifics of your game. Without a trick like these, you will see hitching, but there are a few ways you can minimize it:
* Load in smaller chunks.
* Minimize the amount of assets that come in with each chunk, re-using them as much as possible.
* Optimize or eliminate the amount of code that runs in your components in Start/Awake/OnEnable (this is good advice for people with Pro, too)
* Try to use spawners instead of placed objects where that makes sense. Having a single object that dynamically creates many objects will take much less CPU time.

I hope that helps. Post here or email if you have more questions!

 

Cool, sounds great. I'll be picking up the full set sometime soon. I may ask to see the auto-sectorizing version but will wait and see when I get to another optimization pass on our game.

 

Hi!

I'd like to use the streaming component so that the outside world is one sector containing models of exterior buildings the load other sectors when a user enters once of these buildings. Is that possible? Would I just store the interior of the building off somewhere in space and have the door teleport the player to that part of the world?

I'm also very interested in any terrain stream solution you can come up with that is suitable for mobile.

Does async loading with PRO work on mobile devices?

 

Hi, Kenlem. Thanks for writing.

SECTR can definitely handle the use case you're talking about. Sectors can be nested and overlap, just don't make them children of one another in the hierarchy. In your case, you probably would want to have one or more big sectors for the exterior and then at least one Sector per interior. You'd then use a TriggerLoader to load the building interior when the player got close or use the LoadingDoor to load it when they approached a door. You could also write your own custom loader to do something more sophisticated or specific to your game. No teleporting required, unless you're into that sort of thing

I'll post more about my terrain work shortly, basically as soon as I get through the bug reports for the current point release.

As far as I know, async loading works on all platforms that unity supports, provided you have a Pro license for that platform. The performance profiles of course will be different, with loading from a PS3 BluRay somewhat slower than a PC SSD. In general, though, flash memory in mobile devices is quite fast to read from, which makes them a good target for streaming.

If you have more questions, please don't hesitate to ask here, or email support@makecodenow.com

 

Thanks for the reply. I'll buy SECTR COMPLETE tonight.

 

That's what I like to hear

If you have more questions, don't hesitate to ask.

 

OK. Bought it. Trying to make an terrain with a box on it for the exterior chunk then create another chuck for the interior.

 

Cool. Don't forget to create a portal that links the exterior/terrain sector and the interior. If you have any issues, post here or email support@makecodenow.com.

 

HI ! Thanks for developing this Asset !

_______________

Hope you dont mind-me to jump in with Some "few" Questions And ideas About this Product Present Future : )

_______________________________________________

:: Product development Status :::::

1) Is this Product ( done ) in terms of Features ,
... or are you Planning to Add "lot" more features to its development ?

1.1) If yes Do you have a Features Road map ?

1.2) DO you acept new features ideas ?

______________

I got Here a bunch of them ...
( This were compiled from some other Unity Threads ... And aplied to Your product )
_______________________________________________________________________


:: Some Features Ideas For this product Future development.

_______________________


2) Do you know Hero Engine Seamless Areas / Seamless world Features ?

http://hewiki.heroengine.com/wiki/Seamless_World_2.0
http://hewiki.heroengine.com/wiki/Seamless_world
http://hewiki.heroengine.com/wiki/Seamless_area_link

2.1) Can you Relate some of those features in your extension ?
And Explain WHat your Extension can do more or less near the hero Engine System ?

_____________________________________



3 ) If i Understood Each cube is a StreaminG Area right ?
Each Cube Must be Positioned Paralel to the other with a "Portal" in betwen .



But can We Have LODS / like In Above Example The AREA 2 We See at distance a LOD
( Custom low poly Representative Asset in Severall Levels of details ) of the Whole Level "before entering transition scene and the full chunk be loaded" ?

_______________________________________


3.1) Can this System be used for more than First person Shooters "inside houses" "closed levels" ... ?
How far can we use this sistem in open Worlds ?
So How about HavinG Workflows for Large Terrains Seamless Worlds ?

As Example imagine that each block Bellow is a Large scale Terrain ...

Can we have Automatic Seamless Borders detection, just like Puting a Box Near other and have the Seamless Transictions Automatically happen / Without the assle of us putting "transition Areas"


And What About LOOPs.
Can we Setup Areas That load Other chunks Already in Disck ? And in This Way making Nested Paths ...

____________________________________________________________________


4) Can we have not just Horizontal but but also Vertical And Pipethem in full 3D blocks That is Load levels in XYZ axis




But Can we have also Areas rotated or even twist them ? So we can pipe Them Down Even Diagonally



5) Can we have Also this chunks / levels Blocks "moving, And Rotating and be Animated "
Across The Area or levels like Elevators or lifts ?

So When we enter a chunk it can move across a Whole level wile loading just the near chunks LODs Surounding it ?

Imagine a Train "That is a whole level" moving across a whole Scyfy city , but that we can jump of the train to enter Other Areas Acording its position anytime ...

This would require Automatic Seamless transitions without need for us to setup "portals" ...
just need the Areas touch areas and would create seamless transitions Automaticaly ...

_________________________


6) Can we have More variety of tipes of Sectors like :

Scenes: block That Encapsulate whole scenes with many Areas
Areas: blocks Inside scenes That Encapsulate Levels // having 2 lods .
Levels: Blocks Inside Areas That have Many Sectors. // Having 3 lods ( full, Close , near , far ( bilboard )
Sectors: blocks Inside Levels That have many chunks // Having up to 4 lods
Chunks: Blocks That COntain Meshes Elements And Are Loaded Acording Player Distance // And Each have up to 6 Lods Versions

On a Way We could have Entire Scenes Swaping, but also This way have inside of it Nested Swaping hierachies ...

Then When Saving a Area for example Save all Levels Sectors chunks it has in its hiearchy ....

BuT ENabling us also to Swap Parts That Are loaded from DIsck Acording Oclusion Distance and Acording their Hierachy ....

This way Nesting Scenes With Areas Levels Sectors Chunks Inside of it And Inside eachothers ...
So to be Loaded And Swaped in a Nested way acording player position / distance ... Also Working with chunks / Sectors / Levels / areas / lods for player still see them at large distance ...



This would make possible to Have reaaly large open Worlds ...With Sectors inside sectors ...

7) ... but can we have it with CUSTOM SHAPES ? not just Square blocks ?



_______________________

8 ) Enabling Nested chuncks levels areas scenes ...

Can we Latter Have a Proper Schematic Editor Interface Were we can "organize" And conect "Chunks" "levels" "Areas" "scenes" And Nest it all and Organize those Blocks in a Visual Way ...






....





OK ...

I think thats it on IDEAS for FEATURES in your product !
Hope you dont mind to Take some tough on them ...

I Will buy your product Just to make sure i Support This development ...

It got Already some wounderfull Features !!

Then i Will waith 1 Year To see how far could you reach in new features for this product !


____


THANKS SO MUCH FOR MAKING THE VERY MOST COMPLETE STREAMING PLUGIN IN UNITY SO FAR !

I will be Eaguering for your Development Improvments !


Best regards !




TRIAX
​

 

Triax, wow! That is a lot of questions! I'm not going to re-quote your post, but I've tried to answer everything you asked about. Please let me know if I missed anything or you want to know more.

1) SECTR is at a point I consider to be a stable initial release. All of the modules work well and are reasonably well optimized. That said, I definitely plan to keep developing the product for the forseeable future.

1.1) I don't have a formal roadmap as I'm still learning about what people want and need, but my short term goal is fixing bugs and doing some more in depth tutorial videos. These improvements will be 1.0.x. The next proper update (1.1) will add Playmaker support, some more tools and demos around open worlds since there seems to be a lot of interest there, and some audio UI improvements. After that, I'm going to see what else folks want in the existing modules, and look at one or two new modules (LOGIC for AI, NATURE for weather, and/or GAME for stuff like Portal the game).

1.2) I'm always interesting in hearing what people want, so feel free to post them here or email support@makecodenow.com.

2) I've never shipped a game on the Hero engine, but there seem to be a lot of similarities.

2.1) Like Hero, SECTR thinks of the world as a graph of Sectors, with connections between then (Portals in the case of SECTR, Links in Hero), which allows users to create a wide range of spatial topologies. It looks like Hero has some specific utilities for working with Terrain based spaces, which I plan to add in 1.1 (as I mentioned above). Hero has a ton of server side/MMO/multiplayer specific logic, which SECTR currently does not have. SECTR should work fine with any existing Unity networking code, but it has no network specific logic built in. Perhaps something to consider for a (far) future update.

3) Sectors in SECTR can be any shape, they can overlap, and the portals can be positioned wherever. If you check out the COMPLETE demo, you'll see that it's somewhat more complex/messy than the simple scene used in other tests. For Terrain, you can set that up yourself using the existing tools, but it will be easier when I write the Terrain Sectorizer that automatically makes Sectors and Portals for a Terrain. LODs for distant objects would definitely be very useful for open world games, but it's not currently supported. I am intrigued by the idea, though, especially given how much interest there is in using SECTR as an open world framework.

3.1) SECTR works just fine for first or third person. I tried to write it as generally as possible. Some elements, like VIS, work optimally in indoor or hybrid-indoor (think Metroid Prime, Dead Space, etc) type spaces, but can still be very effective outdoors. STREAM will currently work in any environment, but it'll be easier to use on Terrain after my 1.1 update. AUDIO is already completely happy indoors our outdoors, and some features, like distance based audio occlusion, are designed primarily for large, open spaces.

3.2) SECT doesn't currently support auto-loops, but it's something I find intriguing. I'd like to write a LoopLoader one of these days, and will do it sooner if there is a client who needs it.

4) Yes. SECTR thinks of the world as a graph, and it can be as 3D as you want it to be. I've tried to write all of the logic and 3D math as correctly as possible. The flatness of the demos is just a function of my limited abilities as an artist

5) Yes. Everything in SECTR is *completely* dynamic. You can move, create, destroy, Sectors, Portals, Occluders, Audio, you name it as you like and things will "just work". The only restriction is that if you mark and object as Static, it should not move about, as I perform various optimizations when objects are marked static.

6) Wow, that is a lot of requests! SECTR will likely evolve to include many of the things you're talking about. Sectors can already be nested and overlap, but there is no Sector of Sectors for doing recursive loading like you're talking about. LODs of distant/unloaded objects is also interesting as I mentioned above, and I can see that integrating pretty cleanly. In general, I believe that the best way to build software is to evolve it based on user need, keeping things as simple and clean at each step as possible. With the right mix of time and user feedback, hopefully more of these things will be possible!

7) Sectors can contain whatever you like, and membership is not exclusive, so the fact that the bounds are an AABB doesn't cause many actual problems. Using a an AABB for SECTR bounds makes many tests much faster than they would be otherwise. Mono/C# is pretty fast, but it's not that fast, especially on mobile. Allowing users to define Sectors as 3D convex hulls or the like would make many operations much more expensive. I'm not totally dismissive of the idea in the long term, but the implications are significant enough that I'd want to see a real world use case where a client simply couldn't get the result they needed to before I tackled a change that big.

7.1) A GUI like you describe would be very cool. It would also be a lot of work, but it I would consider it seriously down the road, especially if some of the more complex features that you describe came online, like Sectors that contain Sectors. I actually have a nod to this feature in there already. If you open the Stream window and press the Export Sector Graph button, it will export your Sector/Portal graph as a .dot file that you can visualize in GraphViz. It's pretty cool!

Ok! Hope that answers your questions. Thank you so much for buying SECTR and supporting this product. If you have time, please write a review in the Asset Store. It really helps!

 

THANKS SO MUCH FOR YOUR AMAZING AND GREATH SUPPORT !

Thanks so much to Cover All Questions Numbers / And im so glad so optimistically !

( Deeply sorry for taking of your time in Such Deep Subjects )

I Will be Buying it Soon and will be Aplying it to my project.

I Availed and will be Buying This Next month The SECTR COMPLETE :
https://www.assetstore.unity3d.com/#/content/15356

WIch is Extremly Worthy for its price As Package And BAsicaly Makes this product here HALF price ...

I think is Reaaly Worthy to bet the 100$ For the 4 Extensions

___
I will soon get it And Then .. i will keep the Contact As Customer Support into the Support Chanel of your product ...

I tried other Solutions / I mean All every others there is in asset store so far ...
And they never reached to to all i was needing on Flexibility And workflow.
_____

As far as i studied This is reaaly a Deeply Amazing like no other Solution Released so far ...
And puts unity Really Ahead of other Game Engines...
COngratulations for the amazing Achievement.

Hope i Have Pushed This Development a litle bit further from what was Initialy ment to be ...

People might not See At first
/ But This Extension can give reaaly a new Whole Dimension to Unity Game Development

... Expecialy if With Some more features :
make this be Aplied With the Oclusion Sectors Lods Nested Hierachy loads from DIsck in one ....

This Pack can radicaly change the way we work with unity ... Beside Overcoming Itself The fact of Unity not Beying a 64Bits Editor / but still making full Usage of 64Bits Exe Compiling and player ... or giving Absurd Large levels Possibilities to MOBILES Development ...

Reaaly What you have done in teh COMPLETE pack http://www.sectr.co/complete.html IS A COMPLETE REVOLUTION ...

Now lets see how easy it is or not to Put all its features into work ....

GOOD LUCK WITH SALES WISH YOU A VERY REVOLUTIONARY DEVELOPMENT !
For you and your product ! Good luck !

MY VERY BEST REGARDS


TRISH DIAN / TRIAX GAME STUDIOS
​

 

Can you explain why I get an error message when creating Sectors? "objects overlap..." ,then I get many red bound boxes
Also, the dialog box doesnt allow for a yes selection, seems busted.
I'm having issues with the dynamic culling and portals, nothing seems to work correctly... maybe I need the bug fix you mentioned?
I've created sectors by selecting appropriate assets and creating it, then a portal between. With the portal, I have the front facing towards me as I'm approaching with the current sector set as front, next set as back. is this right?

The auto culling of objects in Viz, they need to be in a sector to work correct?
Is there a way to do the culling without the portals?

Thanks!

 

Sorry for the troubles. I'm more than happy to help. I'm going to make a more in depth video for Core that explains some of this, but I haven't had time yet.

Sectors are defined by the bounds of the *renderable* children. Lights can of course be part of a sector, but they are not used when determining the main Sector bounds (a design decision I made to keep Sectors from being unnecessarily huge). You'll get that warning and see the red boxes if you create a Sector, and some children (often lights) extend beyond that sector and into other Sectors. Sometimes that is totally fine, and sometimes it's not, depending on the game.

As an example, a light that extends beyond a Sector and into another may affect objects in the other Sector. However, if you're streaming, those children won't be instantiated until the Sector is loaded, which might create a visual pop, depending on how your scene is laid out. Culling can have similar problems. If you say yes to the the dialog prompt when you create a Sector will automatically add Member components to anything that extends out an overlaps. Member is the component that you use to tell SECTR that an object should manage itself. It can still be a child of a Sector, but it will be responsible for managing its own children.

Well, that would be the case if not for the bug you found. I just repro'd it here. It's a dumb mistake I made. To fix it, just replace Line 48 of SECTR_CoreMenu.cs with this:

Code (csharp):

1. if(sharedChildren.Count > 0  EditorUtility.DisplayDialog("Overlap Warning", "Some object in this Sector overlap other Sectors, which may cause unexpected behavior. Would you like to make them Members instead of children?", "Yes", "No"))

The VIS bugfixes I mentioned earlier were specific to occluders, so I don't think that's your problem. Can you try the above fix and email support@makecodenow.com with a screenshot of your setup? I can help you sort through whatever VIS issues you're having more quickly that way.

 

Thank you for the detailed feedback! I'll try to wrap my head around this, I'm an artist so allot of this is new, usually designers handle this.
What would be the side effect of the bugs you mention? Not sure what's a bug or if I have a bad setup.
That makes total sense, must be the lights. Thanks! I'm really impressed with the dynamic culling of objects!

 

No problem. Glad you like the culling! I also appreciate the questions. I want SECTR to be as user friendly as possible, so it's invaluable to understand what people find confusing.

If you'd like, email support@makecodenow.com. I'd be happy to find a time to do a screenshare over skype/google hangout. I can take a look at your scene and we can talk through any conceptual questions you have, too.

 

Awesome, great support! Taking the lights out of the sector did it! works wonderfully so far, portals and culling.
Thanks!

 

Very glad it's working for you!

Just so you know, it should be totally ok to have lights as children of your Sector. However, if they are showing red bounding boxes and you're seeing visual artifacts/popping, then you can press the "Fix Shared Children" button in the Inspector for the Sector. That will automatically add Member components to each problem light and the visual artifacts should go away. If they do not, it is a bug, and I will fix it as soon as I hear about it.

The Member component is basically how you tell SECTR about objects that can be in multiple Sectors at once. You can put Members on global objects like the player or AI (you'll see STREAM does this automatically for things like the Neighbor Loader). You can also put Members on children of Sectors. When you do this, the Sector will basically ignore that object and its children, because it trusts the Member component to take care of them properly.

Lastly, in your specific case, if you like there current setup where those overlapping lights are no longer children of the Sector, be sure to add a Member or Culler* component to them. SECTR VIS can cull lights (including shadow casting ones), but it will only cull things that it knows about, (i.e objects that are part of a Sector or part of a Member).

*Culler auto-adds a member and then gives you some additional fine control over how the culling on that object works. You can add them to Sectors, too, for more control. If you play the game in the editor and select a Sector, you'll notice that Cullers are auto-added to any Sectors that don't have them.

 

I just submitted SECTR 1.0.2 to the asset store. It includes some good bug fixes and optimizations and improvements based on feedback from early adopters. It should be available on the store by mid week, but if you want an early copy of that, send an email to support@makecodenow.com and include your invoice number.

SECTR 1.0.2 Release Notes
CORE
* Documentation updates and fixes.
* Fixed bug in Portal bounds computation.
* Significantly optimized Sector and Member update.
* Improved Sector creation logic in complex scenes.


AUDIO
* Optimized audio window asset search. Especially useful for large projects.
* Hardened instance API against accidental reuse.
* Pitch and Volume scalars for all audio sources and audio environments.
* Removed accidental dependencies on demo components.
* Fixed footstep spatialization in demos.
* Added new Start Music component for easily starting music when an object is created.


STREAM
* Fixed bug when exporting parented Sectors for Streaming.
* Removed accidental dependencies on demo components.


VIS
* Fixed occluder auto-orientation and reverse culling.
* Major optimizations to occluder culling.
* Occluders can occlude portals.


COMPLETE
* Converted demo to use Start Music.
* Prefabs updated with Bounds Update Mode settings.

 

Just a heads up that 1.0.2 is now available on the Asset Store.

 

Is there some reason we couldn't bake the navMesh and lightmaps in the generated chunks. I have a somewhat similar system that uses doors to persist the current level and load in the next it that works for me.

 

If you use LoadLevel (which blocks, unloads the current scene, and loads the new scene) then you can do whatever you like in the generated files. However, the main point of SECTR STREAM is to stream (i.e. no blocking loads) which requires using LoadLevelAdditive, which has different behavior depending on the kind of data you're talking about.

For lightmaps, LoadLevelAdditive will simply append the new scene's lightmaps to the global array. This works fine, except Unity will eventually overflow that array. Also, Unity will not unload those added lightmaps, so lightmap memory will simply grow and grow. A big chunk of SECTR STREAM is doing things at export time and at runtime to avoid both of these issues.

For navmeshes, LoadLevelAdditive simply overwrites the current nav mesh with the nav mesh stored in the newly loaded scene (if there is one). There is currently no way to dynamically modify nav meshes (like there is with lightmaps) hence the recommendation in SECTR STREAM that nav meshes stay in the main scene.

If you were so inclined, you could actually generate lightmaps in the exported scenes from SECTR STREAM, provided you setup a LightmapRef component correctly and made a few other modifications to the Chunk import code. So far no one has asked me for that, but if it's relevant to your interests, email support@makecodenow.com and I can tell you how to do it or put it on my backlog.

 

I don't have any need for that in SECTR at the moment but thanks for the offer.

My little system isn't meant for streaming, only breaking up the world into manageable chunks where all the objects are saved and reloaded from disk as needed. I use LoadLevel so the lightmap and navmesh are unloaded and reloaded. I fade out to black and fade in again so the pause isn't too problematic. It looks similar to the way entering and existing buildings in Fallout 3 works.

 

SECTR 1.0.3 is now live in the asset store. For folks interested in using SECTR for open world games, definitely check out the Beta Terrain GUI. It will auto create sectors and portals for your terrain, even split the terrain into multiple chunks for you. The GUI tool is in CORE, and STREAM is now aware of how to handle connected terrains. There's also a new Region Loader for easily streaming a volume around the player.

SECTR 1.0.3 Release Notes
CORE
* Beta Terrain Sectorization GUI. Ideal for setting up terrain-based open worlds.
* Additional optimizations in Member update.
* New Optimization chapter in CORE manual.


AUDIO
* Fixed a bug with max instances not properly limiting playback.
* Fixed leaking pool objects when reloading in editor.
* Fixed bug in application of fade out to HDR sources.
* Fixed Propagation Source attenuation beyond max range.
* Beta Audio System HUD.


VIS
* Fix for visibility traversal terminating early in complex scenes.
* Fixed bug with directional shadow caster bounds projection.
* Minor optimizations to portal and occluder early out logic.


STREAM
* Chunk properly handles unloads during loads and vice versa.
* Fixed duplication of extra components on Sector during export.
* Beta of new Region Loader. Ideal for open world streaming.
* Beta support for terrain grid streaming and stitching.
* Minor optimizations to Loader update logic.

 

FYI that SECTR 1.0.4 is now live on the asset store. Major improvements are Beta PlayMaker support, more improvements to Open World/Terrain tools, and a few bug fixes.

SECTR 1.0.4 Release Notes
CORE
* Beta PlayMaker Support.
* Fix a Unity warning when a Portal is created through the drawing interface.
* Beta Terrain GUI groups new objects when splitting terrain into pieces.
* Beta Terrain GUI can include static and/or dynamic objects during sectorization.

STREAM
* Beta PlayMaker Support.
* Gracefully handle invalid lightmap indices when exporting a Sector for streaming.
* Properly handle deactivated hierarchies during streaming export and import.
* Fix some missing null checks in Trigger Loader.
* Allow Imports in Stream Window even if scene is not checked out.

 

SECTR 1.0.5 is out and fixes two critical issues, one of which is a workaround for a Unity bug that can cause save game corruption. Everyone should get this fix ASAP.

SECTR 1.0.5 Release notes
CORE
* Workaround for critical serialization bug that could cause scene file corruption when creating portals in projects with mixed/binary serialization.

VIS
* Fix bug that could cause infinite loops/hangs in scenes with a lot of pass-through portals (i.e. sectorized terrains).

 

No to quite sure what I did, but I broke the demo. I was trying the more advanced door method one and went in a complete loop, after appearing back at the green room and proceeding to the yellow room the red room and it's hallway failed to load, I fell off the level going through where the door should be: http://gyazo.com/e3324cdabd9a28c715fefb32fd937e74

Yep, seems if I run in a full circuit first to the yellow room, red, blue, and back to green, then back to yellow this happens. If I run the circuit in reversed order it streams just fine, but there also seems to be a hitch with doors getting caught open but upon entering what seems not to be loaded, it instantly loads and you are able to proceed.

 

Thanks for the report. Was that the web demo or the one included in the package? If its the web demo, then I think I already fixed it. I just need to upload a newer demo to the site.

 

SECTR 1.0.6 is now out. This includes mostly UI improvements, including a new "Revert" button for folks who use STREAM as a multi-user workflow tool.

SECTR 1.0.6 Release Notes
CORE
* Fix some issues with multi-selection and custom inspectors.
* Properly orient portals created by Terrain window.

STREAM
* Added Revert option to Stream window, for teams using the Stream window as a multi-user workflow tool.

 

Hi,

Any chance you would consider adding terrain splitting to mesh based terrains instead of the Unity terrain?

 

Good question. It's straightforward to do that, just involves a lot of fiddly mesh math. I'll add it to my backlog, but I'm not sure how soon I'll get to it. Very good idea, though.

BTW - is there a particular mesh terrain solution you have in mind, or just being able to slice meshes generally?

 

I don't have a particular solution in mind. Just would like to be able take a terrain, turn it into a mesh then slice and sectorize it. I may have a go myself.

 

Awesome! If you take a stab at it, lmk how it goes.

 

It was the webplayer. Thanks for checking it out Also cool to see another fellow San Francisco developer. Seeing how the madness sale has the complete kit included, will be checking out your other products. Very nice.

 

SF devs are the best! Definitely excited to be part of the May Madness event.

 

I'm happy to announce that SECTR COMPLETE is part of the May Madness sale for 50% off on the Unity Asset Store! We've reduced the price of the individual SECTR modules (AUDIO, STREAM, VIS) to match.

There's also a new version of SECTR to celebrate this sale. 1.0.7 is likely to be the last update before 1.1.0, which will be the same code but with additional demos showing off the new features that have come online since 1.0.0.

SECTR 1.0.7 Release Notes
CORE
* Added optional PortalDetermined mode to Member. When set to true, Sector membership will only change when the object passes through a Portal (instead of whenever it enters a Sector Bounds). Ideal for games with very complex/concave scenes.

STREAM
* RegionLoader now supports Layers, to allow for more fine grained loading.
* Fixed several bugs in Stream export, including behavior that could unnecessarily break prefabs in exported scene.

 

Hi, everyone. SECTR 1.0.7 introduces a bug in Stream Import (for those of you that use it). I'll be submitting a fix tonight, but for those who need it ASAP, simply change line 44 of SECTR_StreamExport.cs from this:

Code (csharp):

1. GameObject newNode = _FindSectorByName(chunk.NodeName).gameObject;

to this:

Code (csharp):

1. GameObject newNode = GameObject.Find(chunk.NodeName);

 

Hi, I was looking at the quickstart videos and am interested in getting Sectr Complete, especially in the areas of terrain streaming to help with the frame rate. I have a few questions and hope you can help me.

1. I was wondering how Sectr Audio will compare with Master Audio. Are they pretty comparable when it comes to audio management?
2. I know that PlayMaker integration is supported. Unfortunately, our project uses uScript extensively and I was wondering if you will be providing uScript support anytime soon?

Thanks.

 

1) I've really never used Master Audio, just looked at their webpage a bit, so take this with a grain of salt. Both products have some overlap, in that they focus on providing a better UI for creating and mixing game audio. Both try to be as efficient as possible, pooling sounds, and things like that. I know that Master Audio has a more sophisticated music system, but I think SECTR AUDIO has much more sophisticated environmental audio features. That's really what I've tried to focus on with SECTR AUDIO, giving folks tools to create immersive, spatial, 3D audio.

2) To be honest I hadn't really considered it until right now. That said, PlayMaker was very easy to integrate and I suspect that uScript would be easy as well. I can't promise a timeline for it, but if you have an entire team that would license SECTR if it had uScript, then it would definitely be worth my time. Feel free to email support@makecodenow.com if you want to discuss that further.

 

Thanks for the quick reply. We are a very small group of game-lovers who are working currently on a game-project. I doubt if we will be getting more than 1 license right now, although a uScript implementation somewhere in the future would be great. Having said that, I will be getting Sectr Complete because of the advantages that it provides.