Re: [osg-users] osgOcean : Integration into existing Database /Application
Hi Kim, Thanks for the short explainations. Well first the openscenegraph motionmodel or manipluators, manager aren't working. it would be good to get similar behaviour like in application-viewer example. this would be important for integration into existing applications. I do now better understand that we need to implement own geometries for water effetc. would it be not much easier that we can append a geometry (osg file, ive file ,... ) which should be used to attach the water shaders. Say for limit we attache a xy plane with shaped borders, this would be very usefull for many terrain visualisation applications, even for osgEarth this could be once an option for the ocean. of course we have fast unlimited ocean effects but once we have a lake this would not help, right? or could it be an option to cut the lake from the terrain, then we can define the height of the ocean. i will read the papers again, and i hope i can work out some strategy and new ideas which way we should - can go for further osg integration improvments. regards adrian 2009/6/19 Kim C Bale k.b...@hull.ac.uk Hi Adrien, I'm having a slight problem understanding your questions, so I'll do my best and ask some back... Would it be possible to add a ocean geometry and attach the ocean effect, shader. if yes how should it be look like, just a plane? more complex geometry? My idea would be to add a lake surface, and two rivers with different waves, and so on. Do you mean you would like to add you own method of generating the water geometry for lakes and rivers? If so, I've tried to accommodate for additional type of geometry by providing the OceanTechnique base class. Basically osgOcean is comprised of two main parts. OceanTechnique: Which generates and animates the ocean geometry and manages any level of detail algorithms that are required. It uses osg::Geode as a base class and therefore drawables for the geometry. A class derived from this should provide a water shader. Animation is provided by adding a cull/update callback. OceanScene: Which manages the various pre and post render passes required for the effects. This also includes controlling the different types of fogging and lighting that are applied based on whether the main camera view is above or below the water surface. If you want to create your own water geometry class you'll have to inherit from OceanTechnique and then add this class to OceanScene as done with FFTOceanSurface in the example application. OceanScene will only work with one OceanTechnique so you'll have to create a new instance of OceanScene if you wish to use multiple OceanTechniques. The geometry can be as complicated or as simple as you like. If you apply the current water shader to a quad it still looks alright and maybe be suitable for some applications. These two papers provide very good explanations of generating water geometry (the first is used in FFTOceanSurface): http://graphics.ucsd.edu/courses/rendering/2005/jdewall/tessendorf.pdf http://citeseer.ist.psu.edu/cache/papers/cs/26265/http:zSzzSzwww.cs.sunysb.eduzSz~ash zSzwaterCGF.pdf/ The tricky part is the shaders. osgOcean provides a very long list of uniforms which you can make use of if you wish in custom shaders. Some must be applied locally to the OceanTechnique (see: FFTOceanSurface::initStateSet() ), and those related to the multipass rendering are inherited from the statesets within OceanScene (see: void OceanScene::init()). The shader implementation used in FFTOceanSurface can be found in the resources directory (water.frag/water.vert). If you want to use this shader for your own technique you'll have to apply it within your OceanTechnique and add the uniforms found in: FFTOceanSurface::initStateSet(). Your best bet is to look at the FFTOceanSurface class and see how it's implemented. It's not as complicated as it looks, 80% of it is to do with generating the vertex array and primitives for the geomipmapping routine which you may not need. we don't need only an unfinite ocean You can disable infinite ocean effect using: FFTOceanSurface::enableEndlessOcean(false,true); Next problem i got is that the default motion models are not working Do you mean the ocean waves aren't moving? I hope that answers your questions, otherwise I've just gone off on a very lengthy tangent :) Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] On Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: 19 June 2009 06:22 To: OpenSceneGraph Users Subject: [osg-users] osgOcean : Integration into existing Database /Application Hi all i am wondering how i can integrate the osgOcean effect into existing application, database. Would it be possible to add a ocean geometry and attach the ocean effect, shader. if yes how should it be look like, just a plane? more complex geometry? My idea would be to add a lake surface, and two
Re: [osg-users] osgOcean : Integration into existing Database/Application
Hi Kim and John Manipulator developing is a hard task, i will say good and robust and easy to use manipulator are not quite easy to write or to work out. So it would be important having default or common manipulator working with the osgOcean. I am wondering why you having problem with terrain mainpulators if the deformation gets done in vertex shader. so what i would like to mention is the fact that if the gpu support shader 3 (since 2007) you could pass a texture with deformation field information to the GPU and then the geometry stay allways similar. regards adrian 2009/6/19 John Vidar Larring larr...@weatherone.tv Hi Kim and Adrian, As far as I can tell only two of the osgGA manipulators are compatible - Trackball and FlightManipulator. Although you're right the trackball implementation doesn't seem to work correctly, I suspect this is to do with the fact that it doesn't have a node to focus on. TerrainManipulator and DriveManipulators aren't compatible because the ocean surface is animated and they try to position themselves by intersecting with the surface below them, which in the case of the ocean surface, is moving up and down all the time so it creates a nasty camera juddering. I had a go at adding them but I simply couldn't get them to play nicely. If you manage to get them working I'd be interested to see how. Just one idea I'd like to throw out there before I forget. One could possibly make an EllipsoidManipulator quite easily. It would essentially behave like a TerrainManipulator except that it would not take elevation into account; just doing simple ray-ellipoid intersection testing instead. Even better, if there is a way to tell whether intersecting geometry is static or dynamic, one could theoretically implement a manipulator which behaves like the TerrainManipulator over land, and like an Ellipsoid manipulator over the ocean. Best regards, John Kim C Bale wrote: Hi Adrien, Well first the openscenegraph motionmodel or manipluators, manager aren't working. it would be good to get similar behaviour like in application-viewer example. this would be important for integration into existing applications. As far as I can tell only two of the osgGA manipulators are compatible - Trackball and FlightManipulator. Although you're right the trackball implementation doesn't seem to work correctly, I suspect this is to do with the fact that it doesn't have a node to focus on. TerrainManipulator and DriveManipulators aren't compatible because the ocean surface is animated and they try to position themselves by intersecting with the surface below them, which in the case of the ocean surface, is moving up and down all the time so it creates a nasty camera juddering. I had a go at adding them but I simply couldn't get them to play nicely. If you manage to get them working I'd be interested to see how. it be not much easier that we can append a geometry (osg file, ive file ,... ) which should be used to attach the water shaders. I haven't thought a lot about how to implement non-uniform shapes of animated water yet, the goal of osgOcean 1.0 was to get open sea rendering working. However, one of the nice things about the FFT approach is that it tiles. So it would be possible to modify the algorithm so that it places tiles in a non-uniform configuration rather than in a square shape. The current implementation of osgOcean uses a large vertex array that stores the vertices for all the tiles on screen. But a future enhancement will be to store only 1 tiles worth of vertices and then instance it positioning the tiles using a vertex shader. This will be a far more flexible and efficient approach and more suitable for deployment in large terrain datasets. Regards, Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgOcean : Integration into existing Database / Application
Hi all i am wondering how i can integrate the osgOcean effect into existing application, database. Would it be possible to add a ocean geometry and attach the ocean effect, shader. if yes how should it be look like, just a plane? more complex geometry? My idea would be to add a lake surface, and two rivers with different waves, and so on. finally we don't need only an unfinite ocean. Next problem i got is that the default motion models are not working, i played arround with osgviewer example, and osgOcean example. Well how should we use both ideas together in a terrain database (currently existing, but without the nice water effect) /regards adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org