Re: [osg-users] Extending CURL plugin to implement write functions.
Hi, Thanks! That was fast :) Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40840#40840 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issue: Osg Dlls not found on Release mode
Hi Mohamed, On Fri, Jun 24, 2011 at 9:53 AM, Mohamed Alji osgfo...@tevs.eu wrote: ** any information or advice is a welcome The topic of finding dll's has arisen many times on osg-users mailing list forum so my advice is go search the archives. Also have a look at the microsoft online documentation as finding dll's is really a basic issue of setup. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issue: Osg Dlls not found on Release mode
First, I need to thank you very much for taking the time to answer my question. I apologize for not having looking more deeply in the others posts I will do so right now. you can remove this post . [Idea] what about proposing articles for FRI : Frequently Resolved Issues on the wiki. Have a nice day Mohamed ALJI -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40844#40844 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] re-render models to ceate a haptic model
Hi, I am trying to integrate OSG with the Sensable haptic libraries and have a question regarding re-rendering the OSG models. The haptic models capture the geometry of the graphic models from OpenGL commands via the depth or feedback buffer. This is an example supplied by Sensable hlBeginFrame(); // Set material properties for the shapes to be drawn. hlMaterialf(HL_FRONT_AND_BACK, HL_STIFFNESS, 0.7f); hlMaterialf(HL_FRONT_AND_BACK, HL_DAMPING, 0.1f); hlMaterialf(HL_FRONT_AND_BACK, HL_STATIC_FRICTION, 0.2f); hlMaterialf(HL_FRONT_AND_BACK, HL_DYNAMIC_FRICTION, 0.3f); // Start a new haptic shape. Use the feedback buffer to capture OpenGL // geometry for haptic rendering. hlBeginShape(HL_SHAPE_FEEDBACK_BUFFER, gSphereShapeId); // Use OpenGL commands to create geometry. glutSolidSphere(0.5, 32, 32); // End the shape. hlEndShape(); // End the haptic frame. hlEndFrame(); I believe I need to replace; glutSolidSphere(0.5, 32, 32) by passing the function a geode and then forcing this to be rendered causing it to be written to the OpenGL feedback buffer. Could anyone advise me on the best way to approach this? Thank you! Cheers, Craig -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40845#40845 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] re-render models to ceate a haptic model
HI Crag, I don't personally know about the current state of art w.r.t haptic API's but there is an osgHaptics NodeKit that the VRLab in Umea, Sweden developed: http://www.vrlab.umu.se/research/osgHaptics/ This might be what you need for OSG/Haptic integration. Robert. On Fri, Jun 24, 2011 at 10:49 AM, Craig Fletcher c...@hw.ac.uk wrote: Hi, I am trying to integrate OSG with the Sensable haptic libraries and have a question regarding re-rendering the OSG models. The haptic models capture the geometry of the graphic models from OpenGL commands via the depth or feedback buffer. This is an example supplied by Sensable hlBeginFrame(); // Set material properties for the shapes to be drawn. hlMaterialf(HL_FRONT_AND_BACK, HL_STIFFNESS, 0.7f); hlMaterialf(HL_FRONT_AND_BACK, HL_DAMPING, 0.1f); hlMaterialf(HL_FRONT_AND_BACK, HL_STATIC_FRICTION, 0.2f); hlMaterialf(HL_FRONT_AND_BACK, HL_DYNAMIC_FRICTION, 0.3f); // Start a new haptic shape. Use the feedback buffer to capture OpenGL // geometry for haptic rendering. hlBeginShape(HL_SHAPE_FEEDBACK_BUFFER, gSphereShapeId); // Use OpenGL commands to create geometry. glutSolidSphere(0.5, 32, 32); // End the shape. hlEndShape(); // End the haptic frame. hlEndFrame(); I believe I need to replace; glutSolidSphere(0.5, 32, 32) by passing the function a geode and then forcing this to be rendered causing it to be written to the OpenGL feedback buffer. Could anyone advise me on the best way to approach this? Thank you! Cheers, Craig -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40845#40845 ___ 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] re-render models to ceate a haptic model
Thats great thanks Robert, their code is open so I can take a look through it..or use it. Craig -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40848#40848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [3rdparty] 3DS track model and mipmap detail distance
Hi, I'm loading a track in 3ds format, textures are loaded with mipmap levels automatically but the mipmap switch is too close to the camera thus mipmap artefact are too clearly visible expecially on lane borders. Is there a way in OSG to setup texture mipmap distance switching for a loaded model? thanks Robyx ... Thank you! Cheers, Roberto -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40849#40849 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] 3DS track model and mipmap detail distance
Hi, Roberto You can use osg::TexEnvFilter state attribute to set mipmap lod bias. Cheers, Sergey. 24.06.2011, 15:39, Roberto Sartori roberto.sart...@gmail.com: Hi, I'm loading a track in 3ds format, textures are loaded with mipmap levels automatically but the mipmap switch is too close to the camera thus mipmap artefact are too clearly visible expecially on lane borders. Is there a way in OSG to setup texture mipmap distance switching for a loaded model? thanks Robyx ... Thank you! Cheers, Roberto -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40849#40849 ___ 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 for highlighting node under mouse
Hi, Cory
You can write technique for outline effect to use additional passes with
different settings, and add different cull masks to each pass, so you can use
effect node at top of your graph and apply masks on nodes to get correct effect
passes running on them.
You will need to change traverse method like this:
void traverse(osg::NodeVisitor nv, osgFX::Effect* fx)
{
if (!getNumPasses())
{
define_passes();
}
osgUtil::CullVisitor *cv =
dynamic_castosgUtil::CullVisitor *(nv);
if (!cv) return;
unsigned int mask = cv-getTraversalMask();
for (unsigned i=0; igetNumPasses(); ++i)
{
if (cv)
{
cv-pushStateSet(getPassStateSet(i));
}
if (i masks.size())
{
cv-setTraversalMask(masks[i]);
fx-inherited_traverse(nv);
}
else
{
cv-setTraversalMask(mask);
fx-inherited_traverse(nv);
}
if (cv)
{
cv-popStateSet();
}
}
cv-setTraversalMask(mask);
}
masks is vector with traverse masks to be used by cull visitor for each pass.
Cheers,
Sergey.
23.06.2011, 23:18, Cory Riddell c...@codeware.com:
I've been playing with the osgFX classes and I'm thinking about using
osgFX::Outline() to highlight the node(s) under the mouse.
First, I would need a list of highlighted nodes. Initially it would be
empty.
Every highlightable node would have a parent osgFX::Outline instance
with an initial thin black outline.
I would handle osgGA::GUIEventAdapter::MOVE events. Using the
osgUtil::LineSegmentIntersector to find what's under the mouse pointer.
I would compare my list of nodes under the mouse pointer with my list of
highlighted nodes. Any nodes on the highlighted list not under the
mouse, would be reverted to a thin black outline. Any nodes under the
mouse would get a thicker, yellow outline. The list of highlighted nodes
would be updated to reflect the current state.
Is this reasonable? Is having an osgFX::Outline instance on every node a
heavy way of accomplishing this? Is hit-testing every move event crazy?
Alternatively, I thought about just lightening the face color of every
node under the mouse. This wouldn't require any osgFX::Outline() nodes.
Thanks,
Cory
___
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] [3rdparty] osgShadowMap problems
Hi, I've got problems using shadows, I've followed the standard examples as following: // create the shadowed scene m_OSG_Default_3D_Scene = new osgShadow::ShadowedScene; // create and setup the shadow technique m_OSG_ShadowMap = new osgShadow::ShadowMap; m_OSG_ShadowMap-setLight( m_OSG_Default_3D_Scene_SunLight_Source.get() ); m_OSG_ShadowMap-setTextureSize( osg::Vec2s(2048, 2048) ); m_OSG_ShadowMap-setTextureUnit( 1 ); // add the shadowed scene to the main camera m_OSG_Default_3D_Camera-addChild( m_OSG_Default_3D_Scene.get() ); The result does not behave as expected, Shadows appears in the wrong position, please refer to the attached images to look at the result. I'm not able to find more info about shadows in OSG, documentation is very poor and tutorials too much simple. Does anybody know why these artefacts appears? thanks Thank you! Roberto -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40852#40852 Attachments: http://forum.openscenegraph.org//files/24_06_2011_14_01_16_982.png http://forum.openscenegraph.org//files/24_06_2011_14_00_45_801.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Low performance
Hi Robert, You were right here is the same appl stats but on Release mode. [Image: http://img857.imageshack.us/img857/7769/stats2p.png ] Thank you! Mohamed ALJI -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40853#40853 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] improperly culled osgText
HI Terry, On Thu, Jun 23, 2011 at 9:43 PM, Terry Welsh mogu...@gmail.com wrote: Thanks for the reply. Turning off small feature culling does indeed fix my problem, but it's not ideal. It's not ideal at all, I'd call it hack ;-) I guess another hack would be to switch off culling off for the first frame and then re-enable. I'm not sure I understand all the details of what you're saying, but let me take a crack at it. With the current code you can a) turn off small feature culling, which will get you a bounding box of size 0 on the first frame and a reconstructed bounding box of the proper size on later frames, or b) leave small feature culling on, which causes your text to never be displayed. If there must be an incorrect bounding box on the first frame, maybe it should be just large enough to escape being culled as a small feature. Then small feature culling could be left on without any trouble. Of course, if there is any way to build a bounding box of roughly the right shape and size with information about the text to be drawn, that would probably be better. It sounds to me like things happen in the wrong order in OSG to make this practical or even possible. You are reading things correctly, as things stand the view dependent settings in osgText cause problems with sizing and computing bounding volumes for the first frame. Having a view dependent text in two different views will also cause similar issues with the bounding volume. I don't think there is any easy solutions without rejigging a number of design elements. For instance if I was write osgText::Text now I wouldn't put any of the view dependent support into it. Instead this should be provied by osg::AutoTransform, osg::Billboad or similar node level support. This will solve part of the problems, but there still is the issue with view dependent subgraphs and their bounding volumes which would need some resolution at the node level, unfortunately I don't know just what right now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] FBX plugin: crash if using AVI texture
Finally, I could try with the debug build and here's the call stack when the crash occurs: osg78-osgd.dll!osg::ObserverSet::signalObjectDeleted(void * ptr) Line 79 + 0x1b bytes C++ osg78-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 318C++ osg78-osgd.dll!osg::Referenced::unref() Line 200 C++ osg78-osgDBd.dll!osg::ref_ptrosg::Object::~ref_ptrosg::Object() Line 35 + 0x24 bytes C++ osg78-osgDBd.dll!std::_Pair_baseosg::ref_ptrosg::Object,double::~_Pair_baseosg::ref_ptrosg::Object,double() + 0x16 bytes C++ osg78-osgDBd.dll!std::pairosg::ref_ptrosg::Object,double::~pairosg::ref_ptrosg::Object,double() + 0x16 bytes C++ osg78-osgDBd.dll!std::_Pair_basestd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ::~_Pair_basestd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double () + 0x3f bytes C++ osg78-osgDBd.dll!std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ::~pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double () + 0x16 bytes C++ osg78-osgDBd.dll!std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ::`scalar deleting destructor'() + 0x16 bytes C++ osg78-osgDBd.dll!std::_Destroystd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double (std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double * _Ptr) Line 64 C++ osg78-osgDBd.dll!std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ::destroy(std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double * _Ptr) Line 213 + 0x9 bytesC++ osg78-osgDBd.dll!std::_Dest_valstd::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ,std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double (std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double_Alval, std::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double * _Pdest) Line 288 C++ osg78-osgDBd.dll!std::_Treestd::_Tmap_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairosg::ref_ptrosg::Object,double,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ,0 ::_Erase(std::_Tree_nodstd::_Tmap_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairosg::ref_ptrosg::Object,double,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ,0 ::_Node * _Rootnode) Line 1617 + 0x22 bytes C++ osg78-osgDBd.dll!std::_Treestd::_Tmap_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::pairosg::ref_ptrosg::Object,double,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar const ,std::pairosg::ref_ptrosg::Object,double ,0 ::clear() Line 1416 C++ osg78-osgDBd.dll!osgDB::Registry::clearObjectCache() Line 1601 C++ osg78-osgDBd.dll!osgDB::Registry::destruct() Line 431 C++ osg78-osgDBd.dll!osgDB::Registry::~Registry() Line 410 C++ osg78-osgDBd.dll!osgDB::Registry::`vector deleting destructor'() + 0x57 bytes C++ osg78-osgd.dll!osg::Referenced::signalObserversAndDelete(bool signalDelete, bool doDelete) Line 323 + 0x23 bytes C++ osg78-osgd.dll!osg::Referenced::unref() Line 200 C++ osg78-osgDBd.dll!osg::ref_ptrosgDB::Registry::~ref_ptrosgDB::Registry() Line 35 + 0x24 bytes C++ osg78-osgDBd.dll!`osgDB::Registry::instance'::`2'::`dynamic atexit destructor for 's_registry''() + 0xd bytes C++ osg78-osgDBd.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 415 C osg78-osgDBd.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 526 + 0x11 bytes C
Re: [osg-users] advice for highlighting node under mouse
Thank you Sergey. I knew there had to be a better way.
Cory
On 6/24/2011 7:00 AM, Sergey Polischuk wrote:
Hi, Cory
You can write technique for outline effect to use additional passes with
different settings, and add different cull masks to each pass, so you can use
effect node at top of your graph and apply masks on nodes to get correct
effect passes running on them.
You will need to change traverse method like this:
void traverse(osg::NodeVisitor nv, osgFX::Effect* fx)
{
if (!getNumPasses())
{
define_passes();
}
osgUtil::CullVisitor *cv =
dynamic_castosgUtil::CullVisitor *(nv);
if (!cv) return;
unsigned int mask = cv-getTraversalMask();
for (unsigned i=0; igetNumPasses(); ++i)
{
if (cv)
{
cv-pushStateSet(getPassStateSet(i));
}
if (i masks.size())
{
cv-setTraversalMask(masks[i]);
fx-inherited_traverse(nv);
}
else
{
cv-setTraversalMask(mask);
fx-inherited_traverse(nv);
}
if (cv)
{
cv-popStateSet();
}
}
cv-setTraversalMask(mask);
}
masks is vector with traverse masks to be used by cull visitor for each pass.
Cheers,
Sergey.
23.06.2011, 23:18, Cory Riddell c...@codeware.com:
I've been playing with the osgFX classes and I'm thinking about using
osgFX::Outline() to highlight the node(s) under the mouse.
First, I would need a list of highlighted nodes. Initially it would be
empty.
Every highlightable node would have a parent osgFX::Outline instance
with an initial thin black outline.
I would handle osgGA::GUIEventAdapter::MOVE events. Using the
osgUtil::LineSegmentIntersector to find what's under the mouse pointer.
I would compare my list of nodes under the mouse pointer with my list of
highlighted nodes. Any nodes on the highlighted list not under the
mouse, would be reverted to a thin black outline. Any nodes under the
mouse would get a thicker, yellow outline. The list of highlighted nodes
would be updated to reflect the current state.
Is this reasonable? Is having an osgFX::Outline instance on every node a
heavy way of accomplishing this? Is hit-testing every move event crazy?
Alternatively, I thought about just lightening the face color of every
node under the mouse. This wouldn't require any osgFX::Outline() nodes.
Thanks,
Cory
___
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] .zip plugin in OSG trunk (and probably 3.0 as well)
Hi Ulrich, I have come up with a solution to the zip reading problem - I've changed the Registry::read(..) method to check the list of cached archives to see if they can read the filename just after all the plugin are passed the filename. This allows us to do: osgviewer AH-6.zip And have the model load up correctly. Could you try svn/trunk or OSG-3.0 branch out to see how you get on. The issue I came across with converting the .x model to .osgt and .osgx has also been addressed by Wang Rui and has also been checked into svn/trunk and OSG-3.0. Rui found that there was infinite floating point values in the data that the ascii reading in the new serailizaters were failing on. Rui's fix allows the ascii serializers to handle these invalid values without hanging or reporting odd errors. Rui's finding also points to errors in the original .x file but that's a non OSG issue, unless... our .x plugin is buggy... I'm not about to go chase errors in files so I'll get back to wrapping up 3.0.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Please test svn/trunk and OSG-3.0 branch for next rc
Hi All, I have now checked in a couple of bugs and build fixes this morning. Could everyone try svn/trunk or OSG-3.0 branch out an let me know how things compile and run. In particular I'd like feedback on using VisualStudio 2010 as I got a series of confusing direct emails from a OSG user that indicated that he was having problems under VC100 (which I'm guess he meant VisualStudio 2010), unfortunately I couldn't make enough sense of the emails or suggested fixes to know what was going on, but it did leave me with more questions than answers by the time response dried up. So.. at least one user was having problems, for what reason I can't say, I can't say whether the fixes checked in this morning address these issues.. So... what I really need is other members of the community to pitch in and make sure things are working, help clear the fog. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] error building osga plugin in r12640
Visual Studio 2008, Windows 7 building svn revision 12640: 41OSGA_Archive.obj : error LNK2001: unresolved external symbol public: virtual class osgDB::ReaderWriter::WriteResult __thiscall OSGA_Archive::writeShader(class osg::Shader const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::Options const *)const (?writeShader@OSGA_Archive@@UBE?AVWriteResult@ReaderWriter@osgDB@@ABVShader@osg@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBVOptions@4@@Z) 41D:\OpenSceneGraph\build\bin\osgPlugins-3.1.0\osgdb_osga.dll : fatal error LNK1120: 1 unresolved externals -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FAR_PLANE_CULLING
Just as a follow-up question on this topic, what settings are included in the DEFAULT_CULLING? Thanks, -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Thursday, June 23, 2011 3:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] FAR_PLANE_CULLING On 6/23/2011 3:14 PM, Terry Welsh wrote: Haven't looked at this in a while, but I was just performance tuning an old app and got a significant boost by adding in CullSettings::FAR_PLANE_CULLING. Why isn't this included as part of DEFAULT_CULLING? I don't have any hard data, but I suspect the performance penalty for culling with the far plane when you shouldn't isn't near as bad as ignoring the far plane when you should use it. (I suspect NEAR_PLANE_CULLING is not as useful for most apps.) Hi Terry -- Do you have auto-compute near/far turned on? If so, there shouldn't be anything behind the far plane. In that case, it doesn't make sense for the CullVisitor to check every single Drawable's bounding box against a plane that it can't possibly be clipped by. For this reason, culling against the far plane is off by default. If you disable auto-compute near/far, and you expect part of your scene to be behind the far plane, then you should enable far plane culling. I'd expect to see a performance boost in such a case. Hope that helps, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FAR_PLANE_CULLING
Hi Shayne, The definition is in include/osg/CullSettings. Cheers, -Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40863#40863 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] improperly culled osgText
On Fri, 2011-06-24 at 13:57 +0100, Robert Osfield wrote: HI Terry, On Thu, Jun 23, 2011 at 9:43 PM, Terry Welsh mogu...@gmail.com wrote: Thanks for the reply. Turning off small feature culling does indeed fix my problem, but it's not ideal. It's not ideal at all, I'd call it hack ;-) I guess another hack would be to switch off culling off for the first frame and then re-enable. I'm not sure I understand all the details of what you're saying, but let me take a crack at it. With the current code you can a) turn off small feature culling, which will get you a bounding box of size 0 on the first frame and a reconstructed bounding box of the proper size on later frames, or b) leave small feature culling on, which causes your text to never be displayed. If there must be an incorrect bounding box on the first frame, maybe it should be just large enough to escape being culled as a small feature. Then small feature culling could be left on without any trouble. Of course, if there is any way to build a bounding box of roughly the right shape and size with information about the text to be drawn, that would probably be better. It sounds to me like things happen in the wrong order in OSG to make this practical or even possible. You are reading things correctly, as things stand the view dependent settings in osgText cause problems with sizing and computing bounding volumes for the first frame. Having a view dependent text in two different views will also cause similar issues with the bounding volume. I don't think there is any easy solutions without rejigging a number of design elements. For instance if I was write osgText::Text now I wouldn't put any of the view dependent support into it. Instead this should be provied by osg::AutoTransform, osg::Billboad or similar node level support. This will solve part of the problems, but there still is the issue with view dependent subgraphs and their bounding volumes which would need some resolution at the node level, unfortunately I don't know just what right now. TextNode will make this much easier, I think. Coming Soon (tm)! 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] FAR_PLANE_CULLING
Thanks Tony...:) -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tony Horrobin Sent: Friday, June 24, 2011 8:19 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] FAR_PLANE_CULLING Hi Shayne, The definition is in include/osg/CullSettings. Cheers, -Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40863#40863 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Basic Lighting Shaders
On Thu, 2011-06-23 at 13:24 -0400, Jeremy Moles wrote: I'm looking to collect some sample code from OSG users (if this code is shareable) for some basic lighting examples done purely in GLSL. If anyone is willing to share this (I can certainly adapt it, so there's no need to modify it), I'd be grateful. What I'm looking for mainly is how lighting code from source like the Orange Book are different/adapted to OSG. I've begun to compile OSG without support for the FFP, and I'm trying to work up a basic default set of shaders to emulate the FFP functionality. I'm very close, but I'm having trouble figuring out how exactly to caclulate the eye coordinate in my vertex shader when using osgViewer. Right now I'm using: eyePos = vec3(osg_ModelViewMatrix * gl_Vertex); Sigh, remember to ALSO transform your LighPosition (if you're not using the data provided by LightSource[]) by your MVM as well. Don't be dumb like me. :) ...but this starts to fall out of whack as I use the standard TracballManipulator. It works, of course, when in the home() position (and with a new ViewMatrix for the default camera with Y-up). 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] Please test svn/trunk and OSG-3.0 branch for next rc
Hi All, Just a quick note, I've merged a fix to build problem that was picked up VS2008. So for svn/trunk the rev is 12642, while OSG-3.0 branch it's 12643 is what you should be on to get this fix. Once I've got positive feedback on all the main platforms I'll push forward with rc5. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error building osga plugin in r12640
Hi Peter, Ooopps... now implemented and checked into svn/trunk and OSG-3.0. Thanks for the prompt testing and feedback. Robert. On Fri, Jun 24, 2011 at 2:51 PM, Peter Amstutz peter.amst...@tseboston.com wrote: Visual Studio 2008, Windows 7 building svn revision 12640: 41OSGA_Archive.obj : error LNK2001: unresolved external symbol public: virtual class osgDB::ReaderWriter::WriteResult __thiscall OSGA_Archive::writeShader(class osg::Shader const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::Options const *)const (?writeShader@OSGA_Archive@@UBE?AVWriteResult@ReaderWriter@osgDB@@ABVShader@osg@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBVOptions@4@@Z) 41D:\OpenSceneGraph\build\bin\osgPlugins-3.1.0\osgdb_osga.dll : fatal error LNK1120: 1 unresolved externals -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ 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] FAR_PLANE_CULLING
Thanks for the explanation Paul. I hadn't had to look at the auto near/far feature for so long I didn't make the connection. It looks like this old app I'm using has it disabled as you'd expect. -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 8 Date: Thu, 23 Jun 2011 15:30:21 -0600 From: Paul Martz pma...@skew-matrix.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] FAR_PLANE_CULLING Message-ID: 4e03b06d.7090...@skew-matrix.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 6/23/2011 3:14 PM, Terry Welsh wrote: Haven't looked at this in a while, but I was just performance tuning an old app and got a significant boost by adding in CullSettings::FAR_PLANE_CULLING. Why isn't this included as part of DEFAULT_CULLING? I don't have any hard data, but I suspect the performance penalty for culling with the far plane when you shouldn't isn't near as bad as ignoring the far plane when you should use it. (I suspect NEAR_PLANE_CULLING is not as useful for most apps.) Hi Terry -- Do you have auto-compute near/far turned on? If so, there shouldn't be anything behind the far plane. In that case, it doesn't make sense for the CullVisitor to check every single Drawable's bounding box against a plane that it can't possibly be clipped by. For this reason, culling against the far plane is off by default. If you disable auto-compute near/far, and you expect part of your scene to be behind the far plane, then you should enable far plane culling. I'd expect to see a performance boost in such a case. Hope that helps, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Errors reported on BINO-PC on CDash
Hi All, One of the new entries to cdash.openscenegraph.org is Win32-vs9 from the site BINO-PC, this build logs 50 errors before the build gives up: http://cdash.openscenegraph.org/viewBuildError.php?buildid=3924 The errors are almost exclusively: 2LINK : fatal error LNK1104: cannot open file '..\..\lib\osgDBd.lib' I don't think this is a build issue with the source but something odd happening with the setup of the build that has failed. I don't know who setup the build so can't contact them directly so had to broadcast this call here on osg-users. If it's your build could you please have a look into the build issue as failed builds that arne't due to actual problems with the source code or Cmake build system just hide the actual problems that I need to chase up. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] .zip plugin in OSG trunk (and probably 3.0 as well)
Hi Robert, On 24/06/11 15:42 , Robert Osfield wrote: And have the model load up correctly. Could you try svn/trunk or OSG-3.0 branch out to see how you get on. Tried trunk (r12643). It compiles and runs fine on OS X. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hi Stephan, On Thu, Jun 23, 2011 at 9:40 PM, Stephan Wenglorz stephan.maku...@gmx.net wrote: /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp: In member function ‘void plugin3ds::WriterNodeVisitor::writeMaterials()’: /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp:486:14: warning: variable ‘found’ set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/ac/Geode.cpp: In member function ‘void ac3d::Geode::ProcessGeometry(std::ostream, unsigned int)’: /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/ac/Geode.cpp:797:85: warning: variable ‘ModeValuePair’ set but not used [-Wunused-but-set-variable] I've fixed these warnings and checked the fixes into svn/trunk and OSG-3.0 branch. /home/stephan/Dev/LibSources/OpenSceneGraph/include/osg/Vec3f: In function ‘(static initializers for /home/stephan/Dev/LibSources/OpenSceneGraph/examples/osgsharedarray/osgsharedarray.cpp)’: /home/stephan/Dev/LibSources/OpenSceneGraph/include/osg/Vec3f:42:82: warning: array subscript is above array bounds [-Warray-bounds] I can't work out what is wrong with the code in osgshaderarray.cpp or Vec3f - it all looks correct to me with non of the array subscripts out of bounds. Can you spot an error? Is suspect this might just be a compile bug issues a warning in error. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] improperly culled osgText
Okay, so it's a problem that can't be solved properly without some major refactoring. In the meantime, I propose changing this: bbox.set(_position, _position); to this: bbox.set(_position - Vec3(1.0, 1.0, 1.0), _position + Vec3(1.0, 1.0, 1.0)); It's still a hack :) but I think it's better because now text that takes this code will get drawn instead of staying invisible forever. I suppose it's still possible for text to get culled as a small feature this way, but it *always* gets culled the other way. -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 24 Date: Fri, 24 Jun 2011 13:57:59 +0100 From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] improperly culled osgText Message-ID: banlktinfcspn9ed57ots+7ozncs1ums...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 HI Terry, On Thu, Jun 23, 2011 at 9:43 PM, Terry Welsh mogu...@gmail.com wrote: Thanks for the reply. ?Turning off small feature culling does indeed fix my problem, but it's not ideal. It's not ideal at all, I'd call it hack ;-) I guess another hack would be to switch off culling off for the first frame and then re-enable. ?I'm not sure I understand all the details of what you're saying, but let me take a crack at it. ?With the current code you can a) turn off small feature culling, which will get you a bounding box of size 0 on the first frame and a reconstructed bounding box of the proper size on later frames, or b) leave small feature culling on, which causes your text to never be displayed. If there must be an incorrect bounding box on the first frame, maybe it should be just large enough to escape being culled as a small feature. ?Then small feature culling could be left on without any trouble. ?Of course, if there is any way to build a bounding box of roughly the right shape and size with information about the text to be drawn, that would probably be better. ?It sounds to me like things happen in the wrong order in OSG to make this practical or even possible. You are reading things correctly, as things stand the view dependent settings in osgText cause problems with sizing and computing bounding volumes for the first frame. Having a view dependent text in two different views will also cause similar issues with the bounding volume. I don't think there is any easy solutions without rejigging a number of design elements. For instance if I was write osgText::Text now I wouldn't put any of the view dependent support into it. Instead this should be provied by osg::AutoTransform, osg::Billboad or similar node level support. This will solve part of the problems, but there still is the issue with view dependent subgraphs and their bounding volumes which would need some resolution at the node level, unfortunately I don't know just what right now. 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/trunk and OSG-3.0 branch for next rc
Hi All, I'm now ready to tag 3.0.0-rc5, once I've got some positive feedback I'll tag the beast. Right now I've got to go help out with my eldest daughters Birthday party! Have fun ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing a workaround for fullscreen toggling issues under modern X11 window managers
Hi Robert,
On Wednesday, June 22, 2011 17:17:26 Robert Osfield wrote:
At first it would probably help when the NodeVisitor is able to visit
Drawables using the usual accept mehtods or something like that. Then we
could probably just use the Geodes traverse method to walk the drawables.
One dfficulty in this approach is the Bilboard implementation that does
little more then just a traversal of all Drawables.
I don't see any problems with handling subclasses from Geode, it'd be
bit like how
LOD subclasses from Group - it add a per child property that the the
traverse method
handles in a special way. A NodeCallback that overrides the traverse
then would have
to handle the special functionality of a Billboard. In the case of a
Billboard we'd
probably want to have a special handling of cases when chidlren are
Drawable rather
than Node's, as Drawables you can just manage the modelview matrix
directly and don't
need to worry about the view frustum transformation, while normal Nodes you
have to push/pop the view frustum as we do right now for the normal
Transform nodes.
Hmm, I am not exactly sure I already see what you are thinking:
I have started playing with this approach at some time. Attached is the patch
I had so far. The NodeVisitor is just extended by the Drawable. May be the
other drawable derived classes could be put there too. The patch just factors
out the loop body of the geode in the cull visitor and puts that into a new
CullVisitor::apply(Drawable) method.
That patch does not work for any billboard geode. This is just meant as a
miminmal sketch implementation.
Now, If the billboard loop is implemented like the LOD nodes traversal method,
we need virtual access to the modelview matrix in the NodeVisitor base class
from the Billboard::traverse() method. Currently this is not available.
So, may be {push,pop}ModelViewMatrix as a virtual method in the NodeVisitor?
Or do you already have a better idea to do that?
Greetings
Mathias
Index: include/osgUtil/CullVisitor
===
--- include/osgUtil/CullVisitor (revision 12643)
+++ include/osgUtil/CullVisitor (working copy)
@@ -105,6 +105,8 @@
virtual void apply(osg::OccluderNode node);
virtual void apply(osg::OcclusionQueryNode node);
+virtual void apply(osg::Drawable drawable);
+
/** Push state set on the current state group.
* If the state exists in a child state group of the current
* state group then move the current state group to that child.
Index: include/osg/NodeVisitor
===
--- include/osg/NodeVisitor (revision 12643)
+++ include/osg/NodeVisitor (working copy)
@@ -271,6 +271,7 @@
virtual void apply(OccluderNode node);
virtual void apply(OcclusionQueryNode node);
+virtual void apply(Drawable drawable);
/** Callback for managing database paging, such as generated by PagedLOD nodes.*/
class DatabaseRequestHandler : public osg::Referenced
Index: include/osg/Geode
===
--- include/osg/Geode (revision 12643)
+++ include/osg/Geode (working copy)
@@ -41,6 +41,9 @@
virtual Geode* asGeode() { return this; }
virtual const Geode* asGeode() const { return this; }
+/** Traverse downwards : calls children's accept method with NodeVisitor.*/
+virtual void traverse(NodeVisitor nv);
+
/** Add a \c Drawable to the \c Geode.
* If \c drawable is not \c NULL and is not contained in the \c Geode
* then increment its reference count, add it to the drawables list and
Index: include/osg/Drawable
===
--- include/osg/Drawable (revision 12643)
+++ include/osg/Drawable (working copy)
@@ -574,6 +574,10 @@
virtual void accept(PrimitiveIndexFunctor) const {}
+/** Visitor Pattern : calls the apply method of a NodeVisitor with this node's type.*/
+virtual void accept(NodeVisitor nv) { nv.apply(*this); }
+
+
/** Extensions class which encapsulates the querying of extensions and
* associated function pointers, and provide convenience wrappers to
* check for the extensions or use the associated functions.*/
Index: src/osgUtil/CullVisitor.cpp
===
--- src/osgUtil/CullVisitor.cpp (revision 12643)
+++ src/osgUtil/CullVisitor.cpp (working copy)
@@ -876,81 +876,6 @@
// traverse any call callbacks and traverse any children.
handle_cull_callbacks_and_traverse(node);
-RefMatrix matrix = *getModelViewMatrix();
-for(unsigned int i=0;inode.getNumDrawables();++i)
-{
-Drawable* drawable = node.getDrawable(i);
-const BoundingBox bb =drawable-getBound();
-
-if(
Re: [osg-users] OSGExp specular
Hi Jean-Sébastien, Sorry, I've been busy lately. Should I still look into this or does the existing behavior make sense now? Cheers, Farshid On Tue, Jun 21, 2011 at 7:31 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Sergey, osgExp expects specular in range 0...1000, that is range you can set in 3ds max for specular intensity. It's looks different in 3ds max then in osg though. OK, that explains it, I thought the max was 100. I'll adjust my shaders so the result looks the same in Max and in OSG. Thanks, J-S -- __** Jean-Sebastien Guay jean-sebastien.guay@cm-labs.**comjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.**com/http://whitestar02.dyndns-web.com/ __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://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] Animation Embedded in an Object
Hi, I have an object with an embedded animation. The original was a .LWS / .LWO object that I converted to a .IVE file. When I open the .IVE with osgViewer, the animation works just fine. In my application, however, there is no animation (the object displays just fine.) Because the application is a bit complex, I can't really post a concise example, but I am setting up a Composite Viewer and manually calling frame() on it. I suspected that I might need to update the simulation time, so I have also tried calling frame(simTime). That did not fix it either. I'm sure there must be something simple that I am missing, but compared to the code for osgViewer, nothing obvious is jumping out at me. Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40881#40881 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing a workaround for fullscreen toggling issues under modern X11 window managers
Hi Mathias,
I'm afraid I've got too much to think about with the release to start
ponder on other topics so I'm going to bow out gracefully. After 3.0
I'll start thinking about what might go into 3.2, so this would then
be a natural time to bring up topics like how we evolve
Nodes/Drawables/Visitors etc.
Cheers,
Robert.
2011/6/24 Mathias Fröhlich mathias.froehl...@gmx.net:
Hi Robert,
On Wednesday, June 22, 2011 17:17:26 Robert Osfield wrote:
At first it would probably help when the NodeVisitor is able to visit
Drawables using the usual accept mehtods or something like that. Then we
could probably just use the Geodes traverse method to walk the drawables.
One dfficulty in this approach is the Bilboard implementation that does
little more then just a traversal of all Drawables.
I don't see any problems with handling subclasses from Geode, it'd be
bit like how
LOD subclasses from Group - it add a per child property that the the
traverse method
handles in a special way. A NodeCallback that overrides the traverse
then would have
to handle the special functionality of a Billboard. In the case of a
Billboard we'd
probably want to have a special handling of cases when chidlren are
Drawable rather
than Node's, as Drawables you can just manage the modelview matrix
directly and don't
need to worry about the view frustum transformation, while normal Nodes you
have to push/pop the view frustum as we do right now for the normal
Transform nodes.
Hmm, I am not exactly sure I already see what you are thinking:
I have started playing with this approach at some time. Attached is the patch
I had so far. The NodeVisitor is just extended by the Drawable. May be the
other drawable derived classes could be put there too. The patch just factors
out the loop body of the geode in the cull visitor and puts that into a new
CullVisitor::apply(Drawable) method.
That patch does not work for any billboard geode. This is just meant as a
miminmal sketch implementation.
Now, If the billboard loop is implemented like the LOD nodes traversal method,
we need virtual access to the modelview matrix in the NodeVisitor base class
from the Billboard::traverse() method. Currently this is not available.
So, may be {push,pop}ModelViewMatrix as a virtual method in the NodeVisitor?
Or do you already have a better idea to do that?
Greetings
Mathias
___
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] OSGExp, movie textures and OSG file formats
I wonder if anybody else experienced my same problem: I wrote a visitor that looks for movie textures in order to play them, the input files come from 3dsMax via OSGExp v1.0.0, but I made it work only if I export to .osg, if I export to either .ive or .osgb the visitor fails to dynamic_cast any found Image to ImageStream so I cannot play those movie textures. I also noticed that if I export to .osgt then the Image's DataVariance is set to STATIC, even though the texture file type is avi, mov or others (so I have to change it to DYNAMIC otherwise they won't play) Does anyone have the same issues (especially those with the binary formats)? Is all this related to OSGExp only or am I supposed to look for movie texture in a different way than the way I use with .osg files? Thanks. Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40884#40884 ___ 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/trunk and OSG-3.0 branch for next rc
I've built on 32-bit Visual Studio 2010 (without the additional dependencies), and it built just fine - there should be a dashboard report up. Also it looks like my auto-build on Ubuntu 11.04 x64 built fine too. Ryan On Fri, Jun 24, 2011 at 11:29 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi All, I'm now ready to tag 3.0.0-rc5, once I've got some positive feedback I'll tag the beast. Right now I've got to go help out with my eldest daughters Birthday party! Have fun ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com ___ 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/trunk and OSG-3.0 branch for next rc
On Fri, Jun 24, 2011 at 8:50 PM, Ryan Pavlik rpav...@iastate.edu wrote: I've built on 32-bit Visual Studio 2010 (without the additional dependencies), and it built just fine - there should be a dashboard report up. Also it looks like my auto-build on Ubuntu 11.04 x64 built fine too. Thanks for the feedback. I've been looking at the cdash report for th VS 2010 build and had bash at fixing the warning relating to osganimationskinning, the warning wasn't very useful, so I had to guess it was the rather relaxed attitude to int,float,double in the paramters that was at fault so to address this have added in the appropriate .0f or .0 where appropriate. I'm not expect these changes to present any problems, so I'll push ahead with tagging rc5. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-3.0.0-rc5 tagged, please test ;-)
Hi All, Another day, another release candidate! source package : http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.0.0-rc5.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.0-rc5 OpenSceneGraph As things stand I don't have any pending bugs on my inbox to resolve for the release, what feedback I have had on the build of OSG-3.0 branch has been positive so I've gone with this as a good Omen, I've only had feedback on Linux and Windows+VisualStudio 2010, so I'm sticking my neck out a little in testing all todays changes are being perfectly portable, but as it's getting into the evening here in Scotland it's either tag now at let everyone test the rc5 over me night time, or wait till tomorrow. I believe we must be pretty close to being ready to tag 3.0.0, and am personally happy to go for it, but I've only got Linux and small set of apps to test against vs the communities dozens of platforms and hundreds/thousands of applications. So for this rc5 I'd like to push the question out to the community - are you happy with 3.0.0-rc5 being good enough for going 3.0.0 without any further revisions? Is it good enough to base your applications on? Thanks for your testing, I know it's rather gruelling having all these requests for testing, but it is appreciated, and it's really important to software quality, fingers cross rc5 will be the last round of testing we'll need to do then we can all get back to usual days coding and holidays ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hello Robert, On 24.06.2011 18:18, Robert Osfield wrote: Hi Stephan, On Thu, Jun 23, 2011 at 9:40 PM, Stephan Wenglorz stephan.maku...@gmx.net wrote: /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp: In member function ‘void plugin3ds::WriterNodeVisitor::writeMaterials()’: /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp:486:14: warning: variable ‘found’ set but not used [-Wunused-but-set-variable] /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/ac/Geode.cpp: In member function ‘void ac3d::Geode::ProcessGeometry(std::ostream, unsigned int)’: /home/stephan/Dev/LibSources/OpenSceneGraph/src/osgPlugins/ac/Geode.cpp:797:85: warning: variable ‘ModeValuePair’ set but not used [-Wunused-but-set-variable] I've fixed these warnings and checked the fixes into svn/trunk and OSG-3.0 branch. Thanks, just build the 3.0 branch and the two warnings are gone. /home/stephan/Dev/LibSources/OpenSceneGraph/include/osg/Vec3f: In function ‘(static initializers for /home/stephan/Dev/LibSources/OpenSceneGraph/examples/osgsharedarray/osgsharedarray.cpp)’: /home/stephan/Dev/LibSources/OpenSceneGraph/include/osg/Vec3f:42:82: warning: array subscript is above array bounds [-Warray-bounds] I can't work out what is wrong with the code in osgshaderarray.cpp or Vec3f - it all looks correct to me with non of the array subscripts out of bounds. Can you spot an error? Is suspect this might just be a compile bug issues a warning in error. Robert. Sorry, I have no idea what might cause this warning, but you are right, there are some bug reports about it at the gcc bugzilla. Anyway, the example works ok for me. Greetings Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with UV Textures in OSG
Hi, my team and I are trying UV textures for the first time in OpenSceneGraph, however, we have a problem. We use Maya to build our 3D models and when I did UV texturing on a model for a simple dice, it refuses to show up properly in OSG. Even though the UV texturing looks perfect in Maya, as soon as we export it to OSG, the die reverts and the texture looks how it did BEFORE I edited it in the UV Texture Editor. Does anyone know why this isn't working? What extra steps do you need to take in order to use UV Textures in OSG? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40872#40872 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
