I am having problems with using a camera in OpenGL/freeGLUT. Here is my code:
http://pastebin.com/VCi3Bjq5
(For some reason, when I paste the code into the code feature on this site, it gives extremely weird output.)
As far as I can tell this should rotate the camera when arrow keys are pressed - but it does nothing. It also seems that even the initial camera position is wrong. Any clue why this is?
The display function is only called once. You need to either set an idle function with glutIdleFunc() or tell GLUT that the display function must be called again with glutPostRedisplay().
Related
As the title states, I have a Leaflet (version 1.02) map that breaks if I try to zoom in after calling a flyTo() action. Oddly, if I zoom out first, I can then zoom freely, in or out without the map breaking. Panning also works after the flyTo(), but zooming in will still break the map unless I first call a zoomOut action.
I am not at max zoom, and this happens in multiple maps with different sets of markers. If, at zoomend of the flyTo(), I setZoom at the current level, I can then zoom freely, in or out, but this causes the map to flicker after the flyTo() and is very unappealing.
Any thoughts about this?
Thanks in advance!
I know this post is somewhat old at this point, but if anyone runs into a situation where they're using leaflet with the flyTo() function and getting subsequent weird behaviour with zooming then the issue may be what format you're passing your arguments to flyTo().
Make sure the lat, lon are cast to float and zoom is cast to int. I ran into this issue and it turned out to be due to my parameters being passed in a strings. flyTo() seems to operate fine with strings as parameters but subsequent zoom operations act erratically.
I also ran into that bug and I manage to find out a workaround, assuming that the 'zoom' function in 'flyTo' was somehow corrupting the following zoom in action made by clicking on the "+" icon.
I decided to make the flyTo immediately followed by a setZoom action. Here's the code :
map.flyTo(latlong, zoom, {animate: true, duration: 3});
setTimeout(function(){ map.setZoom(zoom);}, 3000);
Options make the flyTo sequence last for 3 seconds
Next line waits 3 second, i.e. exact time for the flyTo to end end and then performs a setZoom, thus canceling any mysterious action of the flyTo that breaks the zoomIn action of the user.
Then it works.
I ran into the same problem. After a .flyTo() call pressing the Zoom + button caused the map to go to maximum zoom, but pressing the Zoom - first meant everything worked OK.
After reading dageshi above, that proved to be the issue.
Make sure the lat, lon are cast to float and zoom is cast to int.
Adding a parseInt() to the value passed to .flyTo() fixed it straight away.
Thanks dageshi
I am currently learning to use SDL2 in C and encountered a problem from which I couldn't find a solution so far
I am trying to run a simple 2 frames animation loop in the middle of the screen, but after a seemingly set amount of loops the window stops responding
while (1)
{
SDL_RenderClear(window->renderer);
test->o_update(sheet, test);
SDL_RenderCopy(window->renderer, sheet->texture, &test->frame, &test->pos);
SDL_RenderPresent(window->renderer);
SDL_Delay(16);
}
The update function updates the coordinates on the sheet of the SDL_rect named "frame" in the test structure, so that it switches to the next frame every 30 frame. Every frame I SDL_RenderCopy, and SDL_RenderPresent to update the screen. Is there something blatantly wrong in my way of doing things ?
The issue came from the lack of wait/poll on SDL events, the process eventually stops responding in those cases.
I have trouble getting Map behave properly when calling ZoomToResolution and PanTo
I need to be able to Zoom into specific coordinate and center map.
The only way I got it working is by removing animations:
this.MapControl.ZoomDuration = new TimeSpan(0);
this.MapControl.PanDuration = new TimeSpan(0);
Otherwise if I make call like this:
control.MapControl.ZoomToResolution(ZoomLevel);
control.MapControl.PanTo(MapPoint());
It does one or another (i.e. pan or zoom, but not both). If (after animation) I call this code second time (map already zoomed or panned to needed position/level) - it does second part.
Tried this:
control.MapControl.ZoomToResolution(ZoomLevel, MapPoint());
Same issue, internally it calls above commands
So, my only workaround right now is to set Zoom/Pan duration to 0. And it makes for bad UX when using mouse.
I also tried something like this:
this.MapControl.ZoomDuration = new TimeSpan(0);
this.MapControl.PanDuration = new TimeSpan(0);
control.MapControl.ZoomToResolution(ZoomLevel);
control.MapControl.PanTo(MapPoint());
this.MapControl.ZoomDuration = new TimeSpan(750);
this.MapControl.PanDuration = new TimeSpan(750);
Which seems to be working, but then mouse interaction becomes "crazy". Mouse scroll will make map jump and zoom to random places.
Is there known solution?
The problem is the second operation replaces the previous one. You would have to wait for one to complete before starting the next one. But that probably doesn't give the effect you want.
Instead zoom to an extent, and you'll get the desired behavior. If you don't have the extent but only center and resolution, you can create one using the following:
var zoomToExtent = new Envelope(point.X - resolution * MapControl.ActualWidth/2, point.Y, point.X + resolution * MapControl.ActualWidth/2, point.Y);
Btw it's a little confusing in your code that you call your resolution "ZoomLevel". I assume this is a map resolution, and not a level number right? The esri map control doesn't deal with service-specific levels, but is agnostic to the data's levels and uses a more generic "units per pixels" resolution value.
Our app has a rotating map view which aligns with the compass heading. We counter-rotate the annotations so that their callouts remain horizontal for reading. This works fine on iOS5 devices but is broken on iOS6 (problem seen with same binary as used on iOS5 device and with binary built with iOS6 SDK). The annotations initially rotate to the correct horizontal position and then a short time later revert to the un-corrected rotation. We cannot see any events that are causing this. This is the code snippet we are using in - (MKAnnotationView *)mapView:(MKMapView *)theMapView viewForAnnotation:(id )annotation
CATransform3D transformZ = CATransform3DIdentity;
transformZ = CATransform3DRotate(transformZ, _rotationZ, 0, 0, 1);
annotation.myView.layer.transform = transformZ;
Anyone else seen this and anyone got any suggestions on how to fix it on iOS6?
I had an identical problem so my workaround may work for you. I've also submitted a bug to Apple on it. For me, every time the map got panned by the user the Annotations would get "unrotated".
In my code I set the rotations using CGAffineTransformMakeRotation and I don't set it in viewForAnnotation but whenever the users location get's updated. So that is a bit different than you.
My workaround was to add an additional minor rotation at the bottom of my viewForAnnotation method.
if(is6orMore) {
[annView setTransform:CGAffineTransformMakeRotation(.001)]; //iOS6 BUG WORKAROUND !!!!!!!
}
So for you, I'm not sure if that works, since you are rotating differently and doing it in viewForAnnotation. But give it a try.
Took me forever to find and I just happened across this fix.
I have a WebGL fragment shader that I am using to do raytracing. I pass in sphere and triangle data using textures. So far I've got 2 spheres and 3 triangles working. When I add the call to check interesection with a 4th triangle, the shader does not link, and calling getProgramInfoLog() just returns null.
Could the fragment shader be getting too big? Or do I need to look for another cause? How do I determine where the problem might be?
Here is a code snippet, commenting out any one of the checkTriangleIntersection calls causes the shader to link successfully.
checkTriangleIntersection(0.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
checkTriangleIntersection(1.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
checkTriangleIntersection(2.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
//checkTriangleIntersection(3.0, rayOrigin, rayDir, piOfNearest, normalOfNearest, colourOfNearest, distOfNearest);
Since all the calls are the same, except for the index, I thought that there would be nothing wrong with the code itself, but is there some kind of limit that I could be running up against?
I'm getting more then 30 FPS before I add the extra function call, and even when I do add the extra call, both the vertex and fragemnt shader compile OK.
I got rid of the issue by putting the calls to checkTriangleIntersection() into a for loop.