[osg-users] Problems with OSG 3.2.0 (ok with 3.0.1)
Hi all, I switched to OSG 3.2.0 from 3.0.1 version. I am experiencing a visualization problem (no problems with 3.0.1 with the same sources). Please see attached images. Red triangles should be the interior of the model and they should be not visible and the grid should be on the back of the model. May be I missed something. I also have a problem on STL ASCII import (for binary import I use my own routine). I got a vector subscript out of range assertion on readNode (during a stripify). Is it correct to use a stripify with the new fast path of OSG 3.2.0? This is the call stack: msvcp100d.dll!std::_Debug_message(const wchar_t * message, const wchar_t * file, unsigned int line) Riga 15C++ osgdb_stld.dll!std::vectorosg::Vec3f,std::allocatorosg::Vec3f ::operator[](unsigned int _Pos) Riga 916 + 0x17 byte C++ osgdb_stld.dll!osg::MixinVectorosg::Vec3f::operator[](unsigned int index) Riga 107 + 0x1d byte C++ osgdb_stld.dll!osg::TemplateArrayosg::Vec3f,28,3,5126::compare(unsigned int lhs, unsigned int rhs) Riga 272 + 0xf byte C++ osg100-osgUtild.dll!VertexAttribComparitor::operator()(unsigned int lhs, unsigned int rhs) Riga 102 + 0x24 byteC++ osg100-osgUtild.dll!std::_Debug_lt_predVertexAttribComparitor,unsigned int,unsigned int(VertexAttribComparitor _Pred, unsigned int _Left, unsigned int _Right, const wchar_t * _File, unsigned int _Line) Riga 674 + 0x14 byte C++ osg100-osgUtild.dll!std::_Unguarded_partitionunsigned int *,VertexAttribComparitor(unsigned int * _First, unsigned int * _Last, VertexAttribComparitor _Pred) Riga 3733 + 0x2b byte C++ osg100-osgUtild.dll!std::_Sortunsigned int *,int,VertexAttribComparitor(unsigned int * _First, unsigned int * _Last, int _Ideal, VertexAttribComparitor _Pred) Riga 3776 + 0x25 byte C++ osg100-osgUtild.dll!std::sortstd::_Vector_iteratorstd::_Vector_valunsigned int,std::allocatorunsigned int ,VertexAttribComparitor(std::_Vector_iteratorstd::_Vector_valunsigned int,std::allocatorunsigned int _First, std::_Vector_iteratorstd::_Vector_valunsigned int,std::allocatorunsigned int _Last, VertexAttribComparitor _Pred) Riga 3806 + 0x7a byteC++ osg100-osgUtild.dll!osgUtil::TriStripVisitor::stripify(osg::Geometry geom) Riga 271 + 0x77 byte C++ osgdb_stld.dll!ReaderWriterSTL::ReaderObject::asGeometry() Riga 134 + 0x17 byteC++ osgdb_stld.dll!ReaderWriterSTL::readNode(const std::basic_stringchar,std::char_traitschar,std::allocatorchar file, const osgDB::Options * options) Riga 437 + 0x19 byte C++ osg100-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter rw) Riga 937 + 0x40 byte C++ osg100-osgDBd.dll!osgDB::Registry::read(const osgDB::Registry::ReadFunctor readFunctor) Riga 1175 + 0x22 byteC++ osg100-osgDBd.dll!osgDB::Registry::readImplementation(const osgDB::Registry::ReadFunctor readFunctor, osgDB::Options::CacheHintOptions cacheHint) Riga 1266 + 0x13 byte C++ osg100-osgDBd.dll!osgDB::Registry::readNodeImplementation(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileName, const osgDB::Options * options) Riga 1468 + 0x32 byte C++ osg100-osgDBd.dll!osgDB::Registry::readNode(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileName, const osgDB::Options * options, bool buildKdTreeIfRequired) Riga 238 + 0x17 byteC++ osg100-osgDBd.dll!osgDB::readNodeFile(const std::basic_stringchar,std::char_traitschar,std::allocatorchar filename, const osgDB::Options * options) Riga 69 + 0x1f byte C++ Thanks Ale -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55994#55994 Attachments: http://forum.openscenegraph.org//files/osg_320_problem_3_353.png http://forum.openscenegraph.org//files/osg_320_problem_2_126.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] 3ds-plugin is not built on android by default
Hi Deniz and Raphael, In my opinion it is worth to use the osg binary native format in mobile applications, as it should reduce the weight of the model file, and it does not have application specific features. In our applications we convert first all the models to the native format using osgconv. Cheers. 2013/8/26 deniz diktas denizdik...@gmail.com Hi Raphael, Thanks for your quick reply, it worked as you said :) However, there is a slight compile problem with converting some variables when compiling osg3.0.1, but I think I fixed that. cheers, deniz raphael wrote: Hi deniz, You can comment line 171 and line 173 of src/osgPlugins/CMakeLists.txt (conditional on Android). I recently compiled this plugin for Android and get no error at compilation (not sure why this plugin has been turned off for Android). ... Cheers, Raphael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55988#55988 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi Torres ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] 3ds-plugin is not built on android by default
Hi Jordi, ok thanks for the advice. But how about the repeating textures in different models? I think they will be repeated for every model's ive-file even if they are shared and may take up too much space depending on the application. I also need to be able to accept any file given by the user, so not all of the assets are under my control so to speak. By the way, do you guys have any idea about how to make go away the osg-noficiations when using opengl-es 2.0? I see many warnings which I think are related to the properties of the old fixed pipeline (like lighting on/off) I thought when osg is built for the core profile / opengl-es 2.0, it deals deal with these kind of things automatically and appearently it does not. I have been able to remove a large number of features by modifying the osg-files by hand, but it is a time-consuming processs and I have not been able to remove all of them. But strange enough, this does not cause any visual problems as long as I use my own shaders but the notifications are still there and they may take up signifant amount of time while trying to set up properties which are not available in the new core profile anyway (and these notifications are being sent during every frame). I have disabled them using osg::setNotifyLevel() but I do not think this is a safe approach because I want to be able to log the osg-output while the user uses the app and it should not bloat the whole log-file due to an error that can be avoided. Is there a visitor or utility to remove all or a subset of the properties related to the old-fixed pipeline functionality? Jordi Torres wrote: Hi Deniz and Raphael, In my opinion it is worth to use the osg binary native format in mobile applications, as it should reduce the weight of the model file, and it does not have application specific features. In our applications we convert first all the models to the native format using osgconv. Cheers, Deniz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55996#55996 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] 3ds-plugin is not built on android by default
Hi Deniz, 2013/8/27 deniz diktas denizdik...@gmail.com Hi Jordi, ok thanks for the advice. But how about the repeating textures in different models? I think they will be repeated for every model's ive-file even if they are shared and may take up too much space depending on the application. I also need to be able to accept any file given by the user, so not all of the assets are under my control so to speak. I was referring to osgb not to ive. But if you must to accept any given file this is out of discussion :). By the way, do you guys have any idea about how to make go away the osg-noficiations when using opengl-es 2.0? I see many warnings which I think are related to the properties of the old fixed pipeline (like lighting on/off) I thought when osg is built for the core profile / opengl-es 2.0, it deals deal with these kind of things automatically and appearently it does not. I have been able to remove a large number of features by modifying the osg-files by hand, but it is a time-consuming processs and I have not been able to remove all of them. But strange enough, this does not cause any visual problems as long as I use my own shaders but the notifications are still there and they may take up signifant amount of time while trying to set up properties which are not available in the new core profile anyway (and these notifications are being sent during every frame). I have disabled them using osg::setNotifyLevel() but I do not think this is a safe approach because I want to be able to log the osg-output while the user uses the app and it should not bloat the whole log-file due to an error that can be avoided. Is there a visitor or utility to remove all or a subset of the properties related to the old-fixed pipeline functionality? As far as I know there isn't such a visitor. Possibily you can hack the 3ds plugin to do what you want, or of course write a visitor to avoid the modification of model files by hand. Maybe others can give you a better approach to this problem. By the way, OSG-3.2 comes with important changes to Geometry now displayLists are deprecated, I think there is a fallback to convert models using displayLists to vertexArrays, perhaps it could serve as inspiration. Cheers. Jordi Torres wrote: Hi Deniz and Raphael, In my opinion it is worth to use the osg binary native format in mobile applications, as it should reduce the weight of the model file, and it does not have application specific features. In our applications we convert first all the models to the native format using osgconv. Cheers, Deniz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55996#55996 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi Torres ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [ANN] Blog and github repository with OpenSceneGraph Examples
Hello dear OSG-community, I want to present you my new blog Advanced 3D Computer Graphic Tutorials (http://3dcgtutorials.blogspot.de/). It could be interesting to some of you. Among other topics, there will be some tutorials for OpenSceneGraph. The tutorials are not meant as an introduction to OpenSceneGraph. Instead they will cover some more advanced rendering techniques. My first tutorial is about implementing Instancing with OpenSceneGraph. My demo goes a bit more into detail, than the osg example for hardware instancing(especially different approaches to store per instance data are shown). I hope my tutorials will be of some use for you. Suggestions for improvement are very welcome. Best regards, Marcel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56000#56000 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] regular osg-models result in notifications with osg built for opengl-3.x / opengl-es-2.0 support
On 26.8.2013 22:32, deniz diktas wrote: Is there a method or utility (maybe some visitor) inside osg that can modify the models so that the rendered model is consistent with opengl-3.x and opengl-es2.0 features, and that these notifications are disabled? Hi Deniz, The short answer is: To my best knowledge, and i might be wrong, osg doesn't provide utility or visitor that can remove fixed pipeline state attributes from the graph or visitor that is able to output core opengl or ES2.0 compatible shaders to be used as a replacement for the fixed pipeline state attributes. Anyway, you might want to have a look at the osgshadergen example to see how to do it with osgUtils:ShaderGenVisitor but I believe it won't produce opengl 3 core or ES 2 compatible shaders. You can of course modify ShaderGenVisitor source... Also, there is osg::ShaderComposer you might want to have a look at, designed to solve problems like one you are describing. The idea here is to attach shader componet to any? fixed pipeline state attribute and then let osg automatically compose final shader program for you. The bad news here is that shader composer isn't finished yet, I believe. Of course, you can have a look at the osgshadercomposition example ... Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] Blog and github repository with OpenSceneGraph Examples
Nice! Thanks. 2013/8/27 Marcel Pursche marcel.purs...@student.hpi.uni-potsdam.de Hello dear OSG-community, I want to present you my new blog Advanced 3D Computer Graphic Tutorials ( http://3dcgtutorials.blogspot.de/). It could be interesting to some of you. Among other topics, there will be some tutorials for OpenSceneGraph. The tutorials are not meant as an introduction to OpenSceneGraph. Instead they will cover some more advanced rendering techniques. My first tutorial is about implementing Instancing with OpenSceneGraph. My demo goes a bit more into detail, than the osg example for hardware instancing(especially different approaches to store per instance data are shown). I hope my tutorials will be of some use for you. Suggestions for improvement are very welcome. Best regards, Marcel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56000#56000 ___ 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] regular osg-models result in notifications with osg built for opengl-3.x / opengl-es-2.0 support
Hi Robert, Thanks for the detailed answer. I will go ahead with ShaderGenVisitor and take it from there. Best, Deniz rmilh wrote: On 26.8.2013 22:32, deniz diktas wrote: Is there a method or utility (maybe some visitor) inside osg that can modify the models so that the rendered model is consistent with opengl-3.x and opengl-es2.0 features, and that these notifications are disabled? Hi Deniz, The short answer is: To my best knowledge, and i might be wrong, osg doesn't provide utility or visitor that can remove fixed pipeline state attributes from the graph or visitor that is able to output core opengl or ES2.0 compatible shaders to be used as a replacement for the fixed pipeline state attributes. Anyway, you might want to have a look at the osgshadergen example to see how to do it with osgUtils:ShaderGenVisitor but I believe it won't produce opengl 3 core or ES 2 compatible shaders. You can of course modify ShaderGenVisitor source... Also, there is osg::ShaderComposer you might want to have a look at, designed to solve problems like one you are describing. The idea here is to attach shader componet to any? fixed pipeline state attribute and then let osg automatically compose final shader program for you. The bad news here is that shader composer isn't finished yet, I believe. Of course, you can have a look at the osgshadercomposition example ... Robert Milharcic ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56003#56003 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
