Hi Jan,
My apologies for not replying earlier, I haven't been checking
osg-users as much as I possibly should have. It appears that I've
missed quite a few osgOcean posts.
>> BTW, is there a reason why is the size of the screen hardwired to
>> 1024x768? Do the shaders expect this? Or why is it so? It took me a while to
>> figure out why it doesn't draw correctly on our wall.
J-S pretty much answered this one- the screen resolution is only
required for setting up the FBOs involved in the fullscreen effects.
However, this can be changed using:
/** Sets the current screen size, needed to initialise the God Ray and
DOF frame buffers.
* Default is 1024x768.
*/
inline void OceanScene::setScreenDims( osg::Vec2s size ){
_screenDims = size;
_isDirty = true;
}
Setting that will cause the FBO textures to be resized and rebound at
the desired resolution on the next pass of the update visitor. You
could easily bind this function to a callback which calls it when the
screen resolution changes.
Back to the original problem with collision detection. As J-S said,
direct access to the vertices is not currently supported. However you
should be able to get access to the geometry by adding some simple
accessors. To be honest I haven't thought about collision detection
much as it wasn't an original requirement for me, but I can see that
it would be a valuable addition and i'll try and give you some
pointers.
The vertices and normals involved in the current frame are stored
within the Vec3Arrays called _activeVertices and _activeNormals in
FFTOceanSurface. Whenever the animation frame or LOD level changes the
entire vertex and normal arrays are updated from precomputed LOD and
animation frames stored in a 2D vector called _oceanTiles - where
they're stored in the format _oceanTiles[frame][lodlevel] .
These two arrays are then assigned to a series of custom osg::Geometry
objects called MipmapGeometry which are basically just osg::Geometry
objects with some extra member variables added.
The MipmapGeometry class stores the current LOD level of the patch and
the primitives that define the geometry for each of the ocean patches.
These objects are then stored within a 2D std::vector called
_oceanGeom. There is in fact a private inline function that will
returns a raw pointer to the desired patch:
/**
* Convenience method for retrieving mipmap geometry from _oceanGeom.
*/
inline FFTOceanSurface::MipmapGeometry* getTile( unsigned int x,
unsigned int y ){
return _oceanGeom.at(y).at(x).get();
}
Like I say I haven't thought about collision detection much, but my
initial thoughts are that you could use the bounding boxes of the
mipmap geometries as a quick way to find the patch in which the
collision occurs and the test the triangles within that patch. The
animation, of course complicates things somewhat. If you're planning
on doing accurate collision detection you should be able to get access
all the vertices involved for the frames at the current LOD from the
_mipmapData container.
I hope that helps a bit, if you have any further questions don't
hesitate to ask and I'll try and be more diligent with my replies.
Regards,
Kim.
2009/9/25 Jean-Sébastien Guay <jean-sebastien.g...@cm-labs.com>:
> Hi Jsn,
>
>> I will have a look at it tomorrow.
>
> Excellent, let me know if you have any questions though Kim C. Bale is more
> familiar with the actual algorithms so for some questions I might have to
> defer to him.
>
>> BTW, is there a reason why is the size of the screen hardwired to
>> 1024x768? Do the shaders expect this? Or why is it so? It took me a while to
>> figure out why it doesn't draw correctly on our wall.
>
> I think it's two things:
>
> a) preference on Kim's part (the example was coded like that when he first
> posted the code)
> b) all the post-render cameras for the RTT effects (DOF, glare, distortion)
> need to know the resolution of the screen, and I don't recall if/how they
> get this info, but I think he may have hard-coded it to 1024x768 to avoid
> having to pass the resolution all over the place. This can be changed.
> Remember that oceanExample is just that - an example. The API in the
> osgOcean lib should allow you to use it in any way, not just in the way
> oceanExample uses it.
>
> Bear in mind that osgOcean came from his own project, so the API was made
> for the way he used it. Then I came in and I had some other requirements for
> the API, so I made it evolve that way. It may well be that our two sets of
> requirements still don't cover all possible uses (in fact the opposite would
> be surprising) so if you need the API to evolve in some other way, it won't
> be a problem! :-)
>
> J-S
> --
> ______________________________________________________
> Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
> http://www.cm-labs.com/
> http://whitestar02.webhop.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
