Re: [osg-users] light, normals
Hi JP, Sorry, "primitives" is a bit vague. I normally make separate (sometimes to set e.g. renderbin number on each) osg::Geometry, each with single addPrimitiveSet. I have not tried multiple addPrimitiveSet on single geometry, but think/hope it should also be OK and share the vertex array. Yes all primitive sets in an osg::Geometry use the same vertex array, but then you can only have one normal array (it's setNormalArray() and not addNormalArray()), so you have to go back to what I said and duplicate vertices to be able to get the effect the OP wanted... That's what I meant. Both solutions are good, it depends on how much duplication will result (for my solution) and how many and how large osg::Geometry objects you will get (for your solution). In general video cards work best with rather large batches of geometry sent in one shot, so I expect the duplication scenario to be a bit faster, but it depends on the bottleneck of course. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi J-S, Jean-Sébastien Guay wrote: Hi JP, and make two primitives. By two primitives, do you mean two osg::Geometry objects sharing the same vertex array? (as opposed to two PrimitiveSets in the same osg::Geometry, which is what he was trying to do...) Yes, that's true and clever, I hadn't thought of that. Sorry, "primitives" is a bit vague. I normally make separate (sometimes to set e.g. renderbin number on each) osg::Geometry, each with single addPrimitiveSet. I have not tried multiple addPrimitiveSet on single geometry, but think/hope it should also be OK and share the vertex array. jp Thanks for your insight, J-S -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi JP, and make two primitives. By two primitives, do you mean two osg::Geometry objects sharing the same vertex array? (as opposed to two PrimitiveSets in the same osg::Geometry, which is what he was trying to do...) Yes, that's true and clever, I hadn't thought of that. Thanks for your insight, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi, i wanna thank the two posters for clarifying which different approaches are possible for this issue, because problems like that weren't covered in the basic opengl books i have read. Cheers, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12220#12220 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi, Jean-Sébastien Guay wrote: Hi Christian, my geometry has 9 vertices - i thought if i use a drawElement index with index swaps to revist a vertex, this would give me the opportunity to use more than one normal per vertex (there are reasons why i need this ;-). i now think the truth is, only real vertices in the vertexlist let me allow to do this. Yes, if you need hard edges, then you need different normals for the same vertex when it's part of a different face. But the way to express that with vertex arrays is to duplicate the vertex in the array and use a different normal. Your analysis seems correct. From what you say above, what you actually did was have a larger number of normals than vertices, thinking that then the extra normals would be used when the same vertex was used in a different primitive set. That doesn't work. When normals are used in BIND_PER_VERTEX mode, it's assumed that you have the same number of vertices as normals, and so the result was just that the extra normals were never used. (same with colors in the color array BTW) So to recap, if normals are used in BIND_PER_VERTEX mode, then vertex i is used with normal i. But vertex i and vertex j can be equal, with a different normal j. And then vertex i and vertex j can be part of different triangles (well, should, otherwise you have a degenerate triangle). At first this seems like a waste of memory, but the hardware is really optimized to work this way. Hope this helps, J-S What J-S says is right and would work fine if you want a single primitive. You can however avoid duplicating vertices if you are willing to make more primitives. Simple contrived example: say you want to draw a triangle and specify normals for both sides manually. (GL_TRIANGLES) Now you can make a single vertex array, normal array and drawelements va = [v1, v2, v3, v3, v2, v1] na = [n1, n1, n1, n2, n2, n2] de = [0, 1, 2, 3, 4, 5] and make a primitive out of this. Or, you can make a single vertex array, 2 normal arrays and 2 drawelements va = [v1, v2, v3] na1 = [n1, n1, n1] na2 = [n2, n2, n2] de1 = [0, 1, 2] de2 = [2, 1, 0] and make two primitives. In this way you can sometimes save some memory by having less vertices loaded up. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi Christian, my geometry has 9 vertices - i thought if i use a drawElement index with index swaps to revist a vertex, this would give me the opportunity to use more than one normal per vertex (there are reasons why i need this ;-). i now think the truth is, only real vertices in the vertexlist let me allow to do this. Yes, if you need hard edges, then you need different normals for the same vertex when it's part of a different face. But the way to express that with vertex arrays is to duplicate the vertex in the array and use a different normal. Your analysis seems correct. From what you say above, what you actually did was have a larger number of normals than vertices, thinking that then the extra normals would be used when the same vertex was used in a different primitive set. That doesn't work. When normals are used in BIND_PER_VERTEX mode, it's assumed that you have the same number of vertices as normals, and so the result was just that the extra normals were never used. (same with colors in the color array BTW) So to recap, if normals are used in BIND_PER_VERTEX mode, then vertex i is used with normal i. But vertex i and vertex j can be equal, with a different normal j. And then vertex i and vertex j can be part of different triangles (well, should, otherwise you have a degenerate triangle). At first this seems like a waste of memory, but the hardware is really optimized to work this way. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light, normals
Hi, okay, i think i figured out that the odd shading is only a result of my missunderstanding of the normals BIND_PER_VERTEX concept. my geometry has 9 vertices - i thought if i use a drawElement index with index swaps to revist a vertex, this would give me the opportunity to use more than one normal per vertex (there are reasons why i need this ;-). i now think the truth is, only real vertices in the vertexlist let me allow to do this. if them is so, this thread is solved. Thank you! Cheers, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12169#12169 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] light, normals
Hi,
i need a little help with some lighting issues. the geometry, a roof, consists
of a drawable with one primitive (DrawElement TRIANGLES) and associated normal
vectors per vertex. the problem is, the resulting shading of the rendering is
not what i have expected.
[Image: http://www.spatiality.at/osg/roof_solid.png ]
[Image: http://www.spatiality.at/osg/roof_wire.png ]
face1 is like wanted, but face2 and face3 seem odd for me.
is this caused by a to crude mesh?
Thank you very much!
Christian
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12161#12161
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
osg::Group* root = new osg::Group();
osg::Geode* polygonGeode = new osg::Geode;
osg::Geometry* polygonGeometry = new osg::Geometry;
polygonGeode->addDrawable(polygonGeometry);
root->addChild(polygonGeode);
osg::Vec3Array* polygonVertices = new osg::Vec3Array;
polygonVertices->push_back( osg::Vec3(400, 400, 0) );
polygonVertices->push_back( osg::Vec3(300, 400, 0) );
polygonVertices->push_back( osg::Vec3(300, 300, 0) );
polygonVertices->push_back( osg::Vec3(500, 300, 0) );
polygonVertices->push_back( osg::Vec3(500, 500, 0) );
polygonVertices->push_back( osg::Vec3(400, 500, 0) );
polygonVertices->push_back( osg::Vec3(300, 350, 50) );
polygonVertices->push_back( osg::Vec3(450, 350, 50) );
polygonVertices->push_back( osg::Vec3(450, 500, 50) );
polygonGeometry->setVertexArray(polygonVertices);
osg::DrawElementsUInt* polygonBase = new osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES, 0);
polygonBase->push_back(1);
polygonBase->push_back(2);
polygonBase->push_back(6);
polygonBase->push_back(2);
polygonBase->push_back(3);
polygonBase->push_back(6);
polygonBase->push_back(6);
polygonBase->push_back(3);
polygonBase->push_back(7);
polygonBase->push_back(3);
polygonBase->push_back(4);
polygonBase->push_back(7);
polygonBase->push_back(7);
polygonBase->push_back(4);
polygonBase->push_back(8);
polygonBase->push_back(4);
polygonBase->push_back(5);
polygonBase->push_back(8);
polygonBase->push_back(5);
polygonBase->push_back(7);
polygonBase->push_back(8);
polygonBase->push_back(5);
polygonBase->push_back(0);
polygonBase->push_back(7);
polygonBase->push_back(7);
polygonBase->push_back(0);
polygonBase->push_back(6);
polygonBase->push_back(0);
polygonBase->push_back(1);
polygonBase->push_back(6);
polygonGeometry->addPrimitiveSet(polygonBase);
//osg::StateSet* stateSet = root->getOrCreateStateSet();
//osg::ShadeModel* shadeModel = new osg::ShadeModel;
//shadeModel->setMode(osg::ShadeModel::FLAT);
//stateSet->setAttribute(shadeModel);
// osg::Vec3 lightPosition(-1.0, -1.0, 2.0);
// osg::ref_ptr lightSource = new osg::LightSource;
// lightSource->setDataVariance(osg::Object::DYNAMIC);
// lightSource->getLight()->setPosition(osg::Vec4(lightPosition, 0));
lightSource->getLight()->setAmbient(osg::Vec4(0.2, 0.2, 0.2, 1.0));
// lightSource->getLight()->setDiffuse(osg::Vec4(0.4, 0.4, 0.4, 1.0));
root->addChild(lightSource);
osg::Vec3Array* normals = new osg::Vec3Array;
polygonGeometry->setNormalArray(normals);
polygonGeometry->setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
{ osg::Vec3 norm(-1, 0, 0); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(-1, 0, 0); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(-1, 0, 0); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, -1, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, -1, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, -1, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, -1, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, -1, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, -1, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, 1, 0); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, 1, 0); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(0, 1, 0); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(-1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(-1, 0, 1); norm.normalize(); normals->push_back(norm); }
{ osg::Vec3 norm(-1, 0, 1); norm.normalize(); normals->push_back(norm); }
