Scene Layers Overview:
Scene Layers is an Editor Extension for Unity 3D. It assists in group style organization in the scene hierarchy and provides additional functionality through the inspector window. As Unity does not have basic grouping or layering functionality seen in other engines (Unity Layers are physics and rendering, with a 32 layer limit), it is common to group game objects using another game object. This works fine so long as the parent game object’s transform is not modified.
Scene Layers expands on this method of grouping and adds ease of visibility and functionality to the hierarchy and inspector. Scene Layers are light and can be used in the editor and its features can be used at runtime if needed. Scene layers is an answer to basic game engine editor functionality that should exist by default, but does not; as such, Scene Layers and included tools and tech are Free Open Source Software
On a previous project I was tasked with creating dynamic lightning that could strike the player if too close to a storm cloud. This was an interesting challenge for me as the lightning had to look great and be dynamically rendered on everything from a high end iOS device to a low end Android device. As this was in the Unity Game Engine the language of choice was C#, which is good as C# is my language of choice these days.
While researching procedural generation for this effect I ran across a lot of implementations that stuck to using multiple line segment structs shoved into a list. This really would not do. A single lightening effect could sprawl out to hundreds or thousands of line segments. Then it would need to be converted into a bill-boarded mesh. The game could have up to 4 Lightning clouds on screen at a time with up to 4 more Queued up above. So at most it would have to support 6 dynamically generated lightening strikes at a time. The lightening had between one and three main bolts, with a probability that at any point along the line another branch could form. It was a big branching fun looking lightening and enough Vector math to crush the heart of the poor mobile cpu.
My color space conversion class has been pushed to Bitbucket and Github. As this is managed code the conversions are not suitable for real time use, but more that suitable for general use. I did not use .Net Color structure in the conversions, I instead opted to use Numerics.Vector4. This allows the color conversions to take advantage of simd hardware where available.This will provide a speed up if your build is x64, with the optimize flag enabled. Here is a list of first release conversions available in the class.
- HSV to RGB
- Lab to RGB
- Lab to XYZ
- RGB to HSV
- RGB to Lab
- RGB to XYZ
- RGB to Yuv
- XYZ to Lab
- XYZ to RGB
- Yuv to RGB
All Conversion are in floating point and support an alpha channel. Each Method is overloaded for single color vector or for a color vector array. It is MIT licensed making it free to use for any purpose. If you wish to contribute just branch and let me know.
Recently I have been working on a .u3d (ECMA 363 4th Edition) compliant decoder in c#. In the specification for the External File Reference block is the requirement to support file name filters that may have the wildcard characters ‘?’ and ‘*’. Dot Net does not include a native method for matching wildcards characters in strings, so I went online to see what solutions others have come up with.
Turns out a really popular response to matching wildcards is to use RegEx. Unless the application is just doing this check once and never again, I cannot communicate just how poor this solution is. It is by far the simplest; a couple lines of code and you are done. RegEx is very powerful but that power comes at a cost; I had to remove it from the full test as it was just too time consuming. Recursive algorithms also seem to be a popular choice, but again they can be slow. I tried the Visual Basic “trick” and even though the performance was more suitable it failed on many of the test cases. The test consists of 100 different strings and wildcard strings that I gathered from the web. Some are “gotchas” intended to test if the method meets the requirements of wildcard rules others are possible uses like URLs. I did eventually find a method that only fails on one test case. I still felt this method was too slow for use in a file loader/decoder. So I decided to throw my hat into the ring and see if there was any way, ugly or elegant that would be faster and still pass every test. I am accustomed to writing real time code that must perform its duty fast enough that the application can go through a full update in 16-33 milliseconds (60 – 30 frames per second). I was determined even if it had to be some sort of dirty hack.
Mobile friendly barbarians, All packed into a single texture/material. Sculpted and painted in Zbrush, low poly in done in Maya. I originally intended to make this a higher poly PBR set but switched over to mobile spec. They perform fairly well; 34 instances on Tegra2 (with full kit), 800 instances on a nvidia 450/i5 PC. Those numbers would be cut in about half if dynamic shadows are used or increased quite a bit on a device newer than a Terga2.