Hi Kim,
Great to know everything is all right. I understand one can get burnt
out on a particular project after a while, you didn't go into specifics
and I totally understand that it may be a delicate subject but I'm glad
to see you back at it once again! :-)
So to your changes. The change to the way the shaders are integrated is
a good approach in fact, the shader integration has troubled me for a
while. My goal with inlining the shader code was to keep the library as
compact as possible. However, it soon became a maintenance nightmare -
people were submitting shader fixes and only editing either the inline
code or the external files and keeping track of which version was
correct was becoming very difficult.
I agree 100%.
I've already done some work to address this. So what I will do is
augment your approach with a pre build script which will read the
external shader files and generate headers which contain the shader code
that are then included in the build. This should go some way to
preventing any discrepancies between inline shaders and external
shaders. I have already written batch scripts to do this in windows, and
I think I made some progress in writing a similar bash script for linux
too but I'm not sure whether I finished it. I'll have to have a dig
around. Thinking about this, more recently I've starting using python as
my scripting language of choice - I'd be keen to use python to do this
but I'm not sure how people would feel about the additional build
dependencies.. do you have any thoughts on this? Simply put it would
make my life a bit easier since I'm windows based and testing bash
scripts is a bit of a pain.
I think the python route would be the best actually, most developers
will already have a python installation, and I would expect they would
only need to run the script if they change shaders, otherwise the C++
files would stay the same. I was thinking of doing something like that
myself. Up to you if you'd rather tackle it.
Instead of headers I would suggest one or more .cpp file(s) that would
define say const char* osgOcean_water_surface_fragment_source = "...";
and then the FFTOceanSurface.cpp file would refer to that symbol and it
would be resolved at link time. A header suggests it would be part of
some public interface, which is not the case here.
The ocean update callback is also a good approach, although I'll have to
make sure to document it on the wiki otherwise it'll be missed.
Good point, I was actually also thinking of doing a documentation pass
because I think we're missing a kind of high-level document that
explains a few use cases and what should work (in particular it would be
nice to explain how to use osgOcean with osgShadow). Once again I can do
this in the near future, before we do the next release.
Since my last update I have fixed the VBO ocean technique so I'll commit
that. I was rather disappointed by the performance gain though I noted a
10% drop on the draw traversal and a 80% drop in the update but no
significant change in the frame rate. It also has the side effect of
creating strange normals on the low resolution tiles. I'm rather dubious
as to whether I've implemented the VBO update correctly so it would be
good to see if improvements could be made there.
I'll have a look when you get to committing the changes. The drops are
good (I assume you mean drop in timings, not drop in performance :-) ),
and I'm sure they will be more significant for real apps (in particular
the 80% drop in update time is very welcome as the ocean will be more
usable in debug builds now).
I'll make a push to get these committed over the weekend, and will of
course give your recent commits a thorough testing. Given the amount of
fixes that have come in since 1.0.1 I think osgocean is due for another
release so I'll make these changes asap and focus on getting another
release out.
Great to see we're on the same page. I think before we make a release
the following milestones should be met:
1. Give the VBO technique more testing with a focus on eliminating
artifacts. If the technique is a step forward in performance but it has
some significant artifacts then it will be less likely to be used in
production applications - the performance gains will likely be overlooked.
2. Clean up the shader code duplication with an automatic generation
scheme. Again python would be my choice.
3. Expand on the usage documentation on the wiki, and perhaps include
some documentation in the release tarball/zip as well.
On a separate subject, we promised to have a look at Quintijn
Hendrickx's osgRiver code to see if it would make sense for inclusion
into osgOcean. I suggest we tackle this after the release, but it might
be nice to have a look at that separately and then have a few
back-and-forths to discuss what we thought. I just don't want to forget
about it. I think I'll log an issue in the issue tracker for that.
Thanks for getting back in touch, and for helping me push this forward
once again,
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
