SOLVED:
Before handling the Video RGBA Data and pushing it to the texture, I was setting the Unpack Alignment to 4. glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
Simply discarding this, or setting back to 1after handling the video frame memory fixes the issue.
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
- END UPDATE -
*Update: This only happens when I am uploading a texture to a mesh. This is being done with opengl es 2.0. That mesh is in 3d space though obviously, and does not overlap the 2d UI text even after the 2d and 3d are composed together. Merely disabling the plane mesh entirely fixes this. Any indication as to why, or how to fix this would be greatly appreciated.
Original Post:
I would appreciate any insight as to why the font looks so odd in the image below and how to fix it. This does not happen in editor, only on device.
I have tried every suggestion that I have seen out there. The script from http://answers.unity3d.com/questions/900663/why-are-my-unity-ui-fonts-rendering-incorrectly.html for instance, as well as rebuilding the font with a much smaller subset of characters, as someone suggests the font atlas is getting full and dropping glyphs to make room for dynamic character changes.
Here is an image:
This DOES NOT happen when the text is already entered. Only after a field is updated such as a score change or the like. I have tried both 32 and 64 bit builds, and it happens on new and old ipads. I have also tried multiple fonts, including Arial.
Related
I’m trying to build a drawing/painting app for the iPad, with textured brush tips and paper.
So far, all drawing app example codes I've come across seem to work by stroking a path. However, I'd like to actually apply a texture all along the path, to simulate say, an oil brush, or charcoal.
Here is an example of a brush tip texture: Bursh tip
The result when painting with the same brush tip: Result
In the results, the top output is what it looks like when the "brush tip" texture is applied far apart along the path.
The bottom result is the texture applied with very small steps along the path. Those who've worked in Photoshop with custom brushes will find this familiar.
I had once prototyped this in Processing years ago (I've since lost the source code), and got it to work in real-time.
In Processing, I converted both the brush tip PNG and the canvas (or the image I'm painting on to) into an array of integers. Then, I simply copied the values from the brush tip to the canvas texture, at the appropriate index. At the end of the cycle, I displayed the image, for that time-step. Repeat this dozens of times in-between each point returned by the mouse.
How would I approach this in iOS, and in real-time? I tried this (https://blog.avenuecode.com/how-to-use-uikit-for-low-level-image-processing-in-swift) but it's way too slow.
This makes me believe Metal might be the only way forward. Is that true, or am complicating this unnecessarily?
Thank you for any guidance!
PS. I'm coding in Swift 5, targeting iOS 13, in Xcode 11.5.
Welcome!
I recommend you check out Core Image. It's Apple's framework for image processing (on a higher level than Metal, though it can integrate with Metal). Unfortunately, the documentation is a bit out-dated, but I'm sure you can translate it into Swift.
Here Apple describes how you would realize a painting app with Core Image and here you can download the corresponding sample project.
I've been writing a little planet generator using Haxe + Away3D, and deploying to HTML5/WebGL. But I'm having a strange issue when rendering my clouds. I have the planet mesh, and then the clouds mesh slightly bigger in the same position.
I'm using a perlin noise function to generate the planetary features and the cloud formations, writing them to a bitmap and applying the bitmap as the texture. Now, strangely, when I deploy this to iOS or C++/OSX, it renders exactly how I wanted it to:
Now, when I deploy to WebGL, it generates an identical diffuse map, but renders as:
(The above was at a much lower resolution, due to how often I was reloading the page. The problem persisted at higher resolutions.)
The clouds are there, and the edges look alright, wispy and translucent. But the inside is opaque and seemingly being rendered differently (each pixel is the same color, only the alpha channel is changed)
I realize this is likely something to do with how the code is ultimately compiled/generated in haxe, but I'm hoping it's something simple like a render setting or blending mode I'm not setting. But since I'm not even sure exactly what is happening, I wouldn't know where to look.
Here's the diffuse map being produced. I overlaid it on red so the clouds would be viewable.
Bitmapdata.perlinNoise does not work on html5.
You should implement it by yourself, or you could use pre-rendered image.
public function perlinNoise (baseX:Float, baseY:Float, numOctaves:UInt, randomSeed:Int, stitch:Bool, fractalNoise:Bool, channelOptions:UInt = 7, grayScale:Bool = false, offsets:Array = null):Void {
openfl.Lib.notImplemented ("BitmapData.perlinNoise");
}
https://github.com/openfl/openfl/blob/c072a98a3c6699f4d334dacd783be947db9cf63a/openfl/display/BitmapData.hx
Also, WebGL-Inspector is very useful for debugging WebGL apps. Have you used it?
http://benvanik.github.io/WebGL-Inspector/
Well, then, did you upload that image from ByteArray?
Lime once allowed access ByteArray with array index operator, even though it shouldn't on js. This is fixed in the lastest version of Lime to avoid mistakes.
I used __get and __set method instead of [] to access a byte array.
Away3d itself might be the cause of this issue too, because the code of backend is generated from different source files depending on the target you use.
For example, byteArrayOffset parameter of Texture.uploadFromByteArray is supported on html5, but not on native.
If away3d is the cause of the problem, which part of the code is causing the problem? I'm not sure for now.
EDIT: I've also experienced a problem with OpenFL's latest WebGL backend. I think legacy OpenFL doesn't have this problem. OpenFL's sprite renderer was changing colorMask (and possibly other OpenGL render states) without my knowledge! This problem occured because my code and OpenFL's sprite renderer was actually using the same OpenGL context. I got rid of this problem by manually disabling OpenFL's sprite renderer.
I have a very simple test code which draws a moving triangle. In Chrome it works fine, however on an Android 4.1 Device with the CocoonJS 1.4.1 launcher (which funnels work to OpenGL ES 2.0) a random effect pops in:
The triangle is drawn, but quite often also a bit translated triangle is also drawn (more exactly, the extra triangle seems to be a replica of a formerly drawn one, but the distance is not consistently the same). The tri needs to be moved with some minimal speed for the effect to show (or maybe the replica is just hidden if moving is slow). The tint of the replica seems to be a bit different (even though the fragment shader color is constant), but it might be some alpha magic.
Other CocoonJS WebGL demos work fine on the device, however they don't exhibit fast movement. OpenGL benchmarks run fine.
Drawing multiple triangles has the same effect. Even though gl.Clear is used, it seems like part of some previous buffer shines through. Have you seen anything similar? Any ideas?
Thank you so much for your report, this is a known bug and we are working to solve this issue.
btw, by changing the setInverval time to this one: setInterval(loop, 16); should solve the problem temporarily.
I packed up several individual sprites and generated a big sprite-sheet 2048*2048 in size with Zwoptex. But I scale down to match each iOS device such as 2048*2048 for iPad HD, 512*512 for iPhone, etc.
I found out that "Spacing Pixel" option in Zwoptex will effect the result of sprites rendering on device. That value means a space (in pixel) between each individual sprite packing up inside sprite-sheet. For instance, if I set that value too low then there's more chance that pixel bleeding will occur on newer or better device as well as older device. But if I increase that value, the chance lowers and for certain value that is high enough, pixel bleeding (hopefully) won't happen.
Anyway, I set value to around 17-20 which is really high and it consumes valuable space on sprite-sheet. The result is, on iPhone simulator, there's still a problem.
As we can only restricts some devices from install the game for certain iOS version, but iPhone 3GS can still update to newest version thus I need to solve this problem.
So I want to know the solution on how to prevent pixel bleeding problem to occur across all iOS devices ranging from iPhone to iPad (included retina).
It would be great to know any best practice or practical solution on selecting certain value for "Spacing Pixel" between sprites to remove the problem away when rendering.
If only the Simulator shows those artifacts, then by all means ignore them! None of your users will ever run your app in the Simulator, will they? The Simulator isn't perfect.
A spacing of 2 pixels around each texture atlas sprite frame is enough (and generally recommended) to kill all artifacts caused by pixel bleeding. If you still see artifacts, they're not a direct cause from too little spacing. They can't be.
I'm not sure about Zwoptex, do you actually have to manually create each scaled-down version of the texture atlas? You may be doing something wron there. Try TexturePacker, I wouldn't be surprised if the artifacts go away just like that.
For example, one type of artifact is caused by not placing objects at integer positions. You may see a gap (usually a black line) between two objects if their position is something like (1.23545, 10.0) and (41.23545, 10.0). Using integer coordinates (1,10) and (41,10) would fix the issues. The difficulty is that this goes all the way up the hierarchy, if these object's parent node is also on a non-integer position you can still experience this line gap artifact.
If you search around you'll find numerous cause and effect discussions for cocos2d artifacts. One thing to keep in mind: do not use the CC_FIX_ARTIFACTS_BY_STRECHING_TEXEL macro. It's not a fix, it doesn't even come close. It kinda fixes the non-integer position artifact and introduces another (much worse IMHO): aliasing/flickering during movement.
I'm currently extending my OpenGL-UI system, for this i rewrite the font part and faced a issue which appears when using mipmapping. Because of the fact that images say more than thousands of words:
As you can see the font's transparency is fading out ( the text should be displayed 8 times! ), this happens only when using LUMINANCE_ALPHA-textures. The code which loads the textures is basically the same but they differ in the formats used, this is what LUMINANCE_ALPHA uses:
TexImageInternalFormat.LUMINANCE_ALPHA, TexImageFormat.LUMINANCE_ALPHA, TexImagePixelType.UNSIGNED_BYTE
Linear filtering is enabled and clamp is set to GL_CLAMP_TO_EDGE. For me it seems like a mipmapping issue but i tried a lot of different settings and it isn't working and, as i already said, RGBA textures are working without any issues. The application also runs on iOS so using a LUMINANCE_ALPHA-texture saves a lot of ram compared to a RGBA.
What could cause this and how can i solve it?
As it turned out the ImageFormat settings have been wrong:
LA8 = new ImageFormat("LA8", TexImageInternalFormat.LUMINANCE_ALPHA, TexImageFormat.LUMINANCE_ALPHA, TexImagePixelType.UNSIGNED_BYTE, 4);
The last number indicates the number of bytes per pixel for this format and should be 2 in case of LUMINANCE_ALPHA. The PVR reader doesn't complain about the missing image data and no exception has been thrown. Changing the 4 to 2 solves the problem.