- July 20, 2009 at 2:51 am #29861
does anyone can give me some idea on how to do user clip plane in GLSL?I read the gles2.0 programming guide line, and it give some example on how to do user clip plane in GLSL. but when i do it, it seems no effect. does anyone can point out my problem?in the books, if you do user clip plane, you will write the two shader: one for vertex,anoter for fragment.vertext shader:uniform vec4 u_clipPlane;
uniform mat4 matViewProjection;
attribute vec4 rm_Vertex;
varying float u_clipDist;
// Compute the distance between the vertex and the clip plane
u_clipDist = dot(rm_Vertex.xyz, u_clipPlane.xyz) + u_clipPlane.w;
gl_Position = matViewProjection * rm_Vertex;
}fragment shader:precision mediump float;
varying float u_clipDist;
// Reject fragments behind the clip plane
if(u_clipDist < 0.0)
gl_FragColor = vec4(0.5, 0.5, 1.0, 0.0);
}my object is to clip some rect region in the screen ,eg(x,y,w,h) some area. can someone tell me how to determine u_clipplane A,B,C,dJuly 21, 2009 at 6:32 pm #33239
The shader looks correct (better use of precision modifiers might speed it up). Are you sure that using clip planes is the best way to achieve what you want?
It looks like the shader wants: (x,y,z) as the normal from the clip plane. w as the distance from the origin.
See:July 23, 2009 at 2:16 am #33240
thanks.actullay, i want to do the same work just like glClipPlane in GLSL. because in GLES2.0, this function has been removed. so i want to emulate this function in GLSL. could you give me some idear whethere my opnion is a proper way to do clipping or other way may be better?July 23, 2009 at 11:05 am #33241
Unfortunately there currently is no really good way of doing user clip planes in OpenGL ES 2.0. Your shaders should work (provided you specify the clip plane in model space), but will not be very efficient compared to geometry-based clipping.
If you just want to restrict rendering to a screen rectangle, use glScissor or glViewport instead.July 27, 2009 at 8:32 am #33242
i try the glScissor , it seems take effect, it can reserve one rect area to restrict the showing of image in this area.what i want to implent a scene is :there is one window,on the window , there is one rect (wxh). here , other thing is just displayed in this rect area with different aspect.because , the rect and the displaying things in the window are all moveing. the rect move round with clock-wise direction.how can i implement this feather about moving rect using glScissor and glViewport? can anyone give some idear? i am just a newer of opengles.July 28, 2009 at 2:49 am #33243
i find one thing, for glScissor and glViewport, they seem only work for 2D clipping not for 3d. in our scene, the rect will also be transform in Z space (rotate in z axis), the clip on the rect still need to work out.
i think the glScissor and glviewport may not be approprite. has any other method? there is still one implementation for this feathure which is implemented by stencil buffer. but in our new target, the stencil buffer way is very slow. so we want to find other solution. could some one can give some suggestion ?July 28, 2009 at 11:32 am #33244
Yes, glScissor and glViewport define a screen rectangle, not clipping in 3D. How exactly are you using the stencil buffer, and what is your target?August 14, 2009 at 7:44 am #33245
we use samsung SC series target, in this target, there is one samsung vendor’s 3D chipset and library. in this target, the depth test and stencil test is very expensive, in the programming guideline, it is recommened to avoid the usage of depth test and stencil test.but currently ,we have one clipping feathure need to be reimplemended , the current solution is based on stencil buffer , so the polygon clipping is supported. in powervr , the performance is good, in SC chipset, it is very slow, unaccepatable, so this feathure is to be reimplemented in other way.i review several way, there are many way to do clipping:1) clip plane.2) stencil buffer test clipping3) Obluique frustum clipping4) depth buffer test clipping5) texture based clippingbut we know, in our new target, 2,4 option is exculeded.and we also need to support ploygon clipping, so 1,3 seems also not acceptable,so i prefer to use option 5 , can anyone give me some suggestion?we want to use hardware-accelated clipping, to speedup the clipping performance, meanwhile , to suffice our ploygon clippingSeptember 4, 2009 at 12:32 pm #33246
Texture based clipping is likely to be harmful to performance on POWERVR hardware – I can’t comment on Samsung’s own solutions, you would have to approach them for support.
I would suggest keeping the working solution for POWERVR (if it does turn out to be better) and keeping a separate codepath (using #ifdefs or whatever) for the other chipsets.