http://www.youtube.com/watch?v=DyssOSmwuoo
according to my video
when call animation PageTransitionForward it will have a triangle on the left
and that triangle can see through next layer
how can i fix it?
It happens because of limitation of depth buffer (search about z-fighting for more info).
To fix it just find CCPageTurn3DAction.m file and in (void)update:(ccTime) method change z coordinate of all vertices of the animated grid to some higher value (e.g. 0.5).
Related
While trying to render a cube with OpenGL I noticed that the vertexes I defined later in my positions array rendered on top of the ones defined earlier:
It is hard to see in the image but if you look closely, you can see the back faces of the cube are rendering on top of the faces closest to the camera. When I move the camera to the other side of the cube it appears normally.
Do I need a check in my fragment shader to see if the face is behind others relative to the camera, and if so how do I implement it?
At first I tried enabling the depth test (I wasn't aware it was off by default) But then nothing rendered. The problem was not clearing the depth buffer every frame with glClear(GL_DEPTH_BUFFER_BIT).
Problem Solved!
So I'm rendering this diagram each frame:
https://dl.dropbox.com/u/44766482/diagramm.png
Basically, each second it moves everything one pixel to the left and every frame it updates the rightmost pixel column with current data. So a lot of changes are made.
It is completely constructed from GL_LINES, always from bottom to top.
However those black missing columns are not intentional at all, it's just the rasterizer not picking them up.
I'm using integers for positions and bytes for colors, the projection matrix is exactly 1:1; translating by 1 means moving 1 pixel. Orthogonal.
So my problem is, how to get rid of the black lines? I suppose I could write the data to texture, but that seems expensive. Currently I use a VBO.
Render you columns as quads instead with a width of 1 pixel, the rasterization rules of OpenGL will make sure you have no holes this way.
Realize the question is already closed, but you can also get the effect you want by drawing your lines centered at 0.5. A pixel's CENTER is at 0.5, and drawing a line there will always be picked up by the rasterizer in the right place.
I was trying to use CCRenderTexture for pixel perfect collision detection, as outlined in this forum posting:
http://www.cocos2d-iphone.org/forum/topic/18522/page/2
The code "as is" works, and I have integrated it with my project
But I am having trouble doing some of the other things discussed:
If I create the renderTexture to be any size less than the screen size, the collision detection doesn't work properly - It seems to show collisions when the sprites are close (<15px) to each other but not actually colliding.
Also I have trouble changing the location of the render texture. Regardless of the position I specify, it seems to go from bottom left (0,0) till the width & height specified. I followed this post:
http://www.cocos2d-iphone.org/forum/topic/18796
But it doesn't solve my problem. I still get bad collisions like specified above. Also, the first post I mentioned on the list contains comments by many users who have resized their textures to 10x10, and repositioned them off screen.
Does anyone have any sample code, so I can see what I am doing wrong? I just use the boilerplate code:
CCRenderTexture* _rt = [CCRenderTexture renderTextureWithWidth:winSize.width height:winSize.height];
_rt.position = CGPointMake(winSize.width*0.5f, winSize.height*0.5f);
[[RIGameScene sharedGameScene]addChild:_rt];
_rt.visible = YES;
I use cocos2d-iphone 1.0.1
You need to move the sprites you intend to draw into the region of the renderTexture before calling draw or visit. Moving the renderTexture does not change the position of _rt.sprite.
The intersection rectangle must be in the region of the renderTexture, otherwise you get inaccurate collisions.
It seems that you cannot change the position of _rt.sprite.
The solution that I use is to determine the origin (x,y) of the intersection box, and offset both the colliding sprites by that much. This will ensure that the intersection rectangle will have its origin at 0,0. Then I calculate the intersection rectangle again (after ensuring the origin of the intersection rect is 0,0) . Then I follow the instructions in the forum posting.
When determining the dimensions of the render texture, I ensure that they are at least as large as the intersection rectangle, and I ensure that the intersection rectangle is fully inside the render texture. This way there are accurate collisions. If even part of the intersection box is outside the render texture i get inaccurate collisions, so before drawing into the render texture, make sure you move the sprites you intend to visit so that the intersection box is entirely within the render texture.
Remember to move the sprites back after you're done. :)
I have two objects drawn on screen in openGL, one is a sphere using the GLU object and one is a texture mapped star. Regardless of the z coordinates, the texture mapped star always seems to draw in front. Is this normal openGL behavior? Is there a way to prevent this?
Note: I am working within the worldwind framework, so maybe something else is going on causing this. But I'm just wondering is it normal for the texture mapped objects to appear in front? I don't think so but I'm not sure...
This isn't a bug in worldwind, this is actually desired behavior. Using glVertex2f() is the same as using glVertex3f() and setting z = 0. So it simply draws the star at a plane very close to the viewer (also depending on your projection).
To solve your issue, you can either disable depth writes using glDepthMask(0), then draw the star, call glDepthMask(1) and then draw the sphere, which will now be in front of the star.
You can also use glDepthFunc(GL_GREATER) on the star or glDisable(GL_DEPTH_TEST) on the sphere to quickly achieve the same effect.
To make anything more complicated (such as star intersecting the sphere), you need to use matrices to put the star at the desired position.
I'm using OpenGL and was told I should draw circles at each vertex of my outline to get smoothness. I tried this and it works great. The problem is speed. It crippled my application to draw a circle at each vertex. I'm not sure how else to fix the anomaly of my outlines other than circles, but using display lists and trying with vertex array both were brutally slow. Thanks
see: Edges on polygon outlines not always correct
One (perhaps too fancy) alternative is to draw a single polygon that bounds the circle (say, a quad), and then use a fragment program to discard the fragments. This would not be entirely trivial to write, but I would bet it's the fastest way.
You would simply pass the circle parameters to the fragment program and discard the fragment if the distance from the fragment center to the center of the circle is bigger than the desired radius.
Have you seen this article?
..or if you have access to the GL utility library, you could use gluDisk