I'd like to develop an iPhone app that does the following:
1. Starts the device camera.
2. Places a layer on the screen containing a stretchable frame for the user to fit to a desired object.
3. Measures the object's width & height.
You may look at this app which does practically what I need and more:
http://itunes.apple.com/us/app/easymeasure-measure-your-camera!/id349530105?mt=8
Notice that it doesn't need to be super accurate and can definitely bear some aberration.
Any clue how to do it?
10x
The clue: Geometry and Trigonometry.
By knowing the camera Field-of-View angles, entering the height of the camera above ground and assuming a planar, i.e. flat, ground, you can use basic geometry and trigonometry to work out everything.
Related
I have a problem where images change z drawing depending on the xposition of my camera - the image shows the problem - I want it so the positions of the images dont change drawing order to camera
https://ibb.co/syHLY8d
Looks like the issue is they're exactly the same depth from the camera, and when the camera moves in the X-coordinate, floating point rounding errors cause the depth values to be slightly different and sort in a different way.
To fix this case you need to move one object slightly further away from the camera, although personally I would say this is generally not an issue worth worrying about, lots of games have small sorting issues like this and most people won't notice.
How to make the 3D game adapt to the screen resolution?
I tried to change the fieldOfView of the camera, but this adjustment does not work correctly!
If you mean UI elements, there are little triangles usually in the middle of the canvas the element is under. These are anchors that will tell the element to try and stay in the same place on the canvas regardless of the screen resolution. You can read more about it here: https://docs.unity3d.com/Manual/UIBasicLayout.html https://docs.unity3d.com/Manual/HOWTO-UIMultiResolution.html
If you mean your actual game view, you'd probably need to write a script that adjusts the camera's FOV at the start of the game based on the resolution, but I have no idea where to even begin on the formula you'd use.
We are using Unity3D to develop an interesting medical application. By making it very briefly, we have a very large touch screen, hanging from a wall. This screen is fixed to the wall and can not be moved. Patients could be adults or children. Tall or short people and so on. Before starting the game, we perform a calibration phase that consists in trying to understand more or less what the touch range is. That is, a taller person can reach the highest points on the screen, while a lower person can not. The calibration phase then identifies more or less which area is reachable. The result of the calibration (simplified) is a rectangle. We would like to fit the content of the game made with Unity3D to be included within this rectangle. That is, there is some function in Unity3D that allows you to specify when you start the game where you "draw" the elements of the game by defining a sort of "sub screen"?
Absolutely yes. It is quite easy, just change the Viewport Rect of the Camera:
Also check the Documentation for completeness (the paragraph Normalized Viewport Rectangles reports an example in games field, where the camera is split for a two-players match...you basically want the same thing but with a single camera).
In this doc, there's also an example in which the viewport is changed programmaticaly (that's your case). Basically:
Camera.main.rect = new Rect(xMin, xMax, yMin, yMax);
I am trying to get 'picking' working in a 3D scene, where the view is rotated such that the iPhone is being held in a landscape mode. I'm using OpenGL ES 2.0 (so all shaders, no fixed-function pipeline).
I'm performing the unproject from within the rendering code and immediately drawing the resulting ray using GL_LINES (ray only gets calculated the 1st time that I touch the screen, so afterwards I can move the camera around to observe the resulting line from various angles).
My unproject code/call is fine (lots of examples of gluUnproject online). My matrix-inversion code is fine (even compared with excel for a few matrices). However, the resulting ray is off by at least 5-15 degrees from where I actually 'clicked' (in the Simulator it really is a click, so I'm expecting a lot more precision from the unproject).
My view is rotated to landscape (after I create the perspective-projection matrix, I rotate it around the Z by -90 degrees; the aspect ratio remains at a portrait one). I believe that the problem with the math being off lies here.
Does anyone have any experience doing picking/unprojection with specifically a landscape view?
Is it possible you simply have the field of view off? Assuming you've stuck to something a lot like the traditional pipeline, if you were inverting your modelview matrix then using generic unproject code (ie, code that assumes a 90 degree field of view in both directions to fill eye space) then that would explain it.
A quick diagnostic test is to see how far off it is for different touches. Touches nearer the centre of projection should be closer to the correct answer.
On a screen with square pixels like the iPhone, the aspect ratio is just the proportion of the horizontal field compared to the vertical. So if you want to be unscientific about it, find the field of view you're using, say f, and try multiplying your results by 90/f or f/90. If that doesn't work, try also throwing a factor of 480/320 or 320/480 in there.
A better solution is to follow your code through and figure out what your actual horizontal and vertical fields of view are. And multiply your results by that over 90.
I've recently had some issues implementing a zooming feature into a painting application. Please let me start off by giving you some background information.
First, I started off by modifying Apple's glPaint demo app. I think it's a great source, since it shows you how to set up the EAGLView, etc...
Now, what I wanted to do next, was to implement zooming functionality. After doing some research, I tried two different approaches.
1) use glOrthof
2) change the frame size of my EAGLView.
While both ways allow me to perfectly zoom in / out, I experience different problems, when it actually comes to painting while zoomed in.
When I use (1), I have to render the view like this:
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrthof(left, right, bottom, top, -1.0f, 1.0f); //those values have been previously calculated
glDisable(GL_BLEND);
//I'm using Apple's Texture2D class here to render an image
[_textures[kTexture_MyImage] drawInRect:[self bounds]];
glEnable(GL_BLEND);
[self swapBuffers];
Now, let's assume I zoom in a little, THEN I paint and after that, I want to zoom out again. In order to get this to work, I need to make sure that "kTexture_MyImage" always contains the latest changes. In order to do that, I need to capture the screen contents after changes have been made and merge them with the original image. The problem here is, that when I zoom in, my screen only shows part of the image (enlarged) and I haven't found a proper way to deal with this yet.
I tried to calculate which part of the screen was enlarged, then do the capturing. After that I'd resize this part to its original size and use yet another method to paste it into the original image at the correct position.
Now, I could go more into detail on how I achieved this, but it's really complicated and I figured, there has to be an easier way. There are already several apps out there, that perfectly do, what I'm trying to achieve, so it must be possible.
As far as approach (2) goes, I can avoid most of the above, since I only change the size of my EAGLView window. However, when painting, the strokes are way off their expected position. I probably need take the zoom level into account when painting and re-calculate the CGPoints in a different way.
However, if you have done similar things in the past or can give me a hint, how I could implement zooming into my painting app, I'd really appreciate it.
Thanks in advance.
Yes, it is definitely possible.
When it comes to paint programs, you should be keeping a linked list or tree of objects to draw for easy insertion / removal. When the user stops painting, (i.e. touchesEnded), you add objects to the data structure containing your scene.
When your user zooms you need to modulate the coordinates of the objects you are drawing with respect to the current viewport, projection, and modelview transforms. In your case, you're not changing the viewport or the modelview transforms so you need only account for the projection transform. You could also implement your zoom using a translation and scale on the modelview matrix but I'll ignore that case for simplicity because it involves inverting the transforms.
The good news is that you are using an orthographic projection so world coordinates correspond to window coordinates when no zooming is in effect. The "world" in your case is a simple canvas that probably corresponds to the size of the device in window coordinates.
Before you add an object to your scene data structure, convert all of the coordinates, using the current projection transform (i.e. the parameters to the glOrthof() call) to world coordinates (i.e. full canvas coordinates). You'll only remain sane if you keep all things in your model in the same coordinate space.
To convert the coordinates, assuming you can never zoom out past full device dimensions in your glOrtho() call, you'll have to scale them down proportional to the ratios of your zoomed ortho dimensions to your unzoomed ortho dimensions then bias them by the difference between your zoomed ortho bottom, left values and those of the original unzoomed ortho values.