using UnityEditor; 

public class LightMapSize_512 : EditorWindow 
{ 
    [MenuItem("LightMapSize/Size_512")] 
    static void Init() 
    { 
        LightmapEditorSettings.maxAtlasHeight = 512; 
        LightmapEditorSettings.maxAtlasWidth = 512; 
    } 
} 

public class LightMapSize_1024 : EditorWindow 
{ 
    [MenuItem("LightMapSize/Size_1024")] 
    static void Init() 
    { 
        LightmapEditorSettings.maxAtlasHeight = 1024; 
        LightmapEditorSettings.maxAtlasWidth = 1024; 
    } 
} 

public class LightMapSize_2048 : EditorWindow 
{ 
    [MenuItem("LightMapSize/Size_2048")] 
    static void Init() 
    { 
        LightmapEditorSettings.maxAtlasHeight = 2048; 
        LightmapEditorSettings.maxAtlasWidth = 2048; 
    } 
} 

public class LightMapSize_4096 : EditorWindow 
{ 
    [MenuItem("LightMapSize/Size_4096")] 
    static void Init() 
    { 
        LightmapEditorSettings.maxAtlasHeight = 4096; 
        LightmapEditorSettings.maxAtlasWidth = 4096; 
    } 
} 

Install "Lightmapping Extended":

Step 1 is to pick up "Lightmapping Extended" on the Unity Asset Store! and commit it into the project!https://www.assetstore.unity3d.com/#/content/6071

While most of the settings are a bit beyond pick up and play, the ability to save and load xml configurations is a life saver and if you are working with a team it can really speed up the workflow. There are great tool tips for the rest of the settings. Without a formal lighting background I make do with what I have and search for what I don't know.

Document Changes:

Despite knowing and saving your production settings with Lightmapping Extended, when dialing in a light setup I take screenshots of the editor and the light map settings panel. This lets me get good before and after images documented when I make subtle changes to the overall settings. It also lets me show others how the system works and how the scene has evolved.

UV scale / ratio fine tuning:

