Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bac9

Pages: 1 ... 4 5 [6] 7 8
: )

Yeah, I already pinned the issue down to premultiplied shaders not actually creating any alpha output. Standard transparent shaders used by UITexture work.
Can you tell me what am I losing quality wise if I were to switch to non-premultiplied shaders? Or it's only a matter of saving texture size (RGB vs RGBA) and being compliant with some mobile hardware?

Edit: Erm... yeah, it's not as simple as I thought. Changing the shader on the altas material has no effect. I guess I need to reimport it?
Edit 2: Okay, a big problem - a black sprite with 50% alpha writes 50% background color + 50% black into RGB of the render texture instead of 100% black, which kills the look of every single semi-transparent element. :(

Edit 3: This can be hidden if you can agree to only use one color for every semi-transparent UI element ever - by setting the clear color of the camera to that color, ensuring that RGB values rendered to texture will stay right. In my case, with black semi-transparent frame fills, that would be setting the camera clear color to black. But that's not ideal as I'd prefer camera clear color to be white, to avoid black leaking into predominantly white UI pixels.

Edit 4: I wonder if the issue can be resolved by creating a custom NGUI shader that writes proper transparency to alpha while refusing to actually display that transparency for the camera when there are no other pixels rendered using that shader underneath, rendering sprite color at full intensity in that case. That will lead to completely proper colors being fed to the RenderTexture, but doing so indiscriminately will kill any and all overlays, potentially leading to background sprites overwriting white text with black in render texture RGB, and other nasty issues. I'm not sure if it's possible to do right.

I'm encountering a pretty strange problem. My UI camera is rendering to a texture which I then use in a material applied to a curved surface attached to a player. It's a standard approach for UI rendering with Oculus, Elite-style world space UI and other use cases like that. Everything works fine, except for one little thing - for some strange reason, not a single UISprite is written to the alpha of that RenderTexture. All UITexture and UILabel objects are rendered perfectly, but sprites vanish. To illustrate:

Original UI:

What I get in the render texture:

I'm not sure what could be the reason for that, frankly.

  • I have checked the source textures, the problem still appears when you use an image that works with UITexture on a UISprite, so it's not an issue with all-black alpha in a source
  • UITextures don't have a custom shader/material, so they are rendered through exact same shader atlased sprites do, which rules out issue with the shaders

Any ideas?

If that helps, I'm using a 3D UI prefab NGUI creates from the menu with minimal changes. UI camera is using Solid Color clear mode with the alpha of the background color set to zero (it's the only clearing configuration that works properly with render textures, anything else will leave trash from the previous frames in the texture).


Edit: Looks like I overlooked the shader difference between UITexture and UISprite - the latter is using premultiplied shader. Can you fill me in on why can't premultiplier shader be rendered into texture and what would I lose by switching the atlas to unlit colored shader used by UITexture by default?

Quite minor problem, but I'm curious if it's possible to fix it. At the moment you are adding your custom packets directly into TNet code, which obviously becomes a problem if an update contains any of those files, as that will wipe your packets out. I'm on a relatively safe side with the version control, as I can check the old version again and copy the missing stuff, but that won't be the case for every user. Is there a way to separate custom packets into standalone files so that this situation won't arise no matter what TNet files are updated in the coming versions?

NGUI 3 Support / Re: NGUI/NDATA data binding features.
« on: August 21, 2014, 05:14:03 AM »
As far as I understand, if you want to go full MVVM and not just do simple bindings in UI, uFrame will probably fit your needs, - it's a pretty well executed framework built on that pattern. I have not worked with it much myself, but it's popular, reviews look positive and docs I've read show impressive system.

Quite simple and straightforward problem: I have noticed that some of the textures in my scenes are sometimes automatically converted to UISprites if the sprites they are using are present in some atlas. I guess it's a helpful optimization that saves time in some use cases (e.g. design a UI with a scattered collection of texture files, generate an atlas from what you actually ended up using, get whole scene instantly converted to properly use it), but in some other use cases it's unfortunately harmful: in particular, when you are using UITexture to allow custom shading of a particular UI element (for example, when you use UITexture with a custom GrabPass based UI shader for semi-transparent blurry window backgrounds).

So, is there a way to disable that option?

NGUI 3 Support / Re: UIPanel movement appears to be Integer based
« on: August 05, 2014, 06:52:54 AM »
The UIPanel Transform in my project snap to a scale of (0.002777778, 0.002777778, 0.002777778) when it was first created, so 1 unit is definitely not 1 pixel.
Actually, that looks like a precisely correct scale for a 360px screen. Provided the camera sees only one unit area, any child of a root scaled like that will have 1:1 unit to pixel scale.

