Re: [osg-users] [osgPlugins] COLLADA Blender reading problem
>
> Marco Cosentino wrote:
> Quote: � Select � � Expand �
> Quote: � Select � � Expand �
> Hi,
> I have a problem (maybe a bug?) in loading a .dae file made with Blender
> collada exporter.
> I'm writing a robot simulation software that uses collada to load both 3d and
> physics.
> The error I get is an exception :
> "Unhandled exception at 0x0049fb10 (msvcr80d.dll) in RobotSimulator.exe:
> 0xC005: Access violation reading location 0x."
>
> This occours when I try to load the collada file. Here is the code I wrote:
>
> Code:
> bool VisualModel::CreateFromColladaFileAndFillDAE(std::string & filename,DAE
> *dae)
> {
> osg::ref_ptr rwoptions(new
> osgDB::ReaderWriter::Options());
> rwoptions->setPluginData("DAE",dae);
> modelnode = osgDB::readNodeFile(filename,rwoptions);
> if(!modelnode) return false;
> return true;
> }
>
>
>
> Here is the stack trace:
>
> Code:
> Quote: � Select �
> msvcr80d.dll!strlen(unsigned char * buf=0x0012e760) Line 81 Asm
> msvcp80d.dll!std::char_traits::length(const char * _First=0x)
> Line 559 + 0x9 bytes C++
> msvcp80d.dll!std::basic_string,std::allocator
> >::assign(const char * _Ptr=0x) Line 1042 + 0x9 bytes C++
> msvcp80d.dll!std::basic_string,std::allocator
> >::operator=(const char * _Ptr=0x) Line 893 C++
> osg55-osgd.dll!osg::Object::setName(const char * name=0x) Line 102 +
> 0x21 bytes C++
> osgdb_daed.dll!osgdae::daeReader::processSinglePPrimitive(osg::Geode
> * geode=0x05c08620, domTriangles * group=0x05c1cbe8, std::map *,osgdae::domSourceReader,std::less *>,std::allocator > > &
> sources=[2](...,...), unsigned int mode=4) Line 243 + 0x14 bytes C++
> osgdb_daed.dll!osgdae::daeReader::processGeometry(domGeometry *
> geo=0x05c1a3e8) Line 219 C++
> osgdb_daed.dll!osgdae::daeReader::processInstanceGeometry(domInstance_geometry
> * ig=0x05c1ee98) Line 47 + 0xc bytes C++
> osgdb_daed.dll!osgdae::daeReader::processNode(domNode * node=0x05c1e310) Line
> 366 + 0x22 bytes C++
> osgdb_daed.dll!osgdae::daeReader::processVisualScene(domVisual_scene *
> scene=0x05c1dd58) Line 156 + 0x23 bytes C++
> osgdb_daed.dll!osgdae::daeReader::convert(const
> std::basic_string,std::allocator > &
> fileURI="./simpleworld.dae") Line 123 + 0xc bytes C++
> osgdb_daed.dll!ReaderWriterDAE::readNode(const
> std::basic_string,std::allocator > &
> fname=".simpleworld.dae", const osgDB::ReaderWriter::Options *
> options=0x05c07100) Line 65 + 0x12 bytes C++
> osg55-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter
> & rw={...}) Line 1399 + 0x40 bytes C++
> osg55-osgDBd.dll!osgDB::Registry::read(const osgDB::Registry::ReadFunctor &
> readFunctor={...}) Line 1537 + 0x22 bytes C++
> osg55-osgDBd.dll!osgDB::Registry::readImplementation(const
> osgDB::Registry::ReadFunctor & readFunctor={...}, bool useObjectCache=false)
> Line 1645 + 0x13 bytes C++
> osg55-osgDBd.dll!osgDB::Registry::readNodeImplementation(const
> std::basic_string,std::allocator > &
> fileName=".simpleworld.dae", const osgDB::ReaderWriter::Options *
> options=0x05c07100) Line 1850 + 0x57 bytes C++
> osg55-osgDBd.dll!osgDB::Registry::readNode(const
> std::basic_string,std::allocator > &
> fileName=".simpleworld.dae", const osgDB::ReaderWriter::Options *
> options=0x05c07100, bool buildKdTreeIfRequired=true) Line 237 + 0x98 bytes C++
> osg55-osgDBd.dll!osgDB::readNodeFile(const
> std::basic_string,std::allocator > &
> filename=".simpleworld.dae", const osgDB::ReaderWriter::Options *
> options=0x05c07100) Line 69 + 0x1f bytes C++
> RobotSimulator.exe!RobotSimulator::VisualModel::CreateFromColladaFileAndFillDAE(std::basic_string,std::allocator
> > & filename=".simpleworld.dae", DAE * dae=0x0012f958) Line 10 + 0x15 bytes
> C++
> RobotSimulator.exe!RobotSimulator::Simulable::LoadModel(RobotSimulator::Model
> model={...}) Line 21 + 0x16 bytes C++
> RobotSimulator.exe!RobotSimulator::Simulator::LoadSimulation(const char *
> pfilename=0x05b4d9c1) Line 93 + 0x28 bytes C++
> RobotSimulator.exe!main(int argc=2, char * * argv=0x05b4d968) Line 54 + 0x20
> bytes C++
> RobotSimulator.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
> RobotSimulator.exe!mainCRTStartup() Line 403 C
> kernel32.dll!7c817077()
>
>
>
>
> The collada model is made by Blender 2.48a using the default startup scene
> with the cube with assigned a green material and esported with Triangles
> option and DisablePhisics option (for testing). You can find it in
> attachments.
> Note that with collada-dom viewer the model is loaded adn displayed correctly
> and with osgviewer the model is loaded witout exceptions but nothing is
> displayed into the scene.
>
> I think the problem is related to the call (you can see in the stack trace)
> osg55-osgd.dll!osg::Object::setName(const char * name=0x)� Line 102 +
> 0x21 bytes
>
> Can you tell me why this appens and how to correct ?
>
> Thank you!!
> Bye :D
>
> The safety check on the material name not being NULL seems
Re: [osg-users] OSGSpotLight example on a GLSL material
Hi Bino, I can't see how many of us will be able divine what is up with your shaders as we have absolutely no knowledge of what you've put into your shader. You question is equivalent to "I have a piece of string you can't see, but can you tell me exactly how long it is". Try including the vertex and fragment shaders you are using then others might have a chance of spotting what is up. Robert. On Fri, Jun 12, 2009 at 6:28 AM, Albino Rodrigues wrote: > Hi, > > > > I have been using the OSGSpotLight example as a starting base to simulate a > flashlight with success. > > > > The scene I was using has now been updated to be drawn with a GLSL NormalMap > shader (included as part of the .ive). The spotlight can no longer be seen. > It does however appear to affect the general lighting of the area it’s in, > but the spotlight and the texture image that goes with it can no longer be > seen. > > > > Any ideas on how to get around this would be much appreciated. > > > > Cheers, > > Bino > > > > > > > > ___ > 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] Image file PagedLOD...
Hi All, Has anyone come across a scenario where they wished to have PagedLOD that instead of handling Nodes, handle images ? Essentially I find myself in a position where I have a model that references a texture, but that texture is quite large, and even with reducing the texture size with little compromise in quality, the time to stream over the web is too large. So, what I'm considering is replacing the image load call, with a similar concept to that of PagedLOD's whereby I could give the "PagedImageLOD" object a list of ordered image file names that I want it to progressively load - in much the same way that apps like google map appears to work. The first image file could be a 2x2 pixel image, whilst the nth image file would be the full-on image. I would want the "PagedImageLOD" to return a valid Image node immediately - perhaps a hard coded small default image - whilst in the background the specified image filesnames are being downloaded, and replace the content of the created image node. The reason for this sort of functionality would be that I could then intercept all image load requests via my own callback handler, replace with a PagedImageLOD request, and still permit most plugins to work happily on the assumption that a model plugin that loads an image is probably only trying to reference that image in some stateset context. Sorry for the thought dump, but has anyone tried/needed to do a similar thing, and if so is there an example available ? Alternatively, if you can think of a better way that would be good as well. Most obvious alternative - that of have an LOD node on the model - would be fine if I only had one or two models. However, I have thousands of different models, so can't really ask our modellers to redo all these. Many thanks for any help/thoughts. Kind regards Neil. .to whose content was progressively replaced by the downloaded images. In this way I could ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Cursor problem under Windows
Hi all,
Currently (the SVN version of OSG), hidding the cursor under Windows has no
effect. Setting cursor to false on the traits or making something like :
osgViewer::ViewerBase::Windowswindows;
viewer.getWindows(windows);
for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr !=
windows.end(); ++itr)
{
(*itr)->useCursor(false);
}
Doesn't work, I always see the cursor...
Any idea on which modification has break things ? The same code was working
for me some weeks ago, but I can't tell which revision it was...
Thanks !
Best regards,
--
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image file PagedLOD...
Hi Neil, The osgEarth project does essentially what you are looking for. Check it out at http://www.osgearth.org Thanks, Jason On Fri, Jun 12, 2009 at 5:08 AM, wrote: > Hi All, > > Has anyone come across a scenario where they wished to have PagedLOD that > instead of handling Nodes, handle images ? > > Essentially I find myself in a position where I have a model that > references a texture, but that texture is quite large, and even with > reducing the texture size with little compromise in quality, the time to > stream over the web is too large. So, what I'm considering is replacing the > image load call, with a similar concept to that of PagedLOD's whereby I > could give the "PagedImageLOD" object a list of ordered image file names > that I want it to progressively load - in much the same way that apps like > google map appears to work. The first image file could be a 2x2 pixel image, > whilst the nth image file would be the full-on image. I would want the > "PagedImageLOD" to return a valid Image node immediately - perhaps a hard > coded small default image - whilst in the background the specified image > filesnames are being downloaded, and replace the content of the created > image node. > > The reason for this sort of functionality would be that I could then > intercept all image load requests via my own callback handler, replace with > a PagedImageLOD request, and still permit most plugins to work happily on > the assumption that a model plugin that loads an image is probably only > trying to reference that image in some stateset context. > > Sorry for the thought dump, but has anyone tried/needed to do a similar > thing, and if so is there an example available ? > > Alternatively, if you can think of a better way that would be good as well. > Most obvious alternative - that of have an LOD node on the model - would be > fine if I only had one or two models. However, I have thousands of different > models, so can't really ask our modellers to redo all these. > > Many thanks for any help/thoughts. > > Kind regards > > Neil. > > > > > .to whose content was progressively replaced by the downloaded images. In > this way I could > ___ > 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] Image file PagedLOD...
Thanks Jason, I'll take a look later today. Jason Beverage wrote: > Hi Neil, > > The osgEarth project does essentially what you are looking for. Check it > out at http://www.osgearth.org > > Thanks, > > Jason > > On Fri, Jun 12, 2009 at 5:08 AM, wrote: > > > Hi All, > > > > Has anyone come across a scenario where they wished to have PagedLOD that > > instead of handling Nodes, handle images ? > > > > Essentially I find myself in a position where I have a model that > > references a texture, but that texture is quite large, and even with > > reducing the texture size with little compromise in quality, the time to > > stream over the web is too large. So, what I'm considering is replacing the > > image load call, with a similar concept to that of PagedLOD's whereby I > > could give the "PagedImageLOD" object a list of ordered image file names > > that I want it to progressively load - in much the same way that apps like > > google map appears to work. The first image file could be a 2x2 pixel image, > > whilst the nth image file would be the full-on image. I would want the > > "PagedImageLOD" to return a valid Image node immediately - perhaps a hard > > coded small default image - whilst in the background the specified image > > filesnames are being downloaded, and replace the content of the created > > image node. > > > > The reason for this sort of functionality would be that I could then > > intercept all image load requests via my own callback handler, replace with > > a PagedImageLOD request, and still permit most plugins to work happily on > > the assumption that a model plugin that loads an image is probably only > > trying to reference that image in some stateset context. > > > > Sorry for the thought dump, but has anyone tried/needed to do a similar > > thing, and if so is there an example available ? > > > > Alternatively, if you can think of a better way that would be good as well. > > Most obvious alternative - that of have an LOD node on the model - would be > > fine if I only had one or two models. However, I have thousands of different > > models, so can't really ask our modellers to redo all these. > > > > Many thanks for any help/thoughts. > > > > Kind regards > > > > Neil. > > > > > > > > > > .to whose content was progressively replaced by the downloaded images. In > > this way I could > > ___ > > 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] Some Fixes
Hi Robert, There is some fixes this is not critic, only for appearance ; osgpointsprites : there is needless inclusions #include #include #include osgautocapture: "Rendring time = " should be "Rendering time = " Regards. -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] COLLADA Blender reading problem
Marco Cosentino wrote:
Marco Cosentino wrote:
Quote: � Select � � Expand �
Quote: � Select � � Expand �
Hi,
I have a problem (maybe a bug?) in loading a .dae file made with Blender collada exporter.
I'm writing a robot simulation software that uses collada to load both 3d and physics.
The error I get is an exception :
"Unhandled exception at 0x0049fb10 (msvcr80d.dll) in RobotSimulator.exe: 0xC005: Access violation reading location 0x."
This occours when I try to load the collada file. Here is the code I wrote:
Code:
bool VisualModel::CreateFromColladaFileAndFillDAE(std::string & filename,DAE *dae)
{
osg::ref_ptr rwoptions(new osgDB::ReaderWriter::Options());
rwoptions->setPluginData("DAE",dae);
modelnode = osgDB::readNodeFile(filename,rwoptions);
if(!modelnode) return false;
return true;
}
Here is the stack trace:
Code:
Quote: � Select �
msvcr80d.dll!strlen(unsigned char * buf=0x0012e760) Line 81 Asm
msvcp80d.dll!std::char_traits::length(const char * _First=0x) Line 559 + 0x9 bytes C++
msvcp80d.dll!std::basic_string,std::allocator >::assign(const char * _Ptr=0x) Line 1042 + 0x9 bytes C++
msvcp80d.dll!std::basic_string,std::allocator >::operator=(const char * _Ptr=0x) Line 893 C++
osg55-osgd.dll!osg::Object::setName(const char * name=0x) Line 102 + 0x21 bytes C++
osgdb_daed.dll!osgdae::daeReader::processSinglePPrimitive(osg::Geode * geode=0x05c08620, domTriangles * group=0x05c1cbe8, std::map,std::allocator > > & sources=[2](...,...), unsigned int mode=4) Line 243 + 0x14 bytes C++
osgdb_daed.dll!osgdae::daeReader::processGeometry(domGeometry * geo=0x05c1a3e8) Line 219 C++
osgdb_daed.dll!osgdae::daeReader::processInstanceGeometry(domInstance_geometry * ig=0x05c1ee98) Line 47 + 0xc bytes C++
osgdb_daed.dll!osgdae::daeReader::processNode(domNode * node=0x05c1e310) Line 366 + 0x22 bytes C++
osgdb_daed.dll!osgdae::daeReader::processVisualScene(domVisual_scene * scene=0x05c1dd58) Line 156 + 0x23 bytes C++
osgdb_daed.dll!osgdae::daeReader::convert(const std::basic_string,std::allocator > & fileURI="./simpleworld.dae") Line 123 + 0xc bytes C++
osgdb_daed.dll!ReaderWriterDAE::readNode(const std::basic_string,std::allocator > & fname=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 65 + 0x12 bytes C++
osg55-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter & rw={...}) Line 1399 + 0x40 bytes C++
osg55-osgDBd.dll!osgDB::Registry::read(const osgDB::Registry::ReadFunctor & readFunctor={...}) Line 1537 + 0x22 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readImplementation(const osgDB::Registry::ReadFunctor & readFunctor={...}, bool useObjectCache=false) Line 1645 + 0x13 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readNodeImplementation(const std::basic_string,std::allocator > & fileName=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 1850 + 0x57 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readNode(const std::basic_string,std::allocator > & fileName=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100, bool buildKdTreeIfRequired=true) Line 237 + 0x98 bytes C++
osg55-osgDBd.dll!osgDB::readNodeFile(const std::basic_string,std::allocator > & filename=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 69 + 0x1f bytes C++
RobotSimulator.exe!RobotSimulator::VisualModel::CreateFromColladaFileAndFillDAE(std::basic_string,std::allocator > & filename=".simpleworld.dae", DAE * dae=0x0012f958) Line 10 + 0x15 bytes C++
RobotSimulator.exe!RobotSimulator::Simulable::LoadModel(RobotSimulator::Model model={...}) Line 21 + 0x16 bytes C++
RobotSimulator.exe!RobotSimulator::Simulator::LoadSimulation(const char * pfilename=0x05b4d9c1) Line 93 + 0x28 bytes C++
RobotSimulator.exe!main(int argc=2, char * * argv=0x05b4d968) Line 54 + 0x20 bytes C++
RobotSimulator.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
RobotSimulator.exe!mainCRTStartup() Line 403 C
kernel32.dll!7c817077()
The collada model is made by Blender 2.48a using the default startup scene with the cube with assigned a green material and esported with Triangles option and DisablePhisics option (for testing). You can find it in attachments.
Note that with collada-dom viewer the model is loaded adn displayed correctly and with osgviewer the model is loaded witout exceptions but nothing is displayed into the scene.
I think the problem is related to the call (you can see in the stack trace)
osg55-osgd.dll!osg::Object::setName(const char * name=0x)� Line 102 + 0x21 bytes
Can you tell me why this appens and how to correct ?
Thank you!!
Bye :D
The safety check on the material name not being NULL seems to have disappeared at SVN revision 9228.
Roger
Hi Roger,
thank you for your reply.
Could you tell me how to avoid this problem? Should I re-insert the check in the source ?
Marco,
I would give it a try. As far as I can see it was only being used for
debug
Re: [osg-users] Image file PagedLOD...
I have a similar problem, some models with too heavvy texture to put on the web... The models were not so many so , for the ones with little geometry I just used a chain of PagedLOD with the same geometry but with texture of incresing resolution. I did the conversion by hand but I' m currently trying to do it in an automatic way. This approach has the problem of replicating geometry. I have also tried to putt al the geometry into ProxyNodes and then refernce them in the PageLOD structure... but this seem result in multiple loading of the same proxy... I thought all files were cached, as images do... Your approach seem interesting, but how you decide when the ImagePagedLOD switch? the PagedLOD inherit the switching from LOD Sorry for the long post.. but it is an interesting argument for me now... Thanks Luigi neil.hug...@tesco.net ha scritto: Hi All, Has anyone come across a scenario where they wished to have PagedLOD that instead of handling Nodes, handle images ? Essentially I find myself in a position where I have a model that references a texture, but that texture is quite large, and even with reducing the texture size with little compromise in quality, the time to stream over the web is too large. So, what I'm considering is replacing the image load call, with a similar concept to that of PagedLOD's whereby I could give the "PagedImageLOD" object a list of ordered image file names that I want it to progressively load - in much the same way that apps like google map appears to work. The first image file could be a 2x2 pixel image, whilst the nth image file would be the full-on image. I would want the "PagedImageLOD" to return a valid Image node immediately - perhaps a hard coded small default image - whilst in the background the specified image filesnames are being downloaded, and replace the content of the created image node. The reason for this sort of functionality would be that I could then intercept all image load requests via my own callback handler, replace with a PagedImageLOD request, and still permit most plugins to work happily on the assumption that a model plugin that loads an image is probably only trying to reference that image in some stateset context. Sorry for the thought dump, but has anyone tried/needed to do a similar thing, and if so is there an example available ? Alternatively, if you can think of a better way that would be good as well. Most obvious alternative - that of have an LOD node on the model - would be fine if I only had one or two models. However, I have thousands of different models, so can't really ask our modellers to redo all these. Many thanks for any help/thoughts. Kind regards Neil. .to whose content was progressively replaced by the downloaded images. In this way I could ___ 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] Intersections with Particle Effects
Hi Bill, > From: Sause, William > I am trying to do intersections with particle effects, however I am > not getting any hits returned since Particle system does not have > intersection support. Robert suggested implementing the > Drawable::accept(PrimtiveFunctor) method in > osgParticle::ParticleSystem. For reference, I looked at the > implementations of this method in Geometry and ShapeDrawable, but they > were quite different from each other and a little confusing. Can > anyone shed some light on this? Did you ever find a good solution for this? I need to be able to pick Particle Systems / Effects as well, and there seems to be 3 different routes for accomplishing this: 1) Implementing the Drawable::accept(PrimtiveFunctor) method in osgParticle::ParticleSystem as suggested above. 2) Add intersection support in ParticleSystem based on its defaultBoundingBox. 3) Adding custom geometry that is always culled, but can be used for intersection testing (Ref: the recent "picking and custom active area" thread) Any thoughts on what's the best approach? Best regards, John -- This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Plugin extension registry
Hi Robert -- Correct me if I'm wrong, but right now OSG doesn't support multiple different file formats that just happen to share the same extension. For example, if three different developers came up with three plugins to load certain information, and all just happened to use extension "abc" for their file names, then the standard OSG interface for loading files wouldn't be able to gracefully support all three file formats. The app would need to explicitly load the plugins for each format, and then things should work well. Is my understanding correct? I'm creating some new plugins and would like to "reserve" the extension to avoid any conflicts with other development. In particular, the extensions I intend to use are: .osgb .skeleton .skel Seems like we need some kind of extension registry; the downside of this is that it is only useful if people use it. Alternatively, I wonder how much effort it would be to enhance the osgDB so that it can handle different file formats that share the same extension? PolyTrans, for example, identifies a plugin through not only the extension, but also a descriptive string that it queries from the DLL after load. Another way to do this would be to modify osgDB so that if the read fails with an error in reading file, the osgDB goes and searches for another plugin to support the extension. Thoughts? -- Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin extension registry
Hi Paul, The extension is only used by osgDB::Registry when no pre-existing plugin is able to load that file format as it uses the "Chain of Responsibility" Design Pattern with the plugins. The mechanism basically calls each registered (already loaded in memory) plugin with all read/write calls, leaving it up to the plugins whether they can handle it or not. This enables a single plugin to handle multiple file formats, or potentially as in your case multiple file formats with the same extension - all you require in this case is for the plugins to properly check the file type. Only if no plugins can handle the read/file attempt does th Registry then attempt to load a new plugin from disk based on the extension name. In your case you'd preload the Polytrans based plugin and let it handle all the file types it can. Robert. On Fri, Jun 12, 2009 at 5:54 PM, Paul Martz wrote: > Hi Robert -- > > Correct me if I'm wrong, but right now OSG doesn't support multiple > different file formats that just happen to share the same extension. For > example, if three different developers came up with three plugins to load > certain information, and all just happened to use extension "abc" for their > file names, then the standard OSG interface for loading files wouldn't be > able to gracefully support all three file formats. The app would need to > explicitly load the plugins for each format, and then things should work > well. Is my understanding correct? > > I'm creating some new plugins and would like to "reserve" the extension to > avoid any conflicts with other development. In particular, the extensions I > intend to use are: > .osgb > .skeleton > .skel > > Seems like we need some kind of extension registry; the downside of this is > that it is only useful if people use it. > > Alternatively, I wonder how much effort it would be to enhance the osgDB so > that it can handle different file formats that share the same extension? > PolyTrans, for example, identifies a plugin through not only the extension, > but also a descriptive string that it queries from the DLL after load. > > Another way to do this would be to modify osgDB so that if the read fails > with an error in reading file, the osgDB goes and searches for another > plugin to support the extension. > > Thoughts? > -- > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > ___ > 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] Cursor problem under Windows
I have an update, using :
osgViewer::ViewerBase::Windowswindows;
viewer.getWindows(windows);
for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr !=
windows.end(); ++itr)
{
//(*itr)->useCursor(false);
(*itr)->setCursor(osgViewer::GraphicsWindow::MouseCursor::NoCursor);
}
Instead of setting useCursor(false) works, the cursor is invisible.
On Fri, Jun 12, 2009 at 12:23 PM, Serge Lages wrote:
> Hi all,
>
> Currently (the SVN version of OSG), hidding the cursor under Windows has no
> effect. Setting cursor to false on the traits or making something like :
>
> osgViewer::ViewerBase::Windowswindows;
>
> viewer.getWindows(windows);
> for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr !=
> windows.end(); ++itr)
> {
>(*itr)->useCursor(false);
> }
>
> Doesn't work, I always see the cursor...
> Any idea on which modification has break things ? The same code was working
> for me some weeks ago, but I can't tell which revision it was...
>
> Thanks !
>
> Best regards,
>
> --
> Serge Lages
> http://www.tharsis-software.com
>
--
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cursor problem under Windows
Hi Serge,
Good to hear you got it working, useCursor(false) should still work
though... so that is a bug. Can you say which versions of the OSG
that useCursor(false) was still working on? Have you tried out other
platforms?
Robert.
On Fri, Jun 12, 2009 at 7:22 PM, Serge Lages wrote:
> I have an update, using :
>
> osgViewer::ViewerBase::Windows windows;
>
> viewer.getWindows(windows);
> for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr !=
> windows.end(); ++itr)
> {
> //(*itr)->useCursor(false);
> (*itr)->setCursor(osgViewer::GraphicsWindow::MouseCursor::NoCursor);
> }
>
> Instead of setting useCursor(false) works, the cursor is invisible.
>
> On Fri, Jun 12, 2009 at 12:23 PM, Serge Lages wrote:
>>
>> Hi all,
>>
>> Currently (the SVN version of OSG), hidding the cursor under Windows has
>> no effect. Setting cursor to false on the traits or making something like :
>>
>> osgViewer::ViewerBase::Windows windows;
>>
>> viewer.getWindows(windows);
>> for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr
>> != windows.end(); ++itr)
>> {
>> (*itr)->useCursor(false);
>> }
>>
>> Doesn't work, I always see the cursor...
>> Any idea on which modification has break things ? The same code was
>> working for me some weeks ago, but I can't tell which revision it was...
>>
>> Thanks !
>>
>> Best regards,
>>
>> --
>> Serge Lages
>> http://www.tharsis-software.com
>
>
>
> --
> Serge Lages
> http://www.tharsis-software.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] Plugin extension registry
Only if no plugins can handle the read/file attempt does th Registry then attempt to load a new plugin from disk based on the extension name. ...and it attempts to load exactly one plugin, and if the IO operation fails, osgDB returns "failure" to the app. It does not go out looking for additional plugins to load. This is a problem if there are multiple plugins supporting multiple different formats that happen to share the same extension string. Unless the app preloads the plugins (which kind of defeats the purpose of plugins), current unmodified OSG will not support different plugins supporting different formats with the same extension. If you'd like to keep OSG as it stands, then it seems reasonable to have some kind of public "extension registry" such as a wiki page, where developers can lay claim to certain extension strings so that we avoid the situation described above. I'd like to lay claim to ".osgb", ".skel", and ".skeleton" for my own work, as it seems reasonable that someone could possibly try to make their own format with extensions like those somewhere down the road, and I want to avoid the conflict that would occur from multiple plugins supporting different formats with the same extension string. I realize this "claim" is only as good as the ether I'm writing in. :-) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cursor problem under Windows
Hi Robert,
I've only tried it on Windows, and about the version where it was working,
maybe it was 2 or 3 weeks ago, but I am really not sure, I've made a fresh
OSG compile last night from the SVN but I can't remember when I dit it the
previous time... :/
I'm really sorry to not investigate further but I don't have time currently,
I'll try to give it a look next week.
Best regards,
On Fri, Jun 12, 2009 at 8:34 PM, Robert Osfield wrote:
> Hi Serge,
>
> Good to hear you got it working, useCursor(false) should still work
> though... so that is a bug. Can you say which versions of the OSG
> that useCursor(false) was still working on? Have you tried out other
> platforms?
>
> Robert.
>
> On Fri, Jun 12, 2009 at 7:22 PM, Serge Lages wrote:
> > I have an update, using :
> >
> > osgViewer::ViewerBase::Windowswindows;
> >
> > viewer.getWindows(windows);
> > for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr
> !=
> > windows.end(); ++itr)
> > {
> > //(*itr)->useCursor(false);
> > (*itr)->setCursor(osgViewer::GraphicsWindow::MouseCursor::NoCursor);
> > }
> >
> > Instead of setting useCursor(false) works, the cursor is invisible.
> >
> > On Fri, Jun 12, 2009 at 12:23 PM, Serge Lages
> wrote:
> >>
> >> Hi all,
> >>
> >> Currently (the SVN version of OSG), hidding the cursor under Windows has
> >> no effect. Setting cursor to false on the traits or making something
> like :
> >>
> >> osgViewer::ViewerBase::Windowswindows;
> >>
> >> viewer.getWindows(windows);
> >> for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr
> >> != windows.end(); ++itr)
> >> {
> >>(*itr)->useCursor(false);
> >> }
> >>
> >> Doesn't work, I always see the cursor...
> >> Any idea on which modification has break things ? The same code was
> >> working for me some weeks ago, but I can't tell which revision it was...
> >>
> >> Thanks !
> >>
> >> Best regards,
> >>
> >> --
> >> Serge Lages
> >> http://www.tharsis-software.com
> >
> >
> >
> > --
> > Serge Lages
> > http://www.tharsis-software.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
>
--
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB compile error
Hi,
When I tried to compile the latest SVN version of
VirtualPlanetBuilder, there was the following error:
1>-- Build started: Project: vpb, Configuration: Release Win32 --
1>Compiling...
1>DataSet.cpp
1>c:\openscenegraph-vpb-svn\src\vpb\dataset.cpp(2187) : error C4716:
'vpb::DataSet::addPatchedTerrain' : must return a value
1>Build log was saved at
"file://c:\OpenSceneGraph-VPB-SVN\src\vpb\vpb.dir\Release\BuildLog.htm"
1>vpb - 1 error(s), 0 warning(s)
Based on this the following function in DataSet.cpp should be changed from:
bool DataSet::addPatchedTerrain(osgTerrain::TerrainTile*
previous_terrain, osgTerrain::TerrainTile* new_terrain)
{
addTerrain(new_terrain);
log(osg::NOTICE,"Currently ignoring patch terrainTile
%s",previous_terrain->getName().c_str());
}
To this:
bool DataSet::addPatchedTerrain(osgTerrain::TerrainTile*
previous_terrain, osgTerrain::TerrainTile* new_terrain)
{
log(osg::NOTICE,"Currently ignoring patch terrainTile
%s",previous_terrain->getName().c_str());
return addTerrain(new_terrain);
}
When I did the above, VPB compiled cleanly.
Regards,
- Anna Sokol
_
"Once we accept our limits, we go beyond them. " -- Albert Einstein
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB compile error
Hi all, Just a general comment... 'vpb::DataSet::addPatchedTerrain' : must return a value I've always been confused as to why gcc allows you to declare a function with a return value and then not have a return statement in it... This is not the first time a similar usage needed to be fixed on Windows (but compiled fine on gcc). It just seems nonsensical to me, it should be an error. Is there some logical reason why it allows this kind of thing? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] picking and custom active area
So far so good. The culling works as expected. I can now define a custom active invisible area and the picking works with it. Unfortunately it did not quite tackle my problem with dragging. The question have now: How do I manually intersect a ray with the x/y-plane of geode? The problem I have is that when I drag an object, the mouse pointer (in my case it is actually one of multiple touches) momentarily leaves it within one frame and the move handler that adjusts the new location is never called. My first approach was to increase the active area so that this does not happen but this leads to all kinds of problems and is not fully robust, conceptually speaking. Instead I would like to do the following: Objects get clicked on, I do normal picking. On mouse drag and up I do manual ray intersection with the entire x/y plane of the object that got the mouse down previously. This way the object never miss out on the drag/up. So how do I manually intersect a ray with the x/y-plane of geode? /stefanix -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=13953#13953 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] picking and custom active area
So I found some code for intersecting a line with a plane.
What I am missing is how do I translate the mouse pointer
coordinates into a line expressed in local coordinates?
Here the intersection code if anybody is interested:
Code:
bool getPlaneLineIntersection(const osg::Vec4d& plane,
const osg::Vec3d& lineStart, const
osg::Vec3d& lineEnd,
osg::Vec3d& isect)
{
// intersects an infinite line with an infinite plane
// in hesse normal form Ax + By + Cz + D = 0
// A,B,C is the normal vector of the plane, D the distance to the
origin
const double deltaX = lineEnd.x() - lineStart.x();
const double deltaY = lineEnd.y() - lineStart.y();
const double deltaZ = lineEnd.z() - lineStart.z();
const double denominator = (plane[0]*deltaX + plane[1]*deltaY +
plane[2]*deltaZ);
if (! denominator) return false;
const double C = (plane[0]*lineStart.x() + plane[1]*lineStart.y() +
plane[2]*lineStart.z() + plane[3]) / denominator;
isect.x() = lineStart.x() - deltaX * C;
isect.y() = lineStart.y() - deltaY * C;
isect.z() = lineStart.z() - deltaZ * C;
return true;
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=13954#13954
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cursor problem under Windows
Hi Robert & Serge,
Here is the offending line:
void GraphicsWindowWin32::setCursorImpl( MouseCursor mouseCursor )
{
if (_mouseCursor != mouseCursor)
{
_mouseCursor = mouseCursor;
HCURSOR newCursor = getOrCreateCursor( mouseCursor);
if (newCursor == _currentCursor) return;
_currentCursor = newCursor;
_traits->useCursor = (_currentCursor != NULL); // Problem:
Changing useCursor when setCursorImpl is called
if (_mouseCursor != InheritCursor)
::SetCursor(_currentCursor);
}
}
It looks like this line isn't really necessary, but if it is desired to
change the useCursor mode when a cursor is set, it should be done in
setCursor, and not setCursorImpl.
void GraphicsWindowWin32::setCursor( MouseCursor mouseCursor )
{
_appMouseCursor = mouseCursor;
setCursorImpl(mouseCursor);
_traits->useCursor = (_currentCursor != NULL); // Line belongs
here instead (if this behavior is desired).
}
From a design perspective, I think useCursor and setCursor methods
should be orthogonal. Changing a cursor should not affect the useCursor
state of the window. Orthogonal designs tend to be more flexible. So if
it were up to me, I would simply delete the line with the result of a
slight change in semantics of the setCursor function.
Serge, try moving the indicated line to the indicated function. If that
doesn't work, delete it entirely. Some other code may be calling
setCursor behind your back and turning it back on.
Regards,
Mark
Robert Osfield wrote:
Hi Serge,
Good to hear you got it working, useCursor(false) should still work
though... so that is a bug. Can you say which versions of the OSG
that useCursor(false) was still working on? Have you tried out other
platforms?
Robert.
On Fri, Jun 12, 2009 at 7:22 PM, Serge Lages wrote:
I have an update, using :
osgViewer::ViewerBase::Windowswindows;
viewer.getWindows(windows);
for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr !=
windows.end(); ++itr)
{
//(*itr)->useCursor(false);
(*itr)->setCursor(osgViewer::GraphicsWindow::MouseCursor::NoCursor);
}
Instead of setting useCursor(false) works, the cursor is invisible.
On Fri, Jun 12, 2009 at 12:23 PM, Serge Lages wrote:
Hi all,
Currently (the SVN version of OSG), hidding the cursor under Windows has
no effect. Setting cursor to false on the traits or making something like :
osgViewer::ViewerBase::Windowswindows;
viewer.getWindows(windows);
for (osgViewer::ViewerBase::Windows::iterator itr = windows.begin(); itr
!= windows.end(); ++itr)
{
(*itr)->useCursor(false);
}
Doesn't work, I always see the cursor...
Any idea on which modification has break things ? The same code was
working for me some weeks ago, but I can't tell which revision it was...
Thanks !
Best regards,
--
Serge Lages
http://www.tharsis-software.com
--
Serge Lages
http://www.tharsis-software.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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
