Updating osgWorks

[Paul Martz]

Hi all. I was the original developer of osgWorks, with support and funding
from Doug at ISU. You haven't heard from me in a while. It's been nearly 2
years since I've done serious coding, so I'm quite out of the loop.

I recently had the itch to get osgWorks building and running with current
OSG. Shortly, I hope to devote the same attention to Bullet and osgBullet.

As osgWorks and other projects were summarily booted off the original Google
Code (R.I.P.), osgWorks "official" repo moved to github under Doug's repo:
mccdo/osgWorks. I've tried building Doug's repo against current OSG, and I
see it requires significant changes to make it compatible with current OSG.
I know Doug originally wanted to keep his repo compatible with OSG v2.8.5
for stability, so perhaps that is the source of the build issues I
encountered.

Searching github for osgWorks reveals there are several forks of the
project, and I suspect / hope one or more of them has been keeping pace with
OSG's ongoing changes.

My question: Which osgWorks fork(s) are people using with current (or fairly
current) OSG?

Thanks for helping get me back up to speed.
-Paul

[Doug McCorkle]

I think we should create a 2.8.5 branch and then master can be configured to build against the latest rev of OSG.

Doug

> --
> You received this message because you are subscribed to the Google Groups "osgworks-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to osgworks-user...@googlegroups.com.
> To post to this group, send email to osgwork...@googlegroups.com.
> Visit this group at http://groups.google.com/group/osgworks-users.
> For more options, visit https://groups.google.com/d/optout.

[Paul Martz]

That sounds like the right approach. However, apparently that won't be necessary. The changes are pretty minor, and we can still build osgWorks from single source for OSG 2.8.5 through to current 3.5.1. A pleasant surprise.

No branch necessary. I hope to have a commit on my pmartz fork shortly. Just doing some rebuilding and final testing.
-Paul

[Kevin Godby]

You can also use the OSG_VERSION_LESS_THAN and similar macros to
maintain compatibility with multiple versions of OSG in the same
codebase.

—Kevin

[Paul Martz]

Thanks, Kevin. Some of those OSG version macros were back-ported to the github OSG 2.8.5 project, so they should work, but for the most part, I prefer to use the osgWorks macros for OSG version checks, as those have been there since the dawn of time.

Right now I'm digging into an osgWorks regression test failure for the Uniqifier. No longer is it recognizing the Geometry class. I seem to recall that there were some major changes to Geometry in the OSG code base, but I wasn't around for the discussion. Is it no longer derived from Geode? Hm, I'll need to dig deeper.
-Paul

[Kevin Godby]

On Fri, Dec 11, 2015 at 5:13 PM, Paul Martz <skewm...@gmail.com> wrote:
> Thanks, Kevin. Some of those OSG version macros were back-ported to the github OSG 2.8.5 project, so they should work, but for the most part, I prefer to use the osgWorks macros for OSG version checks, as those have been there since the dawn of time.

Ah, even better then!

> Right now I'm digging into an osgWorks regression test failure for the Uniqifier. No longer is it recognizing the Geometry class. I seem to recall that there were some major changes to Geometry in the OSG code base, but I wasn't around for the discussion. Is it no longer derived from Geode? Hm, I'll need to dig deeper.

Oh yeah.. Geometry had a major overhaul a bit ago. I'm still dealing
with the fallout of that in my own code in places.

Geometry is now a Drawable. The binding stuff was pulled out of
Geometry and moved elsewhere

I haven't come across a clear migration guide, but if you find one (or
write one), I'd be interested in reading it.

—Kevin

[Paul Martz]

> Oh yeah.. Geometry had a major overhaul a bit ago. I'm still dealing with the
> fallout of that in my own code in places.
>
> Geometry is now a Drawable. The binding stuff was pulled out of Geometry
> and moved elsewhere

Looks like the changes were even more drastic than that. Geode now derives from Group, and Drawable from Node, The Geode (Group) children are now Node Drawables rather that a separate list of Drawables. This means Drawables now get visited by any NodeVisitor that has an apply(Node&).

Previously, Uniqifier did not need to make Geometries or Drawables unique, because they were not Nodes. Now they are Nodes, and the visitor will need to be redesigned if it is to make them unique. Or I'll have to fix the regression test so that it doesn't count Drawables as Nodes.

This is really a major change that, I imagine, will break a lot of custom NodeVisitors. Porting osgWorks and osgBullet to this new paradigm might be much less possible than I originally thought.
-Paul

[Kevin Godby]

On Fri, Dec 11, 2015 at 6:32 PM, Paul Martz <skewm...@gmail.com> wrote:
> Looks like the changes were even more drastic than that. Geode now derives from Group, and Drawable from Node, The Geode (Group) children are now Node Drawables rather that a separate list of Drawables. This means Drawables now get visited by any NodeVisitor that has an apply(Node&).

NodeVisitor stuff has changed recently, too. I ran into a problem with
that a few weeks ago but don't recall the details right off. Just a
heads-up.

—Kevin

[Paul Martz]

Sleeping on this helped, and I realized the Uniqifier was failing because it had a stub apply(Geode&) that did nothing. If I removed it and allow all Geodes to be handled by apply(Group&), then everything works fine. By "works fine", I mean that, when building against current OSG, Geometry and Drawable objects are treated as Nodes by the Uniqifier, and made unique. But if building against older OSG, them Geometry and Drawables are treated as data and not made unique, which is the way things have always worked.

Kevin, thanks for being my sounding board, I really appreciate it.

Doug, my repo (github.com/pmartz/osgworks) is good for OSG 2.8.5 through to current OSG 3.5.1. I sent you two pull requests. One for the code changes, and the other to update the compatibility matrix on the wiki branch.

I'll turn my attention to osgBullet sometime in the future, but I have a couple other projects on my plate right now, so not sure when I can get to that.
-Paul