[osg-users] Dynamic Cubemap with OSG and Shader
Hi, I would like to use the dynamic cubemaps to reproduce the mirror effects in my application, however I found few examples on the internet. Is there any example code related to this topic? I will appreciate that. ... Thank you! Cheers, Rômulo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72534#72534 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic cube map
Hi, I would like to use the dynamic cubemaps to reproduce the mirror effects in my application, however I found few examples on the internet. Do you have any code about dynamic cubemaps to suggest me? ... Thank you! Cheers, Rômulo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72533#72533 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tiny normals: osgviewer vs osgcompositeviewer
Hi there, thanks for your quick input. @Robert; The use case is pretty common: the original model assumes mm, I assume meters. Hence the extreme scaling. Yes I noticed the transforms are flattened, which is probably a good thing in my case but it shouldn't change the rendering. (The model is exported by a 3rd party software so I don't have full control) @Sebastian: Yes you are probably right, I thought that some normals were completely lost though due to the scaling (rescaling = division by 0) but maybe I was lucky this time. Thanks again, Per On 4 December 2017 at 10:38, Sebastian Messerschmidt < sebastian.messerschm...@gmx.de> wrote: > > > Hi Per, > > Just a thought: > Maybe the Optimizer simply applies normal-rescaling? > > Cheers > Sebastian > >> Hi all, >> >> I came across something strange recently; >> the attached model is a red triangle scaled down by a factor 1000. >> The normals are squashed and I see some rendering problems in my app, >> which uses osgcompositeviewer. >> >> Confirmed with >> osgcompositeviewer red.osgt - renders with white color (incorrect) >> BUT >> osgviewer red.osgt - renders with red color (correct) >> >> I did some digging in the OSG code, it seems the difference is that >> osgviewer always >> optimizes the scene graph, something that osgcompositeviewer never does. >> Adding an optimizer to osgcompositeviewer fixes the rendering. >> >> So first question; would it be better if the two viewers applied same >> optimizer settings? >> Since users would expect them to display things in the exact same way. >> >> Second and more interesting; how can optimizer correct a "broken" model? >> >> Thank you! >> >> /Per >> >> >> >> ___ >> 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] [vpb] Terrain Deformation as per Road Profile
Hi, I am planning to use VPB for terrain deformation as per road profile. The road mesh has been generated separately and I shall put it on the terrain. The terrain generated by VPB must deform itself as per the road profile. Also additional geometry must be added to terrain geometry close to the road borders for smoothness as the terrain quad tile cells may be too big. This situation I have tried to visualize as shown in the two below images. Now the best approach I see is to let VPB generate the terrain tiles as OSG files. I know the road border points. I can figure out which terrain tile a segment of the road shall fall. Let’s say I know the road border points for the particular terrain quad tile as per figure 1. Now I need to tessellate or subdivide the Terrain tile cells that are falling on the road path. Thus I need to deform as well as increase the terrain mesh at the road borders. Question: What should be my best approach to achieve this? • I might use tessellation shaders approach, but it might tessellate everywhere I move camera not specifically at road borders. Maybe create a grayscale texture runtime that highlights the road surface & pass it to Tess shaders to tessellate at the road borders? • I might use old GluTess with winding order to cut holes in terrain where road goes. But those may create very long triangles if cell size is large. So please can anybody give me some pointers to approach this? I know this goes beyond VPB. By the way, each terrain tile also has its road cut piece. Thank you, Robert! Cheers, umesh -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72531#72531 Attachments: http://forum.openscenegraph.org//files/2_990.jpg http://forum.openscenegraph.org//files/1_160.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tiny normals: osgviewer vs osgcompositeviewer
Hi Per, Just a thought: Maybe the Optimizer simply applies normal-rescaling? Cheers Sebastian Hi all, I came across something strange recently; the attached model is a red triangle scaled down by a factor 1000. The normals are squashed and I see some rendering problems in my app, which uses osgcompositeviewer. Confirmed with osgcompositeviewer red.osgt - renders with white color (incorrect) BUT osgviewer red.osgt - renders with red color (correct) I did some digging in the OSG code, it seems the difference is that osgviewer always optimizes the scene graph, something that osgcompositeviewer never does. Adding an optimizer to osgcompositeviewer fixes the rendering. So first question; would it be better if the two viewers applied same optimizer settings? Since users would expect them to display things in the exact same way. Second and more interesting; how can optimizer correct a "broken" model? Thank you! /Per ___ 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] Tiny normals: osgviewer vs osgcompositeviewer
Hi Per, A quick response as I've got a clean build of the OSG happening and can't test anything till it's finished. My guess is that the osgUtil::Optimizer is doing something like flattening static transforms in the scene. The transforms that you have in the scene are really extreme w.r.t scaling, also why so many, this is really inefficient. Robert. On 3 December 2017 at 21:34, Per Nordqvist wrote: > Hi all, > > I came across something strange recently; > the attached model is a red triangle scaled down by a factor 1000. > The normals are squashed and I see some rendering problems in my app, > which uses osgcompositeviewer. > > Confirmed with > osgcompositeviewer red.osgt - renders with white color (incorrect) > BUT > osgviewer red.osgt - renders with red color (correct) > > I did some digging in the OSG code, it seems the difference is that > osgviewer always > optimizes the scene graph, something that osgcompositeviewer never does. > Adding an optimizer to osgcompositeviewer fixes the rendering. > > So first question; would it be better if the two viewers applied same > optimizer settings? > Since users would expect them to display things in the exact same way. > > Second and more interesting; how can optimizer correct a "broken" model? > > Thank you! > > /Per > > > ___ > 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
