I have some textures containing some transparency parts (a donut, for example, which would show a transparent center). What I want to do is fill the middle of the donut (or anything else) with a plain white, in code (I don't want to have a double of all my assets that need this tweak in one part of my game).
Is there a way to do this? Or do I really have to have 2 of each of my assets?
First it is possible to change a transparent texture to not-transparent, if it wasn't then graphic editors would be in trouble.
Solution 1 - Easy but takes repetitive editing by hand
The question you should be asking yourself is can you afford the transition at run time or would have two sets of textures be more efficient; from experience I find that the later tends to be more efficient.
Solution 2 - Extremely hard
You will need a shader that supports transparency and that it marks the sections that have to be shaded white. That is, it keeps track of which area will be later filled with white. It is implied that since your "donut" is already transparent on some parts then it already uses that texture that has an alpha, but you will have to write your own shader mask and be able to distinguish which is okay to fill white and which is not (fun problem here). What you need to do is find the condition in which that alpha no longer needs to be alpha and has to be white. Once the condition is met you can change the alpha of via the Color's alpha property. The only way I see you able to do this is if there is a pattern to the objects, so that you can apply some mathematical model to them and use that to find which area gets filled. If the objects are very different then the make two sets of textures starts to look more appealing.
Solution 3 - Medium with high re-use value
You could edit the textures to have two different colors, say pink and green. Green is the area that gets turned white and pink is always transparent. When green should not be white then it is transparent. You would have to edit your textures by hand as well.
Related
I am trying to minimize SetPass calls in Unity canvas.
Consider the following example:
The rendering in canvas happens layer by layer. The rendering sequence can be like the following:
Red squares (+1 set pass call)
Text "1" and yellow squares (+2 set pass call)
Text "2" and pink square (+2 set pass call)
Text "3" (+1 set pass call)
Or, it might be a little better:
Red squares (+1 set pass call)
Yellow squares and then text "1" (+1 set pass call)
Pink square and then texts "2" and "3" (+2 set pass calls)
Because of this, drawing is switching from default image material to text material and back. The result of this drawing will produce at least 4 draw calls, instead of 2. Even though only 2 materials are in use. This example also assumes that Red, Yellow, and Pink squares weren't batched.
Question: is there a way to ensure that text will be always drawn on top?
Notes:
TextMeshPro UI material (mobile-overlay) doesn't help here.
Unity 2019.3.12.f1
All texts are actually placed as last layers (e.g. there is nothing drawing on top of them).
Batching helps sometimes. However, complex UI might use several materials. Since my intention is to always draw text over everything, isn't there a general solution for this?
Z-order makes drawing order even worse and switching between materials happens more frequently.
My guns have a certain range. When hovering over one I want to demonstrate what that means. So I've added a 3d-object (a flattened cylinder) which I want to show/hide onMouse-enter/leave.
But first I need it to be transparent - I've searched and found how - It's materials rendering mode must be transparent, and the color must have an alpha value (here 128).
But it looks VERY SOLID BLACK to me...?
I am stuck on a blending problem that appears to have only started once I started blending without any color. I am painting a grey suit and using shades to capture the lighting realistically. For some reason, when I paint with a dark grey over a light grey, with say 20% opacity, with enough strokes, the color I am painting will match the color in the color picker. With the reverse situation (light to dark), the paint tool never quite blends to the color in the color picker, it is always a shade or two off. No matter how many times I stroke the area, it will not become the color I have chosen. It has me dumbfounded and is crippling my ability to make light and shadow and show depth.
I have tried googling and messing with every possible option, deselecting all, triple checking what layer I am in, but I cannot seem to find anyone else with this problem...
I openned GIMP 2.8 (stable version) and the development version of GIMP and tried a procedure like the one you tell about:
Indeed, when working with 8 bit color, the wayGIMP is structured internally will prevent the gray values to converge toa precise shade of gray in same cases. When GIMP applies 20% of the difference between a value 129 to a pixel valued 127, that "20%" is a "0.4" darkening, which is rounded down to zero.
This certainly won't be dealt with on current GIMP stable, since it is fundamental to the way 8 bit color works, ansd given that GIMP unstable - the 2.9 version that will eventually be out as GIMP 2.10 can be set to use higher color precision so that this behavior does not happen. (With floating point pixel values, you just get as close as you want from your shade of gray).
I'd suggest you either find a compiled "nightly" version of GIMP 2.9 for your system, or try some other way of painting: maybe using a more spread shade of gray with values varying over a broader range, and after you are done, compressing the results to the desired range with the Levels or Curves tool.
Anyway, this is offtopic here - if you have further doubts on painting, please take the question to graphicdesign.stackexachange.com
I am trying to draw a UIColor on the screen of a view-based app, and I am trying to do so using HSB. It is absolutely necessary for me to use HSB in this case. I can create a UIColor object with any S value from 0.0f to 0.75f, but past that the numerical changes have no effect on the actual saturation displayed. I need it to be 1.0f, but it is still using 0.75f. Any ideas on why it is doing that, and how I can make it work?
Because of how it works, + (UIColor *)colorWithHue:(CGFloat)hue saturation:(CGFloat)saturation brightness:(CGFloat)brightness alpha:(CGFloat)alpha actually does not use HSBA values internally; it is simply a wrapper around the device RGB color space.
I think that under extreme cases there surely would be chances that a constant H/B/A + a .75–1 S yields colors that differ so slightly it became imperceptible, despite the color components being digitally tracked as very precise floats. As saturation drops, the number of “available” colors decreases (as the display could only show this many colors, dropping the saturation compresses the usable colors) and the chance of collision simply rises.
Given that your scenario uses H0-1, B1, A1 colors which nearly invalidates my assumption, I was curious and have made a test project; the colors however worked correctly. I’m on iOS 4 SDK GM, so maybe it’ll help if we know which SDK you’re working against.
After doing some experimentation, I've discovered what my issue was.
I was using a for loop to draw single-pixel lines across a view, each with a hue value greater than the previous one. I was doing this to create a color spectrum to be used for a color picker.
My issue arose because I was using CGContext paths, not rects, to do the drawing. Paths, by default, "straddle" the created path with pixels. Because I was setting the width to one, CoreGraphics was forced to average between pixels, creating a desaturated effect. Setting the width to two set the saturation correctly, but the gradient of the spectrum was no longer smooth.
My fix for this issue was to use rects instead of paths. They did not blend between pixels, and the saturation issue was fixed.
I need to place labels with a transparent background over a variable-content UIImage. Readability will vary significantly depending on the relationship between the color of the label's text and the color/luminosity of the area of the image displayed under the label. Since the image will be constantly changing, the color of the label's text needs to change in sync.
I have found several techniques for determining the color, perceived luminosity etc of a single pixel. However, I need to rather quickly (while a view loads) determine the rough perceived color/luminosity of an area of the UIImage under the frame of the UILabel. I presume I will also need to measure the alpha because the same color/luminosity looks different at different alpha values.
Is there a way to calculate such a value for an area? Will I be reduced to simply summing pixels? If it comes to that, is there an algorithm to accomplish this?
I've thought of two possible approaches:
Perform some "folding" operations i.e. combining pixels from one half of the area to the other half. Then repeat until I get a single value. Would this be practical? How would you logically combine pixels to average their perceived color/luminosity?
Sample a statistically significant number of pixels in the area and then combine them (somehow) to get a rough measure.
I think this problem comes up a lot these days with people being so found of customizing backgrounds. Seems like something that would be worth my time to bang out a category or class to handle this and then share it around.
What about simply outlining your text in a way that it will show on both dark and light backgrounds?
This is how it is handled in other situations where text must be displayed over a background with unknown content (for example, films with subtitles).