We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1
backface culling (Read 2124 times)
toastie
backface culling
Jun 29th, 2005, 11:53pm  

Hey, is there any way to enable backface culling in P3D mode? It doesn't seem to be documented.
Back to top
 
Valaam0  
depth
Re: backface culling
Reply #1 - Jul 13th, 2005, 3:41am  
dunno bout all that, but i figured out how to do it in openGL:

Code:

import processing.opengl.*;
import net.java.games.jogl.*;
GL gl;

void setup () {
  size(200, 200, OPENGL);
  gl = ((PGraphicsGL)g).gl;
  gl.glEnable(GL.GL_CULL_FACE);
}


of course, this culls them completely, so you gotta draw your backfaces manually if you want them to be seen for whatever reason.

a known bug is that alpha fills don't render properly on backfaces in processing openGL.  to get around it, use backface culling as shown above, and draw both front and backfaces.
Back to top
 
WWW  
fry
Re: backface culling
Reply #2 - Jul 13th, 2005, 5:54pm  
depth wrote on Jul 13th, 2005, 3:41am:
a known bug is that alpha fills don't render properly on backfaces in processing openGL.  to get around it, use backface culling as shown above, and draw both front and backfaces.

not a known bug, but rather just how opengl is implemented.
Back to top
 
WWW  
depth
Re: backface culling
Reply #3 - Jul 18th, 2005, 9:14pm  
right, sorry.  known 'issue' is prolly more appropriate.  guess that's automatically done in a lot of 3D software (if not APIs).

would it make sense to have an option (something like smooth(), called in setup()) in processing to simultaneously enable backface culling and duplicate polys with flipped normals?

for that matter, how does processing/opengl determine the normal of a poly, does it just depend on the order in which the vertices are drawn?
Back to top
 
WWW  
fry
Re: backface culling
Reply #4 - Jul 19th, 2005, 2:16pm  
yeah, it's one of those things that if you think technically about why gl behaves like that, it makes plenty of sense because of how it affects speed. but also one of the things that a developer/user should ideally never have to think about. we have the code stubbed out to optionally sort all triangles first before rendering, whcih would get rid of the problem, but it's not yet finished and tested.

re: normals and whatnot, check out the reference for lights() from the code in sourceforge: http://cvs.sourceforge.net/viewcvs.py/processing/processing/core/PGraphics3.java?rev=1.45&view=auto (this will be in javadoc format on a new dev site once we get dns updated properly.
Back to top
 
WWW  
depth
Re: backface culling
Reply #5 - Jul 27th, 2005, 4:47pm  
okay...starting to understand.

two questions tho.  the first, simon talks about the vertex mode (AUTO-NORMAL, SHAPE-NORMAL, VERTEX-NORMAL), but i can't see how to set it.  he says it can be set within begin/endShape...?

also, is this a typo in the comment?
(in "Efficiency consequences:")

Quote:
*   into the vertex colors. The converse is our worst-case performance when
*
*   1) lighting is position dependent
*   2) we are in AUTO-NORMAL mode


the worst-case scenario is in VERTEX-NORMAL with position-dependent lighting, no?  tho i'm just kinda stabbing in the dark here....
Back to top
 
WWW  
Page Index Toggle Pages: 1
‹ Previous Topic | Next Topic ›