Re: [osg-users] Shadows on two-sided polygons
Hi Wojtek, thanks a lot for your detailed answer. I will work through the example within one of the next holydays, as I am not a professional programmer (I´m a math teacher) and will need some quiet time for a demanding task like this. My software is a math-software to illustrate vector geometry, and thus displays planes and so on simply as polygons. That´s the reason I need two-sided materials (or at least I decided to do so, the alternative would have been to use more massive planes). For the time being it is a comfort for me that I didn´t make a simple mistake and that it is quite some work to adjust the StandardShadowMap to two-sided polygons. Who maintains ShadowMap? I´d like the maintainer to do some tests with my shader. If you think it´s better than the standard one, I´ll refactor it into the Shadow-Map code. For a first impression, see the images in the last mail. Regards thanks for the example, Andreas Wojciech Lewandowski schrieb: Hi Andreas, If you want to use dual sided materials I believe you will have to review and probably modify the shaders in StandardShadowMap.cpp. I am certain Vertex shader computes ligthing using front lighting and assigns the same colors to backfacing polygons. Another issue would be usage of back faces for shadow map rendering. I guess if you want to use dual face materials you will need to override this. So many people have so many varying requests for shadows that my recomendation for them would be to create their own ShadowTechnique class based on one of LispSM or MinimalShadowMap or even StandardShadowMap. But comparing results, this last one does not really differ that much from ShadowMap which is much easier to override. When overriding any of above classes its important to override inner ViewData class which provides View related resources storage and management. By overriding ViewData::init method you get access to all statesets used by base classes and you can easily override all state attributes. I have prepared an example class (MyViewDependentShadowMap) which shows how to override any of classes stemming from ViewDepenedentShadowTechnique. This class illustrate how to add soft shadows to MinimalDrawBoundsShadowMap class (should be appropriate for you). Have a look at it and modify to your needs. HTH, Wojtek Lewandowski -- From: Andreas Goebel a-goe...@gmx.de Sent: Saturday, November 21, 2009 1:57 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Shadows on two-sided polygons Hi Jean-Sébastien, I have turned off those things, and now it works good for me. Should I refactor that in a way that the application programmer can choose the behaviour and submit that? You could, but I think setting those things via overridden state is also acceptable, since if you need that you'll probably know what to set... You mean by setting the StateAttribute CullFaces to off and override for my shadowed scene? This would probably work (even though it is set with override in the ShadowMap? Which will override which?), but not for the polygon-offset, as this is not controlled with state. I mean this line: // negative polygonoffset - move the backface nearer to the eye point so that backfaces // shadow themselves float factor = _polyOffset[0]; float units = _polyOffset[1]; Another thing: I have written a vertex and a fragment shader that work together in a way that allows the shadows to be rendered exactly in the ambient color. This means that shadowed surfaces look the same as surfaces that face away from the light. This gives a much more natural feeling, and you don´t get false shadows on the backs of polygons. I needed the vertex shader to get the correct ambient color, I think it is not possible to do this with a fragment shader alone. I assume you're talking about osgShadow::ShadowMap? The shaders used for the ViewDependentShadow classes (LightSpacePerspectiveShadowMapDB, CB, VB) already do this. Note that osgShadow::StandardShadowMap is the equivalent of osgShadow::ShadowMap but under the ViewDependentShadow architecture, so you could have used that and you would have gotten the right shadow ambient color. It´s great to hear that, I haven´t used the new classes yet, as they are not (at least in 2.8.2) part of the shadow-Example and I could not easily play with them. However, I have made an option in my program to use the StandardShadowMap, and it does not work for me (yet). Here are the problems: - the side facing away from a light is not dark, example: http://raumgeometrie.de/NeueBilder/testbilder/IncorrectBack.png - the backside of a shadowed plane shows the shadow, too: http://raumgeometrie.de/NeueBilder/testbilder/IncorrectShadowOnBack.png The correct images (with my shaders) look like this: http://raumgeometrie.de/NeueBilder/testbilder/CorrectBack.png And
Re: [osg-users] Deploy OSG application
Dominic Stalder schrieb: Hi Stephan here the answer of my workmate: I tried this without luck. After compiling the Frameworks and using them in my application, I get the following linking errors when building with Xcode: Undefined symbols: non-virtual thunk to osgViewer::Viewer::~Viewer() osgDB::readImageFile(std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB::Options const*) osgText::readFontFile(std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB::Options const*) osgViewer::Viewer::checkNeedToDoFrame() non-virtual thunk to osgViewer::Viewer::setStartTick(unsigned long long) non-virtual thunk to osgViewer::Viewer::setSceneData(osg::Node*) Strange. Check if you are compiling against the same SDK as the frameworks are built with. You can't mix frameworks built for the 10.4 SDK with an app built for 10.5 SDK. What version of osg do you use? I am a bit perplexed, that it doesn't work for you, I am doing this all the time. Also tried that. Compiled the dylibs with cmake and installed them in /usr/local/lib. Compiling and linking against them works fine. For packaging I copied them to the application bundle (to Contents/MacOS/) and changed all paths using install_name_tool. Starting the application does not show any linking errors but the following runtime error occurs: Did you mangle all names? You'll have to mangle not only the app, but also the frameworks and the used plugins. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer windows build is broken
Hi Robert, Hi Colin, The current trunk version of GraphicsWindowWin32 (as of today) cannot be compiled under Windows, since the HGLRC createContextImplementation() method declaration is missing in the corresponding header file. After adding it the osgViewer library compiles without any problems. Regards, Oleg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Develop a scalable binary file format for native OSG scenes?
Hi Robert and all, I'd like to introduce my work of developing a new scalable binary reader/writer plugin in the past a few weeks. It took me more than half a month coding and doing some simple tests. And I really wish it be a good supplement of current native osg scene formats (.osg and .ive), or furthermore, a possible replacement of the .ive format in future? As we know before, the popular used .ive format has been not extensible from the very beginning. So core developers should always update osgdb_ive itself to add new classes and features. And user-defined nodes and objects can only be stored in a customized file format, or using the .osg plugin supporting a DotOsgWrapper mechanism instead, which is scalable. I decided to mimic this DotOsgWrapper mechanism and try to implement a binary file format (.osg is text format and seems to be hardly to work binarily). And I finally created a preliminary version. Because of the size limitation of our mail list, I have to put the source code tarball on my project site and provide the download link here: http://osgenginebook.googlecode.com/files/osgdb_bin.tar.gz Copy the extracted directory to your osgPlugins location and edit osgPlugins/CMakeLists.txt and add: ADD_SUBDIRECTORY(bin) In the ObjectWrapper header file, I have the ObjectWrapper class mimic osgDB::DotOsgWrapper, and the ObjectRegistry class which work like osgDB::Registry and maintains the wrapper map. The REGISTER_OBJECT_WRAPPER macro is used to declare a new object wrapper, which acts similar with REGISTER_DOTOSGWRAPPER. The InputStream and OutputStream class are use for read/write the OSG scene, which support different read*()/write*() methods. They also both have a shared object-id map, to avoid rereading/rewriting shared nodes and statesets. readObject()/writeObject() is the core function for reading/writing osg native subgraphs. The basic structure of this file format is: | offset |type | contents | 00h | uint | OSG verity value, low | 04h | uint | OSG verity value, high | 08h | uint | Plugin version | 0ch | uint | File attribtues | 10h | uint | Size of author information text | 14h | str | n-sized author information text |14h+n | uint | Size of root node wrapper name |18h+n | str | Root node wrapper name, e.g. osg::Group | ... | uint | node id, non-zero value for shared objects | ... | int | Size of written contents, used to vertify data | ... | ... | Attributes of this object and its parent classes. | ... | ... | ... The second step is to write wrappers for every osg core class. An example is: REGISTER_OBJECT_WRAPPER( Geode ) ( new osg::Geode, osg::Geode, osg::Object osg::Node osg::Geode, readGeode, writeGeode ); Hope you already find that there are few differences between it and the .osg wrappers. You will need to declare the proto, the wrapper's name, its associates (parent wrappers path) and reader/writer functions. Wrappers may be added to meet the extensibility requirements. To update existent wrappers, just append to the read/write functions. It should still be recognized by the old plugin, because of the vertify bits (see the format table). I also developed some initial options for writing with this plugin: - IncludeImageData: Set to save data of osg::Image objects directly. - IncludeImageFile: Set to save image files into this binary file. - UseExternalImage: Set to keep a reference of the image file name only. - WriteImageToFile: Set to write the image data on disk while saving. - AuthorInformation=... : Write author information into the binary file. The core OSG library classes are already finished and included in the wrapper_osg directory, but still not tested enough at present. These are on the TODO list right now, any advices and thoughts will be appreciated: - Decide the extension name: At present I just name it .bin, short for binary. A little naive and too common, isn't it? :D - Finish all wrappers of other core libraries, osgAnimation, osgText, osgWidgets and so on. These may be defined inside this plugin or use external dynamic libraries (like the osgwrapper_* files). - Automatically load external wrapper libraries: It would be easy to finish if we merge ObjectRegistry and osgDB::Registry and rewrite the findWrapper() function. - Packing algorithms for vectices and double values, which will be of high performance with geometries and heightfields. - Compression of the entire file, maybe zlib would still be the first choice? - COMPLETELY tests and bug fixes of the plugin, if it is ready to be merged into the osg trunk and be put into use. I'm looking forward to suggestions and testing replies, keeping my fingers crossed. :) Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does anybody know how to include OSGViewer using MFC?
Hi, There is an example called osgViewerMFC that may help you. You need to check the BUILD_MFC_EXAMPLE option in CMake. On Sat, Nov 21, 2009 at 7:28 AM, SoDong Jang wrote: I`m trying to make a very simple CAD program but, all examples aren`t based on MFC... I`ve seen the example called OSGMFC, but,, I couldn`t find an OSGViewer. As u see, I don`t know even the first thing of OSG. I want to follow sb`s achievement. BUT NO EXAMPLES.. help me... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20045#20045 ___ 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] OSG Forum image attachments
Hi Art, I don't know if you caught the thread where this was mentioned, but it appears that any image attachments sent from the forum to the list go through a fugly filter, making it really small and reducing the colour depth quite dramatically. I presume that it's done to prevent huge images being sent off in bulk around the world clogging up inboxes, but is there any chance you could tweak it so that at least the colour depth is preserved? otherwise it makes it really hard to see what's in the image... ...plus I miss all the pretty pictures :) Cheers, Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture wrapping for a geometry object
Hi there I would like to wrap (repeated) my texture image on a geometry object. I read somewhere, that this is not possible directly on the geometry, but how can I do it otherwise? Here is my code: /* * creates the ground geometry */ // creates the vertices array ref_ptrVec3Array verticesGround = new Vec3Array; verticesGround-push_back(Vec3(-WORLD_INFINITY, 0.0, -WORLD_INFINITY)); // back left verticesGround-push_back(Vec3(WORLD_INFINITY, 0.0, -WORLD_INFINITY)); // back right verticesGround-push_back(Vec3(WORLD_INFINITY, 0.0, WORLD_INFINITY)); // front right verticesGround-push_back(Vec3(-WORLD_INFINITY, 0.0, WORLD_INFINITY)); // front left // creates the normal array ref_ptrVec3Array normalsGround = new Vec3Array; normalsGround-push_back(Vec3(0.0, 1.0, 0.0)); // creates the texture coordinates array ref_ptrVec2Array texCoordGround = new Vec2Array; texCoordGround-push_back(Vec2(0.0, 0.0)); texCoordGround-push_back(Vec2(1.0, 0.0)); texCoordGround-push_back(Vec2(1.0, 1.0)); texCoordGround-push_back(Vec2(0.0, 1.0)); // loads the texture image ref_ptrImage imgGrass = osgDB::readImageFile(Utilities::filePath(res/osg/grass.png).toStdString()); // attaches the image to the texture ref_ptrTexture2D texGround = new Texture2D; texGround-setDataVariance(Object::DYNAMIC); texGround-setWrap(Texture::WRAP_S, Texture::REPEAT); texGround-setWrap(Texture::WRAP_T, Texture::REPEAT); texGround-setImage(imgGrass.get()); // releases the image after applying texGround-setUnRefImageDataAfterApply(true); // creates the geometry ref_ptrGeometry geomGround = new Geometry; geomGround-setVertexArray(verticesGround.get()); geomGround-setNormalArray(normalsGround.get()); geomGround-setTexCoordArray(0, texCoordGround.get()); // adds the primitive set to the geometry geomGround-addPrimitiveSet(new DrawArrays(PrimitiveSet::QUADS, 0, 4)); // enables all the necessary states for the ground geometry node ref_ptrStateSet stateGroundGeometry = geomGround-getOrCreateStateSet(); stateGroundGeometry-setTextureAttributeAndModes(0, texGround.get(), StateAttribute::ON); // creates the geode ref_ptrGeode geoGround = new Geode; geoGround-addDrawable(geomGround.get()); Thanks a lot in advance! Best regards Dominic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Develop a scalable binary file format for native OSG scenes?
Hi Wang, Just a little thing to say: I love your idea! I don't have time to look at it right now, but I'm sure I'll use that format later. Thanks. -- Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sun, 22 Nov 2009 12:10:21 +0100, Wang Rui wangra...@gmail.com a écrit: Hi Robert and all, I'd like to introduce my work of developing a new scalable binary reader/writer plugin in the past a few weeks. It took me more than half a month coding and doing some simple tests. And I really wish it be a good supplement of current native osg scene formats (.osg and .ive), or furthermore, a possible replacement of the .ive format in future? As we know before, the popular used .ive format has been not extensible from the very beginning. So core developers should always update osgdb_ive itself to add new classes and features. And user-defined nodes and objects can only be stored in a customized file format, or using the .osg plugin supporting a DotOsgWrapper mechanism instead, which is scalable. I decided to mimic this DotOsgWrapper mechanism and try to implement a binary file format (.osg is text format and seems to be hardly to work binarily). And I finally created a preliminary version. Because of the size limitation of our mail list, I have to put the source code tarball on my project site and provide the download link here: http://osgenginebook.googlecode.com/files/osgdb_bin.tar.gz Copy the extracted directory to your osgPlugins location and edit osgPlugins/CMakeLists.txt and add: ADD_SUBDIRECTORY(bin) In the ObjectWrapper header file, I have the ObjectWrapper class mimic osgDB::DotOsgWrapper, and the ObjectRegistry class which work like osgDB::Registry and maintains the wrapper map. The REGISTER_OBJECT_WRAPPER macro is used to declare a new object wrapper, which acts similar with REGISTER_DOTOSGWRAPPER. The InputStream and OutputStream class are use for read/write the OSG scene, which support different read*()/write*() methods. They also both have a shared object-id map, to avoid rereading/rewriting shared nodes and statesets. readObject()/writeObject() is the core function for reading/writing osg native subgraphs. The basic structure of this file format is: | offset |type | contents | 00h | uint | OSG verity value, low | 04h | uint | OSG verity value, high | 08h | uint | Plugin version | 0ch | uint | File attribtues | 10h | uint | Size of author information text | 14h | str | n-sized author information text |14h+n | uint | Size of root node wrapper name |18h+n | str | Root node wrapper name, e.g. osg::Group |...| uint | node id, non-zero value for shared objects |...| int | Size of written contents, used to vertify data |...| ...| Attributes of this object and its parent classes. |...| ...| ... The second step is to write wrappers for every osg core class. An example is: REGISTER_OBJECT_WRAPPER( Geode ) ( new osg::Geode, osg::Geode, osg::Object osg::Node osg::Geode, readGeode, writeGeode ); Hope you already find that there are few differences between it and the .osg wrappers. You will need to declare the proto, the wrapper's name, its associates (parent wrappers path) and reader/writer functions. Wrappers may be added to meet the extensibility requirements. To update existent wrappers, just append to the read/write functions. It should still be recognized by the old plugin, because of the vertify bits (see the format table). I also developed some initial options for writing with this plugin: - IncludeImageData: Set to save data of osg::Image objects directly. - IncludeImageFile: Set to save image files into this binary file. - UseExternalImage: Set to keep a reference of the image file name only. - WriteImageToFile: Set to write the image data on disk while saving. - AuthorInformation=... : Write author information into the binary file. The core OSG library classes are already finished and included in the wrapper_osg directory, but still not tested enough at present. These are on the TODO list right now, any advices and thoughts will be appreciated: - Decide the extension name: At present I just name it .bin, short for binary. A little naive and too common, isn't it? :D - Finish all wrappers of other core libraries, osgAnimation, osgText, osgWidgets and so on. These may be defined inside this plugin or use external dynamic libraries (like the osgwrapper_* files). - Automatically load external wrapper libraries: It would be easy to finish if we merge ObjectRegistry and osgDB::Registry and rewrite the findWrapper() function. - Packing algorithms for vectices and double values, which will be of high performance with geometries and heightfields. - Compression of the entire file, maybe zlib would still be the first choice? - COMPLETELY tests and bug fixes of the plugin, if it is ready to be merged into the osg trunk and be put into use. I'm looking forward to suggestions
Re: [osg-users] [build] createContextImplementation is undefined in GraphicsWindowWin32.cpp
Hi John, Could you try updating again, it could be that you just updated between check-ins. I just checked cdash.openscenegraph.org and it looks to me like the Windows build machine build OK last night so things should be OK. Robert. On Sat, Nov 21, 2009 at 10:04 PM, John Price john.pric...@gmail.com wrote: Hi, Trying to build SVN 10813 update fails because osgViewer won't compile on Windows. GraphicsWindowWin32.cpp fails because createContextImplementation is undefined. I have the entire source tree indexed, and doing a full text search finds only one reference to createContextImplementation, and that is in GraphicsWindowWin32.cpp on line 1198. Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20068#20068 ___ 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] osgViewer windows build is broken
Hi Oleg, On Sun, Nov 22, 2009 at 10:38 AM, Oleg Dedkow oded...@gmx.de wrote: The current trunk version of GraphicsWindowWin32 (as of today) cannot be compiled under Windows, since the HGLRC createContextImplementation() method declaration is missing in the corresponding header file. After adding it the osgViewer library compiles without any problems. Argg... mixing submission makes life complicated... I've just spotted the error and checked in the missing header. What I don't understand is how last nights build under Windows succeeded given this error Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture wrapping for a geometry object
Hi Dominc, I don't know where you might have got the impression that you can't set up texture repeats with geometry - you just using texture coordinates beyond the 0.0 to 1.0 range and you'll get repeats. Another way is to use a texture matrix to up the tex coords from 0.0 to 1.0 range to what you want. Robert. On Sun, Nov 22, 2009 at 3:28 PM, Dominic Stalder dominic.stal...@bluewin.ch wrote: Hi there I would like to wrap (repeated) my texture image on a geometry object. I read somewhere, that this is not possible directly on the geometry, but how can I do it otherwise? Here is my code: /* * creates the ground geometry */ // creates the vertices array ref_ptrVec3Array verticesGround = new Vec3Array; verticesGround-push_back(Vec3(-WORLD_INFINITY, 0.0, -WORLD_INFINITY)); // back left verticesGround-push_back(Vec3(WORLD_INFINITY, 0.0, -WORLD_INFINITY)); // back right verticesGround-push_back(Vec3(WORLD_INFINITY, 0.0, WORLD_INFINITY)); // front right verticesGround-push_back(Vec3(-WORLD_INFINITY, 0.0, WORLD_INFINITY)); // front left // creates the normal array ref_ptrVec3Array normalsGround = new Vec3Array; normalsGround-push_back(Vec3(0.0, 1.0, 0.0)); // creates the texture coordinates array ref_ptrVec2Array texCoordGround = new Vec2Array; texCoordGround-push_back(Vec2(0.0, 0.0)); texCoordGround-push_back(Vec2(1.0, 0.0)); texCoordGround-push_back(Vec2(1.0, 1.0)); texCoordGround-push_back(Vec2(0.0, 1.0)); // loads the texture image ref_ptrImage imgGrass = osgDB::readImageFile(Utilities::filePath(res/osg/grass.png).toStdString()); // attaches the image to the texture ref_ptrTexture2D texGround = new Texture2D; texGround-setDataVariance(Object::DYNAMIC); texGround-setWrap(Texture::WRAP_S, Texture::REPEAT); texGround-setWrap(Texture::WRAP_T, Texture::REPEAT); texGround-setImage(imgGrass.get()); // releases the image after applying texGround-setUnRefImageDataAfterApply(true); // creates the geometry ref_ptrGeometry geomGround = new Geometry; geomGround-setVertexArray(verticesGround.get()); geomGround-setNormalArray(normalsGround.get()); geomGround-setTexCoordArray(0, texCoordGround.get()); // adds the primitive set to the geometry geomGround-addPrimitiveSet(new DrawArrays(PrimitiveSet::QUADS, 0, 4)); // enables all the necessary states for the ground geometry node ref_ptrStateSet stateGroundGeometry = geomGround-getOrCreateStateSet(); stateGroundGeometry-setTextureAttributeAndModes(0, texGround.get(), StateAttribute::ON); // creates the geode ref_ptrGeode geoGround = new Geode; geoGround-addDrawable(geomGround.get()); Thanks a lot in advance! Best regards Dominic ___ 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] Develop a scalable binary file format for native OSG scenes?
Hi Wang Rui, I haven't done a review yet, so can't comment on specifics of the design/implementation. A couple of quick thoughts. I would love to replace the .osg and .ive formats with a new single native binary/ascii format. Would it be possible to do both with a single plugin? The extension .osg would be the appropriate thing for a native .osg format. An appropriate header could say which version of is represented in the file. Perhaps a .osgb could be used for a binary if needed. In VirtualPlanetBuilder I experimented with serialization of class members using a series of templated classes to bind the reading and writing of members. Perhaps something similar could be used - perhaps you already use such an approach, tomorrow I should have chance to review your code. I also do wonder about whether osgIntrospection could be used to help fill out the serialization details, or... perhaps even the reverse, have the plugin specify accessors to the class members to provide a form of introspection... and then osgIntrospection could then be deprecated... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] createContextImplementation is undefined in GraphicsWindowWin32.cpp
Hi Robert, Thank you for taking the time to reply. Your guess was correct, updating again fixed my build. Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20092#20092 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows on two-sided polygons
Hi Andreas, thanks a lot for your detailed answer. I will work through the example within one of the next holydays, as I am not a professional programmer (I´m a math teacher) and will need some quiet time for a demanding task like this. My software is a math-software to illustrate vector geometry, and thus displays planes and so on simply as polygons. That´s the reason I need two-sided materials (or at least I decided to do so, the alternative would have been to use more massive planes). For the time being it is a comfort for me that I didn´t make a simple mistake and that it is quite some work to adjust the StandardShadowMap to two-sided polygons. Well... it depends. If the only trouble is incorrect back face lighting and lack of shadows from faces in front of light, then method could be simpler: 1. You can write your own shaders. I have read you already did that for ShadowMap. Then with small modification you could try using them with StandardShadowMap. This would give you the correct lighting I guess. Warning: if you want to adapt shaders made for ShadowMap make sure you change names of uniforms to match names used by StandardShadowMap (they use different naming convention). 2. To make sure both faces cast shadows simply call setMode( GL_CULL_FACE, OFF | OVERRIDE ) on your scene root stateset. This will force usage of both faces in shadow map rendering. I hope this will let you reach the goal. But if you don't expect to use any more complex - view dependent techniques in the future then it would be easier to stay with ShadowMap. StandardShadowMap gives the same shadow precision. When one asks why there are two techniques doing the same then the answer is that StandardShadowMap lays foundation for more advanced techniques like MinimalShadowMap LispSM variants. So, if one day you decide to switch to LispSM or MinimalXXXShadowMap then migration will be definitely simpler when you make your tweaks for StandardShadowMap. Who maintains ShadowMap? I´d like the maintainer to do some tests with my shader. If you think it´s better than the standard one, I´ll refactor it into the Shadow-Map code. For a first impression, see the images in the last mail. I guess that would be Robert. If you post the fixes on submissions lists all interested may work as your testers. Regards thanks for the example, You're welcome. Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer windows build is broken
Robert Osfield schrieb: Hi Oleg, On Sun, Nov 22, 2009 at 10:38 AM, Oleg Dedkow oded...@gmx.de wrote: The current trunk version of GraphicsWindowWin32 (as of today) cannot be compiled under Windows, since the HGLRC createContextImplementation() method declaration is missing in the corresponding header file. After adding it the osgViewer library compiles without any problems. Argg... mixing submission makes life complicated... I've just spotted the error and checked in the missing header. What I don't understand is how last nights build under Windows succeeded given this error Robert. Embedded AI, another time/space continuum or just a little help of Q :-) Oleg ___ 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] Develop a scalable binary file format for native OSG scenes?
I love the idea of an extensible binary format. Good work. Robert Osfield wrote: The extension .osg would be the appropriate thing for a native .osg format. An appropriate header could say which version of is represented in the file. Perhaps a .osgb could be used for a binary if needed. I'd recommend using a new unique extension for a new format, unless someone wants to take responsibility to fix OSG's plugin mechanism so that it is more robust in the presence of different formats using the same extension. See the thread Plugin extension registry from last June for a summary of the issue. Both .osg and .osgb are presently in use (.osgb is the file format used by the osgBullet project at Google Code). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple cameras with setRenderOrder(PRE_RENDER, i)
Ross Bohner wrote: Hi, Thank you for the code snippet. Looking it over I see two differences from my implementation which have been giving me a headache. These are not necessarily related to camera render orders so it might be appropriate to send these as separate threads. First difference from your code and mine is the lack of you needing to allocate an image to the render in order to place the texture within a stateset: Consider the following OpenGL call: glTexImage2D(..., width, height, ..., NULL ); Note I'm passing in a width and height but no data. According to the OpenGL spec, this allocates an undefined texture image with dimensions width x height. This is essentially what my posted example is causing to happen when I create an osg::Texture2D with width and height, but no osg::Image data. I don't care that the texture is undefined, because my app initializes it in the first render pass. In my experience, this is required or else a seg fault occurs when the draw traversal references _texture. I am confused on how you are able to pass the texture without allocating an image inside the texture. I have included a code snippet below to fully clarify what I see occurring. Try my code; if it segfaults, let me know. :-) The second difference is your code uses non power of 2 dimensions for your texture to be rendered by your camera. Whenever I have tried to do this I have run into the error : Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) during every draw call to the geometry containing the texture Wow. GLView shows that even the old GeForce 6xxx series supports the NPOT extension. Do you have really old hardware, or perhaps you haven't updated your driver recently? Your code is incomplete so it's impossible to tell what you're doing. You have a pre-render camera with a texture attached; you also have a Geode to render a textured primitive. But I don't see how your code adds them to a scene graph. Nor do I see anything added to your pre-render camera, so as far as I can see there is nothing for it to render. Have you tried compiling and running the code I sent you? How about the osgprerender example? (osgprerender is a little complex, which is why I wrote the more concise rtt.cpp example that I posted.) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Running VPBMaster
Any suggestions here? Should I be doing something with the .source file? From: jaco...@hotmail.com To: osg-users@lists.openscenegraph.org Date: Fri, 20 Nov 2009 15:36:05 -0500 Subject: [osg-users] Running VPBMaster Alright, it looks like I've finally gotten VPBMaster-0.9.10 up and running (with OSG-2.8.0) and I attempted to feed it the input I was previously trying to feed to OSGDem with my older version of OSG. It spit a lot of text to the screen, and now seems to have hung. The last thing on the screen is scheduling task : tasks/build_subtile_L3_X3_Y3/build_subtile_L7_X63_Y63.task. I tried pressing ENTER and it didn't do anything. I've noticed that I now have a couple new files: build_master.source (0 kb) and build_master.tasks (284 kb). I've also got a new tasks directory, which has 17 files (build_root_L0_X0_Y0.task and build_subtile_L3_X0_Y0.task-build_subtile_L3_X3_Y3.task) and 16 directories (build_subtile_L3_X0_Y0-build_subtile_L3_X3_Y3, each consisting of 256 files). Do I need to do something next, or is it processing something behind the curtain, or did something go wrong since my .source file is 0 kb? Any help is appreciated! Thanks, Jake Windows 7: It works the way you want. Learn more. _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How can I get last frame time inn order to create indepent FPS aniamtions?
Hi all.
How can I get last frame time inn order to create indepent FPS aniamtions?
For instance, something like m_last_time_frame:
Code:
double angle=0;
while (!viewer.done()) {
angle=angle+0.1*m_last_time_frame;
viewer.getCamera()-setViewMatrixAsLookAt(osg::Vec3(0,-400,150),
osg::Vec3(0,0,0), osg::Vec3(0,0,1));
viewer.getCamera()-setViewMatrix(osg::Matrix::rotate(angle*DEG_TO_RAD,0,0,1)*viewer.getCamera()-getViewMatrix());
viewer.frame();
}
Thanks.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20102#20102
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Running VPBMaster
So I had VPBMaster running for over two days and it didn't seem to be doing anything so I used Ctrl+C to cancel the task and the following was output to the screen: Recieved signal 2, doing TERMINATE_RUNNING_TASKS_THEN_EXIT. MachinePool::signal(2) Machine::signal(2) Machine::cancelThreads() hostname= , threads=2 Cancel thread Cancel thread Completed Machine::cancelThreads() hostname= , threads=2 End of TaskSet: tasksPending=4113 taskCompleted=0 taskRunning=0 tasksFailed=0 Continuing with existing TaskSet. End of Run: tasksPending=4113 taskCompleted=0 taskRunning=0 tasksFailed=0 MachinePool::reportTimingStats() Machine : Task::type='' minTime=1.120172 maxTime=1.122734 averageTime=1.121453 totalComputeTime=2.242906 numTasks=2 Finished run, but did not complete 4113 tasks. Total elapsed time = 191483.915636 The total elapsed time equates to 2.2 days, which is about how long it was running before I cancelled it. Can anyone tell me what it was doing for 2.2 days, if no tasks were completed in that time? I kicked it off again and cancelled it and I had the same number of tasks created, with all of them Pending, and nothing completing. Am I missing a piece of the puzzle here. Can anyone please help me? Thanks, Jake From: jaco...@hotmail.com To: osg-users@lists.openscenegraph.org Date: Sun, 22 Nov 2009 19:02:07 -0500 Subject: Re: [osg-users] Running VPBMaster Any suggestions here? Should I be doing something with the .source file? From: jaco...@hotmail.com To: osg-users@lists.openscenegraph.org Date: Fri, 20 Nov 2009 15:36:05 -0500 Subject: [osg-users] Running VPBMaster Alright, it looks like I've finally gotten VPBMaster-0.9.10 up and running (with OSG-2.8.0) and I attempted to feed it the input I was previously trying to feed to OSGDem with my older version of OSG. It spit a lot of text to the screen, and now seems to have hung. The last thing on the screen is scheduling task : tasks/build_subtile_L3_X3_Y3/build_subtile_L7_X63_Y63.task. I tried pressing ENTER and it didn't do anything. I've noticed that I now have a couple new files: build_master.source (0 kb) and build_master.tasks (284 kb). I've also got a new tasks directory, which has 17 files (build_root_L0_X0_Y0.task and build_subtile_L3_X0_Y0.task-build_subtile_L3_X3_Y3.task) and 16 directories (build_subtile_L3_X0_Y0-build_subtile_L3_X3_Y3, each consisting of 256 files). Do I need to do something next, or is it processing something behind the curtain, or did something go wrong since my .source file is 0 kb? Any help is appreciated! Thanks, Jake Windows 7: It works the way you want. Learn more. Hotmail: Trusted email with powerful SPAM protection. Sign up now. _ Windows 7: I wanted simpler, now it's simpler. I'm a rock star. http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_myidea:112009___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Develop a scalable binary file format for native OSG scenes?
Hi Robert
A couple of quick thoughts. I would love to replace the .osg and .ive
formats with a new single native binary/ascii format. Would it be
possible to do both with a single plugin?
It's not hard to support both binary and ascii format, I think. In the
case of mine, just leave user-defined wrappers alone and modify only
the read*()/write*() functions like this:
void writeCharArray( const char* s, unsigned int size )
{
if ( _isBinary )
_out-write(s, size);
else
_out s;
}
But it won't be easy to make a friendly one. For example, cow.osg
includes these lines:
StateSet {
rendering_hint OPAQUE_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_LIGHTING ON
}
With the new plugin, which lacks enum descriptions, it may come like:
StateSet {
rendering_hint 1
renderBinMode 8
2884 0
2896 1
}
Hardly to realize it unless you are very familiar with OSG and OpenGL
(GL_CULL_FACE=0x0B44 and GL_LIGHTING=0x0B50). And it really will be a
pain if we had to modify each wrapper to comvert enums to strings.
The extension .osg would be the appropriate thing for a native .osg
format. An appropriate header could say which version of is
represented in the file. Perhaps a .osgb could be used for a binary
if needed.
As Paul said, .osgb may be already used. I suggest .oa for ascii files
and .ob for binary ones, or .osgs (osg scene) for both. Any more
ideas? :)
In VirtualPlanetBuilder I experimented with serialization of class
members using a series of templated classes to bind the reading and
writing of members. Perhaps something similar could be used - perhaps
you already use such an approach, tomorrow I should have chance to
review your code.
I just took a review of osgDB::Serializer and related classes. They
use osgDB::Output and Input for I/O operations. In fact I've leart
into these two classes before, attempting to make them work both
'asciily' and 'binarily'. But the heavy workload forces me to give up
at this stage. Maybe we could have a plan of rewriting osgDB::Output
and Input classes, and then benefit from existing Serializer? Instead
of developing a totally new series of serialization classes.
I also do wonder about whether osgIntrospection could be used to help
fill out the serialization details, or... perhaps even the reverse,
have the plugin specify accessors to the class members to provide a
form of introspection... and then osgIntrospection could then be
deprecated...
Sorry to say, I've no idea about this at present. :)
Wang Rui
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How can I get last frame time inn order to create indepent FPS aniamtions?
Hi Ricardo,
Why don't try reference time?
viewer.getFrameStamp()-getReferenceTime();
Rafa.
On Mon, Nov 23, 2009 at 1:29 AM, Ricardo Ruiz osgfo...@tevs.eu wrote:
Hi all.
How can I get last frame time inn order to create indepent FPS aniamtions?
For instance, something like m_last_time_frame:
Code:
double angle=0;
while (!viewer.done()) {
angle=angle+0.1*m_last_time_frame;
viewer.getCamera()-setViewMatrixAsLookAt(osg::Vec3(0,-400,150),
osg::Vec3(0,0,0), osg::Vec3(0,0,1));
viewer.getCamera()-setViewMatrix(osg::Matrix::rotate(angle*DEG_TO_RAD,0,0,1)*viewer.getCamera()-getViewMatrix());
viewer.frame();
}
Thanks.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20102#20102
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Rafael Gaitán Linares
Instituto de Automática e Informática Industrial http://www.ai2.upv.es
Ciudad Politécnica de la Innovación
Universidad Politécnica de Valencia
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
