Hi Kim,
You seem keen on working on things all by yourself, are you sure I can't
help, at least on documentation? In that past two days I went from
thinking I was going to take over the project entire (at least for the
next release or two) to you coming back and doing everything yourself!
It's kind of a dramatic change of direction for me, and I would have
thought you would welcome the help and delegate a bit of the 3 item list
I made in my previous message :-)
That said, it's good to see activity on the project :-)
J-S
On 10/13/2010 5:04 PM, Kim Bale wrote:
Hi J-S,
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.
I've just implemented this and will commit tomorrow once I've gone
through it to make sure I haven't missed anything.
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.
I concur, I'll merge it in over the weekend and see what can be done.
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.
Well 2 is done and 3 shouldn't take too long, I'll chip away at it in
the evenings.
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.
Absolutely, I feel rather bad about this actually. It's a fairly
substantial chunk of code and requires a fair amount of thought design
wise. I kind of think it might be possible for to exist as
a separate library, but with so many shared shader effects it seems
silly to duplicate the code. Will definitely address this after this
release.
K.
On 13 October 2010 01:21, Jean-Sébastien Guay
<jean-sebastien.g...@cm-labs.com
<mailto:jean-sebastien.g...@cm-labs.com>> wrote:
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 jean-sebastien.g...@cm-labs.com
<mailto:jean-sebastien.g...@cm-labs.com>
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto: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
--
______________________________________________________
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
