I have two spheres on which panoramic image is mapped. I want to make smooth transition between 2 panoramas with fade effect. for both panorama I have initial camera direction set for best view.
Now the issue is if user is looking at some camera angle in first panorama and then he clicks on some button to switch panorama I want to give fade effect and directly land on initial camera angle of another pano.
But as both pano are sharing common camera, I cannot play with camera to achieve it so I devised following solution -
image depicting problem
rotate target sphere so that it looks at desired camera direction.
rotate target sphere so that it looks at existing camera direction.
fadeout source sphere.
camera look at new panos camera direction.
rotate back pano to initial orientation.
Here I am not able to find formula of rotating panorama to look at camera. (like camera is static and pano is rotated to achieve similar effect as if we are moving camera).
Can somebody please help in finding formula to rotate pano(sphere) relative to camera.
Matrix is a very powerful tool to solve rotation problem. I made a simple to explain.
At the beginning, the camera is in the center of the left sphere and face to initial viewpoint, then, the camera face to another point, now, the camera's rotation has changed, next, camera move to the center of the right sphere and keep its orientation. and we need to rotate the right sphere. If C is the point that we want to make the camera to face, first, we rotate A to B， second, we rotate some angle θ equal to C to A.
So, how to do like that? I used matrix, because A is an initial point, matrix in an identity matrix, and the rotation from A to C can be represented by a matrix, calculated by three.js function matrix4.lookAt(eye,center,up) which 'eye' is the camera position, 'center' is coordinate of C, and 'up' is camera up vector. Then, rotation matrix from C to A is the inverse matrix of the matrix from A to C. Because the camera is face to B now, so the camera's matrix equals to the rotation matrix from A to B.
Finally, we put it all together, the final rotation matrix can be written in:rotationMatrix = matrixAtoB.multiply(new THREE.Matrix4().getInverse(matrixAtoC));
jsfiddle example.
This way is a matrix way, you can also solve the problem with the spherical polar system.
I want to rotate a rectangle in a coordinate system. I already know how to rotate each point in it around the 0,0 position, but what I want is to rotate the rectangle around it's minimum x,y point (bottom left, so to speak). I already tried "normalizing" the points first (to 0,0) and then adding the offset again, but my math seems to be faulty.
Two images to clarify. The red circle is the point around which the points in the retangle are rotated. The min (=minimum) point around which to rotate is at 2,1 (bottom left of the dark green rectangle)
First image: What I already can do.
Second image: What I want to accomplish
i have a picture that captured from a fixed position [X Y Z] and angle [Pitch Yaw Roll] and a focal length of F (i think this information is called camera matrix)
i want to change the captured picture to a different position like it was taken in up position
the result image should be like:
in fact i have picture taken from this position:
and i want to change my picture in a way that it was taken in this position:
i hope that i could express my problem.
thnx in advance
It can be done accurately only for the (green) plane itself. The 3D objects standing onto the plane will be deformed after remapping, but the deformation may be acceptable if their height is small relative to the camera distance.
If the camera is never moving, all you need to do is identify on the perspective image four points that are the four vertices of a rectangle of known size (e.g. the soccer field itself), then compute the homography that maps those four points to that rectangle, and apply it to the whole image.
For details and code, see the OpenCV links at the bottom of that Wikipedia article.
I'm trying to write a simple voxel raycaster as a learning exercise. This is purely CPU based for now until I figure out how things work exactly -- fow now, OpenGL is just (ab)used to blit the generated bitmap to the screen as often as possible.
Now I have gotten to the point where a perspective-projection camera can move through the world and I can render (mostly, minus some artifacts that need investigation) perspective-correct 3-dimensional views of the "world", which is basically empty but contains a voxel cube of the Stanford Bunny.
So I have a camera that I can move up and down, strafe left and right and "walk forward/backward" -- all axis-aligned so far, no camera rotations. Herein lies my problem.
Screenshots: (1) raycasting voxels while... ...(2) the camera remains... ...(3) strictly axis-aligned.
Now I have for a few days been trying to get rotation to work. The basic logic and theory behind matrices and 3D rotations, in theory, is very clear to me. Yet I have only ever achieved a "2.5 rendering" when the camera rotates... fish-eyey, bit like in Google Streetview: even though I have a volumetric world representation, it seems --no matter what I try-- like I would first create a rendering from the "front view", then rotate that flat rendering according to camera rotation. Needless to say, I'm by now aware that rotating rays is not particularly necessary and error-prone.
Still, in my most recent setup, with the most simplified raycast ray-position-and-direction algorithm possible, my rotation still produces the same fish-eyey flat-render-rotated style looks:
camera "rotated to the right by 39 degrees" -- note how the blue-shaded left-hand side of the cube from screen #2 is not visible in this rotation, yet by now "it really should"!
Now of course I'm aware of this: in a simple axis-aligned-no-rotation-setup like I had in the beginning, the ray simply traverses in small steps the positive z-direction, diverging to the left or right and top or bottom only depending on pixel position and projection matrix. As I "rotate the camera to the right or left" -- ie I rotate it around the Y-axis -- those very steps should be simply transformed by the proper rotation matrix, right? So for forward-traversal the Z-step gets a bit smaller the more the cam rotates, offset by an "increase" in the X-step. Yet for the pixel-position-based horizontal+vertical-divergence, increasing fractions of the x-step need to be "added" to the z-step. Somehow, none of my many matrices that I experimented with, nor my experiments with matrix-less hardcoded verbose sin/cos calculations really get this part right.
Here's my basic per-ray pre-traversal algorithm -- syntax in Go, but take it as pseudocode:
fx and fy: pixel positions x and y
rayPos: vec3 for the ray starting position in world-space (calculated as below)
rayDir: vec3 for the xyz-steps to be added to rayPos in each step during ray traversal
rayStep: a temporary vec3
camPos: vec3 for the camera position in world space
camRad: vec3 for camera rotation in radians
pmat: typical perspective projection matrix
The algorithm / pseudocode:
// 1: rayPos is for now "this pixel, as a vector on the view plane in 3d, at The Origin"
rayPos.X, rayPos.Y, rayPos.Z = ((fx / width) - 0.5), ((fy / height) - 0.5), 0
// 2: rotate around Y axis depending on cam rotation. No prob since view plane still at Origin 0,0,0
rayPos.MultMat(num.NewDmat4RotationY(camRad.Y))
// 3: a temp vec3. planeDist is -0.15 or some such -- fov-based dist of view plane from eye and also the non-normalized, "in axis-aligned world" traversal step size "forward into the screen"
rayStep.X, rayStep.Y, rayStep.Z = 0, 0, planeDist
// 4: rotate this too -- 0,zstep should become some meaningful xzstep,xzstep
rayStep.MultMat(num.NewDmat4RotationY(CamRad.Y))
// set up direction vector from still-origin-based-ray-position-off-rotated-view-plane plus rotated-zstep-vector
rayDir.X, rayDir.Y, rayDir.Z = -rayPos.X - me.rayStep.X, -rayPos.Y, rayPos.Z + rayStep.Z
// perspective projection
rayDir.Normalize()
rayDir.MultMat(pmat)
// before traversal, the ray starting position has to be transformed from origin-relative to campos-relative
rayPos.Add(camPos)
I'm skipping the traversal and sampling parts -- as per screens #1 through #3, those are "basically mostly correct" (though not pretty) -- when axis-aligned / unrotated.
It's a lot easier if you picture the system as a pinhole camera rather than anything else. Instead of shooting rays from the surface of a rectangle representing your image, shoot the rays from a point, through the rectangle that will be your image plane, into the scene. All the primary rays should have the same point of origin, only with slightly different directions. The directions are determined using basic trig by which pixel in the image plane you want them to go through. To make the simplest example, let's imagine your point is at the camera, and your image plane is one unit along the z axis, and two units tall and wide. That way, the pixel at the upper-left corner wants to go from (0,0,0) through (-1, -1, 1). Normalize (-1, -1, 1) to get the direction. (You don't actually need to normalize the direction just to do ray intersection, but if you decide not to, remember that your directions are non-normalized before you try to compute the distance the ray has travelled or anything like that.) For every other pixel, compute the point on the plane it wants to go through the way you've already been doing, by dividing the size of the plane by the number of pixels, in each direction.
Then, and this is the most important thing, don't try to do a perspective projection. That's necessary for scan-conversion techniques, to map every vertex to a point on the screen, but in ray-tracing, your rays accomplish that just by spreading out from one point into space. The direction from your start point (camera position, the origin in this example), through your image plane, is exactly the direction you need to trace with. If you were to want an orthographic projection instead (and you almost never want this), you'd accomplish this by having the direction be the same for all the rays, and the starting positions vary across the image plane.
If you do that, you'll have a good starting point. Then you can try again to add camera rotation, either by rotating the image plane about the origin before you iterate over it to compute ray directions, or by rotating the ray directions directly. There's nothing wrong with rotating directions directly! When you bear in mind that a direction is just the position your ray goes through if it starts from the origin, it's easy to see that rotating the direction, and rotating the point it goes through, do exactly the same thing.
I'm building a simple 3D drag and drop interface in processing, and want to detect when the mouse rolls over an object. I would imagine that I need to do some matrix translations to the 3D model coordinates to get them into screen space and so on ...
I have a simple version of this working, the problem is that when camera is moved around the scene the coordinates I get go haywire.
So how do I translate the tile coordinates into screen space (since the screenX & screenY aren't working properly)?
UPDATE:
I eventually found two examples from the Processing site on how to do this. Thanks to villintehaspam.
http://processing.org/hacks/hacks:picking
This problem is called picking. Search for mouse picking and you get lots and lots of hits.
Basic theory is this:
Get x,y coords from the mouse click.
Convert these to x,y,z coordinates in eye coordinates (i.e -1 <= x <= 1, -1 <= y <= 1, z=near/far clip distance, if you have a normal projection).
Transform these coordinates by the inverse of the projection matrix to get world coordinates.
You now have a ray from the camera position, with the direction towards the world coordinates you just got.
Make a ray-object intersection test with the objects you want to consider. Choose the object that intersects the ray that is closest to the ray origin (camera position).