[osg-users] Setting up VPBMaster

Jean-Sébastien Guay jean-sebastien.guay at cm-labs.com
Mon Nov 2 09:44:11 PST 2009

Hi Jacob,

> However, my former co-worker 
> wrote a method that handles an ARG_FILE as input to OSGDem and feeds it 
> the parameters as necessary to execute them. I believe this method is 
> doing what vpbmaster would do, if I could get it running. 

Actually vpbmaster does more than that, it allows you to distribute your 
generation tasks over a network of machines so that your total 
generation would take much less time. It's a bit too late for that now, 
but I expect that's the major benefit Robert had in mind when steering 
you towards vpbmaster.

As for your problems, VPB releases are tied to OSG releases, so you need 
them to match. According to the VPB site, even very old versions of VPB 
(0.9.1) required at least OSG 2.2, so I'm not sure what VPB version 
matches OSG 1.2, and even if you can find it, I'm absolutely sure it 
won't have vpbmaster, as that appeared for VPB 0.9.2 as you can see by 
comparing these two links:


Now, in the interest of full disclosure, I can tell you the hard way of 
doing things, just so you can choose yourself whether you want to 
upgrade your app to a recent OSG release or not...

To be able to use vpbmaster and still load the resulting database into 
OSG 1.2, you will need to:

1. Compile a recent OSG (2.8 for example)
2. Compile a recent VPB (0.9.10 to match OSG 2.8 for example)
3. Generate your database using --POLYGONAL so that no osgTerrain 
rendering techniques are used, and generate it into .osg format instead 
of .ive format as that's not backwards-compatible
4. Optionally, you can then make a tool/script to reconvert all the .osg 
files to .ive using OSG 1.2's osgconv tool (there's a page on the VPB 
wiki about this, which hopefully will be obsoleted soon by Chris's 

I'm probably forgetting other options you'd need to specify when 
generating to make sure your resulting files are compatible with OSG 
1.2. The resulting .osg files (assuming you don't do step 4) will be 
much larger and slower to load than the corresponding .ive files, and 
converting them to .ive (step 4) will take a long time (probably close 
to the same time that was needed to generate the database in the first 

So, in the process, you'll compile a recent OSG anyways, and you'll be 
disabling all the features that make that recent release worthwhile. 
You'll also be generating much more data, and spending more time doing 
so. And finally, we won't be able to help you much if the steps I've 
outlined above lead to more problems which I might not have anticipated. 
I don't know about you, but that sounds like a lose-lose situation to me.

Now, you've already invested a lot of time generating the database 
you're doing right now, so keep that of course. But for next time you 
need to generate something like that, you might want to consider what I 
said above. Hope this helps,

Jean-Sebastien Guay    jean-sebastien.guay at cm-labs.com

More information about the osg-users mailing list