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

We're very excited to announce the release of SECTR COMPLETE on the Unity Asset Store. SECTR COMPLETE includes all current and future modules for SECTR, the suite of Unity extensions about spaces, and the connections between them. SECTR COMPLETE is automatically updated with future modules at no extra cost.

• SECTR CORE: Sectr Creation Toolkit
• SECTR AUDIO: Immersive 3D Audio
• SECTR STREAM: Seamless Scene Streaming
• SECTR VIS: Dynamic Occlusion Culling.
• Exclusive Demo Content.
• Automatically includes all future SECTR modules.

If you would like to know more about SECTR COMPLETE, check out the short video below, post a question here, check out our online demo, or email info@makecodenow.com.

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

 

Congrats on the release of your tools! Very excited about it personally. I tweeted about it just now For anyone interested, I really suggest you check it out (there is also a free version to check it out).

 

Thanks for the kind words and support. Beginnings are delicate things and support like this really helps SECTR get off the ground!

 

Man look at you go! Two threads of yours in one day for me to check out! It appears Thomas and I are your personal stalkers for the day, hehe.

Being an open-world gaming fan, streaming has seemingly been the one major thing missing from Unity, so this is pretty compelling stuff. I was tempted to roll my own node-region-neighbor based system but hell, if you want to do the work for me I'm more than happy to pay.

Cheers man

-Steven

 

Hah, thanks! I hope there are many more people like you and Thomas in the world

Also, I totally agree that Unity's build in streaming has been a big miss. Unity has pretty good plumbing for it now, but there are a lot of non-obvious gotchas and there's no UI to speak of. Glad to hear that SECTR is scratching your itch(es)!

 

Yay! So real quick...

...is it safe to assume that when a sector is unloaded any garbage collection is then at Unity's behest? (i.e. Instantiate/Destroy)

...is there a memory limiter? GTA5 managed to fit into what was left of the meager 512 megs available on last gen consoles, so I'd imagine having method to set the amount of memory you can commit would be valuable (mobile).

...is the streaming able to being utilizing assets as they come in (drip feed) or does the entire sector need to be loaded in order to then use the assets?

Tough questions I know!! (or maybe not haha)

Thanks for your time!

-Steven

 

Great questions.

When unloading a Sector, STREAM Destroys the Sector and its children, removes any unreferenced lightmaps, and calls UnloadAllUnreferencedAssets. There's probably some garbage generated by that, but I don't force a GC as that would make a hitch on unload even more likely.

There is no built in memory limitation. Unity games are too diverse and on too many platforms for me to think of something that will work for everyone. My main goal has just been to get memory as low as possible (i.e. handling tough cases like lightmaps). The Unity Memory Stats are all accurate when STREAM is enabled, and that's a good tool for devs to see what their real memory usage is.

Stream mostly uses LoadLevelAdditive (Async for pro users). Async loading pulls the data in in a thread over multiple frames, but the GameObjects are created in one go. There's no way to use them one at a time, but you can totally control the granularity of Sectors. SECTR STREAM also has a Group Loader, which lets you treat multiple Sectors as one for the purposes of loading and unloading.

 

Wonderful! Using works like stats and enabled and real, along with multiple-frames and granularity...that satisfies me duly.

Thanks again for taking the time man. I shall now speak with my monies!

-Steven

 

Awesome! I am a fan of money. If you like SECTR and have time to write a review, that would be much appreciated, too!

 

Now you're just getting greedy...

...oh fine, deal.

 

Hey, I just wanted to point out before this conversation, I wasn't really sure how SECTR could help me. I think in your video you make the mistake of explaining what it is instead of how it can help.

For example, someone describing a car: It has a frame. Some wheels. It has seats you can sit in. An engine.

Someone describing a car in a way that I can use: A car goes really fast. It might have taken you a day to get to Ogdenville before, now you can get there in less than an hour!

I much prefer the second way. Instead of telling me what SECTR is made up of and having me sort of have to figure out how it might benefit, tell me how all this stuff is superior to the alternative. It almost sounded like you were describing Unity itself in your video.

I looked at your WebPlayer demo and saw the loading and unloading -- it's too bad it can't chop up a terrain in the same way. I'm sure it's the way Unity handles terrains, but that would have been amazing.

 

Really good feedback. I'm definitely learning a lot about how to best explain and promote this tech, which is particularly tricky since much of it is pretty systemsy.

