Re: [osg-users] Linesegment, shader
Hi Robert, thanks for your quick answer. I think that a shader would be the best way at the moment. Do you know any literature or examples for this problem. If you have any ideas please let me know. Thanks, Roland -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Osfield Gesendet: Montag, 6. Oktober 2008 18:08 An: OpenSceneGraph Users Betreff: Re: [osg-users] Linesegment, shader Hi Roland, You'll need to be a be more specific about the nature of your problem, as this make a huge difference about what solutions you could possibly pursue. For instance if you don't need any results on the CPU and you want the results to be screen space then using shaders is a very good way tackle the problem, but if you need to results back on the CPU then using a GPU to do this would only work effectively in cases were you can wait for a CPU to GPU back to CPU round trip which is very expensive. Robert. On Mon, Oct 6, 2008 at 4:23 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Dear all osg users, I meassure the distance of a ray (linesegment) from a given point (start point of the ray) to the first intersection of this ray with any object in the scene. Now I need more than one ray (up to 4000 rays) to simulate a sensor. I have read that it could be done with a fragment shader, to meassure the distances from any view pose to the object in sight. So, maybe you have any ideas to solve this problem. Best regards, R. Leitner ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning message picked up error in triangleintersection freezes applications running with OSG after approx. 15 minutes
Hi, Jean-Sébastien Guay wrote: Hi Ulrich, Warning:: Picked up error in TriangleIntersect (-1.81147 0.476811 -0.118829, -1.78078 0.471588 -0.0661082, -1.79068 0.886959 -0.0813922) (1.#QNAN, 1.#QNAN, 1.#QNAN) Warning:: Picked up error in TriangleIntersect (-1.79068 0.886959 -0.0813922, -1.78078 0.471588 -0.0661082, -1.78498 This won't help you directly, but as a first step in identifying the source of the problem, the one time I've seen this error is when some objects were moved too far from the origin (to DBL_MAX in this case...). The LineSegmentIntersector at that time used floats, so when DBL_MAX was truncated to a float, it gave QNAN as above, and I got similar messages. And, as you describe, the messages would be printed so often that the application slowed to a crawl. You could scrutinize the placement of objects which you're picking. If there are any objects which might move very far away, or any object you don't want to pick against actually, use nodemasks to prevent the IntersectionVisitor from visiting them. Then again, your problem might be caused by something completely different. It's pretty much a shot in the dark... If you have access to the OSG sources and a debug OSG binary, place a breakpoint where the error message is printed, then run the simulation and try to reproduce the problem. When it breaks, it might at least tell you which node was being tested for intersection, and in which circumstances. Hope this helps, A colleague of mine encountered something similar, it was caused in an intersector by converting small doubles to floats which then became 0's. I've asked him for the details and will post asap. 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] osgdot graph generation tool
Jean-Sébastien Guay wrote: I wanted to see what the graph for a file looked like, and I remembered the osgdot tool that Paul Melis had made. I got it off Mike's osgtoy SVN, and I quickly did a few modifications which I'd like to recontribute. Mike, would you care to integrate my changes? * Uses second command line argument as output filename * Checks that there are exactly two command line arguments, prints usage if not * Gives count of vertices in addition to primitive sets (I'd like to add the detail of primitive types in the future - i.e. 60 triangles, 15 quad strips, etc.) * Fixed the casting pointer to unsigned int issue by using uintptr_t. Hopefully this is supported by all compilers and works on 64 bit machines, I don't have one to test on... I think it's a useful tool, and I'd really like to make it into an output plugin sometime, so it could be integrated into OSG proper. Too much stuff on my plate right now, but I'm keeping it in mind. Hey, that's very nice! I'm happy to see other people find this thingy useful (I knew I did ;-)) Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdot graph generation tool
Schmidt, Richard wrote: I have written an osgDot some time ago, maybe you can use it as a base for yours. It's designed as a plugin, contains the cmake makefiles and uses the visitor concept. Curious, is this a similar tool you wrote yourself, or is this my original tool completely restructured? It's hard to tell :) Paul Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Thrall, Bryan Gesendet: Montag, 6. Oktober 2008 18:23 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgdot graph generation tool Jean-Sébastien Guay wrote on Monday, October 06, 2008 10:19 AM: Hi Bryan, Another improvement I'd be interested in seeing applied is: http://sourceforge.net/tracker/index.php?func=detailaid=1866010group_id=139833atid=744686 Yes, I saw that, I just wanted to keep the modifications small w.r.t. Mike's version of osgdot.cpp in the osgtoy SVN. But I agree, doing that in a visitor is more in keeping with OSG's normal practices. If I make an output plugin out of this, I'll make it with a visitor, as then the modifications will be pretty large anyways. :-) I just didn't want my patch to be forgotten, and thought this was a good opportunity to bring it up :) I'm glad I'm not the only one who thinks this is a nifty tool and is working to improve it. Thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdot graph generation tool
Hi Paul I created it based on your idea. Richard Schmidt, Richard wrote: I have written an osgDot some time ago, maybe you can use it as a base for yours. It's designed as a plugin, contains the cmake makefiles and uses the visitor concept. Curious, is this a similar tool you wrote yourself, or is this my original tool completely restructured? It's hard to tell :) Paul Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Thrall, Bryan Gesendet: Montag, 6. Oktober 2008 18:23 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgdot graph generation tool Jean-Sébastien Guay wrote on Monday, October 06, 2008 10:19 AM: Hi Bryan, Another improvement I'd be interested in seeing applied is: http://sourceforge.net/tracker/index.php?func=detailaid=1866010group_id=139833atid=744686 Yes, I saw that, I just wanted to keep the modifications small w.r.t. Mike's version of osgdot.cpp in the osgtoy SVN. But I agree, doing that in a visitor is more in keeping with OSG's normal practices. If I make an output plugin out of this, I'll make it with a visitor, as then the modifications will be pretty large anyways. :-) I just didn't want my patch to be forgotten, and thought this was a good opportunity to bring it up :) I'm glad I'm not the only one who thinks this is a nifty tool and is working to improve it. Thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to make the StateVisitor::Optimizer and other Optimizer Classes work better
Hi Dimi, The Optimizer class do in general work very well at their job, but they do choose not to be overly aggressive in the optimizations and requiring DataVariance to be STATIC is one of these protections. If you data isn't STATIC then you need to look into why it isn't. Also w.r.t State optimization - there are two parts the first is optimization of StateAttribute's so that all attributes that can be shared are shared, then a second pass that compares the StateSet's, and here it can just use pointer comparisons, and doesn't need to do a deep compare, and the previous pass will have removed all the duplicates. You make no mention of which version of the OSG you are using, so there is no way we can tell whether you are using the latest improvements/fixes to the Optimizer classes, if you aren't then just upgrade as it's pointless trying to debug something that is already fixed. Robert. On Mon, Oct 6, 2008 at 7:40 PM, dimi christop [EMAIL PROTECTED] wrote: A while ago I asked the list why the StateVisitor::Optimizer was not working and why I had very poor optimizing results. I was prompted by more experienced user to investigate the source myself This is what I did and I found a few tricks which will make the optimizer work very well. This holds especially true if you are building you own geometry of do your own loader plugin. 1) Flag the DataVariance of all Attributes and osg::Objects as STATIC unless you want otherwise. I noticed that at least 80% of the optimizer classes skip states for optimization if the Attributes are not flagged as STATIC. So NO STATIC NO OPTIMIZATION. 2) Especially for the StateVisitor::Optimizer class there is also something else to consider. This Optimizer class should merge all the similar StateSets, but in my example even though the StateSets had exactly the same attributes and values they never go merged. Looking further into that matter I found out that the StateVisitor does a shallow compare when checking two StateSets for equality, this means that it looks if the pointers and not their contents are the same. Although OSG supports StateSets compares which take into account the contents of the Attributes there is no way to pass this flag into the StateVisitor::Optimizer class. So there are two solutions if you want it to work a) Mess with the source b) When creating the StateSets take care to attach instanced Attributes whever possible, by reusing the same pointer if the StateSets Attributes have the same values. In general look up yourself the source whenever the optimizer is not working as expected. Also dont always use the DEFAULT_OPTIMIZATION flags there are many more flags which can be used to produce better results. Like the MERGE_GEOMETRY or TRISTRIP_GEOMETRY flag. Also sometimes running 2 consecutive optimizer passes with the same flags produces better results than only one pass. Experimenting is the key. Dimi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice On Texturing Usage (Artifacts w/ osgPango)
Hi Jeremy, On Mon, Oct 6, 2008 at 8:37 PM, Jeremy Moles [EMAIL PROTECTED] wrote: Okay, answered my own question. I reversed the index order (by reversing my calls to addPrimitiveSet()) and it renders properly from the front. But does it render properly from the back? I'm an idiot. :) Welcome to the club :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] release edition question!
Hi YangXio,
Could you have another bash at explaning what you are trying to
achieve and what problems you see as I couldn't work this out from
your original email. Screenshots would help a lot - a picture is
worth a thousand words :-)
Robert.
2008/10/7 YangXiao [EMAIL PROTECTED]:
Hi
When i run my project exe int vs2005,that's ok, But when i run outer
it's not
correct! I function is render a scale a graphics boudary_width and
graphics ..
osg::Group * createGraph(osg::Vec3Array* points,osg::Vec4Array*
graph_color,osg::Vec4Array* boudary_color,int boudary_width,std::string
_name)
{
osg::Group* trans = new osg::Group;
osg::MatrixTransform* trans_scale = new osg::MatrixTransform;
osg::Geode * graph = new osg::Geode;
graph-setName(_name + inter);
osg::Geode * graph_scale = new osg::Geode;
graph_scale-setName(_name + outer);
//得到所有点的x,y轴的包围盒
float x_min=0,x_max=0,y_min=0,y_max=0;
x_min = x_max = points-operator [](0).x();
y_min = y_max = points-operator [](0).y();
for (int i=1;ipoints-size();++i)
{
if ((points-operator [](i).x())x_min)
x_min = points-operator [](i).x();
if ((points-operator [](i).x())x_max)
x_max = points-operator [](i).x();
if ((points-operator [](i).y())y_min)
y_min = points-operator [](i).y();
if ((points-operator [](i).y())y_max)
y_max = points-operator [](i).y();
}
//中心点
double x_mid = (x_min+x_max)/2;
double y_mid = (y_min+y_max)/2;
//得到要伸缩的比例
double x_scale = 1+2*boudary_width/(x_max-x_min);
double y_scale = 1+2*boudary_width/(y_max-y_min);
//设置变换矩阵
osg::Matrix matrix_scale;
osg::Matrix matrix_trans;
osg::Matrix matrix_trans1;
matrix_scale.makeScale(osg::Vec3(x_scale,y_scale,1));
matrix_trans.makeTranslate(-x_mid,-y_mid,0);
matrix_trans1.makeTranslate(x_mid,y_mid,0);
//生成几何节点 osg::Geode* graph = new osg::Geode();
{
//生成新的几何节点
osg::Geometry* geometry = new osg::Geometry();
//geometry-setName(geometry );
osg::Geometry* geometry_scale = new osg::Geometry();
//geometry_scale-setName(geometry_scale);
//设置节点的顶点
geometry-setVertexArray(points);
geometry_scale-setVertexArray(points);
// 设置几何面的颜色
geometry-setColorArray(graph_color);
geometry-setColorBinding(osg::Geometry::BIND_OVERALL);
geometry_scale-setColorArray(boudary_color);
geometry_scale-setColorBinding(osg::Geometry::BIND_OVERALL);
// 添加绘制的几何
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,points-size()));
geometry_scale-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,points-size()));
// Setup blending
geometry-getOrCreateStateSet()-setMode(GL_BLEND,
osg::StateAttribute::ON);
osg::BlendFunc *fn = new osg::BlendFunc();
fn-setFunction(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA);
geometry-getOrCreateStateSet()-setAttributeAndModes(fn,
osg::StateAttribute::ON);
geometry_scale-getOrCreateStateSet()-setAttributeAndModes(fn,
osg::StateAttribute::ON);
//设置透明属性 --透明开关打开
geometry-getOrCreateStateSet()-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
geometry_scale-getOrCreateStateSet()-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
//添加到节点
graph_scale-addDrawable(geometry_scale);
trans_scale-addChild(graph_scale);
osg::Matrix t = matrix_trans*matrix_scale*matrix_trans1;
trans_scale-setMatrix(t);
graph-addDrawable(geometry);
trans-addChild(graph);
trans-addChild(trans_scale);
}
return trans;
}
Best regards. YangXiao.
雅虎邮箱，您的终生邮箱！
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] change vertex shader input dynamically
Hi Fabian, The osgvolume example has code that modifies uniforms via an event handler, so go have a look at this code. The key you are probably missing is passing of a pointer to the uniform to the event handler so that the event handler can set the value directly. Robert. On Tue, Oct 7, 2008 at 5:26 AM, Fabian Bützow [EMAIL PROTECTED] wrote: Hi everyone, I want to change a scalefactor in a vertex program dynamically. The scalefactor is changed by the user via an InputHandler. float scaleFactor= 1.0; ShaderInputHandler* input= new ShaderInputHandler(scaleFactor); //add handler to view .. geometryStateSet-addUniform(new Uniform(scaleFactor, scaleFactor)); I tried to add an update callback, but that didnt work..?! Could you help me? Cheers, Fabian. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linesegment, shader
On Tue, Oct 7, 2008 at 7:45 AM, Leitner, Roland [EMAIL PROTECTED] wrote: Hi Robert, thanks for your quick answer. I think that a shader would be the best way at the moment. Do you know any literature or examples for this problem. If you have any ideas please let me know. You still haven't answer what the problem is. I'd still have to guess at what problem you are trying to solve. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] release edition question!
This sounds like a problem with variable and memory initialisation etc.
When run within VS you operate in a clean sandbox where all the memory
is nicely managed and initialised by VS. In the debug versions, numeric
variables and pointers are initialized to 0 and NULL whilst in the
release versions, those numeric variables and pointers are any random
value so you could have unexpected results.
google debug v release for more info on this - plenty of people have
been bitten. Also http://www.codeproject.com/KB/debug/releasemode.aspx
contains some good info.
I might be wide of the mark but it's the best I can manage based on your
first 2 sentences.
Nick
YangXiao wrote:
Hi
When i run my project exe int vs2005,that's ok, But when i run outer
it's not
correct! I function is render a scale a graphics boudary_width and
graphics ..
osg::Group * createGraph(osg::Vec3Array* points,osg::Vec4Array*
graph_color,osg::Vec4Array* boudary_color,int
boudary_width,std::string _name)
{
osg::Group* trans = new osg::Group;
osg::MatrixTransform* trans_scale = new osg::MatrixTransform;
osg::Geode * graph = new osg::Geode;
graph-setName(_name + inter);
osg::Geode * graph_scale = new osg::Geode;
graph_scale-setName(_name + outer);
//得到所有点的x,y轴的包围盒
float x_min=0,x_max=0,y_min=0,y_max=0;
x_min = x_max = points-operator [](0).x();
y_min = y_max = points-operator [](0).y();
for (int i=1;ipoints-size();++i)
{
if ((points-operator [](i).x())x_min)
x_min = points-operator [](i).x();
if ((points-operator [](i).x())x_max)
x_max = points-operator [](i).x();
if ((points-operator [](i).y())y_min)
y_min = points-operator [](i).y();
if ((points-operator [](i).y())y_max)
y_max = points-operator [](i).y();
}
//中心点
double x_mid = (x_min+x_max)/2;
double y_mid = (y_min+y_max)/2;
//得到要伸缩的比例
double x_scale = 1+2*boudary_width/(x_max-x_min);
double y_scale = 1+2*boudary_width/(y_max-y_min);
//设置变换矩阵
osg::Matrix matrix_scale;
osg::Matrix matrix_trans;
osg::Matrix matrix_trans1;
matrix_scale.makeScale(osg::Vec3(x_scale,y_scale,1));
matrix_trans.makeTranslate(-x_mid,-y_mid,0);
matrix_trans1.makeTranslate(x_mid,y_mid,0);
//生成几何节点 osg::Geode* graph = new osg::Geode();
{
//生成新的几何节点
osg::Geometry* geometry = new osg::Geometry();
//geometry-setName(geometry );
osg::Geometry* geometry_scale = new osg::Geometry();
//geometry_scale-setName(geometry_scale);
//设置节点的顶点
geometry-setVertexArray(points);
geometry_scale-setVertexArray(points);
// 设置几何面的颜色
geometry-setColorArray(graph_color);
geometry-setColorBinding(osg::Geometry::BIND_OVERALL);
geometry_scale-setColorArray(boudary_color);
geometry_scale-setColorBinding(osg::Geometry::BIND_OVERALL);
// 添加绘制的几何
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,points-size()));
geometry_scale-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POLYGON,0,points-size()));
// Setup blending
geometry-getOrCreateStateSet()-setMode(GL_BLEND,
osg::StateAttribute::ON);
osg::BlendFunc *fn = new osg::BlendFunc();
fn-setFunction(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA);
geometry-getOrCreateStateSet()-setAttributeAndModes(fn,
osg::StateAttribute::ON);
geometry_scale-getOrCreateStateSet()-setAttributeAndModes(fn,
osg::StateAttribute::ON);
//设置透明属性 --透明开关打开
geometry-getOrCreateStateSet()-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
geometry_scale-getOrCreateStateSet()-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
//添加到节点
graph_scale-addDrawable(geometry_scale);
trans_scale-addChild(graph_scale);
osg::Matrix t = matrix_trans*matrix_scale*matrix_trans1;
trans_scale-setMatrix(t);
graph-addDrawable(geometry);
trans-addChild(graph);
trans-addChild(trans_scale);
}
return trans;
}
Best regards. YangXiao.
雅虎邮箱，您的终生邮箱！ http://cn.mail.yahoo.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stopping nodes receiving shadows
Hi Roger, I would like to render a scene that has some nodes in it that should not receive a shadow, and also some nodes that should neither cast nor receive a shadow but still be rendered. Not that I want to curb your enthusiasm to fix a percieved problem, but there are ways to achieve what you want without changing the shadow technique code. (Note that I will only speak from experience with osgShadow::ShadowMap and the new ViewDependentShadow techniques - the others I know less about but it might be similar) First of all, ShadowMap and the new ViewDependentShadow classes (LightSpacePerspectiveShadowMap being the one you probably want) will honor the castsShadow traversal mask. So if you flag a node like so: unsigned int castsShadow = shadowedScene-getCastsShadowTraversalMask(); node-setNodeMask(node-getNodeMask() ~castsShadow); it will not cast shadows (and its volume will not be considered when calculating the shadow casting volume, which is good for reducing shadow aliasing in the case of ShadowMap). Second, no shadow technique right now honors the receivesShadow traversal mask. But you can work around this by putting the node you don't want to receive shadows outside the shadowedScene in your scene graph. So for example, your actual scene root would be an ordinary osg::Group, which would have as children all the nodes you don't want to receive shadows, and also the ShadowedScene under which all nodes will receive shadows. You can also add control for receiving shadows in your shadow shader. Both ShadowMap and LightSpacePerspectiveShadowMap allow you to replace the shaders by ones you would write yourself. In my case, I have a single shader pair (vertex + fragment) for the whole scene, where I have a uniform that controls if the object is shadowed (so if this uniform is false, no shadow map lookup will be performed for the current vertex/fragment). Then I just set that uniform to the desired value on the nodes. This might slow down your rendering a bit, but it gives you better control over shadow application in your scene. So with those suggestions I think you can get the result you want. If not, perhaps I've misunderstood what you were trying to accomplish. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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
[osg-users] Can you get the Post Cull results
HI Y'all (OSG 2.61) My colleague has a problem he's trying to solve. In that once the cull has gone through and done its stuff , we need to be able to post process all the nodes that have passed the cull to be dispatched to the draw, we cannot do this in the cull itself as we have to find details about the nodes spatial neighbors in order to modify parts of the geometry based on things like the neighbors level of detail among other things Is there a way to get the node list at the end of the cull traversal or will we have to replace the standard cull traverser with our own that makes saves off a list of nodes that will be dispatched Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can you get the Post Cull results
A couple years ago I created a custom cull visitor to do this. I'd love to find an easier (more appropriate) way of post processing cull results, but my brain hurts every time I dig that deep into osg's internals. Brian [EMAIL PROTECTED] wrote: - To: osg-users@lists.openscenegraph.org From: Tomlinson, Gordon [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 10/07/2008 09:53AM Subject: [osg-users] Can you get the Post Cull results HI Y'all (OSG 2.61) My colleague has a problem he's trying to solve. In that once the cull has gone through and done its stuff , we need to be able to post process all the nodes that have passed the cull to be dispatched to the draw, we cannot do this in the cull itself as we have to find details about the nodes spatial neighbors in order to modify parts of the geometry based on things like the neighbors level of detail among other things Is there a way to get the node list at the end of the cull traversal or will we have to replace the standard cull traverser with our own that makes saves off a list of nodes that will be dispatched Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C) : (+ 1 ) 571-265-2612 ( W ) : (+ 1 ) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linesegment, shader
Hi Roland, On Tue, Oct 7, 2008 at 1:03 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Sorry ;) I need the results (distance map) back to the cpu. If you need the results back on the CPU then you will most likely be best to use a CPU based algorithm. You could render to depth buffer and then read this back but the round trip to the graphics card is likely to blow all the speed advantages of using the CPU for depth testing. From OSG-2.6 onwards the OSG has KdTree support that can help with speed of intersection testing. Or alternatively write your own custom intersection codes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linesegment, shader
Okay, I have to try it. Could you give me any code or literature to implement this for (first) one ray? Thanks, Roland -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Osfield Gesendet: Dienstag, 7. Oktober 2008 14:30 An: OpenSceneGraph Users Betreff: Re: [osg-users] Linesegment, shader Hi Roland, On Tue, Oct 7, 2008 at 1:03 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Sorry ;) I need the results (distance map) back to the cpu. If you need the results back on the CPU then you will most likely be best to use a CPU based algorithm. You could render to depth buffer and then read this back but the round trip to the graphics card is likely to blow all the speed advantages of using the CPU for depth testing. From OSG-2.6 onwards the OSG has KdTree support that can help with speed of intersection testing. Or alternatively write your own custom intersection codes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linesegment, shader
Hi Robert, I have simulated a ray (line segment) which has a given position and orientation in the scene. Then I compute the distance between the start point of the ray and the first object which is intersected by this ray. This distance value is then a gain in a function. Now I would meassure the distances of up to 4000 rays. The start points of these rays are concentrated in one point and divergent like the rays of a pinhole camera. I need the distances use it as gains in a function that is computed every frame step in the same code. If you have any questions, please let me know. Regards, Roland -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Osfield Gesendet: Montag, 6. Oktober 2008 18:08 An: OpenSceneGraph Users Betreff: Re: [osg-users] Linesegment, shader Hi Roland, You'll need to be a be more specific about the nature of your problem, as this make a huge difference about what solutions you could possibly pursue. For instance if you don't need any results on the CPU and you want the results to be screen space then using shaders is a very good way tackle the problem, but if you need to results back on the CPU then using a GPU to do this would only work effectively in cases were you can wait for a CPU to GPU back to CPU round trip which is very expensive. Robert. On Mon, Oct 6, 2008 at 4:23 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Dear all osg users, I meassure the distance of a ray (linesegment) from a given point (start point of the ray) to the first intersection of this ray with any object in the scene. Now I need more than one ray (up to 4000 rays) to simulate a sensor. I have read that it could be done with a fragment shader, to meassure the distances from any view pose to the object in sight. So, maybe you have any ideas to solve this problem. Best regards, R. Leitner ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] subversion tags
Hi, This is probably only directed to Paul Martz and Robert Osfield, but here it goes : I was wondering if you could add two more tags on the subversion repository that would be tagging the latest stable and development releases and evolving with them. For example : OpenSceneGraph-latest-stable-release would be the same as OpenSceneGraph-2.6.1 OpenSceneGraph-latest-dev-release would be OpenSceneGraph-2.7.2 as of today and moving to OpenSceneGraph-2.7.3 sooner or later. My aim is to setup (my) continuous integration servers to build automatically the latest version of each branch. -- Mathieu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgParticle
Good day! I built custom particle system like in tutorials on osg site Now I'd like to control it using event handlers For example when I press a key I'd like to emit particle What's the best way to do it? Thanx in advance Bye ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linesegment, shader
Hi Roland, Thanks for the extra details, but alas still missing important bits - answered parts from my first set of questions. The key is what do you want to do with gain function, you do need this result for all the rays back on the CPU, or can it be used in shader to compute a pixel value that will be seen on screen or used as a texture for later rendering? Robert. On Tue, Oct 7, 2008 at 12:11 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Hi Robert, I have simulated a ray (line segment) which has a given position and orientation in the scene. Then I compute the distance between the start point of the ray and the first object which is intersected by this ray. This distance value is then a gain in a function. Now I would meassure the distances of up to 4000 rays. The start points of these rays are concentrated in one point and divergent like the rays of a pinhole camera. I need the distances use it as gains in a function that is computed every frame step in the same code. If you have any questions, please let me know. Regards, Roland -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Osfield Gesendet: Montag, 6. Oktober 2008 18:08 An: OpenSceneGraph Users Betreff: Re: [osg-users] Linesegment, shader Hi Roland, You'll need to be a be more specific about the nature of your problem, as this make a huge difference about what solutions you could possibly pursue. For instance if you don't need any results on the CPU and you want the results to be screen space then using shaders is a very good way tackle the problem, but if you need to results back on the CPU then using a GPU to do this would only work effectively in cases were you can wait for a CPU to GPU back to CPU round trip which is very expensive. Robert. On Mon, Oct 6, 2008 at 4:23 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Dear all osg users, I meassure the distance of a ray (linesegment) from a given point (start point of the ray) to the first intersection of this ray with any object in the scene. Now I need more than one ray (up to 4000 rays) to simulate a sensor. I have read that it could be done with a fragment shader, to meassure the distances from any view pose to the object in sight. So, maybe you have any ideas to solve this problem. Best regards, R. Leitner ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stopping nodes receiving shadows
Hi Cedric, I already notice this problem for my usage i fixed it (for the osg 2.6). Check in the file as attachement for USE_RECEIVER_MASK I recommand you to search in the mailing because we already talk about that before, and it could give you more informations. Was this submitted for inclusion into the baseline OSG? It looks like it solves a long standing problem with ShadowMap (the receivesShadow mask doesn't have any effect). Although, as I said, there are already other ways to accomplish that. And I may have been mistaken, it looks like the ViewDependentShadow techniques use the receivesShadow mask as well. I've never checked if it works, but I assume it does :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Can you get the Post Cull results
Hi Gordon, I think the easiest way forward would be to subclass from osgViewer::Renderer an provide you own implementation of cull/draw. It might be that we could refactor the Renderer base class a little to make this type of subclassing more straight forward so I'm open to suggestions. Robert. On Tue, Oct 7, 2008 at 2:53 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: HI Y'all (OSG 2.61) My colleague has a problem he's trying to solve. In that once the cull has gone through and done its stuff , we need to be able to post process all the nodes that have passed the cull to be dispatched to the draw, we cannot do this in the cull itself as we have to find details about the nodes spatial neighbors in order to modify parts of the geometry based on things like the neighbors level of detail among other things Is there a way to get the node list at the end of the cull traversal or will we have to replace the standard cull traverser with our own that makes saves off a list of nodes that will be dispatched Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice On Texturing Usage (Artifacts w/ osgPango)
On Tue, 2008-10-07 at 09:16 +0100, Robert Osfield wrote: Hi Jeremy, On Mon, Oct 6, 2008 at 8:37 PM, Jeremy Moles [EMAIL PROTECTED] wrote: Okay, answered my own question. I reversed the index order (by reversing my calls to addPrimitiveSet()) and it renders properly from the front. But does it render properly from the back? Well, no matter what I do I can't get it to render properly from both sides using my current method. However, as long as I make sure the geometry's Z values are properly ascending (that is, the first quad has a z == -1.0f, and each quad increments z by 0.001f) then it renders properly from the front at least. The real way to do it, I think, is to have an UpdateCallback that sorts the Geometry based on each quad's size somehow, switching to DrawElements instead of DrawArrays... I'm an idiot. :) Welcome to the club :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice On Texturing Usage (Artifacts w/ osgPango)
Jeremy Moles schrieb: On Tue, 2008-10-07 at 09:16 +0100, Robert Osfield wrote: Hi Jeremy, On Mon, Oct 6, 2008 at 8:37 PM, Jeremy Moles [EMAIL PROTECTED] wrote: Okay, answered my own question. I reversed the index order (by reversing my calls to addPrimitiveSet()) and it renders properly from the front. But does it render properly from the back? Well, no matter what I do I can't get it to render properly from both sides using my current method. However, as long as I make sure the geometry's Z values are properly ascending (that is, the first quad has a z == -1.0f, and each quad increments z by 0.001f) then it renders properly from the front at least. The real way to do it, I think, is to have an UpdateCallback that sorts the Geometry based on each quad's size somehow, switching to DrawElements instead of DrawArrays... Have you tried to disable writing into the depth-buffer? This is what I am doing with a similar problem, no depth-sorting needed. This approach has some other disadavantages, though. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stopping nodes receiving shadows
Hi This code is not submitted because it's just a work around, not a clean way to do it, i make it when i tried shadow. I did not work again on the new shadow implementation but when I will test it, it will be the time to adapt this code for it if it's not yet included :) If it can help other users, i will be happy to contribute :) Cedric Jean-Sébastien Guay wrote: Hi Cedric, I already notice this problem for my usage i fixed it (for the osg 2.6). Check in the file as attachement for USE_RECEIVER_MASK I recommand you to search in the mailing because we already talk about that before, and it could give you more informations. Was this submitted for inclusion into the baseline OSG? It looks like it solves a long standing problem with ShadowMap (the receivesShadow mask doesn't have any effect). Although, as I said, there are already other ways to accomplish that. And I may have been mistaken, it looks like the ViewDependentShadow techniques use the receivesShadow mask as well. I've never checked if it works, but I assume it does :-) J-S -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Near and far calculation and depth maps (and a questionabout WoWvx)
Chris, Please read following page, until final conclusion: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html So if you have gone to the conclusion you should now understand why computeNearFar is added to OSG. It simply allows to better utilize depth buffer range. Compute NearFar using primitives is simply more precise than using bounding volumes so this may explain why you got better results with COMPUTE_NEAR_FAR_USING_PRIMITIVES. You should also know that depth buffer spread does not linearly correspond to view space z coordinate. Thats why when displayed as grayscale some objects may be hard to discern (especially if 24 bits are clamped to 8 bits). Depth buffer values are spread non linearly so when put into monochrome image they often end up with so similar colors that image looks completely flat (either white or black). You may want to add special shader to pseudo color depth buffer like in topographical maps to actually notice variety of depth values. I hope this helps a little ;-). Cheers, Wojtek I have a few questions about the way OSG handles depth maps, and how the range of depth values relates to the near and far calculation done by OSG. Firstly, just to confirm my understanding. I have assumed that the purpose of OSG calculating nearfar values is so that depth map values will range between 0.0 and 1.0 for pixels rendered between the near and far range. Oh.. and for clipping too!? Please shoot me now if that's not correct. ;-) As a test case, I constructed a very simple scene comprised of a large cuboid with a number of smaller cuboids within it. When I move the camera inside the large cuboid, I had expected the depth map rendered by an RTT camera to show depth values of all the smaller cuboids in the scene, but it doesn't, it just seems to contain a solid black texture. (you can easily display an inverted representation of the depth map of a scene using the osgViewer option '--wowvx-20') Now, the odd thing is that if I change the nearfar calculation mode of the RTT camera to: camera-setComputeNearFarMode(osg::CullSettings::ComputeNearFarMode::COMPUTE_NEAR_FAR_USING_PRIMITIVES) instead of the default, which is COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES ,the smaller cubes now appear as I would have expected in the depthmap. I have been looking for an explantion for this difference in the OSG code in: bool CullVisitor::updateCalculatedNearFar(const osg::Matrix matrix,const osg::Drawable drawable, bool isBillboard) It seemed to me that there may be an issue with the code: ---snip--- //if (d_near0.0) osg::notify(osg::WARN) 3) set near with d_near=d_near std::endl; _computed_znear = d_near; ---snip--- which allows negative values of 'd_near' to be assigned to '_computed_znear' and hence the near clipping plane to be behind the camera. In fact, the code a few lines above this snippet does ignore values of d_near 0.0, so I wondered if this snippet should have the same logic. In fact, if I change the snippet above (by removing the comment and putting in an else), ---new snip--- if (d_near0.0) osg::notify(osg::WARN) 3) set near with d_near=d_near std::endl; else _computed_znear = d_near; ---new snip--- the depth map seems correct for my test example, yippie! Let me know if I need to put this change on the submissions list. Ah ha nope.. I haven't finished with your attention yet ;-) What follows is a different issue, only loosely related to the above: I can see that I should expect to get a kind of 'popping' effect in a depth map range due to culling of objects as I move through as scene. It seemed to me that getting 'smooth' transitions in near/far calculations would be 'at least in concept' a difficult/impossible problem to solve. You are probably wondering why I care about this, when a even large jitters in depth map range does not seem to affect the rendered scene much. The answer is, because the depth map is used as part of the input to a WoWvx autostereoscopic display. The problem is that to transfer the depthmap data to the stereoscopic display, the depthmap gets rendered as a greyscale image, presumably losing a lot of precision in converting to int 0-255 range greyscale color value. The effect I get as I move through a scene is that the contrast in the depthmap image seems to fade in and out as I move the camera past objects in the scene, and this affects the 3D effect you get from the WoWvx. I can see that the WoWvx implementation in OSG does include some disparity calculation shader code that allows adjustment of the conversion from depthmap value to greyscale, but it is difficult to see how to calculate the parameters 'on the fly' as you move through a scene. Does anyone have any suggestions or advice on how dynamically keep more contrast in greyscale rendering of a depthmap? Chris. ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Advice On Texturing Usage (Artifacts w/ osgPango)
Hi Jeremy, On Tue, Oct 7, 2008 at 3:00 PM, Jeremy Moles [EMAIL PROTECTED] wrote: But does it render properly from the back? Well, no matter what I do I can't get it to render properly from both sides using my current method. I suspected this would be the case. However, as long as I make sure the geometry's Z values are properly ascending (that is, the first quad has a z == -1.0f, and each quad increments z by 0.001f) then it renders properly from the front at least. The real way to do it, I think, is to have an UpdateCallback that sorts the Geometry based on each quad's size somehow, switching to DrawElements instead of DrawArrays... One could possibly use glPolygonOffset but this is has problems of its own. One approach I have contemplated for osgText is to allow for the glyphs quads to overlap, but whether there is an overlap break the quads up into non overlapping and overlapping chunks. Then when the glyphs are rendered the parts that overlap use exactly the same coords so all fragments on the overlap have the same coordinates which in turn means that you can the depth test mode that allows fragments through when their z value is the same or less. While I'm not at a point that I can dive into osgText right now, me feeling is that osgPango and osgText functionality need to be brought all under osgText, with us learning from when Pango and osggPango do above the existing osgText library and coding this directly into osgText, whilest at the same time taking advantage of some more robust rendering approach such as the one I suggest above. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stopping nodes receiving shadows
Hi Cedric, This code is not submitted because it's just a work around, not a clean way to do it, i make it when i tried shadow. Well, doing two traversals is pretty much required if you don't want to change the shader. This may have a large performance hit however. In my experience, using shadow maps more than doubles the cull time on machines with a slow CPU, so if this can be kept to a minimum, all the better. I think the way I gave with a uniform parameter in the shader to control this is more flexible, and it might be faster (since you then only do one traversal). Testing would be needed to confirm this of course, and it would depend on the scene you're rendering. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Stopping nodes receiving shadows
Hi,
I already notice this problem for my usage i fixed it (for the osg 2.6).
Check in the file as attachement for USE_RECEIVER_MASK
I recommand you to search in the mailing because we already talk about
that before, and it could give you more informations.
Cheers,
Cedric
Jean-Sébastien Guay wrote:
Hi Roger,
I would like to render a scene that has some nodes in it that should
not receive a shadow, and also some nodes that should neither cast
nor receive a shadow but still be rendered.
Not that I want to curb your enthusiasm to fix a percieved problem,
but there are ways to achieve what you want without changing the
shadow technique code.
(Note that I will only speak from experience with osgShadow::ShadowMap
and the new ViewDependentShadow techniques - the others I know less
about but it might be similar)
First of all, ShadowMap and the new ViewDependentShadow classes
(LightSpacePerspectiveShadowMap being the one you probably want) will
honor the castsShadow traversal mask. So if you flag a node like so:
unsigned int castsShadow = shadowedScene-getCastsShadowTraversalMask();
node-setNodeMask(node-getNodeMask() ~castsShadow);
it will not cast shadows (and its volume will not be considered when
calculating the shadow casting volume, which is good for reducing
shadow aliasing in the case of ShadowMap).
Second, no shadow technique right now honors the receivesShadow
traversal mask. But you can work around this by putting the node you
don't want to receive shadows outside the shadowedScene in your scene
graph. So for example, your actual scene root would be an ordinary
osg::Group, which would have as children all the nodes you don't want
to receive shadows, and also the ShadowedScene under which all nodes
will receive shadows.
You can also add control for receiving shadows in your shadow shader.
Both ShadowMap and LightSpacePerspectiveShadowMap allow you to replace
the shaders by ones you would write yourself. In my case, I have a
single shader pair (vertex + fragment) for the whole scene, where I
have a uniform that controls if the object is shadowed (so if this
uniform is false, no shadow map lookup will be performed for the
current vertex/fragment). Then I just set that uniform to the desired
value on the nodes. This might slow down your rendering a bit, but it
gives you better control over shadow application in your scene.
So with those suggestions I think you can get the result you want. If
not, perhaps I've misunderstood what you were trying to accomplish.
Hope this helps,
J-S
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED]
http://www.plopbyte.net
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgShadow/ShadowMap
#include osgShadow/ShadowedScene
#include osg/Notify
#include osg/ComputeBoundsVisitor
#include osg/PolygonOffset
#include osg/CullFace
#include osg/io_utils
using namespace osgShadow;
#include iostream
//for debug
#include osg/LightSource
#include osg/PolygonMode
#include osg/Geometry
#include osgDB/ReadFile
#include osgText/Text
#define IMPROVE_TEXGEN_PRECISION 1
//
// fragment shader
//
static const char fragmentShaderSource_noBaseTexture[] =
uniform sampler2DShadow osgShadow_shadowTexture; \n
uniform vec2 osgShadow_ambientBias; \n
\n
void main(void) \n
{ \n
gl_FragColor = gl_Color * (osgShadow_ambientBias.x + shadow2DProj( osgShadow_shadowTexture, gl_TexCoord[0] ) * osgShadow_ambientBias.y); \n
}\n;
//
// fragment shader
//
static const char fragmentShaderSource_withBaseTexture[] =
uniform sampler2D osgShadow_baseTexture; \n
uniform sampler2DShadow osgShadow_shadowTexture; \n
uniform vec2 osgShadow_ambientBias; \n
\n
void main(void) \n
{ \n
vec4 color = gl_Color * texture2D( osgShadow_baseTexture, gl_TexCoord[0].xy ); \n
gl_FragColor = color * (osgShadow_ambientBias.x + shadow2DProj( osgShadow_shadowTexture, gl_TexCoord[1] ) * osgShadow_ambientBias.y); \n
}\n;
//
// fragment shader
//
static const char fragmentShaderSource_debugHUD_texcoord[] =
uniform sampler2D osgShadow_shadowTexture; \n
\n
void main(void) \n
{ \n
vec4 texCoord =
Re: [osg-users] Stopping nodes receiving shadows
Yes i dont say my implementation is good, it was just the easiest way i found to do it. I am not very confortable with the uniform because it could not work if you use a more complex shader, or you will have to take care about the shader you use and reimport the uniform in your shader to manage this case, it's maybe not a problem but you are right it's probably faster than re culling. Anyway I would need more time to investigate this functionnality and test with uniform. I will have the time soon, I hope :) Cedric Jean-Sébastien Guay wrote: Hi Cedric, This code is not submitted because it's just a work around, not a clean way to do it, i make it when i tried shadow. Well, doing two traversals is pretty much required if you don't want to change the shader. This may have a large performance hit however. In my experience, using shadow maps more than doubles the cull time on machines with a slow CPU, so if this can be kept to a minimum, all the better. I think the way I gave with a uniform parameter in the shader to control this is more flexible, and it might be faster (since you then only do one traversal). Testing would be needed to confirm this of course, and it would depend on the scene you're rendering. J-S -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linesegment, shader
Hi Robert, Sorry ;) I need the results (distance map) back to the cpu. Roland -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Osfield Gesendet: Dienstag, 7. Oktober 2008 13:44 An: OpenSceneGraph Users Betreff: Re: [osg-users] Linesegment, shader Hi Roland, Thanks for the extra details, but alas still missing important bits - answered parts from my first set of questions. The key is what do you want to do with gain function, you do need this result for all the rays back on the CPU, or can it be used in shader to compute a pixel value that will be seen on screen or used as a texture for later rendering? Robert. On Tue, Oct 7, 2008 at 12:11 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Hi Robert, I have simulated a ray (line segment) which has a given position and orientation in the scene. Then I compute the distance between the start point of the ray and the first object which is intersected by this ray. This distance value is then a gain in a function. Now I would meassure the distances of up to 4000 rays. The start points of these rays are concentrated in one point and divergent like the rays of a pinhole camera. I need the distances use it as gains in a function that is computed every frame step in the same code. If you have any questions, please let me know. Regards, Roland -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Osfield Gesendet: Montag, 6. Oktober 2008 18:08 An: OpenSceneGraph Users Betreff: Re: [osg-users] Linesegment, shader Hi Roland, You'll need to be a be more specific about the nature of your problem, as this make a huge difference about what solutions you could possibly pursue. For instance if you don't need any results on the CPU and you want the results to be screen space then using shaders is a very good way tackle the problem, but if you need to results back on the CPU then using a GPU to do this would only work effectively in cases were you can wait for a CPU to GPU back to CPU round trip which is very expensive. Robert. On Mon, Oct 6, 2008 at 4:23 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Dear all osg users, I meassure the distance of a ray (linesegment) from a given point (start point of the ray) to the first intersection of this ray with any object in the scene. Now I need more than one ray (up to 4000 rays) to simulate a sensor. I have read that it could be done with a fragment shader, to meassure the distances from any view pose to the object in sight. So, maybe you have any ideas to solve this problem. Best regards, R. Leitner ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice On Texturing Usage (Artifacts w/ osgPango)
Hi all, I will try to reorder the index array from the area of quads in an update callback. Then it should work but specific for this case. Cedric Robert Osfield wrote: Hi Jeremy, On Tue, Oct 7, 2008 at 3:00 PM, Jeremy Moles [EMAIL PROTECTED] wrote: But does it render properly from the back? Well, no matter what I do I can't get it to render properly from both sides using my current method. I suspected this would be the case. However, as long as I make sure the geometry's Z values are properly ascending (that is, the first quad has a z == -1.0f, and each quad increments z by 0.001f) then it renders properly from the front at least. The real way to do it, I think, is to have an UpdateCallback that sorts the Geometry based on each quad's size somehow, switching to DrawElements instead of DrawArrays... One could possibly use glPolygonOffset but this is has problems of its own. One approach I have contemplated for osgText is to allow for the glyphs quads to overlap, but whether there is an overlap break the quads up into non overlapping and overlapping chunks. Then when the glyphs are rendered the parts that overlap use exactly the same coords so all fragments on the overlap have the same coordinates which in turn means that you can the depth test mode that allows fragments through when their z value is the same or less. While I'm not at a point that I can dive into osgText right now, me feeling is that osgPango and osgText functionality need to be brought all under osgText, with us learning from when Pango and osggPango do above the existing osgText library and coding this directly into osgText, whilest at the same time taking advantage of some more robust rendering approach such as the one I suggest above. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stopping nodes receiving shadows
Hi Cedric, I am not very confortable with the uniform because it could not work if you use a more complex shader, or you will have to take care about the shader you use and reimport the uniform in your shader to manage this case, it's maybe not a problem but you are right it's probably faster than re culling. Once you move to completely shader-based rendering, you need to keep an firm grip on your shaders in order to control everything :-) For example, if some other node somewhere is using another shader that is overriding your own shaders it will give wrong results. So yes, you have to know what is going on with shaders everywhere in your graph. It's just part of the game. :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Warning message picked up error in triangleintersection freezes applications running with OSG after approx. 15 minutes
forgot the attachment...
J.P. Delport wrote:
Hi,
J.P. Delport wrote:
Hi,
Jean-Sébastien Guay wrote:
Hi Ulrich,
Warning:: Picked up error in TriangleIntersect
(-1.81147 0.476811 -0.118829, -1.78078 0.471588 -0.0661082, -1.79068
0.886959 -0.0813922)
(1.#QNAN, 1.#QNAN, 1.#QNAN)
Warning:: Picked up error in TriangleIntersect
(-1.79068 0.886959 -0.0813922, -1.78078 0.471588 -0.0661082, -1.78498
This won't help you directly, but as a first step in identifying the
source of the problem, the one time I've seen this error is when some
objects were moved too far from the origin (to DBL_MAX in this
case...). The LineSegmentIntersector at that time used floats, so
when DBL_MAX was truncated to a float, it gave QNAN as above, and I
got similar messages. And, as you describe, the messages would be
printed so often that the application slowed to a crawl.
You could scrutinize the placement of objects which you're picking.
If there are any objects which might move very far away, or any
object you don't want to pick against actually, use nodemasks to
prevent the IntersectionVisitor from visiting them.
Then again, your problem might be caused by something completely
different. It's pretty much a shot in the dark... If you have access
to the OSG sources and a debug OSG binary, place a breakpoint where
the error message is printed, then run the simulation and try to
reproduce the problem. When it breaks, it might at least tell you
which node was being tested for intersection, and in which
circumstances.
Hope this helps,
A colleague of mine encountered something similar, it was caused in an
intersector by converting small doubles to floats which then became 0's.
I've asked him for the details and will post asap.
Two things you could try.
1) Attached is my colleague's modified IntersectVisitor.cpp, there is a
check for the size of TriangleIntersect.
2) You could try make the struct TriangleIntersect in
IntersectVisitor.cpp use Vec3d instead of Vec3.
Let us know if either works.
regards
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.
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgUtil/IntersectVisitor
#include osg/Transform
#include osg/Geode
#include osg/LOD
#include osg/Billboard
#include osg/Notify
#include osg/TriangleFunctor
#include osg/Geometry
#include osg/Projection
#include osg/Camera
#include osg/io_utils
#include float.h
#include algorithm
#include map
using namespace osg;
using namespace osgUtil;
Hit::Hit()
{
}
Hit::Hit(const Hit hit)
{
// copy data across.
_ratio = hit._ratio;
_originalLineSegment = hit._originalLineSegment;
_localLineSegment = hit._localLineSegment;
_nodePath = hit._nodePath;
_geode = hit._geode;
_drawable = hit._drawable;
_matrix = hit._matrix;
_inverse = hit._inverse;
_vecIndexList = hit._vecIndexList;
_primitiveIndex = hit._primitiveIndex;
_intersectPoint = hit._intersectPoint;
_intersectNormal = hit._intersectNormal;
}
Hit::~Hit()
{
}
Hit Hit::operator = (const Hit hit)
{
if (hit==this) return *this;
_matrix = hit._matrix;
_inverse = hit._inverse;
_originalLineSegment = hit._originalLineSegment;
_localLineSegment = hit._localLineSegment;
// copy data across.
_ratio = hit._ratio;
_nodePath = hit._nodePath;
_geode = hit._geode;
_drawable = hit._drawable;
_vecIndexList = hit._vecIndexList;
_primitiveIndex = hit._primitiveIndex;
_intersectPoint = hit._intersectPoint;
_intersectNormal = hit._intersectNormal;
return *this;
}
const osg::Vec3 Hit::getWorldIntersectNormal() const
{
if (_inverse.valid())
{
osg::Vec3 norm = osg::Matrix::transform3x3(*_inverse,_intersectNormal);
norm.normalize();
return norm;
}
else return _intersectNormal;
}
IntersectVisitor::IntersectState::IntersectState()
{
_segmentMaskStack.push_back(0x);
}
IntersectVisitor::IntersectState::~IntersectState()
{
}
bool
Re: [osg-users] Linesegment, shader
On Tue, Oct 7, 2008 at 1:42 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Okay, I have to try it. Could you give me any code or literature to implement this for (first) one ray? osgUtil::IntersectionVisitor coupled with a osgUtil::LineSegmentIntersector is your first point of call on the OSG side. Examples like osgintersection would be one place to start w.r.t code examples. The IntersectionVisitor is used all over the OSG so go searching through the sources. Also see osgkdtree example and osg-users archives for discussion about the new KdTree support. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] observer_ptr threadsafe?
Hi Richard, On Tue, Oct 7, 2008 at 3:04 PM, Schmidt, Richard [EMAIL PROTECTED] wrote: The DatabaseRequests store observer_ptrs to those nodes where they want to insert the node they just loaded. In the database pager code one will find it in void DatabasePager::addLoadedDataToSceneGraph(double timeStamp): osg::ref_ptrosg::Group group = databaseRequest-_groupForAddingLoadedSubgraph.get(); In this case it seem to be valid, because addLoadedDataToSceneGraph is called by the main thread?!. osg::observer_ptr is used in this case as the _groupForAddingLoadedSubgraph node has a ref_ptr to the DatabaseRequest, and if it had a ref_ptr it'd create a circular dependency and prevent the node and DatabaseRequest from ever being deleted. Whether this particular line is safe is something we'll need to review carefully. I wrote with the assumption that it would be safe, but threading is rather wistful beast so I might have missed possible failure cases. For there to a be possible failure in this case we'd require 1) ref_ptr = observer_ptr to not be thread safe 2) for another thread or threads to be able to delete the _groupForAddingLoadedSubgraph at the same time as addLoadedDataToSceneGraph is running (or possible even just the same time as this assignment.) However my question is: Is there a thread safe way going from observer_ptr to ref_ptr? Asking the question other way around would be a bit more informative, what threading combination would lead to a problem with ref_ptr to observer_ptr and if there is a problem, what can we do about it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stopping nodes receiving shadows
Shadow people, I would like to render a scene that has some nodes in it that should not receive a shadow, and also some nodes that should neither cast nor receive a shadow but still be rendered. From looking at the code it appeared to me that ReceivesShadowTraversalMask was the thing to control this, however on closer inspection I find that only the MinimalDrawBoundsShadowMap and ShadowTexture techniques use this mask in any way. Of these two only ShadowTexture uses this mask to control decoration of the main scene traversal. The ShadowTexture technique does two consecutive traversals of the main scene using the normal (non RTT) camera. One with a logical and of the main cull traversal mask and the receives shadow traversal mask and another with a logical and of the main cull traversal mask and the casts shadow traversal mask. As far as I can see this has two drawbacks, firstly that nodes with active bits umasked by both the receives shadow (cull) mask and the casts shadow (cull) mask will be rendered twice (Is this true, or have I missed something?), and secondly nodes with no active bits in either mask will not be rendered at all. I started thinking of ways I could fix this (in ShadowTexture for a start!) but have come to a stop. Does anyone have any ideas on how to approach it. The most promising way I have so far is to do the main scene traversal with a derived version of osgUtil::CullVisitor but the complexity of transferring state from one cull visitor to another has defeated me. My apologies in advance if I have missed something obvious. But for the time being it looks like I will have to put up with shadows on my selection highlights and translucent geometry :-) Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stopping nodes receiving shadows
Hi Guys, Nope, receivesShadowMask is generally ignored in ViewDependentShadows. Exception in MinimaDrawBoundsShadowMap but there it is used only to approximate shadow volume which is later additionaly refined. Problem is that implementing receiveShadowMask without messing with shaders/and uniforms during render traversals would probably require splitting cull traversal into two traversals one for receiveShadowMask nodes and one for those without it. Two cull traversals probably mean two sets of render stages and possible issues with bin sorting. I guess that alternatively one may use shadow shader and special uniform which would activate shadow map for nodes with receiveShadowMask I suspose thats what J-S did. And I think its ok when done explicitly by end user programmer. But such approach on middleware/library level would probably mean adding aditional uniforms and/or shaders into stategraph according to node maks found while culling. I am not sure if this is fully acceptable and risk free. This also means that shadow shader would be used for all nodes even for those without receiveShadowMask. If one would expect that shadowing would not touch any aspect of receiveShadowMask free nodes he could be unpleseantly surprised as shaders usually make some shortcuts and sacrifice some of fixed pipeline functionality. In my opinion generic shadow algorthm which could be used without modification with all types of database and types of aplication was not yet found. And I would not try to make such algorithm. Anyone should expect that if certain approach does not work for their case they need to either derive their own shadow from exisiting classes or create their own solutions. Cheers, Wojtek Hi Cedric, I already notice this problem for my usage i fixed it (for the osg 2.6). Check in the file as attachement for USE_RECEIVER_MASK I recommand you to search in the mailing because we already talk about that before, and it could give you more informations. Was this submitted for inclusion into the baseline OSG? It looks like it solves a long standing problem with ShadowMap (the receivesShadow mask doesn't have any effect). Although, as I said, there are already other ways to accomplish that. And I may have been mistaken, it looks like the ViewDependentShadow techniques use the receivesShadow mask as well. I've never checked if it works, but I assume it does :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] subversion tags
Hi Robert, I'm not talking about a symbolique link. It's just a another copy, just plain subversion copy : svn copy -mtagging 2.7.2 http://.../trunk http://.../tags/osg-2.7.2 svn copy -mupdating developer release http://.../tags/osg-2.7.2 http://.../tags/osg-latest-dev-release and then tagging next release would be the same : svn copy -mtagging 2.7.3 http://.../trunk http://.../tags/osg-2.7.3 svn copy -mupdating developer release http://.../tags/osg-2.7.3 http://.../tags/osg-latest-dev-release Only if I wanted to have the the latest developer release checked out, if I had : svn co http://.../tags/osg-latest-dev-release osg-devel in the 2.7.2 days it would then update to the 2.7.3 (when it's tagged) with an svn update Is it a bit clearer ? Mathieu 2008/10/7 Robert Osfield [EMAIL PROTECTED]: Hi Mathieu, What you are asking for is symbolic link to the latest tags rather than an actual tag. I don't know if svn is capable of doing something like this. Perhaps the webserver could do some url direction.. I have no clue on this stuff so I'll leave it to svn server and web server experts to dive in with recommendations. Robert. On Tue, Oct 7, 2008 at 3:07 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi, This is probably only directed to Paul Martz and Robert Osfield, but here it goes : I was wondering if you could add two more tags on the subversion repository that would be tagging the latest stable and development releases and evolving with them. For example : OpenSceneGraph-latest-stable-release would be the same as OpenSceneGraph-2.6.1 OpenSceneGraph-latest-dev-release would be OpenSceneGraph-2.7.2 as of today and moving to OpenSceneGraph-2.7.3 sooner or later. My aim is to setup (my) continuous integration servers to build automatically the latest version of each branch. -- Mathieu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning message picked up error in triangleintersection freezes applications running with OSG after approx. 15 minutes
Hi, J.P. Delport wrote: Hi, Jean-Sébastien Guay wrote: Hi Ulrich, Warning:: Picked up error in TriangleIntersect (-1.81147 0.476811 -0.118829, -1.78078 0.471588 -0.0661082, -1.79068 0.886959 -0.0813922) (1.#QNAN, 1.#QNAN, 1.#QNAN) Warning:: Picked up error in TriangleIntersect (-1.79068 0.886959 -0.0813922, -1.78078 0.471588 -0.0661082, -1.78498 This won't help you directly, but as a first step in identifying the source of the problem, the one time I've seen this error is when some objects were moved too far from the origin (to DBL_MAX in this case...). The LineSegmentIntersector at that time used floats, so when DBL_MAX was truncated to a float, it gave QNAN as above, and I got similar messages. And, as you describe, the messages would be printed so often that the application slowed to a crawl. You could scrutinize the placement of objects which you're picking. If there are any objects which might move very far away, or any object you don't want to pick against actually, use nodemasks to prevent the IntersectionVisitor from visiting them. Then again, your problem might be caused by something completely different. It's pretty much a shot in the dark... If you have access to the OSG sources and a debug OSG binary, place a breakpoint where the error message is printed, then run the simulation and try to reproduce the problem. When it breaks, it might at least tell you which node was being tested for intersection, and in which circumstances. Hope this helps, A colleague of mine encountered something similar, it was caused in an intersector by converting small doubles to floats which then became 0's. I've asked him for the details and will post asap. Two things you could try. 1) Attached is my colleague's modified IntersectVisitor.cpp, there is a check for the size of TriangleIntersect. 2) You could try make the struct TriangleIntersect in IntersectVisitor.cpp use Vec3d instead of Vec3. Let us know if either works. regards 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] Stopping nodes receiving shadows
Hi Wojtek, Nope, receivesShadowMask is generally ignored in ViewDependentShadows. Exception in MinimaDrawBoundsShadowMap but there it is used only to approximate shadow volume which is later additionaly refined. OK, thanks for the clarification. Problem is that implementing receiveShadowMask without messing with shaders/and uniforms during render traversals would probably require splitting cull traversal into two traversals one for receiveShadowMask nodes and one for those without it. Two cull traversals probably mean two sets of render stages and possible issues with bin sorting. That's what Cedric did, and I agree that it might introduce issues. I guess that alternatively one may use shadow shader and special uniform which would activate shadow map for nodes with receiveShadowMask I suspose thats what J-S did. Not exactly, in my application there is no relation between receivesShadowMask and the uniform variable. I simply don't use the receivesShadowMask. When I want a node to not receive shadows I simply set the uniform to false. So in my architecture, the castsShadowMask is used to remove nodes from the shadowMap traversal, but then when rendering the uniform is checked. I have contemplated ways of syncing the uniform to the nodemasks, but in the end it's not that useful and would introduce a traversal per frame to make sure the values stay in sync. And I think its ok when done explicitly by end user programmer. But such approach on middleware/library level would probably mean adding aditional uniforms and/or shaders into stategraph according to node maks found while culling. I am not sure if this is fully acceptable and risk free. This also means that shadow shader would be used for all nodes even for those without receiveShadowMask. If one would expect that shadowing would not touch any aspect of receiveShadowMask free nodes he could be unpleseantly surprised as shaders usually make some shortcuts and sacrifice some of fixed pipeline functionality. I totally agree, it's not for the library to make these decisions but for the application programmer. In my opinion generic shadow algorthm which could be used without modification with all types of database and types of aplication was not yet found. And I would not try to make such algorithm. Anyone should expect that if certain approach does not work for their case they need to either derive their own shadow from exisiting classes or create their own solutions. Again I agree, the library can provide some tools but a totally plug-and-play shadow algorithm is (in my opinion) not possible since it depends on too many factors which only the application programmer can know about. Just to be clear: when I was suggesting to use uniforms or to place non-shadow-receiving nodes in a different subgraph not under the ShadowedScene, I was not suggesting that osgShadow should do that. I was saying that it was the user's responsibility. It's not too hard to do but if you need that functionality you need to do it yourself. Thanks for your clarifications Wojtek. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Linesegment, shader
Leitner, Roland wrote: Okay, I have to try it. Could you give me any code or literature to implement this for (first) one ray? Perhaps a raytracing example I posted somewhere mid-july (titled Little ray-tracing example using the KD-tree) will give you some start. It shows how you can use osgUtil::IntersectionVisitor coupled with a osgUtil::LineSegmentIntersector to find scene intersections. Paul Thanks, Roland -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Robert Osfield Gesendet: Dienstag, 7. Oktober 2008 14:30 An: OpenSceneGraph Users Betreff: Re: [osg-users] Linesegment, shader Hi Roland, On Tue, Oct 7, 2008 at 1:03 PM, Leitner, Roland [EMAIL PROTECTED] wrote: Sorry ;) I need the results (distance map) back to the cpu. If you need the results back on the CPU then you will most likely be best to use a CPU based algorithm. You could render to depth buffer and then read this back but the round trip to the graphics card is likely to blow all the speed advantages of using the CPU for depth testing. From OSG-2.6 onwards the OSG has KdTree support that can help with speed of intersection testing. Or alternatively write your own custom intersection codes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] subversion tags
Hi Mathieu, I do understand what your are looking for, but I don't agree it's clearer... having two tags for the same thing, and copying over the top of the same tag repeatidly. I consider this misuse of the svn repository. Robert. On Tue, Oct 7, 2008 at 4:18 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi Robert, I'm not talking about a symbolique link. It's just a another copy, just plain subversion copy : svn copy -mtagging 2.7.2 http://.../trunk http://.../tags/osg-2.7.2 svn copy -mupdating developer release http://.../tags/osg-2.7.2 http://.../tags/osg-latest-dev-release and then tagging next release would be the same : svn copy -mtagging 2.7.3 http://.../trunk http://.../tags/osg-2.7.3 svn copy -mupdating developer release http://.../tags/osg-2.7.3 http://.../tags/osg-latest-dev-release Only if I wanted to have the the latest developer release checked out, if I had : svn co http://.../tags/osg-latest-dev-release osg-devel in the 2.7.2 days it would then update to the 2.7.3 (when it's tagged) with an svn update Is it a bit clearer ? Mathieu 2008/10/7 Robert Osfield [EMAIL PROTECTED]: Hi Mathieu, What you are asking for is symbolic link to the latest tags rather than an actual tag. I don't know if svn is capable of doing something like this. Perhaps the webserver could do some url direction.. I have no clue on this stuff so I'll leave it to svn server and web server experts to dive in with recommendations. Robert. On Tue, Oct 7, 2008 at 3:07 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi, This is probably only directed to Paul Martz and Robert Osfield, but here it goes : I was wondering if you could add two more tags on the subversion repository that would be tagging the latest stable and development releases and evolving with them. For example : OpenSceneGraph-latest-stable-release would be the same as OpenSceneGraph-2.6.1 OpenSceneGraph-latest-dev-release would be OpenSceneGraph-2.7.2 as of today and moving to OpenSceneGraph-2.7.3 sooner or later. My aim is to setup (my) continuous integration servers to build automatically the latest version of each branch. -- Mathieu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] subversion tags
Robert Osfield wrote: I do understand what your are looking for, but I don't agree it's clearer... having two tags for the same thing, and copying over the top of the same tag repeatidly. I consider this misuse of the svn repository. Same feeling here... What you could do is create a new directory called latest next to the trunk, branches, tags, etc directories. Then you set two svn:externals on that directory, one named stable pointing to the latest released stable revision (the same on that was tagged), and one named development pointing to the latest released development version. When a new release is made the appropriate property of the latest dir would need to be updated. On the end-user side an svn update within his/her checkout of the latest directoy would update if needed. At least, I think this should work, would need to try it out though. Paul Robert. On Tue, Oct 7, 2008 at 4:18 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi Robert, I'm not talking about a symbolique link. It's just a another copy, just plain subversion copy : svn copy -mtagging 2.7.2 http://.../trunk http://.../tags/osg-2.7.2 svn copy -mupdating developer release http://.../tags/osg-2.7.2 http://.../tags/osg-latest-dev-release and then tagging next release would be the same : svn copy -mtagging 2.7.3 http://.../trunk http://.../tags/osg-2.7.3 svn copy -mupdating developer release http://.../tags/osg-2.7.3 http://.../tags/osg-latest-dev-release Only if I wanted to have the the latest developer release checked out, if I had : svn co http://.../tags/osg-latest-dev-release osg-devel in the 2.7.2 days it would then update to the 2.7.3 (when it's tagged) with an svn update Is it a bit clearer ? Mathieu 2008/10/7 Robert Osfield [EMAIL PROTECTED]: Hi Mathieu, What you are asking for is symbolic link to the latest tags rather than an actual tag. I don't know if svn is capable of doing something like this. Perhaps the webserver could do some url direction.. I have no clue on this stuff so I'll leave it to svn server and web server experts to dive in with recommendations. Robert. On Tue, Oct 7, 2008 at 3:07 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi, This is probably only directed to Paul Martz and Robert Osfield, but here it goes : I was wondering if you could add two more tags on the subversion repository that would be tagging the latest stable and development releases and evolving with them. For example : OpenSceneGraph-latest-stable-release would be the same as OpenSceneGraph-2.6.1 OpenSceneGraph-latest-dev-release would be OpenSceneGraph-2.7.2 as of today and moving to OpenSceneGraph-2.7.3 sooner or later. My aim is to setup (my) continuous integration servers to build automatically the latest version of each branch. -- Mathieu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] subversion tags
Paul Melis wrote: Robert Osfield wrote: I do understand what your are looking for, but I don't agree it's clearer... having two tags for the same thing, and copying over the top of the same tag repeatidly. I consider this misuse of the svn repository. Same feeling here... What you could do is create a new directory called latest next to the trunk, branches, tags, etc directories. Then you set two svn:externals on that directory, one named stable pointing to the latest released stable revision (the same on that was tagged), and one named development pointing to the latest released development version. When a new release is made the appropriate property of the latest dir would need to be updated. On the end-user side an svn update within his/her checkout of the latest directoy would update if needed. At least, I think this should work, would need to try it out though. Now that I think about it, perhaps making self-referential svn:externals isn't such a great idea, hmmm :) But then again, svn might just handle it Paul Paul Robert. On Tue, Oct 7, 2008 at 4:18 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi Robert, I'm not talking about a symbolique link. It's just a another copy, just plain subversion copy : svn copy -mtagging 2.7.2 http://.../trunk http://.../tags/osg-2.7.2 svn copy -mupdating developer release http://.../tags/osg-2.7.2 http://.../tags/osg-latest-dev-release and then tagging next release would be the same : svn copy -mtagging 2.7.3 http://.../trunk http://.../tags/osg-2.7.3 svn copy -mupdating developer release http://.../tags/osg-2.7.3 http://.../tags/osg-latest-dev-release Only if I wanted to have the the latest developer release checked out, if I had : svn co http://.../tags/osg-latest-dev-release osg-devel in the 2.7.2 days it would then update to the 2.7.3 (when it's tagged) with an svn update Is it a bit clearer ? Mathieu 2008/10/7 Robert Osfield [EMAIL PROTECTED]: Hi Mathieu, What you are asking for is symbolic link to the latest tags rather than an actual tag. I don't know if svn is capable of doing something like this. Perhaps the webserver could do some url direction.. I have no clue on this stuff so I'll leave it to svn server and web server experts to dive in with recommendations. Robert. On Tue, Oct 7, 2008 at 3:07 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi, This is probably only directed to Paul Martz and Robert Osfield, but here it goes : I was wondering if you could add two more tags on the subversion repository that would be tagging the latest stable and development releases and evolving with them. For example : OpenSceneGraph-latest-stable-release would be the same as OpenSceneGraph-2.6.1 OpenSceneGraph-latest-dev-release would be OpenSceneGraph-2.7.2 as of today and moving to OpenSceneGraph-2.7.3 sooner or later. My aim is to setup (my) continuous integration servers to build automatically the latest version of each branch. -- Mathieu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] subversion tags
Hi Paul, Now that I think about it, perhaps making self-referential svn:externals isn't such a great idea, hmmm :) You mean an svn:externals that points to some other directory in your repository? No, that's fine. It's the way the SVN book advises to replace the modules functionality. You create an empty directory in your repo, and then give it a bunch of externals that correspond to the specific parts of your repo that you want to be included in the module. It's kind of using svn:externals like a symlink. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
Hi Robert, I am planning to make a 2.7.3 dev release tomorrow morning, there have been plenty of changes checked in since 2.7.2 so there is potential for build breaks so I'd appreciate testing across platforms of svn/trunk. If you have a clean build or a build failure please post your results into the list so I can keep tabs on where things are build/what is left to fix up. Builds fine on Windows Vista 32 bit, VC++ 2005 (VC8), CMake 2.6.1. Ran osgviewer and a few other examples (to verify that the recent changes were merged) and all looks fine. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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
[osg-users] Please test SVN of VIrtualPlanetBuilder in prep for VPB-0.9.8 dev release
Hi All, Once the the OSG-2.7.3 dev release is tagged, I follow up with a VPB-0.9.8 dev release. So... I'd also appreciate testing of VPB svn/trunk which requires OSG svn/trunk. Once both of these are out we'll have a paired release for VPB/OSG once more. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of VIrtualPlanetBuilder in prep for VPB-0.9.8 dev release
Hi Robert, Once the the OSG-2.7.3 dev release is tagged, I follow up with a VPB-0.9.8 dev release. So... I'd also appreciate testing of VPB svn/trunk which requires OSG svn/trunk. Once both of these are out we'll have a paired release for VPB/OSG once more. Just call me Speedy Gonzales. :-) VPB builds fine on Windows Vista 32 bit, VC++ 2005 (VC8), CMake 2.6.1. Tested osgdem with a relatively small terrain build with --TERRAIN and it worked fine. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Stopping nodes receiving shadows
Hi J S,
Comments at the bottom.
Jean-Sbastien Guay wrote:
Hi
Roger,
I would like to render a scene that has some
nodes in it that should not receive a shadow, and also some nodes that
should neither cast nor receive a shadow but still be rendered.
Not that I want to curb your enthusiasm to fix a percieved problem, but
there are ways to achieve what you want without changing the shadow
technique code.
(Note that I will only speak from experience with osgShadow::ShadowMap
and the new ViewDependentShadow techniques - the others I know less
about but it might be similar)
First of all, ShadowMap and the new ViewDependentShadow classes
(LightSpacePerspectiveShadowMap being the one you probably want) will
honor the castsShadow traversal mask. So if you flag a node like so:
unsigned int castsShadow =
shadowedScene-getCastsShadowTraversalMask();
node-setNodeMask(node-getNodeMask() ~castsShadow);
it will not cast shadows (and its volume will not be considered when
calculating the shadow casting volume, which is good for reducing
shadow aliasing in the case of ShadowMap).
Second, no shadow technique right now honors the receivesShadow
traversal mask. But you can work around this by putting the node you
don't want to receive shadows outside the shadowedScene in your scene
graph. So for example, your actual scene root would be an ordinary
osg::Group, which would have as children all the nodes you don't want
to receive shadows, and also the ShadowedScene under which all nodes
will receive shadows.
You can also add control for receiving shadows in your shadow shader.
Both ShadowMap and LightSpacePerspectiveShadowMap allow you to replace
the shaders by ones you would write yourself. In my case, I have a
single shader pair (vertex + fragment) for the whole scene, where I
have a uniform that controls if the object is shadowed (so if this
uniform is false, no shadow map lookup will be performed for the
current vertex/fragment). Then I just set that uniform to the desired
value on the nodes. This might slow down your rendering a bit, but it
gives you better control over shadow application in your scene.
So with those suggestions I think you can get the result you want. If
not, perhaps I've misunderstood what you were trying to accomplish.
Hope this helps,
J-S
Thanks for the suggestions. They may well be my only option, but I am a
bit limited in what I can do as I am adding shadowing into an existing
application, which also limits me to the OSG 2.6 branch for production
code.
I realise that taking nodes out of the tree could do what I want, but
that would be a bit messy as most of them are under LOD nodes, and the
user needs to be able to switch shadows on and off on various objects.
I have managed to avoid fragment shaders so far. Experiments using
ShadowMap gave me between a 30 and 50 percent raw framerate (non
vsynced) hit, and I am up against it performance wise in many cases
already. I already have a version which runs my own shader but as far
as I can see the ShadowMap does not allow me to specify my own uniforms
via a public interface, and more importantly unilaterally turns off
ambient lighting in the main scene.
I am happy to invest some time in finding a solution that may be of
more general use. Please forgive me now for dumping some general
observations into this message.
I notice from some earlier correspondence that you also made the same
assumption that I did about control of shadow reception using the
receivesShadow mask. I wonder if the fact that none of the implementors
of shadow techniques have found a way of using this mask/bit to control
the application of a shadowed state during the scene rendering pass
calls its place in the design into question.
At the heart of OSGs scene traversal algorithm is the
osg::Node::validNodeMask code
inline bool validNodeMask(const osg::Node node) const
{
return (getTraversalMask() (getNodeMaskOverride() |
node.getNodeMask()))!=0;
}
In normal usage the fundamental result of this is that any bit that is
set in the NodeMask (which to my way of thinking is not really a mask
but a set of flag bits :-) ) and not masked by the travesal mask will
cause the node and its children to be included in the processing, but
in reverse no unmasked bit can be set if the node is to be excluded.
Also as far as the general purpose osgUtill::CullVisitor is concerned
this only controls whether a node is included in its cull processing
not any conditional processing within the internal cull processing of a
node.
It seems to me that most efficient way to ensure that a node is
correctly shadowed would be to not unconditionally push a shadowing
state onto the stateSet stack at the start of the ShadowTechnique cull
method, but to find a way to conditionally add it on a node by node
basis during the main cull traversal. One way to do this would be by
adding a cull callback to every node in every child subgraph, but
Re: [osg-users] Please test SVN of VIrtualPlanetBuilder in prep for VPB-0.9.8 dev release
Hi,
osg build fine : vista 32bit VC++ 2005 (VC8) and cmake 2.6.
vpb build fine : same configuration.
But with vpbmaster I have a little problem :
If I use the option --run-path d:\tmp
vpbmaster write in the task files : --run-path C:\Users\Christophe
It seems to use the default path and not the path I have specified.
I have just added the line
taskManager-setRunPath(runPath);
when vpbMaster read the --run-path option and it works. I don't know if it's
the better solution but anyway
here is the file modified vpbmaster.cpp
Regards.
On Tue, Oct 7, 2008 at 6:19 PM, Robert Osfield [EMAIL PROTECTED]wrote:
Hi All,
Once the the OSG-2.7.3 dev release is tagged, I follow up with a
VPB-0.9.8 dev release. So... I'd also appreciate testing of VPB
svn/trunk which requires OSG svn/trunk. Once both of these are out
we'll have a paired release for VPB/OSG once more.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Christophe Loustaunau.
/* -*-c++-*- VirtualPlanetBuilder - Copyright (C) 1998-2007 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commericial and non commericial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include vpb/Commandline
#include vpb/TaskManager
#include vpb/System
#include vpb/FileUtils
#include osg/Timer
#include osgDB/ReadFile
#include osgDB/WriteFile
#include iostream
#include signal.h
int main(int argc, char** argv)
{
osg::ref_ptrvpb::TaskManager taskManager =
vpb::System::instance()-getTaskManager();
#ifndef _WIN32
taskManager-setSignalAction(SIGHUP,
vpb::TaskManager::COMPLETE_RUNNING_TASKS_THEN_EXIT);
taskManager-setSignalAction(SIGQUIT,
vpb::TaskManager::TERMINATE_RUNNING_TASKS_THEN_EXIT);
taskManager-setSignalAction(SIGKILL,
vpb::TaskManager::TERMINATE_RUNNING_TASKS_THEN_EXIT);
taskManager-setSignalAction(SIGUSR1, vpb::TaskManager::RESET_MACHINE_POOL);
taskManager-setSignalAction(SIGUSR2,
vpb::TaskManager::UPDATE_MACHINE_POOL);
#endif
taskManager-setSignalAction(SIGABRT,
vpb::TaskManager::TERMINATE_RUNNING_TASKS_THEN_EXIT);
taskManager-setSignalAction(SIGINT,
vpb::TaskManager::TERMINATE_RUNNING_TASKS_THEN_EXIT);
taskManager-setSignalAction(SIGTERM,
vpb::TaskManager::TERMINATE_RUNNING_TASKS_THEN_EXIT);
osg::Timer_t startTick = osg::Timer::instance()-tick();
osg::ArgumentParser arguments(argc,argv);
// set up the usage document, in case we need to print out how to use this
program.
arguments.getApplicationUsage()-setApplicationName(arguments.getApplicationName());
arguments.getApplicationUsage()-setDescription(arguments.getApplicationName()+
application is utility tools which can be used to generate paged geospatial
terrain databases.);
arguments.getApplicationUsage()-setCommandLineUsage(arguments.getApplicationName()+
[options] filename ...);
arguments.getApplicationUsage()-addCommandLineOption(--cache
filename,Read the cache file to use a look up for locally cached files.);
arguments.getApplicationUsage()-addCommandLineOption(-h or
--help,Display this information);
std::string runPath;
if (arguments.read(--run-path,runPath))
{
vpb::chdir(runPath.c_str());
taskManager-setRunPath(runPath);
}
// if user request help write it out to cout.
if (arguments.read(-h) || arguments.read(--help))
{
arguments.getApplicationUsage()-write(std::cout,osg::ApplicationUsage::COMMAND_LINE_OPTION);
return 1;
}
// if user request list of supported formats write it out to cout.
if (arguments.read(--formats))
{
std::coutSupported formats:std::endl;
const vpb::System::SupportedExtensions extensions =
vpb::System::instance()-getSupportExtensions();
for(vpb::System::SupportedExtensions::const_iterator itr =
extensions.begin();
itr != extensions.end();
++itr)
{
std::cout itr-first :;
bool first = true;
if (itr-second.acceptedTypeMask vpb::Source::IMAGE)
{
std::cout imagery;
first = false;
}
if (itr-second.acceptedTypeMask vpb::Source::HEIGHT_FIELD)
{
if (!first) std::cout,;
std::cout dem;
first = false;
}
if (itr-second.acceptedTypeMask vpb::Source::MODEL)
{
if (!first) std::cout,;
std::cout model;
first = false;
}
if
Re: [osg-users] Stopping nodes receiving shadows
Hi JS, Cedric, Wojtek Jean-Sbastien Guay wrote: Hi Wojtek, Nope, receivesShadowMask is generally ignored in ViewDependentShadows. Exception in MinimaDrawBoundsShadowMap but there it is used only to approximate shadow volume which is later additionaly refined. OK, thanks for the clarification. Problem is that implementing receiveShadowMask without messing with shaders/and uniforms during render traversals would probably require splitting cull traversal into two traversals one for receiveShadowMask nodes and one for those without it. Two cull traversals probably mean two sets of render stages and possible issues with bin sorting. That's what Cedric did, and I agree that it might introduce issues. I guess that alternatively one may use shadow shader and special uniform which would activate shadow map for nodes with receiveShadowMask I suspose thats what J-S did. Not exactly, in my application there is no relation between receivesShadowMask and the uniform variable. I simply don't use the receivesShadowMask. When I want a node to not receive shadows I simply set the uniform to false. So in my architecture, the castsShadowMask is used to remove nodes from the shadowMap traversal, but then when rendering the uniform is checked. I have contemplated ways of syncing the uniform to the nodemasks, but in the end it's not that useful and would introduce a traversal per frame to make sure the values stay in sync. And I think its ok when done explicitly by end user programmer. But such approach on middleware/library level would probably mean adding aditional uniforms and/or shaders into stategraph according to node maks found while culling. I am not sure if this is fully acceptable and risk free. This also means that shadow shader would be used for all nodes even for those without receiveShadowMask. If one would expect that shadowing would not touch any aspect of receiveShadowMask free nodes he could be unpleseantly surprised as shaders usually make some shortcuts and sacrifice some of fixed pipeline functionality. I totally agree, it's not for the library to make these decisions but for the application programmer. In my opinion generic shadow algorthm which could be used without modification with all types of database and types of aplication was not yet found. And I would not try to make such algorithm. Anyone should expect that if certain approach does not work for their case they need to either derive their own shadow from exisiting classes or create their own solutions. Again I agree, the library can provide some tools but a totally plug-and-play shadow algorithm is (in my opinion) not possible since it depends on too many factors which only the application programmer can know about. Just to be clear: when I was suggesting to use uniforms or to place non-shadow-receiving nodes in a different subgraph not under the ShadowedScene, I was not suggesting that osgShadow should do that. I was saying that it was the user's responsibility. It's not too hard to do but if you need that functionality you need to do it yourself. Thanks for your clarifications Wojtek. J-S I guess my last post is way out of sequence now. Serves me right for walking away from half composed message for a few hours and then pressing send when I got back before I checked new mail. At least my original message provoked some debate, which was what I wanted. Sorry Cedric, I had done a scan back through the list but I only noticed JS's posts. It would be nice to have a non fragment shader/uniform approach. I think my cull callback approach is doable but messy. But a least most of the mess is at graph construction/teardown time. It might be better to add a callback facility into osgUtil::cullVisitor that gets called before each node is processed and can push back some extra state. But it all eats cycles. Retaining the ReceivesShadow bit/bits is good for non rendering traversals such as the one Wojtek mentioned and at least they are there for use as state by cull callbacks. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] subversion tags
Hi All, IMHO, the svn:external scheme is far more complex than copying tags (svn copy is a very cheap operation in subversion). I won't argue on which is best, they both achieve the same goal. But is this goal (having a way to checkout the latest devel/stable release) of any use to somebody else (other than setting up automatic nightly builds of OSG) ? I'm using the vendor branches anyway. Mathieu 2008/10/7 Jean-Sébastien Guay [EMAIL PROTECTED]: Hi Paul, Now that I think about it, perhaps making self-referential svn:externals isn't such a great idea, hmmm :) You mean an svn:externals that points to some other directory in your repository? No, that's fine. It's the way the SVN book advises to replace the modules functionality. You create an empty directory in your repo, and then give it a bunch of externals that correspond to the specific parts of your repo that you want to be included in the module. It's kind of using svn:externals like a symlink. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMap question.
Hi, I work on project need shadow between avatar and model, and I add shadowmap as the example code but it doesn't work. I read the shadow example and seems that the glsl shader only has two texture unit, one for shadowbase and one for shadowTexture. Do I need to assign my own texture unit for the shadow receiver? Another question, do I need to create a vertext shader to calculate the matrix transformation between two camera(one light, one main cam)? Thanks a lot. Hui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] subversion tags
Mathieu MARACHE wrote: IMHO, the svn:external scheme is far more complex than copying tags (svn copy is a very cheap operation in subversion). I won't argue on which is best, they both achieve the same goal. But is this goal (having a way to checkout the latest devel/stable release) of any use to somebody else (other than setting up automatic nightly builds of OSG) ? I'm using the vendor branches anyway. As I'm not the one doing any of the necessary work if this moves forward I don't really mind which solution would be chosen. I'm against adding two _tags_ (i.e. under directory /tags) that represent the latest stable and development releases, but there's no reason why two svn copys couldn't be made somewhere else in the repository. Regards, Paul Mathieu 2008/10/7 Jean-Sébastien Guay [EMAIL PROTECTED]: Hi Paul, Now that I think about it, perhaps making self-referential svn:externals isn't such a great idea, hmmm :) You mean an svn:externals that points to some other directory in your repository? No, that's fine. It's the way the SVN book advises to replace the modules functionality. You create an empty directory in your repo, and then give it a bunch of externals that correspond to the specific parts of your repo that you want to be included in the module. It's kind of using svn:externals like a symlink. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stopping nodes receiving shadows
Hi Roger, Thanks for the suggestions. They may well be my only option, but I am a bit limited in what I can do as I am adding shadowing into an existing application, which also limits me to the OSG 2.6 branch for production code. I can relate, as I am also working on an existing framework which is used in multiple existing applications, and up until lately we were actually at OSG 2.2. I recently upped that to 2.6, with Wojtek's ViewDependentShadow added locally. I realise that taking nodes out of the tree could do what I want, but that would be a bit messy as most of them are under LOD nodes, and the user needs to be able to switch shadows on and off on various objects. Sure, I agree it complicates things. I have managed to avoid fragment shaders so far. Experiments using ShadowMap gave me between a 30 and 50 percent raw framerate (non vsynced) hit, and I am up against it performance wise in many cases already. I already have a version which runs my own shader but as far as I can see the ShadowMap does not allow me to specify my own uniforms via a public interface, and more importantly unilaterally turns off ambient lighting in the main scene. Adding shadows can be expected to drop the total frame rate (vsync off, as you say) by roughly half, since you're essentially rendering twice. Other than disabling some unneeded effects when rendering to the shadow map, which will lower the hit somewhat, you can't do anything about that. The straight truth is that you're rendering twice, so expect a hit related to that. As to not using shaders, well, you're using shadows so you're using shaders already... osgShadow::ShadowMap uses a fragment shader under the ShadowedScene (no vertex shader, so the fixed vertex processing is kept, but that's pretty easy to replicate in a vertex shader). So using those shaders or using your own won't make much difference in performance (as long as your shaders are well written, which of course requires some learning if you haven't done it before), but the difference is that everything is under your control. For example, the problem with ambient lighting can be solved by changing the shader - it's a result of how the osgShadow::ShadowMap default shader is written. Replace that shader by one that calculates the ambient lighting correctly, and the problem is solved. Writing your own shaders also gives you control over lots of other things, and you can use your own uniforms for all of it. For me, it all comes down to the later points by Wojtek. osgShadow::ShadowMap gives you the tools, and does the basic things, but for anything else, it's up to the user of the library to do them in the way they see fit. For me, replacing the osgShadow::ShadowMap shaders was the way to go, as in the long run it also opens the doors to lots of other things. For you it may be something else. I won't go into your comments on node masks, as I don't think there's much to be said about that. Node masks are the way they are, and they're useful for some things, but in this case there are other solutions that work as well or better... Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] ShadowMap question.
Hui,
hui wrote:
Hi,
I work on project need shadow between avatar and model, and I add shadowmap as the example code but it doesn't work. I read the shadow example and seems that the glsl shader only has two texture unit, one for shadowbase and one for shadowTexture. Do I need to assign my own texture unit for the shadow receiver? Another question, do I need to create a vertext shader to calculate the matrix transformation between two camera(one light, one main cam)?
Thanks a lot.
Hui
The current ShadowMap is buggy and only works with default values for
the texture units when the default shaders are used. The defaults are
for texture unit 0 to be any texture you have already applied to the
scene and for texture unit 1 to be the shadow map texture used
internally by ShadowMap. The only other configuration that works is for
you to call ShadowMap::setTextureUnit(0) in which case texture unit 0
will be used for the internal shadow map texture unit and no other
texturing will be applied to the scene.
Here is some code you can use to set a different internal texture unit
to ShadowMap
std::string MyFragmentShaderSource(
"uniform sampler2D osgShadow_baseTexture; \n"
"uniform sampler2DShadow osgShadow_shadowTexture; \n"
"uniform vec2 osgShadow_ambientBias; \n"
"\n"
"void main(void) \n"
"{ \n"
" vec4 color = gl_Color * texture2D( osgShadow_baseTexture,
gl_TexCoord[0].xy ); \n"
" gl_FragColor = color * (osgShadow_ambientBias.x +
shadow2DProj( osgShadow_shadowTexture, gl_TexCoord[] ) *
osgShadow_ambientBias.y); \n"
"}\n");
m_pShadowedScene = new osgShadow::ShadowedScene;
osg::ref_ptrosgShadow::ShadowMap pShadowMap = new
osgShadow::ShadowMap;
m_pShadowedScene-setShadowTechnique(pShadowMap.get());
std::string::size_type Offset = MyFragmentShaderSource.find("");
MyFragmentShaderSource.erase(Offset, 4);
char TempBuff[5];
_itoa(m_ShadowTextureUnit, TempBuff, 10);
MyFragmentShaderSource.insert(Offset, TempBuff);
pShadowMap-addShader(new osg::Shader(osg::Shader::FRAGMENT,
MyFragmentShaderSource));
pShadowMap-setTextureUnit(m_ShadowTextureUnit);
//pShadowMap-init(); // Need to call this if the OSG update
visitor not being used or ShadowMap::setDebugHUD is not called
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
Builds fine with gcc version 4.3.2, Linux 2.6.26-1-amd64. El Martes 07 Octubre 2008ES 18:00:17 Robert Osfield escribió: Hi All, I am planning to make a 2.7.3 dev release tomorrow morning, there have been plenty of changes checked in since 2.7.2 so there is potential for build breaks so I'd appreciate testing across platforms of svn/trunk. If you have a clean build or a build failure please post your results into the list so I can keep tabs on where things are build/what is left to fix up. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
I seem to be getting some lock up when switching threading models in osgviewer (with the cow). However I also see these in 2.6.0 now that I test it (haven't been using 2.6 yet). What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. This is with vsync off, b.t.w., in case timings issues might be at play here. The lockup always seems to occur when switching to CullThreadPerCameraDrawThreadPerContext. Here's a relevant stack trace #0 0xe424 in __kernel_vsyscall () #1 0xb7963576 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7ef79c8 in OpenThreads::Condition::wait () from /home/melis/c/osg/build/2.7.2/bin/../lib/libOpenThreads.so.11 #3 0xb7a49e4d in osgViewer::ViewerBase::renderingTraversals () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #4 0xb7a48833 in osgViewer::ViewerBase::frame () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #5 0xb7a48971 in osgViewer::ViewerBase::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #6 0xb7a3a033 in osgViewer::Viewer::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #7 0x0804b1e6 in main () Paul Robert Osfield wrote: Hi All, I am planning to make a 2.7.3 dev release tomorrow morning, there have been plenty of changes checked in since 2.7.2 so there is potential for build breaks so I'd appreciate testing across platforms of svn/trunk. If you have a clean build or a build failure please post your results into the list so I can keep tabs on where things are build/what is left to fix up. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU osgShadow
Hi Art, thanks for your attention. I've constructed an example for you by
minimally modifying Example viewer. Below is the modified view.cpp. It has an
additional createScene function that sets up a shadowed scene. Also note the
#define ENABLE_SHADOWS. Commenting that out will use the default scene instead
of the shadowed one for comparison.
Michael
PS You'll have to link to osgShadow as well of course
#include osg/GLExtensions
#include osgViewer/Renderer
#include osgGA/TrackballManipulator
#include osgDB/WriteFile
#include osgPPU/Processor.h
#include osgteapot.h
#define ENABLE_SHADOWS
#if defined (ENABLE_SHADOWS)
# include osgShadow/ShadowedScene
# include osgShadow/ShadowMap
# include osg/LightSource
#endif
//--
// Create camera resulting texture
//--
osg::Texture* createRenderTexture(int tex_width, int tex_height, bool depth)
{
// create simple 2D texture
osg::Texture2D* texture2D = new osg::Texture2D;
texture2D-setTextureSize(tex_width, tex_height);
texture2D-setResizeNonPowerOfTwoHint(false);
texture2D-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
texture2D-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
texture2D-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_BORDER);
texture2D-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_BORDER);
texture2D-setBorderColor(osg::Vec4(1.0f,1.0f,1.0f,1.0f));
// setup float format
if (!depth)
{
texture2D-setInternalFormat(GL_RGBA16F_ARB);
texture2D-setSourceFormat(GL_RGBA);
texture2D-setSourceType(GL_FLOAT);
}else{
texture2D-setInternalFormat(GL_DEPTH_COMPONENT);
}
return texture2D;
}
//--
// Create scene
//--
osg::Group* createScene(const std::string filename)
{
osg::Node* loadedModel = NULL;
// Load in the model to use in our scene
if (!filename.empty()) loadedModel = osgDB::readNodeFile(filename);
if (!loadedModel) loadedModel = createTeapot();
if (!loadedModel) return NULL;
#if defined (ENABLE_SHADOWS)
const int ReceivesShadowTraversalMask = 0x1;
const int CastsShadowTraversalMask = 0x2;
osgShadow::ShadowedScene* shadowedScene = new osgShadow::ShadowedScene;
shadowedScene-setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);
shadowedScene-setCastsShadowTraversalMask(CastsShadowTraversalMask);
osg::LightSource* lightSource = new osg::LightSource;
lightSource-getLight()-setPosition(
osg::Vec4(osg::Vec3(100.0, 0.0, 100.0f), 0.0f));
// Setup the scene with shadows via shadow mapping
osgShadow::ShadowMap* shadowMap = new osgShadow::ShadowMap;
shadowMap-setTextureSize(osg::Vec2s(1024, 1024));
shadowMap-setLight(lightSource);
shadowedScene-setShadowTechnique(shadowMap);
shadowedScene-addChild(lightSource);
return shadowedScene;
#else
osg::Group* scene = new osg::Group;
scene-addChild(loadedModel);
return scene;
#endif
}
//--
// Setup the camera to do the render to texture
//--
void setupCamera(osg::Camera* camera)
{
osg::Viewport* vp = camera-getViewport();
// create texture to render to
osg::Texture* texture = createRenderTexture((int)vp-width(),
(int)vp-height(), false);
osg::Texture* depthTexture = createRenderTexture((int)vp-width(),
(int)vp-height(), true);
// set up the background color and clear mask.
camera-setClearColor(osg::Vec4(0.0f,0.0f,0.0f,0.0f));
camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
// set viewport
camera-setViewport(vp);
camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
camera-setProjectionMatrixAsPerspective(35.0, vp-width()/vp-height(),
1.0, 256.0);
// tell the camera to use OpenGL frame buffer object where supported.
camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
// attach the texture and use it as the color buffer.
camera-attach(osg::Camera::COLOR_BUFFER, texture);
camera-attach(osg::Camera::DEPTH_BUFFER, depthTexture);
}
//--
int main(int argc, char **argv)
{
// parse arguments
osg::ArgumentParser arguments(argc,argv);
// give some info in the console
printf(view ppufile [osgfile]\n);
if (argc = 1) return 0;
// construct the viewer.
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();
unsigned int screenWidth;
unsigned int screenHeight;
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
And I'm forgetting the important details: - Gentoo Linux 2.6.25 - GCC 4.1.2 - NVidia Geforce 9600GT, driver 173.14.09 Paul Paul Melis wrote: I seem to be getting some lock up when switching threading models in osgviewer (with the cow). However I also see these in 2.6.0 now that I test it (haven't been using 2.6 yet). What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. This is with vsync off, b.t.w., in case timings issues might be at play here. The lockup always seems to occur when switching to CullThreadPerCameraDrawThreadPerContext. Here's a relevant stack trace #0 0xe424 in __kernel_vsyscall () #1 0xb7963576 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7ef79c8 in OpenThreads::Condition::wait () from /home/melis/c/osg/build/2.7.2/bin/../lib/libOpenThreads.so.11 #3 0xb7a49e4d in osgViewer::ViewerBase::renderingTraversals () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #4 0xb7a48833 in osgViewer::ViewerBase::frame () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #5 0xb7a48971 in osgViewer::ViewerBase::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #6 0xb7a3a033 in osgViewer::Viewer::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #7 0x0804b1e6 in main () Paul Robert Osfield wrote: Hi All, I am planning to make a 2.7.3 dev release tomorrow morning, there have been plenty of changes checked in since 2.7.2 so there is potential for build breaks so I'd appreciate testing across platforms of svn/trunk. If you have a clean build or a build failure please post your results into the list so I can keep tabs on where things are build/what is left to fix up. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using OSG with Borland C++ Builder 2007
Ok, I just recently got tasked with getting some information out of an OpenFlight database for use in our current program, which is written in Borland C++ Builder 2007 (BCB2007). I tried to open up a sample application, and got errors with some of the math functions, which I was able to resolve, but now I am getting an error with DatabasePager: [BCC32 Error] DatabasePager(375): E2247 'DatabasePager::_databasePagerThreadPaused' is not accessible I was wondering if there was anything special that needed to be done to use OSG with BCB2007? I read that I may need to compile it with BCB2007 before I can use it, but haven't found anything conclusive yet. Could someone point me in the right direction with this? Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
Hi Paul, What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. FYI, the ThreadingHandler checks that it doesn't receive multiple change threading model events within 1 second of each other so if you press 'm' multiple times in rapid succession only one per second will be taken into account. For the crash, I'm not seeing it on Win32. It could possibly be graphics driver-related? We've seen this on Windows occasionally. You could try an older or newer version. Also, if you have multiple monitors, try starting osgviewer on a single one, or on both, possibly even disabling one of the monitors to see if you can replicate the problem. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Stopping nodes receiving shadows
J-S, Roger, I am writing for purely formal reasons. It would be rude to not anwser to your posts. But J-S actually said all I wanted to say. So I have nothing more to add. Thanks for discussion guys ;-) Cheers, Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jean-Sebastien Guay Sent: Tuesday, October 07, 2008 8:35 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Stopping nodes receiving shadows Hi Roger, Thanks for the suggestions. They may well be my only option, but I am a bit limited in what I can do as I am adding shadowing into an existing application, which also limits me to the OSG 2.6 branch for production code. I can relate, as I am also working on an existing framework which is used in multiple existing applications, and up until lately we were actually at OSG 2.2. I recently upped that to 2.6, with Wojtek's ViewDependentShadow added locally. I realise that taking nodes out of the tree could do what I want, but that would be a bit messy as most of them are under LOD nodes, and the user needs to be able to switch shadows on and off on various objects. Sure, I agree it complicates things. I have managed to avoid fragment shaders so far. Experiments using ShadowMap gave me between a 30 and 50 percent raw framerate (non vsynced) hit, and I am up against it performance wise in many cases already. I already have a version which runs my own shader but as far as I can see the ShadowMap does not allow me to specify my own uniforms via a public interface, and more importantly unilaterally turns off ambient lighting in the main scene. Adding shadows can be expected to drop the total frame rate (vsync off, as you say) by roughly half, since you're essentially rendering twice. Other than disabling some unneeded effects when rendering to the shadow map, which will lower the hit somewhat, you can't do anything about that. The straight truth is that you're rendering twice, so expect a hit related to that. As to not using shaders, well, you're using shadows so you're using shaders already... osgShadow::ShadowMap uses a fragment shader under the ShadowedScene (no vertex shader, so the fixed vertex processing is kept, but that's pretty easy to replicate in a vertex shader). So using those shaders or using your own won't make much difference in performance (as long as your shaders are well written, which of course requires some learning if you haven't done it before), but the difference is that everything is under your control. For example, the problem with ambient lighting can be solved by changing the shader - it's a result of how the osgShadow::ShadowMap default shader is written. Replace that shader by one that calculates the ambient lighting correctly, and the problem is solved. Writing your own shaders also gives you control over lots of other things, and you can use your own uniforms for all of it. For me, it all comes down to the later points by Wojtek. osgShadow::ShadowMap gives you the tools, and does the basic things, but for anything else, it's up to the user of the library to do them in the way they see fit. For me, replacing the osgShadow::ShadowMap shaders was the way to go, as in the long run it also opens the doors to lots of other things. For you it may be something else. I won't go into your comments on node masks, as I don't think there's much to be said about that. Node masks are the way they are, and they're useful for some things, but in this case there are other solutions that work as well or better... Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
Hi Paul, What type of data sets do you see lock ups on? What is the rest of your hardware specs? FYI, I haven't seen lock ups with toggling threading models, just tried it again and no problems so we'll need to work hard to reproduce elsewhere. My system is Quad core Intel, 4GB, Kubuntu 7.10, 64bit, 8800GTS 640Mb. Robert. On Tue, Oct 7, 2008 at 8:16 PM, Paul Melis [EMAIL PROTECTED] wrote: And I'm forgetting the important details: - Gentoo Linux 2.6.25 - GCC 4.1.2 - NVidia Geforce 9600GT, driver 173.14.09 Paul Paul Melis wrote: I seem to be getting some lock up when switching threading models in osgviewer (with the cow). However I also see these in 2.6.0 now that I test it (haven't been using 2.6 yet). What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. This is with vsync off, b.t.w., in case timings issues might be at play here. The lockup always seems to occur when switching to CullThreadPerCameraDrawThreadPerContext. Here's a relevant stack trace #0 0xe424 in __kernel_vsyscall () #1 0xb7963576 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7ef79c8 in OpenThreads::Condition::wait () from /home/melis/c/osg/build/2.7.2/bin/../lib/libOpenThreads.so.11 #3 0xb7a49e4d in osgViewer::ViewerBase::renderingTraversals () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #4 0xb7a48833 in osgViewer::ViewerBase::frame () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #5 0xb7a48971 in osgViewer::ViewerBase::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #6 0xb7a3a033 in osgViewer::Viewer::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #7 0x0804b1e6 in main () Paul Robert Osfield wrote: Hi All, I am planning to make a 2.7.3 dev release tomorrow morning, there have been plenty of changes checked in since 2.7.2 so there is potential for build breaks so I'd appreciate testing across platforms of svn/trunk. If you have a clean build or a build failure please post your results into the list so I can keep tabs on where things are build/what is left to fix up. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using OSG with Borland C++ Builder 2007
Hi Geoff, Borland C++ isn't a compiler that others use in the OSG community, or at least not publicly so I'm afraid you are probably on your own with the need, and the ability to fix problems. The OSG is written is pretty clean C++ and compiles with a range of compilers so if Borland C++ is up to scratch as a Standard C++ compiler then you could probably get things to compile. For others to help guide you/help you out you'll need to provide more information about the OS version, the OSG version, CMake version, as well as more details about the specific compiler errors - for instance copy the exact compiler error you get and we'll be able to help dissect, without this info all we can is shrug our shoulders and move on. Robert. On Tue, Oct 7, 2008 at 8:32 PM, Geoff [EMAIL PROTECTED] wrote: Ok, I just recently got tasked with getting some information out of an OpenFlight database for use in our current program, which is written in Borland C++ Builder 2007 (BCB2007). I tried to open up a sample application, and got errors with some of the math functions, which I was able to resolve, but now I am getting an error with DatabasePager: [BCC32 Error] DatabasePager(375): E2247 'DatabasePager::_databasePagerThreadPaused' is not accessible I was wondering if there was anything special that needed to be done to use OSG with BCB2007? I read that I may need to compile it with BCB2007 before I can use it, but haven't found anything conclusive yet. Could someone point me in the right direction with this? Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unicode support for Windows
Hi Michael et. al, On Tue, Oct 7, 2008 at 6:58 PM, Michael Platings [EMAIL PROTECTED] wrote: My solution: - Add a OSG_USE_UTF8_FILENAMES option to CMake - let the user store all filenames in UTF-8 using osg::ConvertUTF16toUTF8() - where a file is loaded, if OSG_USE_UTF8_FILENAMES is true then convert the filename to UTF-16 using osg::ConvertUTF8toUTF16() and use a wide character function to open the file e.g. _wfopen instead of fopen. Just for a little clarification of the proposed solution, the code affected is primarily opening files using ofstream, ifstream or the C fopen(), and will look like... From Shader.cpp: std::ifstream sourceFile; sourceFile.open(OSG_STRING_TO_FILENAME(fileName).c_str(), std::ios::binary); From ReaderWriterOSG.cpp: std::ifstream fin(OSG_STRING_TO_FILENAME(fileName).c_str()); From 3ds/file.cpp f=OSG_fopen(filename, rb); From rgb/ReaderWriterRGB.cpp: std::ofstream fout(OSG_STRING_TO_FILENAME(fileName).c_str(), std::ios::out | std::ios::binary); The actual code submission has a few extra #ifdef too, the line changes themselves aren't drastic, but they are widespread (67 changed files in the submission). My hope with widenning the discussion out to osg-users we'll be able to get ideals on how to streamline the required changes futher, and if possible make them less intrusive. It might be that we need to change all 67 files, but unless we solve this problem elegantly it's a problem that will keep on haunting us as new submission come in a break the above types of usage. Off the top of my head my first suggestions, perhaps naive, would be to have a osgDB::ifstream and osgDB::ofstream implementations that take std::string (or alternatively) as parameters for the constructors and open() and hide the traditional methods, and have these subclasses do the internal conversions required. An osgDB::fopen() could also be written. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU osgShadow
Hi Michael,
hmm, your setup for the shadowed scene isn't correct. I have attached a changed
setup where I am able to see the teapot shadowed by some shadow technique and
also working perfectly with the osgPPU (latest svn release). Look at it. Call
with ./viewer Data/motionblur.ppu
Does it solve your problem?
Cheers,
art
--- Michael Guerrero [EMAIL PROTECTED] schrieb am Di, 7.10.2008:
Von: Michael Guerrero [EMAIL PROTECTED]
Betreff: Re: [osg-users] osgPPU osgShadow
An: osg-users@lists.openscenegraph.org
Datum: Dienstag, 7. Oktober 2008, 21:16
Hi Art, thanks for your attention. I've constructed an
example for you by
minimally modifying Example viewer. Below is the modified
view.cpp. It has an
additional createScene function that sets up a shadowed
scene. Also note the
#define ENABLE_SHADOWS. Commenting that out will use the
default scene instead
of the shadowed one for comparison.
Michael
PS You'll have to link to osgShadow as well of course
#include osg/GLExtensions
#include osgViewer/Renderer
#include osgGA/TrackballManipulator
#include osgDB/WriteFile
#include osgPPU/Processor.h
#include osgteapot.h
#define ENABLE_SHADOWS
#if defined (ENABLE_SHADOWS)
# include osgShadow/ShadowedScene
# include osgShadow/ShadowMap
# include osg/LightSource
#endif
//--
// Create camera resulting texture
//--
osg::Texture* createRenderTexture(int tex_width, int
tex_height, bool depth)
{
// create simple 2D texture
osg::Texture2D* texture2D = new osg::Texture2D;
texture2D-setTextureSize(tex_width, tex_height);
texture2D-setResizeNonPowerOfTwoHint(false);
texture2D-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
texture2D-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
texture2D-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_BORDER);
texture2D-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_BORDER);
texture2D-setBorderColor(osg::Vec4(1.0f,1.0f,1.0f,1.0f));
// setup float format
if (!depth)
{
texture2D-setInternalFormat(GL_RGBA16F_ARB);
texture2D-setSourceFormat(GL_RGBA);
texture2D-setSourceType(GL_FLOAT);
}else{
texture2D-setInternalFormat(GL_DEPTH_COMPONENT);
}
return texture2D;
}
//--
// Create scene
//--
osg::Group* createScene(const std::string filename)
{
osg::Node* loadedModel = NULL;
// Load in the model to use in our scene
if (!filename.empty()) loadedModel =
osgDB::readNodeFile(filename);
if (!loadedModel) loadedModel = createTeapot();
if (!loadedModel) return NULL;
#if defined (ENABLE_SHADOWS)
const int ReceivesShadowTraversalMask = 0x1;
const int CastsShadowTraversalMask = 0x2;
osgShadow::ShadowedScene* shadowedScene = new
osgShadow::ShadowedScene;
shadowedScene-setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);
shadowedScene-setCastsShadowTraversalMask(CastsShadowTraversalMask);
osg::LightSource* lightSource = new osg::LightSource;
lightSource-getLight()-setPosition(
osg::Vec4(osg::Vec3(100.0, 0.0, 100.0f), 0.0f));
// Setup the scene with shadows via shadow mapping
osgShadow::ShadowMap* shadowMap = new
osgShadow::ShadowMap;
shadowMap-setTextureSize(osg::Vec2s(1024, 1024));
shadowMap-setLight(lightSource);
shadowedScene-setShadowTechnique(shadowMap);
shadowedScene-addChild(lightSource);
return shadowedScene;
#else
osg::Group* scene = new osg::Group;
scene-addChild(loadedModel);
return scene;
#endif
}
//--
// Setup the camera to do the render to texture
//--
void setupCamera(osg::Camera* camera)
{
osg::Viewport* vp = camera-getViewport();
// create texture to render to
osg::Texture* texture =
createRenderTexture((int)vp-width(),
(int)vp-height(), false);
osg::Texture* depthTexture =
createRenderTexture((int)vp-width(),
(int)vp-height(), true);
// set up the background color and clear mask.
camera-setClearColor(osg::Vec4(0.0f,0.0f,0.0f,0.0f));
camera-setClearMask(GL_COLOR_BUFFER_BIT |
GL_DEPTH_BUFFER_BIT);
// set viewport
camera-setViewport(vp);
camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
camera-setProjectionMatrixAsPerspective(35.0,
vp-width()/vp-height(),
1.0, 256.0);
// tell the camera to use OpenGL frame buffer object
where supported.
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
Robert Osfield wrote: What type of data sets do you see lock ups on? Errr, the cow dataset :) What is the rest of your hardware specs? Intel Core2 Duo, 3 Gb, single monitor. The gfx card has 512 Mb, but that will hardly have any influence here. Just tested with vsync turned on and now I get a lockup of a few seconds, followed by Threading model 'CullThreadPerCameraDrawThreadPerContext' selected. Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) [endlessly] This is still with cow.osg. I'll see what downgrading the nvidia drivers does for this Paul FYI, I haven't seen lock ups with toggling threading models, just tried it again and no problems so we'll need to work hard to reproduce elsewhere. My system is Quad core Intel, 4GB, Kubuntu 7.10, 64bit, 8800GTS 640Mb. Robert. On Tue, Oct 7, 2008 at 8:16 PM, Paul Melis [EMAIL PROTECTED] wrote: And I'm forgetting the important details: - Gentoo Linux 2.6.25 - GCC 4.1.2 - NVidia Geforce 9600GT, driver 173.14.09 Paul Paul Melis wrote: I seem to be getting some lock up when switching threading models in osgviewer (with the cow). However I also see these in 2.6.0 now that I test it (haven't been using 2.6 yet). What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. This is with vsync off, b.t.w., in case timings issues might be at play here. The lockup always seems to occur when switching to CullThreadPerCameraDrawThreadPerContext. Here's a relevant stack trace #0 0xe424 in __kernel_vsyscall () #1 0xb7963576 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7ef79c8 in OpenThreads::Condition::wait () from /home/melis/c/osg/build/2.7.2/bin/../lib/libOpenThreads.so.11 #3 0xb7a49e4d in osgViewer::ViewerBase::renderingTraversals () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #4 0xb7a48833 in osgViewer::ViewerBase::frame () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #5 0xb7a48971 in osgViewer::ViewerBase::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #6 0xb7a3a033 in osgViewer::Viewer::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #7 0x0804b1e6 in main () Paul Robert Osfield wrote: Hi All, I am planning to make a 2.7.3 dev release tomorrow morning, there have been plenty of changes checked in since 2.7.2 so there is potential for build breaks so I'd appreciate testing across platforms of svn/trunk. If you have a clean build or a build failure please post your results into the list so I can keep tabs on where things are build/what is left to fix up. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
On Tue, Oct 7, 2008 at 9:14 PM, Paul Melis [EMAIL PROTECTED] wrote: I seem to be getting some lock up when switching threading models in osgviewer (with the cow). However I also see these in 2.6.0 now that I test it (haven't been using 2.6 yet). What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. This is with vsync off, b.t.w., in case timings issues might be at play here. The lockup always seems to occur when switching to CullThreadPerCameraDrawThreadPerContext. Here's a relevant stack trace #0 0xe424 in __kernel_vsyscall () #1 0xb7963576 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7ef79c8 in OpenThreads::Condition::wait () from /home/melis/c/osg/build/2.7.2/bin/../lib/libOpenThreads.so.11 #3 0xb7a49e4d in osgViewer::ViewerBase::renderingTraversals () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #4 0xb7a48833 in osgViewer::ViewerBase::frame () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #5 0xb7a48971 in osgViewer::ViewerBase::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #6 0xb7a3a033 in osgViewer::Viewer::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #7 0x0804b1e6 in main () I can reproduce this as well. gcc 4.1.2, nvidia 8600M-GT 256MB, c2d 2.2GHz, driver 169.12, single display (laptop) 1920x1200. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU osgShadow
Awesome, thanks for the correction. I see that my initial example forgot to actually add the model to the shadowed scene :P But that wasn't the real problem. The real problem was giving osgPPU the same node that i was using for shadows. After seeing what you did in your correction I rearranged the graph like this: scene-addChild(shadowedScene); shadowedScene-addChild(loadedModel); and everything worked as expected. Now I just want to understand why this worked. It it because osgPPU and osgShadow are no longer fighting to control the state of the single scene node? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
Paul Melis wrote: Robert Osfield wrote: What type of data sets do you see lock ups on? Errr, the cow dataset :) What is the rest of your hardware specs? Intel Core2 Duo, 3 Gb, single monitor. The gfx card has 512 Mb, but that will hardly have any influence here. Just tested with vsync turned on and now I get a lockup of a few seconds, followed by Threading model 'CullThreadPerCameraDrawThreadPerContext' selected. Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) [endlessly] This is still with cow.osg. I'll see what downgrading the nvidia drivers does for this Well, going back to 169.12 does seem to make that problem go away (but the non-vsynced framerate has gone down to about 1/10th of what it was with the 173 series, doh!) Paul Paul FYI, I haven't seen lock ups with toggling threading models, just tried it again and no problems so we'll need to work hard to reproduce elsewhere. My system is Quad core Intel, 4GB, Kubuntu 7.10, 64bit, 8800GTS 640Mb. Robert. On Tue, Oct 7, 2008 at 8:16 PM, Paul Melis [EMAIL PROTECTED] wrote: And I'm forgetting the important details: - Gentoo Linux 2.6.25 - GCC 4.1.2 - NVidia Geforce 9600GT, driver 173.14.09 Paul Paul Melis wrote: I seem to be getting some lock up when switching threading models in osgviewer (with the cow). However I also see these in 2.6.0 now that I test it (haven't been using 2.6 yet). What's more, switching of the threading model with 'm' does not always seem to happen. Sometimes when I press 'm' the threading model doesn't change, only when I press 'm' again. This is with vsync off, b.t.w., in case timings issues might be at play here. The lockup always seems to occur when switching to CullThreadPerCameraDrawThreadPerContext. Here's a relevant stack trace #0 0xe424 in __kernel_vsyscall () #1 0xb7963576 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7ef79c8 in OpenThreads::Condition::wait () from /home/melis/c/osg/build/2.7.2/bin/../lib/libOpenThreads.so.11 #3 0xb7a49e4d in osgViewer::ViewerBase::renderingTraversals () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #4 0xb7a48833 in osgViewer::ViewerBase::frame () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #5 0xb7a48971 in osgViewer::ViewerBase::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #6 0xb7a3a033 in osgViewer::Viewer::run () from /home/melis/c/osg/build/2.7.2/bin/../lib/libosgViewer.so.46 #7 0x0804b1e6 in main () Paul Robert Osfield wrote: Hi All, I am planning to make a 2.7.3 dev release tomorrow morning, there have been plenty of changes checked in since 2.7.2 so there is potential for build breaks so I'd appreciate testing across platforms of svn/trunk. If you have a clean build or a build failure please post your results into the list so I can keep tabs on where things are build/what is left to fix up. Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release
On Tue, Oct 7, 2008 at 10:58 PM, Paul Melis [EMAIL PROTECTED] wrote: Well, going back to 169.12 does seem to make that problem go away Interesting, since I have the problem with the 169.12 driver. Maybe I should upgrade to make it go away ;) -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Random Particle Color, alpha, etc.
I'm porting my current particle system to OSG (version 2.6.x). I am hoping to use osgParticle instead of wrapping my current OpenGL calls in OSG drawables. It seems that osgParticle overall provides more functionality than my current scheme. However, I'm unsure of the best way to handle random start and end colors, alpha, etc. for particles in a system. In my current code, I set a range for both the starting and ending color and the starting and ending colors are randomly chosen from that range. (For example, I may want the particle start off red to red-yellow with little to no transparency and end up red to white with almost full transparency.) My first thought was to override the osgParticle::Particle::update method and initialize the particle with the desired randomness. Alas, osgParticle::Particle has no virtual methods. So, I dug further and found that I could override osgParticle::ParticleSystem::createParticle or osgParticle::Emitter::emit and change the default particle template every time to apply the desired randomness. That doesn't seem like a very elegant solution. I have to believe someone else has done something similar before. Am I missing something or have I found the best options? Is there a reason that osgParticle::Particle has absolutely no virtual methods? John Cummings ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU osgShadow
Hi, Awesome, thanks for the correction. I see that my initial example forgot to actually add the model to the shadowed scene :P But that wasn't the real problem. The real problem was giving osgPPU the same node that i was using for shadows. I do not realy understand what you mean here with giving osgPPU the same node as for shadows. osgPPU doesn't now anything about the graph, it does only get camera as input, hence use the camera color buffer texture as input. Therefor the camera, which is connected to the osgPPU, which can be your main camera or some other one, should be able to render your shadowed scene. Cheers, art After seeing what you did in your correction I rearranged the graph like this: scene-addChild(shadowedScene); shadowedScene-addChild(loadedModel); and everything worked as expected. Now I just want to understand why this worked. It it because osgPPU and osgShadow are no longer fighting to control the state of the single scene node? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] fullscereen rendering on second monitor
Good day! I'd like to use dual monitor configuration and use fullscreen mode rendering on second monitor and rendering in window on fist monitor using osg Could you please tell me how to make it? Thanx in advance Bye ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
