In the shadow map sample provided by Microsoft I've noticed an issue where shadows are not properly projected when thin geometry is projected at high angles, see here the shadows being projected, notice the poles from the lights are not projected:
And in this screenshot we see things from the lights perspective, not ethe poles are clearly visible: http://imgur.com/k2woZ.png
So two questions really, is this an actual bug or a limitation with shadow mapping and if it's a bug how can I fix it?
The source is directly from the Microsoft DirectX Sample Browser 'ShadowMap' sample from July 2004, the sample browser is the latest August 2009 one.
Have a look at your shadow buffer (use Pix or write it to disk).
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.
The problem I'm facing is similar and closely related to this issue on Github but that's for Unity SDK, my question is for iOS SDK.
I want to achieve the same thing. Let me explain, basically I have pixel grid in which each pixel'd have equal size. Pixel is set to be 10m x 10m in real world. The thing I experienced is that if pixel locates towards the northern or southern part of the world, its size is stretched like the following.
Click for larger resolution
But when such pixel locates along the equator line, or simply along the middle part of the world. It looks ok like following
Click for larger resolution
There's no problem about rendering stuff, or positioning on Mapbox. The thing is I want every pixel to be square visually.
I've read along on the issue I linked above. It relates to mercator and the world is not flat thus makes this visual happens. It looks stretched along the northern and southern part of world map. As well, I found out that there's no equal functionalities as presented in Unity SDK for this particular problem on iOS SDK, so I'm not sure which approach I should go on to solve this solution.
How can I achieve equal size of pixel on the gridline on mapbox using Mapbox iOS SDK? Is there already solutions provided in the SDK?
FYI.
My requirement also needs real distance as shown on the map. I'm not sure it'd affect the solution as presented in the link I linked above.
I use Mapbox iOS SDK 3.7.6
My initial approach is straightforward as I fix the size of pixel to be 10m x 10m, then calculate its corresponding latitude and longitude value. Use those values to position them in Mapbox treating entire world map as a tilemap. Anyway I didn't take into account mercator in calculation, so this might be the case, if so then how to do just that? Only thing from my checking as available in iOS SDK is MGLMapView's metersPerPoint(atLatitude:). No tile ID system, or Conversions.cs as seen on Unity SDK. So i'm not sure on how to go on and solve this problem.
Update
I managed to solve it and made it work!
I'll come back and post the solution.
My solution is to port sphericalmercator.js to swift, then use it in code. I use a fixed zoom level of level 22 as its visual look is closest to what I need and also before. I went with the approach to at least have it looks visually equal not necessary its physical size.
Thanks to a hint in this answer on how to use sphericalmercator.js.
Anyway from my testing with it, tile size as set when you creating an instance using SphericalMercator seems not to be in effect no matter what value I set. Only zoom level will determine number of tiles across the world map for you. Note that upper-left corner is origin which is 0,0 tile index. Lower zoom level value will generate large tile size, but higher value will generate smaller tile size.
You can take a look as SphericalMercator-swift; the code I ported from origin JS implementation as linked above along with how to use it to get tile index, or bounding box of longitude/latitude in swift code in order to do rendering stuff on top of Mapbox.
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 use ID3DXSprite interface to draw gui controls in my app. I have a 512x512 texture with all controls and use sprite->Draw() telling the exact RECT of control. Everything works fine except a strange bug on only one(!) machine.
Normally, the control looks:
And on that strange machine:
Moreover, some controls look fine but also many of them look like this one - with corrupted edges and ... well you can see the difference :(
The second machine has Intel(R) G41 Express Chipset video adapter.
Please, if someone has ANY ideas why can it happen - help!
Regards, Anthony.
It looks to me like you have mipmaps in the sprite's texture and the card is choosing the wrong mipmap level. Set the mip map level, explicitly to 1, and see if that helps.
Can anyone tell me if it is possible to import .jpg files into MS Mappoint Europe 2006 ?
If it is possible can this be done by an OCX control ?
I would like to import some aerial photography of an area into MapPoint to enhance the coverage of a small area,
Thanks for your time
Ian
Not in an easy and meaningful way.
I have heard of people importing their image tiles as pushpin images, and then plotting these across the map area. This should work but the tile sizes will be scale invariant. Ie. the image will be messed up as you zoom in or out.
A more complex method is to use MapPoint in an ActiveX control and intercept all zoom/pan messages. Then use these to determine the current view area and projection. Then using Win32 GDI+ calls you should be able to overlay an image over the area of the ActiveX control (use alpha to set transparency). That is theory - it would take quite a bit of experimentation to get it to work, and it is probably easier to use an alternative implementation (or even an open source viewer).