In my Intro video, I tried to end each section with a use oriented line, but you're right that I should lead with that more. I'll keep that in mind for future updates to the materials.

As for terrain, it would def be nice to have a more granular terrain chunk system. That's pretty much the core of how we did open world streaming in Brutal Legend. The one workaround is to use multiple terrains attached to one another. SECTR Stream would be able to stream that.

 

Interesting stuff. Some questions:

1. If it's using LoadLevelAsync, what's the real purpose of using this system when it's built into unity?

2. could you go into more detail about texture / lightmap streaming? Is this done your end or part of loadlevelasync?


In your opinion what could unity do in order to make it more smooth?

 

Interesting questions

The main purpose of SECTR STREAM (there are other SECTR modules like VIS and AUDIO) is to provide a framework/structure that makes unity's asset loading primitives (like LoadLevelAdditive) useable/useful for a wide variety of games. As an example, Unity provides LoadLevelAdditive, but no tools/pipeline for creating scenes to use with that function. Similarly, there's no built in logic that tells you when or how you should load these sub-scenes, even if you were able to export them. Lastly, streaming, especially in Unity, has a lot of non-obvious dead ends and corner cases. How should you handle global scene data like lightmaps or nav meshes? What do you do about game objects that move from chunk-to-chunk? Why is it better to use LoadLevelAdditive than AssetBundles? SECTR STREAM's purpose is to create a framework that addresses all of these issues in a comprehensive, cohesive, relatively bullet proof fashion. At least, that's my goal

Lightmaps are a good example of one of the corner cases. By default Unity stores all lightmaps in a global structure in the scene, which means that all lightmaps are loaded by default. That can be a ton of memory even for a modestly sized level. By default, LoadLevelAdditive will simply append to this array, which is not a very useful behavior and makes unloading super not easy. Most Sectors only reference a few lightmaps, so it's a waste to load more than necessary. SECTR Stream handles lightmap streaming essentially by tracking lightmap references at export and at runtime. At export, STREAM creates a component that has references to the lightmap textures used by that chunk. Also, lightmaps are removed from the base scene once they are no longer referenced by anything. At runtime, when a chunk is loaded, its lightmap textures come in along with all of the referenced assets in that scene. STREAM then fixes up the master Lightmaps array with these textures so that lightmapped objects look right. When a chunk is unloaded, the opposite happens. Except, not quite. Because lightmaps can be shared between Sectors, unloading requires careful bookkeeping (reference counting) so that lightmaps are only cleared out when they are no longer referenced.

The biggest thing Unity could do to improve streaming would be to continue to lower the main thread CPU cost of loading things "asynchronously". Even with the async APIs, Unity still winds up doing a lot of main thread asset fixup post-load, and they may even synchronize the main and render threads. They also need to lower the CPU cost of instantiating objects, or at least time slice that work more over multiple frames. The aggregate is that there can be enough main thread CPU time to cause a noticeable hitch, especially on slower systems, and all that stuff happens at a level I can't really fix or workaround.

Ok, short questions, long answers, but hopefully helpful ones!

 

Just an FYI for anyone using VIS or COMPLETE, there may be a bug in Occluder Auto-Orientation code. I'm traveling and haven't had time to confirm it yet, but if you have any confusing behavior with Occluder auto-orientation, please email support@makecodenow.com. If I confirm the bug, I'll post a fix here and include the fix in the next update.

 

Already put this asset at the top of my purchase list when the funds are available in a couple of weeks. The demos are great, it looks like a must buy. Fantastic work.

 

Awesome! Thank you!! More demos coming soon, too

 

I just bought the pack and am currently working through the various components and possibilities. Looking great so far. However, there's one thing: When I tried to delete the "Demos" folder (throwing off ballast for my project) an error popped up:



I found the missing script in "SECTR/Demos/Core/Scripts/...".

After I had copied all scripts from this "Demos" subfolder to the folder "SECTR/Code/Core/Scripts/..." I was finally able to delete the Demos. Maybe it would make sense to put all scripts that are required for the core system (without the demos) outside the demo folders, so that one does not have to carry the demos all the way with the project.

 

How embarrassing. That's totally my fault. I'd organized things in the current folders so that folks could easily do what you're trying to do and just remove the demo folders and be fine. I didn't think about the CharacterAudio -> CharacterMotor dependency. CharacterAudio uses messages, so it doesn't even need the CharacterMotor dependency. I'll just update the messages to pass in the surface type.

