[osg-users] [forum] Rendering backface like front face

[Florian Kolbe]

Hi,

sorry if this may be too obvious. I was wondering if there is some kind of backface mode where backfaces are rendered like the front face?
We have a model here that "looks" normal in Rhino and SimLab Composer because they seem to be able to render that way ("backface like front face") - see foot note. Looking at the model in OSG it becomes obvious, that some surfaces are inside out (e.g. black if culling is off, or invisible if backface culling is active).

Instead of fixing the model, I was interested if I could teach OSG to render the backface like the front face (in terms of material and shading etc)?


Thank you!

Cheers,
Florian

e.g. for Rhino: http://docs.mcneel.com/rhino/5/help/en-us/options/view/display_mode_options.htm
search for "Backface settings" the setting is called "Use front face settings" which seems to be the default

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53088#53088





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Paul Martz]

Did you try turning on 2-sided lighting?

--
Paul Martz
Skew Matrix Software LLC

[Christian Buchner]

When I tried two sided lighting yesterday, I found that the back faces were lit, but not in the same way as the front faces.

Also note that on most recent Geforce cards two sided lighting will not be hardware accelerated. They did that to boost the sale of their professional Quadro series of cards.

To get a real identical lighting on front and back sides, you may have to use a fragment shader, and do your own lighting calculations (e.g. reversing the surface normal if the back side is shown)

Christian

[Florian Kolbe]

Ok, so I found this:

http://www.openscenegraph.org/projects/osg/wiki/Support/OpenGL2OSGLookup

So I am now doing this:


Code:

osg::ref_ptr<osg::LightModel> lightModel = new osg::LightModel;
// http://www.glprogramming.com/red/chapter05.html
// "OpenGL reverses the surface normals for back-facing polygons; typically, this means that the surface
// normals of visible back- and front-facing polygons face the viewer, rather than pointing away.
// As a result, all polygons are illuminated correctly. However, these additional operations usually make
// two-sided lighting perform more slowly than the default one-sided lighting."
lightModel->setTwoSided(true);
// http://www.opengl.org/sdk/docs/man2/xhtml/glLightModel.xml
// "GL_SINGLE_COLOR specifies that a single color is generated from the
// lighting computation for a vertex. GL_SEPARATE_SPECULAR_COLOR
// specifies that the specular color computation of lighting be stored
// separately from the remainder of the lighting computation. The specular
// color is summed into the generated fragment's color after the application
// of texture mapping (if enabled). The initial value is GL_SINGLE_COLOR."
lightModel->setColorControl(osg::LightModel::SINGLE_COLOR);
// as of 2.9.9 this would be the default
lightModel->setAmbientIntensity(osg::Vec4(0.2f,0.2f,0.2f,1.0f));
// http://www.glprogramming.com/red/chapter05.html
// "A local viewpoint tends to yield more realistic results, but since the direction has to be calculated for each vertex,
// overall performance is decreased with a local viewpoint. By default, an infinite viewpoint is assumed."
lightModel->setLocalViewer(false);
modelNode->getOrCreateStateSet()->setAttributeAndModes(lightModel.get());




Question: Am I missing something? What about glMaterialfv ( GL_FRONT_AND_BACK, ...) I read about somewhere else? For my model, something along those lines does not seem necessary.

If someone is interested, the performance impact is as follows:
before 4.75 FPS
after 2.9 FPS

(so it may be best to fix the model in the long run)

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=53098#53098

[Florian Kolbe]

@cbuchner1
Hmm, well I bet a lot of software relies on that feature...
By the way I am using NVIDIA GeForce GTX 550 Ti and it works here.

> When I tried two sided lighting yesterday, I found that the back faces were lit, but not in the same way as the front faces.

Well what I did was to make sure that LightModel::setAmbientIntensity() would get the same values where applied.

Did not try it for surfaces with textures though.

@ Paul thanks for the hint!

Cheers,
Florian

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=53101#53101

[Christian Buchner]

@cbuchner1
> Hmm, well I bet a lot of software relies on that feature...

I found threads by the Blender team who had to create workarounds because on some newer Geforce cards (4xx and 5xx series) suddenly the viewport update were orders of magnitude slower.

http://blairwillems.com/2012/04/28/blender-improve-viewport-performance-on-geforce-4xx-5xx-cards/
http://projects.blender.org/tracker/index.php?func=detail&aid=29724&group_id=9&atid=498

Also this issue has been mentioned in the nvidia forums:

https://devtalk.nvidia.com/default/topic/529615/opengl/two-sided-lighting-on-geforce-cards/

So, ideally you would turn the two sided lighting feature off for anything but the simplest geometries, and perform a two sided lighting in a fragment shader.

Christian

[Paul Martz]

On Thu, Mar 14, 2013 at 3:43 AM, Christian Buchner <christia...@gmail.com> wrote:

When I tried two sided lighting yesterday, I found that the back faces were lit, but not in the same way as the front faces.

Are your front and back material colors set to the same values, or to different values?

Two-sided lighting seems to work fine on my GeForce 650, no performance issue that I am aware of. Obviously the lighting computation needs to be done twice at each vertex, but if the model isn't vertex-limited this is not an issue.

   -Paul

[Christian Buchner]

The front and back material properties were set to same values, it's just that when doing the calculations for the back side, the normal vector is not pointing towards the light source but away from it.

I only looked at this issue briefly, and concluded that it would take some GLSL to fix it.

Christian

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

If you enable two-sided lighting, the driver flips the lighting normals
so that the back side of the polygon is lit correctly. There should be
no need to do this in a shader (with OGL that supports fixed
functionality...).

[Paul Martz]

There are a couple different scenarios.

If a surface is composed of triangles that all have a normal consistent with the winding order, but some of the triangles are facing the wrong way, then two-sided lighting will address the issue. That's why I asked the OP if he had tried this.

If your surface has normals that are not consistent with vertex winding order, then you might be able to fix this in a shader by flipping the normal only when the dot product is negative, but I've never tried this. I've always just called it a modeling bug. :-)

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Paul,

Thanks for pointing that out. I failed to mention the winding rule
dependency...

-Shayne