NGUI 3 Support / Re: Feature request: inverse sliced sprite rendering
« on: July 21, 2014, 08:06:06 AM »
IMHO it's looking weird because of the refresh button on the right. Its shadow doesn't change when you change the "depth" of your rectangle.

The depth change like that won't be used on that particular element of the UI, I'm just using it as an example.

The titular sliced sprites will mostly be used for other things, like lists on hover and click, to attract focus through depth.

NGUI 3 Support / Re: Feature request: inverse sliced sprite rendering
« on: July 21, 2014, 06:27:01 AM »
I looked up the creation of custom widget classes on the net and stumbled on the following thread:

You can create a custom widget if you want -- just derive from UISprite or UIWidget, and override the OnFill function.

I have just tried to do precisely that, and unfortunately encountered the following error:

Assets/SupportScripts/UI/UISpriteInverse.cs(42,30): error CS0115: `UISpriteInverse.OnFill(UIWidget, int, BetterList<UnityEngine.Vector3>, BetterList<UnityEngine.Vector2>, BetterList<UnityEngine.Color32>)' is marked as an override but no suitable method found to override

As far as I understand, the issue pops up because UISprite overrides the OnFill itself, instead of having it as a virtual method. I admit I'm not very familiar with how override methods in C# are supposed to work when the method of a parent class is actually an override of another method of yet another parent class (UIWidget, in this case) instead of a virtual method, but I guess that's the cause of the error. After all, you can't make a method both virtual and override, which makes it not possible to override the OnFill.

Is that a relatively recent change in NGUI that was made after the answer I have quoted above? Or maybe I misunderstand the quote and should declare the OnFill method in my inheriting class as "new" instead of "override"?


Edit: Scratch that, looks like I have overlooked the arguments in my override method and left an UIWidget reference among them, which was not there in actual OnFill method in UISprite and was only used by the delegate method. Intellisense won't highlight that, but that breaks the override. Fixed the arguments to match the UISprite OnFill and errors disappeared - looks like override chains are allowed in C# after all.

Now, another question is - how can I add a new property drawer to the UISpriteInverse inspector in a similar way you handle Widget and Anchor drawers? I have looked at the custom editor code you use and I'm not sure I'm familiar with the way you do it, me being only experienced with traditional one class/one custom inspector approach which your code doesn't look similar to (you don't even use OnInspectorGUI). Is there some straightforward way of doing it, similar to, let's say, DrawDefaultInspector, that will allow me to add new EditorGUILayout elements to the sprite inspector without breaking or hiding your complex editors?

Not sure if I worded it clearly, but in essense my question is: how can I add new custom inspector elements to the custom inspector of a class that inherits from a class that already has a custom inspector?


Edit 2: Solved the custom inspector problem by duplicating all contents of UISpriteInspector class into new custom editor and adding OnInspectorGUI into it like this:

   public override void OnInspectorGUI ()
      base.OnInspectorGUI ();
      UISpriteInverse s = target as UISpriteInverse;
      UISpriteInverse.OffsetStyle style = (UISpriteInverse.OffsetStyle)EditorGUILayout.EnumPopup ("Mode",;
      float offsetLeft = EditorGUILayout.Slider ("L", s.offsetLeft, 0f, 128f);
      float offsetRight = EditorGUILayout.Slider ("R", s.offsetRight, 0f, 128f);
      float offsetTop = EditorGUILayout.Slider ("T", s.offsetTop, 0f, 128f);
      float offsetBottom = EditorGUILayout.Slider ("B", s.offsetBottom, 0f, 128f);
      if (GUI.changed)
         NGUIEditorTools.RegisterUndo ("Sliced sprite changed", s.gameObject); = style;
         s.offsetLeft = offsetLeft;
         s.offsetRight = offsetRight;
         s.offsetTop = offsetTop;
         s.offsetBottom = offsetBottom;
         s.MarkAsChanged ();
         NGUITools.SetDirty (target);

Not sure if it's the cleanest way and is sure doesn't look as fancy as the property drawers you have created for widget and anchor variables, but it works.

And now, here's the new sprite type in action.

NGUI 3 Support / Re: Feature request: inverse sliced sprite rendering
« on: July 17, 2014, 10:04:41 AM »

    The format took a bit of time to figure out, but it works now.
    Few questions I'm still puzzled with, though:

    • Is it safe to directly modify the vertex positions in a mesh? I get issues with distorted mesh persisting even after a component controlling inverse slicing was removed and affected sprite was marked as changed many times, leading me to believe that geometry of the sprites is not rebuilt too often. Is there a way for me to force the geometry rebuilding, so that I will have an option to instantly restore the original state of a mesh once inverse slicing component becomes unnecessary?
    • Is there a way to get a sprite to update it's geometry in the editor so that offset editing can be previewed without using play mode? I tried a few methods provided by NGUI classes, including MarkAsChanged, but nothing works, unfortunately.
    • Are there any potential issues that can arise from a sprite going outside of bounds NGUI expects it to be? Haven't noticed any so far though, and in theory only stuff like minor issues with UIPanel clipping comes to mind.

    NGUI 3 Support / Re: Feature request: inverse sliced sprite rendering
    « on: July 17, 2014, 05:08:34 AM »
    Would recently added onPostFill delegate work for that sort of modification?
    Looks like it's exposing quite a bit of data, probably enough to implement that.

    Buffer offset: 0
    Vertex count: 36
    V0: 0 / -221 / 0
    V1: 0 / -213 / 0
    V2: 8 / -213 / 0
    V3: 8 / -221 / 0
    V4: 0 / -213 / 0
    V5: 0 / -8 / 0
    V6: 8 / -8 / 0
    V7: 8 / -213 / 0
    V8: 0 / -8 / 0
    V9: 0 / 0 / 0
    V10: 8 / 0 / 0
    V11: 8 / -8 / 0
    V12: 8 / -221 / 0
    V13: 8 / -213 / 0
    V14: 1272 / -213 / 0
    V15: 1272 / -221 / 0
    V16: 8 / -213 / 0
    V17: 8 / -8 / 0
    V18: 1272 / -8 / 0
    V19: 1272 / -213 / 0
    V20: 8 / -8 / 0
    V21: 8 / 0 / 0
    V22: 1272 / 0 / 0
    V23: 1272 / -8 / 0
    V24: 1272 / -221 / 0
    V25: 1272 / -213 / 0
    V26: 1280 / -213 / 0
    V27: 1280 / -221 / 0
    V28: 1272 / -213 / 0
    V29: 1272 / -8 / 0
    V30: 1280 / -8 / 0
    V31: 1280 / -213 / 0
    V32: 1272 / -8 / 0
    V33: 1272 / 0 / 0
    V34: 1280 / 0 / 0
    V35: 1280 / -8 / 0

    UVs size: 36
    UV0: 0.65625 / 0.5439453
    UV1: 0.65625 / 0.5517578
    UV2: 0.6640625 / 0.5517578
    UV3: 0.6640625 / 0.5439453
    UV4: 0.65625 / 0.5517578
    UV5: 0.65625 / 0.5986328
    UV6: 0.6640625 / 0.5986328
    UV7: 0.6640625 / 0.5517578
    UV8: 0.65625 / 0.5986328
    UV9: 0.65625 / 0.6064453
    UV10: 0.6640625 / 0.6064453
    UV11: 0.6640625 / 0.5986328
    UV12: 0.6640625 / 0.5439453
    UV13: 0.6640625 / 0.5517578
    UV14: 0.7109375 / 0.5517578
    UV15: 0.7109375 / 0.5439453
    UV16: 0.6640625 / 0.5517578
    UV17: 0.6640625 / 0.5986328
    UV18: 0.7109375 / 0.5986328
    UV19: 0.7109375 / 0.5517578
    UV20: 0.6640625 / 0.5986328
    UV21: 0.6640625 / 0.6064453
    UV22: 0.7109375 / 0.6064453
    UV23: 0.7109375 / 0.5986328
    UV24: 0.7109375 / 0.5439453
    UV25: 0.7109375 / 0.5517578
    UV26: 0.71875 / 0.5517578
    UV27: 0.71875 / 0.5439453
    UV28: 0.7109375 / 0.5517578
    UV29: 0.7109375 / 0.5986328
    UV30: 0.71875 / 0.5986328
    UV31: 0.71875 / 0.5517578
    UV32: 0.7109375 / 0.5986328
    UV33: 0.7109375 / 0.6064453
    UV34: 0.71875 / 0.6064453
    UV35: 0.71875 / 0.5986328

    NGUI 3 Support / Feature request: inverse sliced sprite rendering
    « on: July 15, 2014, 09:51:57 AM »
    A few days ago I had to implement Android L-style UI elements of arbitrary size which can change their depth and have to cast appropriately scaled/blurred shadow as that depth slides around during animations. This turned out to be a bigger problem than I have expected, because while the Sliced sprite type allows you to make a shadow that perfectly fits to a rectangle of an arbitrary size (using anchoring), it does not allow you to scale the border quads of the shadow sprite while anchoring the center quad to a parent object.

    The problem stems from the fact that Sliced sprites, of course, get their full scale from their height/width properties, and calculate the size of the border quads by subtracting offsets from the resulting area. So, if you want to create a shadow that has a gradient covering 16 pixels around a rectangle, you have to create a sliced sprite with 16px gradients and set up it's border offsets to 16px, then using anchoring with the 16px offset. Now, if you want the very same rectangle to cast a 32px shadow, you can't reuse the same shadow sprite.

    I think this issue can be fairly easily fixed, opening a way to a very rich variety of UI elements ranging from shadows with dynamically adjustable radius to reusable frames, animated pixel-perfect edge highlights and so on. Here is how the proposed additional sprite rendering mode can work.


    • Use UISprite properties to set up the dimensions of the center quad instead of the total sprite dimensions
    • Use the pixel size of the borders the sprite has listed in the atlas properties only to set up UV mapping of the 9-quad sprite, and not for the actual size of the border quads
    • Set up the size of the 8 border quads using an additional property "border size or something", be it one int for a uniform offset, or a Vector4 for anchor-like flexible offsets)

    How feasible is it to add something like this to NGUI?

    TNet 3 Support / OnNetworkDisconnect not being called
    « on: June 23, 2014, 10:10:11 AM »
    Maybe I have overlooked something in the documentation, but is OnNetworkDisconnect supposed to be called in the latest version of TNet? As far as I see, only OnNetworkConnect with the false result argument is actually being called in the event of a client being disconnected from a server, and OnNetworkDisconnect remains inactive no matter the scenario. This is reproduced on AutoJoin example shipped with TNet.

    I'm not having any obstacles with that, keeping both connect/disconnect related code under OnNetworkConnect is somewhat convenient even. But I'm curious whether OnNetworkDisconnect was deprecated/deactivated or whether I'm doing something wrong (like, maybe it's only supposed to work on an object with an active TNObject)?

    TNet 3 Support / Re: Building a modified server executable
    « on: June 20, 2014, 01:38:53 AM »
    Thanks, that works!

    One more question: how to add namespaces and individual classes properly? I know about the Add Reference option in the VS solution explorer context menu (but that one only accepts .dll, .exe, .manifest, etc. files) and I know that you can drag individual .cs files into the solution explorer, but I'm not sure the latter is a proper way of doing it, because I'm noticing that changes to a class from that .cs file done through a Unity-generated solution are not replicated when open that class in the server solution (suggesting that drag-and-dropping .cs files into a server solution probably creates duplicate file somewhere and not a reference). Am I missing some obvious third way of adding classes to a solution?

    Let's say I want to add SimpleJSON namespace (containing just one small .cs file) into the server project in the very same way you added TNet namespace into it. How do I go about it?

    Update: A-ha, looks like I was moving stuff into the solution explorer incorrectly. Instead of using root folder and dragging individual .cs file I wanted, I should have dragged whole Plugins folder into Assets folder already present in the server solution explorer, and then use "Exclude from project" context option to drop every single file but SimpleJSON.cs.

    Okay, I ignored the "requested address is not valid" message yesterday, moved the project to a different PC to continue working on it, and pulled the repo on the first PC right now. The message is not appearing anymore, for whatever reason. Maybe it was some harmless quirk of Windows/hardware and not something in the code. So I guess that problem is solved, heh.

    TNet 3 Support / Building a modified server executable
    « on: June 18, 2014, 06:21:50 AM »
    Sorry if that was brought up before, but there a page in the documentation or a tutorial available somewhere covering how can you modify the standalone server code and build it? I'm not terribly familiar with this aspect of VS, - I only ever used it to work on the code and never touched the build options and project management options. I imagine there are dozens of tutorials on the subject if I would know what to search for. In particular, I'm wondering about two things:

    1. How to get TNetServer project working? I understand that TNet ships with the source code of the server and I see Assets/TNet/TNetServer/TNetTest/ServerMain.cs plus .csproj/.sln in the server archive, but I'm not sure if I'm opening them correctly. I'm not seeing how ServerMain.cs is supposed to work with "using TNet;" when it's classes aren't there in the TNetTest folder. Am I supposed to somehow modify the project settings or move TNet classes from Assets/TNet to Assets/TNet/TNetServer/TNetTest folder?

    2. How to build TNetServer project properly? It's probably something straightforward like hitting a hotkey and choosing the name/location of an executable, but there are plenty of branching menus in VS and I'm not yet sure where to look for the build option.

    Reason I'm touching the subject in the first place is that I need to implement a simple authentication system. I already have it up and running on a client, and it's possible to leave this way by using very dirty tricks like distributing username/password DB to every single client without ever touching server logic, but it would be nicer to have it in one place. Hence the questions above.

    Pages: 1 ... 4 5 [6] 7 8