I'm traveling now but will be home this afternoon. I'll make this fix, check for any other bogus dependencies, and include it in my next update. If you (or anyone else) wants the proper fix before it's live (usually takes a few days), just email support@makecodenow.com and I'll send you the latest files.

Thanks for buying and supporting SECTR!

 

Hi there

Wow, that was fast, thanks for your reply (-:

Don't worry, that's not an (urgent) issue. Copying over the dependencies to "SECTR/Code/Core/Scripts" works fine for me for the time being. However, you might want to look for further dependencies. E.g. "SECTR_FPController" (not to be mixed with "SECTR_FPSController") is also in "Demos" and seems to have a dependency from somewhere in "SECTR/Code/Core/Scripts" as well. I had to copy it over as well.

 

Definitely. I just got home and you're right, there are deps on SECTR_FPController and SECTR_CharacterMotor in SECTR_Loader.cs. I'll fix those, too, probably in the next few hours. Again, if you want the fixes early, just email!

 

FYI that I confirmed there is a bug in Occluder auto orientation. The fix will be in this week's point relase, but in case anyone needs it sooner, simply replace Line 96 of SECTR_Occluder.cs with the following:

Code (csharp):

1. Vector3 cameraVec = cameraPos - occluderPos;

 

FYI that I just finished fixing these. They will be in the point release I submit tomorrow.

 

FYI that there is a GUI bug in a Sector creation helper dialog. This will be fixed in 1.0.1 but you can fix it yourself replacing 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"))

 

Do you think this would be good for 2d game as well?
I thought about to some of its features for a mobile game.
Are mobile games supported with this asset?
Do a modern normal pc need this for a 2d game?
What would be the benefits for mobiles?

 

Sectr Complete looks like an awesome package.

We're making a sandbox game where users create their own content. We talked about the idea of streaming but in the end decided it would be a bit complex, what with players messing around how many objects were in level and where those objects were placed. Since it wasn't a core feature for first release, we set streaming levels aside for later. However, with the release of SECTR Complete we're reconsidering.

Our game is for mobile. One of the problems we've encountered is that a mobile's GPU can only handle rendering x amount of geometry before it simply crashes. Since we had decided to leave streaming until later the simple solution was to just limit the amount of geometry a player is allowed to build(e.g. limit amount of GameObjects the player can place in world), so there is never the chance of a player gazing upon more vertices then the device can handle.

If we went with Sectr Complete, it would really give us the option of letting the player create large worlds--which would be swweeeet-- but we would have to limit the amount of GameObjects the player could place per sector. With your package is that easily doable? Does Sectr Complete keep track of all gameObjects placed with in a sector at runtime? If so, is there a public readonly that we can read off of on our end?

Thank you in advance.

 

It depends on the game and which SECTR modules you're talking about. SECTR VIS (occlusion culling) probably isn't much use, unless it's a 2.5D with a lot of complexity to the camera. SECTR AUDIO works fine in 2D or 3D, and the audio asset management and mixing tools would be valuable anywhere. Using HDR audio in a 2D game might be super cool. SECTR STREAM will also work for 2D, but you'd have to set of the Sectors with a bit of care. Also, you'd only want to use it if your 2D game had a lot of art, more than fit into memory, or you wanted the entire game to be one big seamless experience for the player.

SECTR works on all platforms Unity supports, including mobile. The next release, 1.0.1, has some good optimizations for mobile, and mobile is always a challenge for all systems performance wise, but I definitely write everything as efficiently as possible because I know so many people want a solution that's viable on Android and iOS.

If you want to talk specifics about your game privately, email support@makecodenow.com.

 

Thank you for the kind words and the interest in SECTR. I'll answer your question as best I can.

In short, yes, you can easily find out which objects are in a Sector. Specifically, all children of a Sector are considered part of it, and the Sector class keeps a flattened list of all of these children. There is also a Member component, which you put onto objects that need to be Sector aware, but potentially part of multiple Sectors. Sectors keep track of all Members that are in them, and Members keep track of all Sectors they are in (it's possible, even common, for a Member to be in multiple Sectors at a time). You can see this first hand by downloading the free SECTR Core from the asset store. It has the tools for creating Sectors by hand plus all of the API I just described.

One caveat with STREAM is that Unity will only let you export new scenes (which is part of how SECTR STREAM works) from the Editor. If you want to let players create spaces, then stream them out of memory, than stream them back in, that's not something SECTR supports directly. I can give you some guidance about how you can persist modifications to Sectors across loads and unloads, but if the entire Sector is dynamic, there is no good way (yet) to stream all of that dynamic data back in. It sounds like for your game you could stream the world and have a system for persisting the player placed objects, and that might work. If you wanted to do something like Streaming Minecraft, a game where literally every voxel is player creatable/modifiable, then SECTR STREAM will not help you much. Some of the features I described above in SECTR Core might still be helpful, but that module is free (including source) and you're more than welcome to build anything on top of that foundation that you like.

If you'd like to evaluate SECTR STREAM (or COMPLETE), just email support@makecodenow.com, tell me a bit about your game, and I'll send an eval package your way.

 

I have another question and maybe it is stupid but i am not a programmer.
I have at least two assets that help me to pool objects and let them be reused because i read that is faster on mobiles instead to instantiate and destroy them.
Will pooling work with this and if so what do i have to look for?

With this i mean your full pack because i only think it make sense to buy it with it´s full power to a good price

 

Hi, RandAIThor. Pooling is definitely faster in Unity, especially on mobile. SECTR actually does its own pooling wherever possible, especially in the AUDIO and VIS components. Generally, you don't need to worry about pooling with SECTR, but if you want to pool and re-use regular GameObjects in your scene, the components that ship with SECTR AUDIO should work with your existing pooling plugins.

PS - 1.0.1 will be in submission later today, which contains some good bug fixes and additional optimizations.

 

Good to know, i think you have a new customer
So the pooling is controlled by SECTR. Do it controll the spawning too so that if my player move along, kill one big boss and without a reason he goes back and then came to the same place, do he again will have to fight against this big boss that he killed before?

edit:
On the other side i would like it if my i.e. Health pack that should spawn i.e. Every 3 minutes, still spawn in the Same situation like above.

 

SECTR only pools the things that it creates itself; it can't automatically pool things that you create externally to SECTR (like the big boss). Basically, if you buy SECTR you can be confident that it do what it does as efficiently as possible (including internal pooling), and then you can use your other libraries to pool objects that you create, like the big boss or health pack. Make sense?

 

@MakeCodeNow Thank you for the quick reply!

So you're saying dynamic Sector creation at runtime is not supported yet (does the "yet" mean that you might be contemplating that feature?)), but that it would be indeed be possible to build in Unity editor, say, 50 sectors, and then at runtime persist the objects which the player places inside each sector. This would take some work on our end but is doable.

Tell me if I'm in the ballpark here on how to implement this, just to make sure I understand the scope of work involved to help prioritize.

My guess is that we would want to build a class that contained edge coordinates of the sectors, and when a gameObject is placed in world at runtime we compare the transform.position to the sectors locations and register that gameObject with the Sector that matches.

After that, if the player moves a gameObject we call an UpdateSector(GameObject updateMe); to place the gameObject in its new Sector, should the player move the object across Sector boundaries.

At save time we grab the stored gameObjects off of the Sectors and store them in a Dictionary<Sector, GameObject>and save that data.

OnReload we load gameObjects and restore/repopulate the Sectors gameObject lists using the Dictionary we saved earlier.

Am I thinking along the correct lines? Will that work? Is there a better way?

Thank you for your help.

 

Dynamic Sector creation is totally supported. However, to stream a Sector from disk it first needs to be exported into its own .unity file, which you can only do from the editor. You're absolutely right, though, that you could create the static Sector data in the Editor, export it, and runtime persist the player created objects.

Actually, the SECTR Member component will do pretty much all of that for you. If you have a Member on an object, there's a function to get all of the Sectors it's currently in, and Event's you can hook into if you want to know when that list changes.

Yes, you'll need to handle the persistance of those player created objects yourself. Saving player objects to a container and restoring from that container seems like a totally workable idea.

Anyway, I hope that helps! Write back if you have more questions.

 

Make sense and so i have bought it
Thank you for your answers.

 

Thanks for your support! Feel free to post more questions here if and when you 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.

 

FYI that 1.0.2 is now live on the Unity Asset Store.

 

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.

 

Sectr Complete says that more will be added later. What kind of commitment to that is there? Where do you draw the line on creating a new series of assets, rather than adding them to this set?

I guess I just want to see that commitment written down before I lay my money on the set.

One of the things I'd like to see in the future is a Portal-style teleportal where the locations might not actually be adjacent. Bonus points for non-rectangular and runtime usage. I know you mentioned you were considering it, but is it something that's definitely on your plate?

 

Those are good, honest questions. Let me answer them as best I can.

Right now the only really firm commitment I can make is that if/when I add new SECTR modules, SECTR COMPLETE owners will get them for free. If you're considering buying SECTR, I would do it based on what is available in SECTR now at the current price. If you are interested in those features, and think the price is fair for what you get today, then it's worth buying. If not, just hold off and see what comes next.

Of course, I do plan to add more modules to SECTR, but I can't honestly tell you which ones or when. The Tele-portal stuff is one of the top candidates, but it's also fairly involved. At the same time, there's a ton of interest in open world features, and of course I need to continue to fix and improve the current modules. Some of the modules I'm considering require more art than my current ones, so I have to figure out logistics and costs there. Lastly, my wife is pregnant and I've heard that babies can take up a lot of time. I suspect that in a few months my main new module will be him

As to your questions about whether a new module is part of SECTR or a new series of assets, my main criteria is if it makes sense to be part of SECTR, then it will be. In general, I want SECTR to be bigger and most of the things I'm thinking about creating would naturally fit into SECTR. That said, I may release a few small plugins, like face tracking in Android, which really don't have anything to do with Sectors or Portals, and hence wouldn't be part of SECTR.

 

So I just started reading about your tools and the first question that popped into my head was: Would this work well with a system like Photon Pun+?

I am just starting a multi-player combat app for Android using photon cloud. If it would are there any tutorials for doing this?

Thanks!

 

I think SECTR should work just fine with Photon. Just add SECTR components to your scene or game prefabs and I think everything should "just work". Is there a specific use-case that you're concerned about?

 

No It was just in General I am trying to wrap my head around the concepts. For example I can see how the Core package could help for an "Interior" But I am not sure how it would be used outside in a city environment. I get payed on Friday so I am sure I will be purchasing this. So I thought I would start thinking now about practical applications for your tools.

 

You can think of a Sector as a chunk of space, and a Portal as a connection between chunks. Those chunks can be rooms of a building, or they can be a city block, or a section of terrain. SECTR 1.0.3 includes a beta tool that will auto-sectorize terrain for you, and you could do something similar in a city type environment. The only real caveat is that you have to be a bit more careful if you try to use SECTR VIS in big, outdoor spaces, to make sure you setup your Sectors and Occluders in a way that doesn't spend more CPU than it saves.

 

FYI that SECTR 1.0.4 is now live in the asset store. Major improvements are beta support for PlayMaker, additional Open World/Terrain authoring improvements, UI polish in AUDIO, and bug fixes all over. Enjoy!

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.

AUDIO
* Beta PlayMaker Support.
* Multi-select support in Audio Window.
* Arrow navigation in Audio Window.
* Press space to audition cue or clip, Esc to stop.
* UI fixups in Bus and Cue inspectors.
* Fix subtle bug with distance attenuation sometimes being too large.
* Fix bug that could cause occluded sounds to not become un-occluded.
* Optimizations for redundant pitch and volume changes.

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.

VIS
* Beta PlayMaker Support

 

FYI that a user just found a critical bug in the terrain tools and visibility culling. Fortunately the fix is easy.

To anyone affected by this and doesn't want to wait for 1.0.5, simply delete the following lines from SECTR/Code/Vis/Scripts/SECTR_CullingCamera.cs:

Code (csharp):

1. if(currentNode.portal)
2. {
3.     visitedPortals.Remove(currentNode.portal);
4. }
5.  

If you don't want to modify the code yourself, email support@makecodenow.com and I'll send you a code patch.

PS - For terrain occlusion culling to work, make sure to setup an invisible layer as described in the Vis docs.

 

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).

 

SECTR 1.0.6 is now available on the asset store. It includes one critical fix to VIS, and some nice improvements everywhere.

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

AUDIO
* New keyboard shortcuts (Enter to rename, Ctrl/Cmd D to duplicate, Del/Bksp to delete).
* Ensure horizontal scroll bars don’t appear unless absolutely necessary in Audio window property panel.

VIS
* Properly fix portal traversal culling bug introduced in 1.0.5. Now traversal works for all known portal types and scene configurations.

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

 

Hello,

I want to ask about PlayMaker support. Is SECTR completly controllable by this? Or does it need some coding anyway, even though someone uses PlayMaker? I'm asking if you have to know c# to use it with PlayMaker.