Hi Robert -- Just to clarify, as I stated in the "Improving multisampled
FBO" thread, this is more than a new feature. It's a necessary
workaround for an OSX / NVIDIA-specific driver defect.
We'll want this capability in svn trunk, but waiting for a new stable
release, and all the associated testing, is impractical for my client.
So we need another venue for release.
Branching from 2.8.2 is a good suggestion, thanks. We can do this as
either a 2.8.2 branch, or a 2.8.3 point release.
To do this as a 2.8.3 point release, I agree we should keep binary
compatibility. I could implement this change as a CPP macro controlled
through CMake without affecting binary compatibility. The default
behavior would be the current behavior, but developers could change this
behavior in CMake so that the resolve blit doesn't resolve the depth
buffer. It would be "all on" or "all off", but I think this will be
sufficient for my purposes.
I'll discuss with the client and see if they prefer a non-ABI compatible
2.8.2 branch, or a 2.8.3 with CMake controlled MSFBO resolve behavior.
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
+1 303 859 9466
Robert Osfield wrote:
Hi Paul,
On Wed, Oct 21, 2009 at 5:24 PM, Paul Martz <[email protected]> wrote:
Hi Robert and all -- I'm about to start work on the multisampled FBO
enhancement mentioned in the thread "Improving multisampled FBO".
http://groups.google.com/group/osg-users/browse_thread/thread/7fd8acaf422d90d1/4b4478521ef35174?hl=en&lnk=gst&q=Improving+multisampled+FBO#4b4478521ef35174
Specifically, I'm going to add an entry point to Camera that allows the
application to control how the resolve FBO is configured, and how the
resolve blit is performed. This will involve mods to Camera and RenderStage.
I'm putting in this change for a client that is using OSG v2.8.2, so I want
to do the change on the 2.8 branch and make another point release, 2.8.3.
Before I embarked on this, I wanted to check and see if there was any other
activity on the 2.8 branch, so that we could coordinate efforts.
I'll be working on this over the next few days, with a release as soon as
the code is functional and tested.
My hope with the 2.8 branch would be that it would remain binary
compatible unless we absolutely had to make a bug fix that required a
ABI change. You're suggested changes will change the ABI, and also
the feature set. I'm therefore very wary about the justification of
making these changes to what should be just a maintenance series. I
don't feel it's appropriate to breaking the ABI because it's
convenient way to release a new feature early for a client.
Perhaps making a separate branch for your work from 2.8.2 would be
more appropriate. This way you make may the changes you feel are
appropriate, and then I can review these and considering how best to
merge the features into svn/trunk, without us having to break the ABI
of the maintenance series that is 2.8.x.
Cheers,
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
