i don't know if this is the right place to ask this, but i recently created this library.
An issue bought to my attention that a OnePlus phone the vertex shader i use for displacing the vertices of a plane cuts off after a point.
This is not the case with my iPhone on iOS 14.5 though.
I have found that in the fBM function, at these lines, setting the turbulence to true and taking the absolute value of the noise causes it to work but i do not want the turbulence to always be on.
Testing it on an other OnePlus phone seems to cause the issue, but testing it on a Samsung makes everything work perfectly
Any idea whats causing this bug?
Related
I've got a scene with ~35k sprites which are all pretty much static. The goal is to create an image that the user can save, so having the output be consistent across platforms is ideal. Below is roughly the same scene as rendered in both browsers, firefox on my desktop on the left and mobile safari on an iphone 6 on the right. The ios one is a little blurrier because I just took a snapshot of it, but the code running on both is exactly the same.
It seems like the mobile safari version gets darker the more dense things are, like where the semi-transparent heads of the soldiers are overlapping it's just not averaging right. I've set premultipliedAlpha: false, messed with material blend modes, texture settings, and for the life of me I can't get the ios version to match. Any help would be appreciated! :)
I'm looking to develop an outdoor application but not sure if the tango tablet will work outdoors. Other depth devices out there tend to not work well outside becuase they depend on IR light being projected from the device and then observed after it bounces off the objects in the scene. I've been looking for information on this and all I've found is this video - https://www.youtube.com/watch?v=x5C_HNnW_3Q. Based on the video, it appears it can work outside by doing some IR compensation and/or using the depth sensor but just wanted to make sure before getting the tablet.
If the sun is out, it will only work in the shade, and darker shade is better. I tested this morning using the Java Point Cloud sample app, and only get > 10k points in my point cloud in center of my building's shadow, close to the building. Toward the edge of the shadow the depth point cloud frame rate goes way down and I get the "Few depth points" message. If it's overcast, I'm guessing your results will vary, depending on how dark it is, I haven't tested this yet.
The tango (yellowstone) tablet also works by projecting IR light patterns, like the other depth sensing devices you mentioned.
You can expect the pose tracking and area learning to work as well as they do indoors. The depth perception, however, will likely not work well outside in direct sunlight.
I have been building a Sprite Kit game for quite some time now. Just recently I have been adding gyro/tilt functionality. Using the CMMotionManager, I've been able to access the numbers surprisingly easily. However, my problem arises as a result of how the acceleration.x values are stored.
You see, the way my game works, when the game starts, the phone quickly calibrates itself to how it's currently being held, and then I respond to changes in the acceleration.x value (holding your phone in landscape orientation, this is equivalent to tilting your screen towards and away from you.) However, laying your phone flat is 1.0 and tilting it straight towards you is 0.0, and then it loops back through those values if you go beyond that. So, if someone is sitting upright and their phone is calibrated at .1, and they tilt their phone .2 downwards, the results will not be what is expected.
Is there any easy way to counteract this?
Why are you trying to make your own system for this? You shouldn't really be using the accelerometer values directly.
There is a class called CMAttitude that contains all the information about the orientation of the device.
This orientation is not taken raw from accelerometer data but uses a combination of the accelerometers, gyroscopes and magnetometer to calculate the current attitude of the device.
From this you can then take the roll, pitch and yaw values and use those instead of having to calculate them yourself.
Class documentation for CMAttitude.
I'm working on a multi platform game. It uses OpenGL ES 2.0 and the whole scene renders perfectly fine on iOS and also windows using Mali's OpenGL ES emulator.
I recently ported it to Mac OSX. The only change I had to make was to get glCompileShader to ignore lowp, mediump and highp. Other than that, for the most everything seems to work fine with the exception of all models rendering inside out.
I've tried the following to fix it without any luck..
Disabling culling altogether
Switching cull mode between front, back, front and back
Switching front face to be CW and CCW
Enabling, disabling depth buffer
Trying less, greater, lequal and gequal for depthfunc
Reversing near and far in the projection matrix
The only other thing I could think of is the handedness. My scene is authored in a left handed coordinate system. I end up flip the z axis of the view matrix to compensate for it. So, on OSX, I tried flipping back the view matrix and trying LH and RH projection matrix combinations with that and the results behaved as expected with the exception of models rendering inside out.
At this point I'm totally stumped.
It seems like some default state is different between OpenGL ES an OpenGL.
Ideas?
Found the issue. I did not have a valid depth buffer. For some reason, the sample code I used to setup my OpenGL context forgot about the depth buffer.
Thanks to Reto Koradi for pointing it out.
I am working on a game in Unity3d and I am facing a bizarre problem. My NGUI elements are turned into a black area when I run the game into iPod4 and iPhone4. However it is working well in iPad, iPod5 and iPhone5.
It seems to me that in iPod NGUI is not able to get the corresponding Atlas. Even the UIlabel are being shown as a black area in NGUI. Does anybody know what the problem might be?
Is there any memory problem on a lower capability device that might cause this?
Black sprites in NGUI on mobile platforms are usually caused by your atlas being larger than what is supported by the hardware. It's a simple physical limitation. The hardware simply does not support textures of a larger size.
The iPad and iPad2 (originally, though this changed) are limited to 2k textures. The iPad 2 (now), 3 and 4, as well as the Mini, the iPhone 4S and 5, and the iPod 5 do have 4k texture support.
So that explains the issues you were having. A simple hardware limitation.
Hey guys I got the solution. The problem caused by NGUI Atlas which was of 4096*4096. I have lower the atlas's resolution 2048*2048. Now everything is fine.
Black sprites in NGUI on mobile platforms are usually caused by your atlas being larger than what is supported by the hardware. It's a simple physical limitation