After I get my main light sources in and where I want them I run a high quality bake so I can see where major shadows fall. Armed with this I can manually select all prefabs that are 100% within shadow and set their "Scale in Lightmap" setting down to .1 - .05. Once you have done this to all relevant objects you can do the reverse for 'hero' objects. Unfortunately you often want to increase the light map resolution on large objects such as the ground, and depending on how the geometry is split up the UV block might be too big and bulky to do too much with. (Currently Unity 4.1 does a terrible job auto laying out UV's - according to this thread that should be resolved in 4.2)

Maximize your resolution within your output targets:

Once I have all the manual light map scaling in place I then nuke my settings back down to a 10-20 second render time and start inching the resolution up or down to get everything at my desired output target. We often want to get everything onto 1 1024 map (which we can still cut down later). I want the scene to look as good as it can be - even if it means spending an hour bumping up the resolution by .01!

Editing the light map .exr file:

While my options are limited I from time to time do bring in the final .exr image into Photoshop for some slight level adjustments Note that doing this will probably hose you if you need to do dual light map realtime lighting. Photoshop is pretty limited in what you can do to a 32 channel image however I do have a work around for solidifying unity's output if I feel the image will benefit form it. since you can't use the magic wand with a tolerance of 1 to select out and delete the black I save off a version with 16 channels, save a selection of what I want to delete and load it back into the 32 bit file, delete out the black and run Solidify A on it to blend in the image. I am 100% sure there is an easier way to do this - I just have no experience editing HDR files, let alone 16bit in photoshop.

Wishes:

I would LOVE to be able to set what I want my output to be and have Unity fill in the rest. I usually have to spend an hour or two over the course of a scene setup fine tuning the atlas resolution trying to get it all onto 1 1024 map for instance. This changes and needs to be re-optimized every time you manually set a scale override on something in your scene (which I have the tendency to do quite often!)

Additionally I would LOVE to have some sort of automated workflow occur where I could set up a stationary camera that takes the same screenshot after every bake and splices in the settings data as well!

That's all for now, hope this saves somebody some time!

출처 http://mkingery.com/blog/unity-lightmapping-tips-tricks-and-thoughts

파일을 열 때 에러가 났다는 것인데 파일이 존재함에도 불구하고 에러가 난 것입니다.  

이런 경우는 해당 파일이 다른 프로세스에서 사용중이기 때문에 나옵니다.  

그래서 원본 파일을 템프 파일에 복사한 후 원본이 아닌 복사본을 열어버리고.. 나중에 다시 템프 파일을 삭제해 버리는 것이죠. 

                        string fileTemp = fileFullNm + "_tmp";
                        File.Copy(fileFullNm, fileTemp, true);

                        //다른프로세서가 사용중인것을 방지
                        FileStream fs = new FileStream(fileTemp, FileMode.Open);

                        ~~~~

                        File.Delete(fileTemp);

[출처] C# 다른 프로세스가 사용중이라면서 에러가 나는경우에 이렇게|작성자 doghole

링크 : http://smilejsu.tistory.com/576

링크 : http://istudy.tistory.com/75

링크 : http://warmz.tistory.com/365

Link : http://forum.codecall.net/topic/71788-reading-excel-files-in-c/

Platform Dependent Compilation

Unity includes a feature named "Platform Dependent Compilation". This consists of some preprocessor directives that let you partition your scripts to compile and execute a section of code exclusively for one of the supported platforms.

Furthermore, you can run this code within the Editor, so you can compile the code specifically for your mobile/console and test it in the Editor!

Platform Defines

The platform defines that Unity supports for your scripts are:

Also you can compile code selectively depending on the version of the engine you are working on. Currently the supported ones are:

Note: For versions before 2.6.0 there are no platform defines as this feature was first introduced in that version.

Testing precompiled code.

We are going to show a small example of how to use the precompiled code. This will simply print a message that depends on the platform you have selected to build your target.

First of all, select the platform you want to test your code against by clicking on File -> Build Settings. This will bring the build settings window to select your target platform.

Build Settings window with the WebPlayer Selected as Target platform.

Select the platform you want to test your precompiled code against and press the Switch Editor button to tell Unity which platform you are targeting.

Create a script and copy/paste this code:-

// JS
function Awake() {
  #if UNITY_EDITOR
    Debug.Log("Unity Editor");
  #endif

  #if UNITY_IPHONE
    Debug.Log("Iphone");
  #endif

  #if UNITY_STANDALONE_OSX
    Debug.Log("Stand Alone OSX");
  #endif

  #if UNITY_STANDALONE_WIN
    Debug.Log("Stand Alone Windows");
  #endif	
}


// C#
using UnityEngine;
using System.Collections;

public class PlatformDefines : MonoBehaviour {
  void Start () {

    #if UNITY_EDITOR
      Debug.Log("Unity Editor");
    #endif

    #if UNITY_IPHONE
      Debug.Log("Iphone");
    #endif

    #if UNITY_STANDALONE_OSX
	Debug.Log("Stand Alone OSX");
    #endif

    #if UNITY_STANDALONE_WIN
      Debug.Log("Stand Alone Windows");
    #endif

  }			   
}


// Boo
import UnityEngine

class PlatformDefines (MonoBehaviour): 

	def Start ():
		ifdef UNITY_EDITOR:
			Debug.Log("Unity Editor")

		ifdef UNITY_IPHONE:
			Debug.Log("IPhone")

		ifdef UNITY_STANDALONE_OSX:
			Debug.Log("Stand Alone OSX")

		ifdef not UNITY_IPHONE:
			Debug.Log("not an iPhone")

Then, depending on which platform you selected, one of the messages will get printed on the Unity console when you press play.

Note that in c# you can use a CONDITIONAL attribute which is a more clean, less error-prone way of stripping out functions, see http://msdn.microsoft.com/en-us/library/4xssyw96.aspx.

In addition to the basic #if compiler directive, you can also use a multiway test in C# and JavaScript:-

#if UNITY_EDITOR
    Debug.Log("Unity Editor");
#elif UNITY_IPHONE
    Debug.Log("Unity iPhone");
#else
    Debug.Log("Any other platform");
#endif

However, Boo currently supports only the ifdef directive.

Platform Custom Defines

It is also possible to add to the built-in selection of defines by supplying your own. In the Other Settings panel of the Player Settings, you will see the Scripting Define Symbols textbox.

Here, you can enter the names of the symbols you want to define for that particular platform, separated by semicolons. These symbols can then be used as the conditions for #if directives just like the built-in ones.

Global Custom Defines

You can define your own preprocessor directives to control which code gets included when compiling. To do this you must add a text file with the extra directives to the "Assets/" folder. The name of the file depends on the language you are using, and the extension is .rsp:

As an example, if you include the single line "-define:UNITY_DEBUG" in your smcs.rsp file the define UNITY_DEBUG will exist as a global define for C# scripts, except for Editor scripts.

Every time you make changes to .rsp files you will need to recompile for them to be effective. You can do this by updating or reimporting a single script (.js, .cs or .boo) file.

If you want to modify only global defines, you should use Scripting Define Symbols in Player Settings, because this will cover all the compilers. If you choose the .rsp files instead, you'll have to provide one file for every compiler Unity uses, and you won't know when one or another compiler is used.

The use of the .rsp files is described in the help section of the smcs application which is included in the Editor installation folder. You can get more information by running "smcs -help". Also, bear in mind the .rsp file needs to match the compiler being invoked. For example, when targeting the web player, smcs is used with smcs.rsp; when targeting standalone players, gmcs is used with gmcs.rsp; when targeting MS compiler, csc is used with csc.rsp; and so on.

출처 : https://docs.unity3d.com/Documentation/Manual/PlatformDependentCompilation.html

Unity AssetBundle Dependencies

In the last few weeks I’ve spent quite a lot of time with Unity’s Asset Bundle system. Understanding how dependencies were tracked. What determines GC cleanup of assets and understanding why the editor profiler produces particular results has been a bit of a struggle. I’m lucky enough to work for a group that allows me to have access to the Unity source code however so this has probably been slightly less painful than it has been for others going down this same path.

First, I’d like to acknowledge what appears to be the most useful piece of Unity Answers information that I’ve come across, located here. This seems to explain the general mechanics of how to include dependencies using the push and then pop method in an editor script.

For my purposes, I created a test project that contained several prefabs all containing simple GUI elements. These elements all used the same fonts and referenced the same textures. This was to verify that, in the editor profiler and in instruments, assets were in fact being shared.

I’ve included my example editor script below to demonstrate some of the methods I used for packing the bundles. In my case, I am traversing all assets in my prefab folder and treating elements with the word “Global” in their name as shared. If I were to have many dependency bundles instead of the one that I have in this example I would have to sort the order in which I am packing these bundles.

using UnityEngine;
using UnityEditor;

using System.IO;
using System.Collections.Generic;

public class AssetBundleBuild : MonoBehaviour
{
    [MenuItem("AssetBundle/Build Bundles")]
    private static void BuildBundles()
    {
        DirectoryInfo directory = new DirectoryInfo(Application.dataPath + "/Prefabs");
        FileInfo[] files = directory.GetFiles("*.prefab", SearchOption.AllDirectories);

        bool shouldPush;

        BuildPipeline.PushAssetDependencies();
        foreach (FileInfo f in files)
        {
            shouldPush = !f.Name.Contains("Global");
            if (shouldPush)
            {
                BuildPipeline.PushAssetDependencies();
            }

            // Get each asset path
            string path = Application.dataPath + "/Bundles/" + f.Name.Substring(0, f.Name.LastIndexOf(".")) + ".bundle";
            string assetPath = f.FullName.Substring(f.FullName.IndexOf("Assets", f.FullName.Length - f.FullName.IndexOf("Assets")));

            Object asset = AssetDatabase.LoadMainAssetAtPath(assetPath);
            //Debug.Log("Asset to pack " + asset + " , " + asset.name);

            BuildAssetBundleOptions options = 
                BuildAssetBundleOptions.DisableWriteTypeTree | 
                BuildAssetBundleOptions.CollectDependencies | 
                BuildAssetBundleOptions.CompleteAssets | 
                BuildAssetBundleOptions.DeterministicAssetBundle;

            if (!shouldPush)
            {
                Object[] d = EditorUtility.CollectDependencies(new Object[] { asset });

                List<Object> dSource = new List<Object>();
                List<string> dNames = new List<string>();

                // In this case I'm attempting to manually collect dependencies for tracking purposes
                // however this does not always seem to be necessary unless you have complex prefab heirarchies
                foreach (Object o in d)
                {
                    if (o != null && !dSource.Contains(o))
                    {
                        Debug.Log(" -- d " + o + " , " + o.name + " , " + o.GetType());

                        dSource.Add(o);
                        dNames.Add(o.name);
                    }
                }

                Debug.Log("::BUILDING DEPENDENCY BUNDLE:: " + asset.name + " , " + dSource.Count);
                BuildPipeline.BuildAssetBundleExplicitAssetNames(
                    dSource.ToArray(), 
                    dNames.ToArray(), 
                    path, 
                    options, 
                    EditorUserBuildSettings.activeBuildTarget);
            }
            else
            {
                Debug.Log("::NON DEPENDENCY:: " + asset.name);
                BuildPipeline.BuildAssetBundleExplicitAssetNames(
                    new Object[] { asset }, 
                    new string[] { asset.name }, 
                    path, 
                    options, 
                    EditorUserBuildSettings.activeBuildTarget);

                if (shouldPush)
                {
                    BuildPipeline.PopAssetDependencies();
                }
            }
        }

        BuildPipeline.PopAssetDependencies();

        Debug.Log("[AssetBundleBuild] Complete.");
    }
}

Now, from the standpoint of packing shared dependencies, this seemed to work with most asset types such as textures or prefabs but when I included fonts, while they wouldn’t be duplicated across multiple bundles, I would always see two copies of my fonts. One set would be flagged as being ‘used by scripts and native code’ and the other would only be flagged as ‘used by native code’. After performing numerous tests, I discovered that upon opening the dependency bundle containing the font I was interested in, if there was a copy of the font in the project directory as well, both versions would be loaded into Resources. I haven’t been able to verify whether this happens on device as well but my inclination is that it only occurs in the editor.

The Problem of the Decompression Buffer

Another problem that became visible when working with large quantities of bundles that (based off of conversations with Unity technical representatives and the 4.2.0b3 beta client) may have changed in such a way as to render the problem less dire is that Unity, as of 4.1.5, allocates an 8mb decompression buffer per each asset bundle being opened. If there is an attempt to parallelize these requests, each request will allocate it’s own decompression buffer. This can be rather disconcerting as one can see how the allocation amount (especially on restricted memory devices) can really get a guy down.

Although 4.2.0b3 seems to be reducing the decompression buffer size down to 0.5mb per bundle the problem of parallelization still persists. The only immediate solution for individuals loading any quantity of bundles seems to be amortizing the requests in such a way as to prevent too much overlap. If someone out there has a suggestion to mitigate this problem otherwise please drop me a line mcelroy.jon[at]gmail.com

출처 : http://blog.jonmcelroy.com/post/55526714506/unity-assetbundle-dependencies

KGC AssetBundle