Re: [osg-users] Dae plugin, textures not visible (related to Geode/Geometry changes ?)
Hi Robert, I've tried your modification and it works fine. Thanks, Luc De : osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] De la part de Robert Osfield Envoyé : vendredi 21 novembre 2014 18:26 À : OpenSceneGraph Users Objet : Re: [osg-users] Dae plugin, textures not visible (related to Geode/Geometry changes ?) Hi Luc, I haven't tested it yet but the following is what I'm thinking of (file also attached), could you try it out and let me know how you get on. Was about to fire off this email and wait for feedback, but have decided to go ahead and check this change into svn/trunk. If there are issues we can amend it. Robert. Index: src/osg/CopyOp.cpp === --- src/osg/CopyOp.cpp (revision 14485) +++ src/osg/CopyOp.cpp (working copy) @@ -33,7 +33,6 @@ } COPY_OP( Object, DEEP_COPY_OBJECTS ) -COPY_OP( Node, DEEP_COPY_NODES ) COPY_OP( StateSet, DEEP_COPY_STATESETS ) COPY_OP( Image,DEEP_COPY_IMAGES ) COPY_OP( Uniform, DEEP_COPY_UNIFORMS ) @@ -49,6 +48,16 @@ return const_castReferenced*(ref); } +Node* CopyOp::operator() (const Node* node) const +{ +if (!node) return 0; + +const Drawable* drawable = node-asDrawable(); +if (drawable) return operator()(drawable); +else if (_flagsDEEP_COPY_NODES) return osg::clone(node, *this); +else return const_castNode*(node); +} + StateAttribute* CopyOp::operator() (const StateAttribute* attr) const { if (attr _flagsDEEP_COPY_STATEATTRIBUTES) [X]http://www.1spatial.com [http://www.1spatial.com/wp-content/themes/1spatial/images/youtube.png]http://www.youtube.com/user/1SpatialGroup [http://www.1spatial.com/wp-content/themes/1spatial/images/facebook.png] https://www.facebook.com/1Spatial [http://www.1spatial.com/wp-content/themes/1spatial/images/linkedIn.png] http://www.linkedin.com/company/1spatial [http://www.1spatial.com/wp-content/themes/1spatial/images/twitter.png] http://www.twitter.com/1spatial 1Spatial France SAS Les informations contenues dans cet e-mail sont confidentielles et uniquement adressées au destinataire. Les opinions qui y sont exprimées peuvent être celles de l'auteur et ne représentent pas nécessairement celles du Groupe 1Spatial. Cet e-mail a été scanné et est garanti sans aucun virus. 1Spatial France SAS est une société de droit français, membre du Groupe 1Spatial. Siège Social : Immeuble AXEO2, 23-25 Avenue Aristide Briand, 94110 Arcueil, France. RCS CRETEIL 334 416 336 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dae plugin, textures not visible (related to Geode/Geometry changes ?)
Hi, I've dug a little into osg ::clone operator and I think it is broken for Geodes since the Geode/Geometry change. If a cloning is done on a Geode with the flag DEEP_COPY_DRAWABLES, The clone function of osg::Group will be called, wich is correct to my understanding, but for childs (Drawables), the osg::Node cloning operator is called instead of Drawable/Geometry one. The offending code : osg::Geode *pCopiedOsgGeode = static_castosg::Geode*(pOsgGeode-clone(osg::CopyOp::DEEP_COPY_DRAWABLES)); pCopiedOsgGeode is NOT a deep copy of pOsgGeode Robert, do you have an idea how it should work or be repaired ? Luc De : osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] De la part de Luc Frauciel Envoyé : lundi 17 novembre 2014 10:52 À : osg-users@lists.openscenegraph.org Objet : [osg-users] Dae plugin, textures not visible (related to Geode/Geometry changes ?) Hi, I've got a set of collada files that don't load anymore (no textures), see attachment. I've tracked the problem down to daeReader.cpp / void daeReader::processBindMaterial The geometry is cached and then texture coordinates arrays are copied to a clone geometry. However, before copying, a call to getTexCoordArrayList().clear() is done on the clone geometry. What is strange is that this call also clear the texcoordarray from the cached geometry, which invalidate the code following. The cloned geometry is supposed to be a deep copy of cached geometry but share the same pointers. I don't know if the deep copy mechanism is broken or what but something wrong here. I'm using OSG 3.2. Command line : osgviewer CubeSport.dae -O daeUseSequencedTextureUnits This was working a few month ago (before I updated to the new Geode/Geometry logic). Are you able to reproduce the problem ? Do someone know the logic/expected behavior behind this cloning mechanism ? Regards Luc Frauciel Responsable RD RD Manager T +33 (0)1 71 33 01 48 http://1spatial.com/fr/event/club-des-utilisateurs-francophones-1spatial[Image supprimée par l'expéditeur.]http://1spatial.com/fr/event/club-des-utilisateurs-francophones-1spatialhttp://1spatial.com/fr/event/club-des-utilisateurs-francophones-1spatial 1Spatial France SAS Les informations contenues dans cet e-mail sont confidentielles et uniquement adressées au destinataire. Les opinions qui y sont exprimées peuvent être celles de l'auteur et ne représentent pas nécessairement celles du Groupe 1Spatial. Cet e-mail a été scanné et est garanti sans aucun virus. 1Spatial France SAS est une société de droit français, membre du Groupe 1Spatial. Siège Social : Immeuble AXEO2, 23-25 Avenue Aristide Briand, 94110 Arcueil, France. RCS CRETEIL 334 416 336 [X]http://www.1spatial.com [http://www.1spatial.com/wp-content/themes/1spatial/images/youtube.png]http://www.youtube.com/user/1SpatialGroup [http://www.1spatial.com/wp-content/themes/1spatial/images/facebook.png] https://www.facebook.com/1Spatial [http://www.1spatial.com/wp-content/themes/1spatial/images/linkedIn.png] http://www.linkedin.com/company/1spatial [http://www.1spatial.com/wp-content/themes/1spatial/images/twitter.png] http://www.twitter.com/1spatial 1Spatial France SAS Les informations contenues dans cet e-mail sont confidentielles et uniquement adressées au destinataire. Les opinions qui y sont exprimées peuvent être celles de l'auteur et ne représentent pas nécessairement celles du Groupe 1Spatial. Cet e-mail a été scanné et est garanti sans aucun virus. 1Spatial France SAS est une société de droit français, membre du Groupe 1Spatial. Siège Social : Immeuble AXEO2, 23-25 Avenue Aristide Briand, 94110 Arcueil, France. RCS CRETEIL 334 416 336 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Handling of Vendor extra in Collada (dae) Reader/Writer
Hi osg-users, I have to support a type of Collada that contain specific vendor extra profiles. For the moment, osg dae reader handle them with some hardcoded vendor specific profiles : GOOGLEEARTH, SCEI ,OpenSceneGraph However, I've got the feeling that each Collada producer defines its own profile adapted to its needs. What would be the proper way to handle this ? - hardcode a newer vendor profile and submit it to OSG ? - rewrite my own ReaderWriter from the current one ? (but this would require a bunch of virtual on current one) - add a form of callback mechanism to osg dae plugin to support custom extras handling ? - another brillant idea ? Regards, Luc Luc FRAUCIEL Département Produits/RD Tél. : +33 1 71 33 01 48 E-mail : luc.frauc...@star-apic.com Website : www.star-apic.com image/gifimage/pngimage/pngimage/pngimage/jpegimage/pngimage/jpeg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] adding barrel distortion for stereoscopic rendering in Oculus Rift head set
Hi Christian, I still haven't managed to get my hands on an Oculus Rift, but as soon as KickStarter rewards get delivered, I will work on this point. There is already some kind of specific distortions implemented in OSG for dome projection (osgdistortion example). From what I've heard, the distorsion shader for the Rift is quite easy to implement. Luc - VRGeek and Rift fan De : Christian Buchner christian.buch...@gmail.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 20/03/2013 19:32 Objet : [osg-users] adding barrel distortion for stereoscopic rendering in Oculus Rift head set Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi, has anyone here started to add some Oculus Rift support as an additional stereoscopic mode of OSG? It would require some barrel predistortion (with the exact parameters yet to be announced) and requires rendering at 60 FPS with vsync, side by side. 1280×800 resolution. It's probably a good idea to render each eye to an FBO and perform the barrel distortion in a pixel shader. Maybe the rendering to FBO needs to be done at a slightly higher resolution because the barrel distortion leads to a higher effective resolution at the center of the image. And you certainly don't want to see any aliasing there. Christian ___ 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] [osgPlugins] DDS Texture vanish withLINEAR_MIPMAP_LINEAR
I've seen that kind of problems on AMD/ATI boards. Luc De : Robert Osfield robert.osfi...@gmail.com A : osg-users@lists.openscenegraph.org Date: 30/10/2012 15:27 Objet : Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi Tim, Try running your app on a system with a difference graphics card/driver, there is a change the issue is a driver bug. Robert. On 30 October 2012 09:18, Tim Rambau tim.ram...@dlr.de wrote: Hi, I have a terrain model with 1024x1024 DXT1 textures. Using a min filter with LINEAR_MIPMAP_LINEAR the textures are gone, changing only this filter to LINEAR everything is back again. The textures contain 1 main image and 10 mipmaps... Any ideas? Thanks Cheers, Tim. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50877#50877 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tesselator and output primitives
Hi Albert, I've answered the same question on this list a few weeks ago. A search in the archives should get you to it. And yes, it's possible, natively. Luc De : Aurelien Albert aurelien.alb...@alyotech.fr A : osg-users@lists.openscenegraph.org Date: 10/10/2012 20:29 Objet : [osg-users] Tesselator and output primitives Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi, I use tesselator to generate a geometry from a LINE_LOOP primitive. The tesselator output give me a TRIANGLES_FAN primitive which seems to be correct. Now I would like to get the tesselator output as TRIANGLES primitive. Is there anyway to control the primitive type built by the tesselator ? Or is there any OSG tool function / visitor that can convert TRIANGLES_FAN to TRIANGLES ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50551#50551 ___ 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] RTT camera and nested camera
Hi everybody, I'm stuck with a problem when trying to render to RTT camera. I want to render a scene to a RTT camera (the way osgposter does it). In my scene, I've got a osgephemeris SkyNode. To avoid culling problems, the skynode is rendered with it's own Camera ( see : http://osdir.com/ml/OpenSceneGraph-Users/2009-04/msg01170.html the suggestion of J-S Guay) While rendering directly to frame buffer my scene is ok : scene + skydome While rendering to a RTT camera, the objects below the Skydome camera are not rendered in the texture. I've tried to play with different parameters (render order etc...) but I don't understand how it work (or should work). During the traversal of a scene rendered through a RTT camera, how the nested cameras behave ? Do they automatically acquire the RTT camera target ? Do I have to set up something ? Luc ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT camera and nested camera
Thanks Sergey, that was what I feared. It will not be easy to get these rendertarget parameters at the nested camera level. I have searched for a way to 'copy' the render target from a camera in parent nodepath, but the Camera class does not seem to be taylored for that, I will probably use a visitor to propagate RTT parameters to nested cameras. Luc De : Sergey Polischuk pol...@yandex.ru A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 31/08/2012 16:04 Objet : Re: [osg-users] RTT camera and nested camera Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi During the traversal of a scene rendered through a RTT camera, how the nested cameras behave ? Same as usual, render to framebuffer by default. Do they automatically acquire the RTT camera target ? Do I have to set up something ? Yes, you should specify rendertarget if you dont want to get result on framebuffer. You should explicitly attach same rtt to both your cameras. Cheers. 31.08.2012, 16:48, Luc Frauciel luc.frauc...@star-apic.com: Hi everybody, I'm stuck with a problem when trying to render to RTT camera. I want to render a scene to a RTT camera (the way osgposter does it). In my scene, I've got a osgephemeris SkyNode. To avoid culling problems, the skynode is rendered with it's own Camera ( see : http://osdir.com/ml/OpenSceneGraph-Users/2009-04/msg01170.html the suggestion of J-S Guay) While rendering directly to frame buffer my scene is ok : scene + skydome While rendering to a RTT camera, the objects below the Skydome camera are not rendered in the texture. I've tried to play with different parameters (render order etc...) but I don't understand how it work (or should work). During the traversal of a scene rendered through a RTT camera, how the nested cameras behave ? Do they automatically acquire the RTT camera target ? Do I have to set up something ? Luc = ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Example using osgUtil::Tessellator to only get back GL_TRIANGLE primitives?
Hi Preet, I recently submitted a modification to Tesselator that allows to do that. You have to modify the underlying gluTesselator Callbacks to use GLU_TESS_EDGE_FLAG Here is an example. void CALLBACK noStripCallback(GLboolean userData) { } #include osg/GLU class CustomTessellator : public osgUtil::Tessellator { public: virtual void beginTessellation() { reset(); if (!_tobj) _tobj = osg::gluNewTess(); osg::gluTessCallback(_tobj, GLU_TESS_VERTEX_DATA, (osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::vertexCallback); osg::gluTessCallback(_tobj, GLU_TESS_BEGIN_DATA, (osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::beginCallback); osg::gluTessCallback(_tobj, GLU_TESS_END_DATA, (osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::endCallback); osg::gluTessCallback(_tobj, GLU_TESS_COMBINE_DATA,(osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::combineCallback); osg::gluTessCallback(_tobj, GLU_TESS_ERROR_DATA, (osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::errorCallback); //Here is the New TESS Callback : //Force to only creates triangles osg::gluTessCallback(_tobj, GLU_TESS_EDGE_FLAG, (osg::GLU_TESS_CALLBACK) noStripCallback); if (tessNormal.length()0.0) osg::gluTessNormal(_tobj, tessNormal.x(), tessNormal.y(), tessNormal.z()); osg::gluTessBeginPolygon(_tobj,this); } }; Luc De : Preet prismatic.proj...@gmail.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 22/07/2012 07:14 Objet : [osg-users] Example using osgUtil::Tessellator to only get back GL_TRIANGLE primitives? Envoyé par : osg-users-boun...@lists.openscenegraph.org Is there anyway to use osgUtil::Tessellator to only get back GL_TRIANGLE primitives? With the available examples, the tessellator adds/changes the primitive sets of the osg::Geometry passed to it into multiple triangle fans, triangle strips, and triangles. I want my geometry to just consist of GL_TRIANGLE draw calls. Also, there's another method of using the tessellator where it looks like you manually define contours / add vertices, etc, but I can't figure out how to use it. Could anyone provide a small example, or maybe point out what I'm doing wrong: osgUtil::Tessellator myTess; myTess.setTessellationNormal(offsetVec); myTess.beginTessellation(); myTess.beginContour(); for(int i=0; i areaVx-size(); i++) { osg::Vec3 * someVertexPtr = someVertex; myTess.addVertex(someVertexPtr); } myTess.endContour(); myTess.endTessellation(); std::cout Num Contours myTess.getContours().size();// gives me a zero ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives)
Hi Gath, I use osgShadow (VDSM) and osgEphemeris in conjunction, and they seem to work together. However, there are known problems related to osgEphemeris which are broader : - The Skydome in osgEphemeris can be very large, causing unwanted interaction with culling/ nearfar planes. see http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026772.html long thread, but with useful hints towards solutions - I remember problems with clearing operation, but probably related to solutions to the previous problem. If the only thing that you want is a skydome, osgEphemeris is an overkill for that. You probably still have to consider the culling problems introduced by skydomes (a scene with a skydome is artificially big). Luc De : Garth D garthy_...@entropicsoftware.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 05/04/2012 15:34 Objet : [osg-users] Using osgShadow with osgEphemeris (or alternatives) Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi everyone, In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow (namely ShadowTexture), with both animated and static models, and started to work in osgEphemeris in order to provide a more interesting sky than a single static colour. One thing I noticed is that whenever osgEphemeris is working, the location of cast shadows shifted around significantly, and they are nowhere near the objects that are casting them (ie. the shadows were very clearly incorrect). Depending on the view angle, they also bounced around to different locations. I noticed that animated models no longer cast shadows, but that may have just been a symptom specific to my particular case. In case the node mask was causing a problem (for osgShadow I am using 1 to cast, and 2 to receive), I tried different values. Setting it to zero caused the EphemerisModel to vanish (is this normal?), and to four left it there, but didn't help the shadow situation. In any case, when the EphemerisModel was working, the shadows were shifted around and incorrect. I've tried disabling lighting on the model (via state sets and GL_LIGHTING), as well as attaching it to different nodes, but I don't seem to have struck upon the correct combination. Interestingly enough, if I use either on their own, they work fine. Shadows work fine, without ephemeris models; and ephemeris models seem to produce good results if I turn off shadows. Can anyone suggest any things to try, confirm there are known problems, or otherwise? On a side note, I began to investigate osgEphemeris in the first case as I needed a simple sky. My requirements are pretty low, as the sky is merely decorative, so I don't necessarily *have* to use osgEphemeris specifically. I am wondering what the best approach to sky creation in OSG 3.0.1 would be? The potential solutions I ran into were: - Use the sky code osghangglide as a base/inspiration. - Find a spare $1.5k and use SilverLining (a bit overkill for my application at present!) - Use skydome.osgt from the OpenSceneGraph data dir (I gave this a shot, but I wasn't able to successfully get it working correctly with the rest of my app) - Build up my own geometry, customising the texture coordinates as I need (the most flexible approach, but the most time consuming, and the most pointless if someone has done it already), and grab or buy some existing sky textures to match the expected texture. - Use osgEphemeris, which is what I'm looking at above. Are there other solutions that I should be exploring as well, or in preference? Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives)
May I ask re your usage of osgShadow and osgEphemeris, which shadow technique you were using? VDSM (View Dependant Shadow Map), with custom shaders for multi-texturing, transparency, fog, etc... I exclude the skydome of osgephemeris from culling (cf thread) and disable depth test on it. VDSM works quite well for non human-like viewpoints (near the ground, looking towards horizon). Luc De : Garth D garthy_...@entropicsoftware.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 05/04/2012 16:15 Objet : Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives) Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi Luc, Thanks for the fast reply on that one. I hadn't considered checking out interactions with the clip planes. I've had to manually override their calculation in a past project, so this could be worth checking out. Incidentally, I did shrink the ephemeris model via setSkyDemoRadius a fair bit before starting, but the presence of the geometry is likely going to move the clip planes around. May I ask re your usage of osgShadow and osgEphemeris, which shadow technique you were using? And yes, osgEphemeris is probably overkill ultimately. ;) Garth On 05/04/12 23:30, Luc Frauciel wrote: Hi Gath, I use osgShadow (VDSM) and osgEphemeris in conjunction, and they seem to work together. However, there are known problems related to osgEphemeris which are broader : - The Skydome in osgEphemeris can be very large, causing unwanted interaction with culling/ nearfar planes. see http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026772.html long thread, but with useful hints towards solutions - I remember problems with clearing operation, but probably related to solutions to the previous problem. If the only thing that you want is a skydome, osgEphemeris is an overkill for that. You probably still have to consider the culling problems introduced by skydomes (a scene with a skydome is artificially big). Luc De : Garth D garthy_...@entropicsoftware.com A :OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 05/04/2012 15:34 Objet :[osg-users] Using osgShadow with osgEphemeris (or alternatives) Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi everyone, In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow (namely ShadowTexture), with both animated and static models, and started to work in osgEphemeris in order to provide a more interesting sky than a single static colour. One thing I noticed is that whenever osgEphemeris is working, the location of cast shadows shifted around significantly, and they are nowhere near the objects that are casting them (ie. the shadows were very clearly incorrect). Depending on the view angle, they also bounced around to different locations. I noticed that animated models no longer cast shadows, but that may have just been a symptom specific to my particular case. In case the node mask was causing a problem (for osgShadow I am using 1 to cast, and 2 to receive), I tried different values. Setting it to zero caused the EphemerisModel to vanish (is this normal?), and to four left it there, but didn't help the shadow situation. In any case, when the EphemerisModel was working, the shadows were shifted around and incorrect. I've tried disabling lighting on the model (via state sets and GL_LIGHTING), as well as attaching it to different nodes, but I don't seem to have struck upon the correct combination. Interestingly enough, if I use either on their own, they work fine. Shadows work fine, without ephemeris models; and ephemeris models seem to produce good results if I turn off shadows. Can anyone suggest any things to try, confirm there are known problems, or otherwise? On a side note, I began to investigate osgEphemeris in the first case as I needed a simple sky. My requirements are pretty low, as the sky is merely decorative, so I don't necessarily *have* to use osgEphemeris specifically. I am wondering what the best approach to sky creation in OSG 3.0.1 would be? The potential solutions I ran into were: - Use the sky code osghangglide as a base/inspiration. - Find a spare $1.5k and use SilverLining (a bit overkill for my application at present!) - Use skydome.osgt from the OpenSceneGraph data dir (I gave this a shot, but I wasn't able to successfully get it working correctly with the rest of my app) - Build up my own geometry, customising the texture coordinates as I need (the most flexible approach, but the most time consuming, and the most pointless if someone has done it already), and grab or buy some existing sky textures to match the expected texture. - Use osgEphemeris
Re: [osg-users] Methods to improve large scene shadows with ViewDependentShadowMap
Hi Wang Rui, I'm also working on very large urban areas with osgShadow::ViewDependentShadowMap. I encounter the same problems. I also had to use some kind of PCF to reduce some inacceptable noise (huge 'Moiré' effects). I tried to use PSSM recently introduced in ViewDependentShadowMap to cope with aliasing effects with no success : - PSSM procuce some strange artifacts on half of the view when mixing the two shadow textures (each half shadow is ok) - the separation line is not adapted to a 'human walking' point of view (too far in the scene) I doubt that changing the depth of the shadow map will produce noticable effects : numerical instabilities will exist, whatever the depth. At what angles did you encounter innacceptable alisasing issues ? For views that are not near tangent to the ground plane, the results I got seems ok. Is your problem global or limited to certain points of view ? Is your target resolution way beyond the resolution of the shadow map (1*1) per ex ? Luc De : Wang Rui wangra...@gmail.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 12/03/2012 10:39 Objet : [osg-users] Methods to improve large scene shadows with ViewDependentShadowMap Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi all, I'm currently working on an example that uses osgShadow::ViewDependentShadowMap for generating dynamic shadows on a large area of buildings. It can work correctly on a huge city which is created by CityEngine and then converted to OSG styled scene graph. It also generates aliasing issues as expected, but I'm still looking for some good solutions to reduce such problem and want to discuss them in this thread if possible. My test program and a simple shader file can be found in attachement. I've already read a similar topic at: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-August/053731.html And I believe it is necessary to apply some filters on the shadow map (the test shader file simply uses PCF here) and increase the texture resolution as well. But for huge scene, a 4096-sized RTT texture will be a heavy burden. So I wonder if there are some more methods to choose, for example, is it possible to change the internal format of the texture to GL_DEPTH_COMPONENT32 to improve the shadow comparision process? Meanwhile, is it necessary to perform a screen space blurring to reduce the aliasing effect? It is a serious problem for my scene now as I can't use a very high resolution. Could anyone suggest some other possible methods on the post-processing level? To be honest, the ViewDependentShadowMap is the best shadow solution for me at present as it is easy to be integrated with custom shaders and embedded into a deferred shading framework. The test city models are about 180MB. If any of you think it important for digging into the problem. I'd like to share them freely, too, as I believe these automatically generated models should not have any copyrights with them. :-) Cheers, Wang Rui [pièce jointe screen_space_shadow.cpp supprimée par Luc Frauciel/STAR-APIC] [pièce jointe shadowRenderer.frag supprimée par Luc Frauciel/STAR-APIC] ___ 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] Slow rendering with displaylist.
Hi Martin, Be aware that for some combinaison of driver/hardware, VBO just don't work properly. I've encoutered the case on some Intel/ATI chipsets. A simple terrain created with VPB couldn't be loaded. With VBO OFF, everything was OK. Be also aware that if you use small geometries, there is a high overhead with VBO at initialization. It could be a good idea to make VBO you default implementation, but don't forget to have fallbacks when things will go wrong (especially if you have no control over target hardware) http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2011-July/052968.html http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-August/015543.html Luc De : Martin Großer grosser.mar...@gmx.de A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 28/02/2012 13:01 Objet : Re: [osg-users] Slow rendering with displaylist. Envoyé par : osg-users-boun...@lists.openscenegraph.org Hello, thanks to you, it was very helpful. Now I will only use VBOs. Greetings, Martin Original-Nachricht Datum: Tue, 28 Feb 2012 12:44:15 +0100 Von: Daniel Trstenjak daniel.trsten...@science-computing.de An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] Slow rendering with displaylist. Hi Martin, That is basically true. I want to get a feeling about DisplayLists and VBOs. I know that the display list is a precompiled sequence of OpenGL commands. That is the reason that I tought the display lists should be faster. But the question isn't the comparison, but the slow render performance when I want to use display lists. I think everything is wrong in my implementation. But I don't know what. My point about system/graphics card memory is wrong. I thought about glVertexPointer, but this call isn't even compiled into a display list and shouldn't be used with one. So OSG will most likely use glBegin/glEnd to put the vertex data into the display list. It boils down to what Mathias ;) said, it's an implementation issue, dirty corner cases and driver developers don't optimize the display lists anymore, because they're deprecated and just not used that much anymore. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ 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] OSG 2.8.3 3.0.1 view dependent shadowclippingplane
Hi Robert and J-S, In fact, that was what I was doing too. (with LighSpacePerspectiveShadowMap) Our data/global parameters are dynamically build and we have to adapt dynamically the shaders applied However, in the old way, the searchAndReplace stuff was mixing up custom shaders too. I had to create a CustomShadowMap with a no-op searchAndReplaceShaderSource to avoid that. And of form of 'generic uniforms' provided by ShadowMap can make the adaptation of the technique easier. For example, a setBaseTextureCoordIndex( std::vectorunsigned int index ) could allow to declare multiple texture units. Even if this units are not used by the Base Shader itself, you can easily acces them and the base shader will not crush them. For sure Shader Composition would be an elegant way to handle that. I'm not working on shadows for the moment, but when I'll get back to that part, I'll try the new technique and see what can be done to make it more flexible (if ever it were not enough). Luc De : Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 08/25/2011 12:31 AM Objet : Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadowclippingplane Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi Robert, Luc, The shader supplied by this technique doesn't implement any handling of multi-texturing itself so it'll be up to the user to provide their own shaders to do this. As a side note Luc, nothing forced you to use the ShadowMap's own shaders and searchAndReplace... functionality. You could simply replace the shaders, define your own uniforms for sampler name - texture unit mapping, and do multi-texturing that way. That's what we did. No shader provided by a library can be 100% flexible and support all use cases (at least until shader composition is done). The shaders in the older shadow techniques were no exception, but luckily you could replace them. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.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] OSG 2.8.3 3.0.1 view dependent shadowclippingplane
Hi, Great news ! Will this new technique handle multitexturing ? That was one of the problems in older osgShadow techniques: the shadow shaders used void setBaseTextureUnit( unsigned int unit ) with a single texture unit and then void searchAndReplaceShaderSource was rewriting over the base shader. In particular, using osgShadows in conjunction with osgEarth was a nightmare Luc De : Robert Osfield robert.osfi...@gmail.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 08/24/2011 04:17 PM Objet : Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadow clippingplane Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi All, I now have enough of the new ViewDependentShadowMap technique implemented for members of the community to start testing it out on their own data. From the testing I've done so far it looks to be signifcantly faster and produces more consistently high quality results than any of the other techniques we have had so far. The algorithm isn't based on any one paper, but one could say it in similar to perspective/light space perspective shadow maps but I abdoned the maths behind these approaches as I just couldn't get them to work reliably enough over a wide range of data. The new technique isn't finished yet, it's certainly far enough along for others to start testing and to report back results. The new technique isn't compatible with depth partitioning yet, and while it does handle spot lights it do so avoiding tackling the perspective transform in light space. My hope with the shdow implementation is that it'll be robust and flexible enough to replace all the old shadow techniques. The new techhnique also lays down the framework for future support of mltiple shadow maps such as with cascaded or parallel split shadow maps, as well handling multiple lights+shadows. If we can get it working robust enough I'll removal all the old techniques and enable us to have a lighter weight osgShadow library. All the changes are now checked into svn/trunk. To test use the --vdsm option in osgshadow, or use the new osgShadow::ViewDepedentShadowMap technique class in place of your existing shadow technique used in your application. Please let me know how you get on. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ATI FirePro M8900
I work on a Dell M6400 with a FirePro M7740 on Windows 7 64-bit. Same issue. Hours of installation/desinstallation of different drivers did nothing. The only workaround I've found is to disable VBO : pager-setDrawablePolicy(osgDB::DatabasePager::USE_DISPLAY_LISTS); There is also an Env setting to do that I think. It put an end to Geometric nightmare and random crashes. I really don't know what's pro in Ati FirePro... Luc De : J.P. Delport jpdelp...@csir.co.za A : osg users osg-users@lists.openscenegraph.org Date: 07/11/2011 05:18 PM Objet : [osg-users] ATI FirePro M8900 Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi all, we've got users with shiny new Dell Precision M6600 laptops with the FirePro M8900 ATI chips on Windows 7 64-bit. Terrain databases that work perfectly well almost everywhere produce artistic but not quite pleasing results in osgviewer, see attached. Any ideas on how to work around ATI's OpenGL uselessness? We've already suggested buying NVidia cards :/ Help on installing other driver versions, other than those blessed by Dell with AMD shrugging their shoulders [1], would also be welcome. cheers jp [1] http://support.amd.com/us/kbarticles/Pages/737-28041SupportforATIMobility.aspx -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. [pièce jointe ati-junk.jpg supprimée par Luc Frauciel/STAR-APIC] ___ 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] TerraPage terrain LODs are jumping again - have LOD ranges to be sorted?
Robert Osfield Wrote: For PagedLOD nodes the children should always be ordered from lowest resolution/ furthest distance first, to highest resolution/near distance last. What you describe fits this just fine. Would it be possible to add this constraint in PagedLOD header ? The only information available in the source for now is in LOD header : LOD may display multiple children simultaneously if their corresponding ranges overlap. Children can be in any order, and don't need to be sorted by range or amount of detail. If the number of ranges (m) is less than the number of children (n), then children m+1 through n are ignored. and could be misleading regarding the behaviour of PagedLOD which inherits from LOD. I've been fooled by this in the past :) Best Regards, Luc Robert Osfield robert.osfi...@gmail.com Envoyé par : osg-users-boun...@lists.openscenegraph.org 09/08/2010 02:19 PM Veuillez répondre à OpenSceneGraph Users osg-users@lists.openscenegraph.org A osg-users@lists.openscenegraph.org cc Objet Re: [osg-users] TerraPage terrain LODs are jumping again - have LOD ranges to be sorted? Hi Martin, For PagedLOD nodes the children should always be ordered from lowest resolution/ furthest distance first, to highest resolution/near distance last. What you describe fits this just fine. The TerraPage plugin has extra scheme above PagedLOD that seek to hold back use of higher resolution children when a neighbouring tile is of too low a resolution for the boundary meshes to be able to fit together. This scheme is pretty complicated and is very specific to the way that TerraPage maintains central and boundary meshes. I haven't personally seen the cycling you talk about but my guess is that this is the most fruitful area to look at when searching for a cause. Robert. On Wed, Sep 8, 2010 at 12:18 PM, Martin Scheffler osgfo...@tevs.eu wrote: Hi, this is a problem that was fixed some time ago but pops up again now. I have a terrapage terrain that loads fine, but every few seconds the detailed LODs are swapped against lower res ones and back again. This looks funny and bogs down the system. After poking around with a debugger the only thing that I noticed is that the LOD ranges are sorted high to low: For example: _rangeList[0] goes from 1000 to MAX_FLOAT _rangeList[1] goes from 0 to 1000 Can this cause these problems? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31409#31409 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] collada: use of bind_vertex_input
Hi, I've encoutered kmz files with dae files inside that look like that : Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind /instance_material /technique_common /bind_material The texture coords are not loaded. If I add a bind_vertex_input element, textures works. Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind bind_vertex_input semantic=CHANNEL1 input_semantic=TEXCOORD input_set=1/ /instance_material /technique_common /bind_material Do someone know what's happening ? Is it a problem in the file or the dae reader ? The file is opened correctly in GoogleEarth. Thank you! Cheers, Luc -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30846#30846 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] collada: use of bind_vertex_input
lucfrauciel wrote: Hi, I've encoutered kmz files with dae files inside that look like that : Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind /instance_material /technique_common /bind_material The texture coords are not loaded. If I add a bind_vertex_input element, textures works. Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind bind_vertex_input semantic=CHANNEL1 input_semantic=TEXCOORD input_set=1/ /instance_material /technique_common /bind_material Do someone know what's happening ? Is it a problem in the file or the dae reader ? The file is opened correctly in GoogleEarth. Thank you! Cheers, Luc The issue is similar to : http://forum.openscenegraph.org/viewtopic.php?t=2676 (more recent thread) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30855#30855 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RE Loading an Osg model from memory
Hi, osgDB::ReaderWriter::ReadResult will keep a handle on the node. At the end of your function (after return), the reference count of you object (maintained by ReadResult) will drop to Zero = object destroyed. I don't know what is the official way to avoid that, but one way or another, you will have to keep a ref_count pointer on your node to keep it alive. Luc Manolo Padron Martinez manol...@gmail.com Envoyé par : osg-users-boun...@lists.openscenegraph.org 29/04/2010 16:30 Veuillez répondre à OpenSceneGraph Users osg-users@lists.openscenegraph.org A osg-users@lists.openscenegraph.org cc Objet [osg-users] Loading an Osg model from memory Hi: We're trying to load an osg model from an stream. We got the code like this membuf sb((char *)Data, Size); std::istream stream(sb); osgDB::ReaderWriter* reader = osgDB::Registry::instance()-getReaderWriterForExtension(osg); if(reader) { osgDB::ReaderWriter::ReadResult rr = reader-readNode(stream,0); if(rr.success()) { osg::Node *new_model = new osg::Node(*rr.getNode()); return new_model; } } return NULL; Its seems to load as it should. Rr is successfull but when I try to add the node to a treenode I didn't saw it on screen. If I change the code before for the code to load it from disk It works perfectly. Any idea? There are a problem with the plugin of osg file when a stream is used to read the node? Regards from Canary Islands ___ 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] Improving the OpenSceneGraph project efficiency andbalance
How would you go about setting up automatic testing of the examples? What could you test here and how would you do it? -- Philip Lowman Hi, An idea could be to mimic the way VTK handle that question ( http://www.vtk.org) They generate a bunch of reference automatic screenshots through CTest and then do image comparisons. I admit that the initial setup seems quite high but I don't see any other way to do automatic testing of a graphic library. Luc Philip Lowman phi...@yhbt.com Envoyé par : osg-users-boun...@lists.openscenegraph.org 23/02/2010 12:17 Veuillez répondre à OpenSceneGraph Users osg-users@lists.openscenegraph.org A OpenSceneGraph Users osg-users@lists.openscenegraph.org cc Objet Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance On Tue, Feb 23, 2010 at 4:32 AM, Tim Moore timoor...@gmail.com wrote: Is there a critical mass of power users willing to use an experimental tree? I'm not sure. Even if not, automated testing of the examples would help verify any OSG tree. How would you go about setting up automatic testing of the examples? What could you test here and how would you do it? -- Philip Lowman ___ 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