[osg-users] osgDem Windows Front-End
Anyone knows of a Windows front-end for osgDem? I am writing one right now and would like to check out some examples first. Thanks, - Nick - _ Get Cultured With Arts & Culture Festivals On Live Maps http://local.live.com/?mkt=en-ca&v=2&cid=A6D6BDB4586E357F!2010&encType=1&style=h&FORM=SERNEP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
--- Begin Message ---
Hello,
answering to Nick Prudent's proposal for a Windows front-end for osgdem,
I would suggest to create an XML configuration file parser. XML files
are easily editable from specialized XML editor given a schema
definition of the file content.
Advantages over a specialized front end are:
- cross platform for free
- repeatability (can rerun a configuration file on error)
- documentation (can extract configuration in a human readable form for
reports)
- maintenance and expansibility (only need to update configuration file
parser and XML schema)
I am using a similar approach within my pet project, Le Petit Poucet GPS
software (petit-poucet.org). Main application is downloading and
geo-referencing images, then writing an XML configuration file
(attached, conf.ptig), then a specialized version of osgdem called
pti_gen, it is parsing this XML file and generating .osga (attached is
the crude parser I wrote based on Expat, parse_config.cpp).
My parser is not covering all features of osgdem command line and
vpb::DataSet but could be extended easily.
Note that I am using extensively GDAL's VRT format to add
geo-referencing to image files but this geo-referencing could be
included into the osgdem configuration. It is possible to pass to GDAL a
string containing XML corresponding to a VRT file.
Antoine
/home/tonio/.pti/cache/orig/YosemiteFall_gpx.osga
GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AXIS["Lat",NORTH],AXIS["Long",EAST],AUTHORITY["EPSG","4326"]]
/home/tonio/.pti/cache/imagery/landsat/YosemiteFall_gpx_landsat.vrt
/home/tonio/.pti/cache/imagery/srtm/YosemiteFall_gpx_srtm.vrt
/home/tonio/.pti/cache/imagery/usgs_drg/YosemiteFall_gpx_usgs_drg.vrt
/home/tonio/.pti/cache/imagery/us_ned/YosemiteFall_gpx_us_ned.vrt
///@file pti_gen.cpp
/// 3D terrain generator config file parser
///
///@author Antoine Hue
///@date 26.06.2007
/*
This file is part of Le-Petit-Poucet
Le-Petit-Poucet is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include
#include
#include
#include
#include
#include
#include
#include
typedef enum {
tt_unknown = 0,
tt_pti_gen,
tt_bin_path,
tt_archive_file,
tt_gdal_data,
tt_srs,
tt_geospatial_extents,
tt_source
} tag_type_t;
typedef struct tag_mapping {
tag_type_t tag_type; /* enum from above for this tag */
const char *tag_name; /* xpath-ish tag name */
} tag_mapping;
/*
* xpath(ish) mappings between full tag paths and internal identifers.
* These appear in the order they appear in the GPX specification.
* If it's not a tag we explictly handle, it doesn't go here.
*/
tag_mapping tag_path_map[] = {
{tt_pti_gen, "/pti_gen"},
{tt_bin_path, "/pti_gen/bin_path"},
{tt_archive_file, "/pti_gen/archive_file"},
{tt_gdal_data, "/pti_gen/gdal_data"},
{tt_srs, "/pti_gen/srs"},
{tt_geospatial_extents, "/pti_gen/geospatial_extents"},
{tt_source, "/pti_gen/source"},
{tt_unknown}
};
static tag_type_t get_tag(const char *t)
{
tag_mapping *tm;
for (tm = tag_path_map; tm->tag_type != tt_unknown; tm++)
if (0 == strcmp(tm->tag_name, t))
return tm->tag_type;
return tt_unknown;
}
static tag_type_t current_tag = tt_unknown;
static std::string xpath;
static std::string c_cdata;
static bool image_source = false;
static int n_source = 0;
static const char *get_attr ( const char **attr, const char *key )
{
while ( *attr ) {
if ( strcmp(*attr,key) == 0 )
return *(attr + 1);
attr += 2;
}
return NULL;
}
static void start(vpb::DataSet *ds, const char *el, const char **attr)
{
xpath += '/';
xpath += el;
current_tag = get_tag ( xpath.c_str() );
c_cdata.clear();
switch ( current_tag )
{
case tt_pti_gen:
case tt_bin_path:
case tt_archive_file:
case tt_gdal_data:
case tt_srs:
break;
case tt_geospatial_extents:
{
double xMin, yMin, xMax, yMax;
bool geo;
xMin = strtod(get_attr(attr, "min_x"), NULL);
yMin = strtod(get_attr(attr, "min_y"), NULL);
xMax = strtod(get_attr(attr, "max_x"), NULL);
yMax = strtod(get_attr(attr, "max_y"), NULL);
geo = atoi(get_attr(attr, "geograph
Re: [osg-users] osgDem Windows Front-End
Antoine, Thanks for the advice. Actually, I have already started saving osgDem parameters as XML to allow users to save their sessions. My clients have "Command-Line-O-Phobia", so they asked me to add a simple UI for executing osgDem. It's not difficult, but I was wondering if anyone had done this in the past. I'm specially interested in how to provide feedback while the data is being generated. osgDem works like a 3rd party renderer like Mental Ray and RenderMan. Some people cannot use these products unless they have a graphical UI to interact with. That's were I come in ;) Regards, - Nick - > >answering to Nick Prudent's proposal for a Windows front-end for osgdem, I >would suggest to create an XML configuration file parser. XML files are >easily editable from specialized XML editor given a schema definition of >the file content. _ See Fireworks On Live Image Search http://search.live.com/images/results.aspx?q=Fireworks&mkt=en-ca&FORM=SERNEP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
Nick Prudent wrote: > Antoine, > > Thanks for the advice. Actually, I have already started saving osgDem > parameters as XML to allow users to save their sessions. > > My clients have "Command-Line-O-Phobia", so they asked me to add a simple UI > for executing osgDem. It's not difficult, but I was wondering if anyone had > done this in the past. I'm specially interested in how to provide feedback > while the data is being generated. > > osgDem works like a 3rd party renderer like Mental Ray and RenderMan. Some > people cannot use these products unless they have a graphical UI to interact > with. That's were I come in ;) > > I understand the value of GUI but I tend to be GUI-o-sceptic. GUI have a lot of value in helping the end user understanding a complex task/design and avoiding having to learn and remember something like VI commands. However, they also get very frustrating for power users that now have been over complexity. Some professional applications provide a GUI but are able to generate a script to accomplish the same command sequence without clicking over and over. This is not that bad and is a good way to learn. Moreover, osgdem has a lot of features and the underneath DataSet class even more. I hope you will find a nice way to wrap this! Antoine ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
FYI, I am currently changing the way that VTPB defines its source and
destination graphs. The source data is based on the
osgTerrain::Terrain/Layer classes and serialization. The destination
graph is not yet set but right now looks most likely to reuse PagedLOD
directly. The serialization will be supported by both .osg and .ive.
With the new work there will be several apps that can be run to
process chunks for the serialized destination graph. These will be
able to run multi-threaded as well as distributed across the network.
These apps will be nature be command line driven.
Defining the source data could be defined in an xml format, although
it won't really get you much over the .osg based source graph
serialization Follows is a current example:
osgTerrain::Terrain
{
name "puget sound"
ElevationLayer
{
CartesianLocator 0 0 100 100
Image ps_height_512.tif
}
ColorLayer
{
CartesianLocator 0 0 100 100
Images
{
ps_height_512.tif
ps_texture_1k.tif
}
}
}
I haven't modified osgdem to use the above as an input file format,
but this should be possible - one just loads the source data and then
traverse the loaded scene graph for its Terrain nodes, this could then
help build the old style source graph.
osgdem itself will stay largely untouched while I rewrite VPB, all the
new features will grow alongside it, and when they are ready and well
tested it should be possible to just drop osgdem.
In my planed work I don't have a GUI front end planned, exactly what a
GUI might need to encompass will depend upon how the final low level
code/apps work. Note that my VPB work will deliver have a system that
can do incremental and distributed builds, something osgdem can't do -
it just has to everything in a one pass.
The VPB work does mean that I can't recommend investing much effort
into osgdem. If you can spend a day mocking up a front end then fine,
but do expect it to be replaced within the next six months by
something that is quite different in the way it works.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
Robert,
Thanks for the update. No matter how it's implemented internally, there is
still a need for my clients to not have to hack a command line or a text/xml
file. They are not programmers (they don't even use Windows's
CommandPrompt). When VPB is up and running, I'll just update the back-end to
reflect that.
XML is great way to save parameters in a cross-platform fashion.
- Nick -
From: "Robert Osfield" <[EMAIL PROTECTED]>
Reply-To: osg-users@lists.openscenegraph.org
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] osgDem Windows Front-End
Date: Sat, 18 Aug 2007 16:54:23 +0100
FYI, I am currently changing the way that VTPB defines its source and
destination graphs. The source data is based on the
osgTerrain::Terrain/Layer classes and serialization. The destination
graph is not yet set but right now looks most likely to reuse PagedLOD
directly. The serialization will be supported by both .osg and .ive.
With the new work there will be several apps that can be run to
process chunks for the serialized destination graph. These will be
able to run multi-threaded as well as distributed across the network.
These apps will be nature be command line driven.
Defining the source data could be defined in an xml format, although
it won't really get you much over the .osg based source graph
serialization Follows is a current example:
osgTerrain::Terrain
{
name "puget sound"
ElevationLayer
{
CartesianLocator 0 0 100 100
Image ps_height_512.tif
}
ColorLayer
{
CartesianLocator 0 0 100 100
Images
{
ps_height_512.tif
ps_texture_1k.tif
}
}
}
I haven't modified osgdem to use the above as an input file format,
but this should be possible - one just loads the source data and then
traverse the loaded scene graph for its Terrain nodes, this could then
help build the old style source graph.
osgdem itself will stay largely untouched while I rewrite VPB, all the
new features will grow alongside it, and when they are ready and well
tested it should be possible to just drop osgdem.
In my planed work I don't have a GUI front end planned, exactly what a
GUI might need to encompass will depend upon how the final low level
code/apps work. Note that my VPB work will deliver have a system that
can do incremental and distributed builds, something osgdem can't do -
it just has to everything in a one pass.
The VPB work does mean that I can't recommend investing much effort
into osgdem. If you can spend a day mocking up a front end then fine,
but do expect it to be replaced within the next six months by
something that is quite different in the way it works.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_
Former Police Officer Paul Gillespies TAKE BACK THE INTERNET tips and
tricks, watch the video now http://safety.sympatico.msn.ca/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
On 8/18/07, Nick Prudent <[EMAIL PROTECTED]> wrote: > Robert, > > Thanks for the update. No matter how it's implemented internally, there is > still a need for my clients to not have to hack a command line or a text/xml > file. They are not programmers (they don't even use Windows's > CommandPrompt). When VPB is up and running, I'll just update the back-end to > reflect that. > > XML is great way to save parameters in a cross-platform fashion. XML is O.K for saving parameters, but I would say its rather a stretch to say its a great way... The ascii example I provided will be a lot more human readable than any XML format. Writing serialization code in .osg format is not too difficult write, and in the case of future VPB work you won't actually need to write anything to do the serialization and the loading and saving will all be done for you via the src/osgPlugins/osgTerrain plugin. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
On 8/18/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > On 8/18/07, Nick Prudent <[EMAIL PROTECTED]> wrote: > > Robert, > > > > Thanks for the update. No matter how it's implemented internally, there > is > > still a need for my clients to not have to hack a command line or a > text/xml > > file. They are not programmers (they don't even use Windows's > > CommandPrompt). When VPB is up and running, I'll just update the > back-end to > > reflect that. > > > > XML is great way to save parameters in a cross-platform fashion. > > XML is O.K for saving parameters, but I would say its rather a stretch > to say its a great way... > > The ascii example I provided will be a lot more human readable than > any XML format. Writing serialization code in .osg format is not too > difficult write, and in the case of future VPB work you won't actually > need to write anything to do the serialization and the loading and > saving will all be done for you via the src/osgPlugins/osgTerrain > plugin. > > Hi Robert, In this case I disagree with you (about the human readable, not the serialization part where you are right). XML has the advantage of having a lot of really good editors (even graphical ones), adding to that the possibility to make .XSD files to validate your XML (and to help edit them, it's so cool with Visual Studio to write an XML with an XSD reference file...), it's much easier to to not make mistake writting an XML than a custom format where you can look for hours before finding a missing bracket or ";". Another advantage of XML is also that in all programming languages there are good parsers, allowing to create easily a GUI for the configuration files without having to write the parsing part. I thing that the current wave of XML based formats like COLLADA, KML, Open XML and others are a really good thing. Voilà, that was just my two cents on the subject. :) -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
Hello Nick, > I'm specially interested in how to provide feedback > while the data is being generated. I worked on a renderfarm management software in the past, and what I would do is read the stdout of the external process (in that case, a command-line renderer like Mental Ray or Maya/Lightwave's command-line renderers, in your case osgdem) and parse it. On a Unix variant, you can just open a pipe to the running process's stdout (IIRC), but on Windows I don't know how you'd do that. Once that's done, you'd have to find tokens that allow you to deduce the progress and use that to give feedback. I can't really help you for that, as I don't know what kind of output osgdem produces... So I guess I didn't really add to what you already knew, other than to say it can be done. :-) Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDem Windows Front-End
HI Serge, When I say human readable I mean just that, directly readable without the need for a special editor. XML sucks in this department. Its barely human readable without special editors. If end users want to add xml input to setting up VPB then that just fine, one could even do this via a plugin - note that its a plugin that is loading the .osgTerrain, this would allow you to do the dead of xml support without any modifications to VPB. Robert. On 8/18/07, Serge Lages <[EMAIL PROTECTED]> wrote: > On 8/18/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > On 8/18/07, Nick Prudent <[EMAIL PROTECTED]> wrote: > > > Robert, > > > > > > Thanks for the update. No matter how it's implemented internally, there > is > > > still a need for my clients to not have to hack a command line or a > text/xml > > > file. They are not programmers (they don't even use Windows's > > > CommandPrompt). When VPB is up and running, I'll just update the > back-end to > > > reflect that. > > > > > > XML is great way to save parameters in a cross-platform fashion. > > > > XML is O.K for saving parameters, but I would say its rather a stretch > > to say its a great way... > > > > The ascii example I provided will be a lot more human readable than > > any XML format. Writing serialization code in .osg format is not too > > difficult write, and in the case of future VPB work you won't actually > > need to write anything to do the serialization and the loading and > > saving will all be done for you via the src/osgPlugins/osgTerrain > > plugin. > > > > > > Hi Robert, > > In this case I disagree with you (about the human readable, not the > serialization part where you are right). XML has the advantage of having a > lot of really good editors (even graphical ones), adding to that the > possibility to make .XSD files to validate your XML (and to help edit them, > it's so cool with Visual Studio to write an XML with an XSD reference > file...), it's much easier to to not make mistake writting an XML than a > custom format where you can look for hours before finding a missing bracket > or ";". > > Another advantage of XML is also that in all programming languages there are > good parsers, allowing to create easily a GUI for the configuration files > without having to write the parsing part. I thing that the current wave of > XML based formats like COLLADA, KML, Open XML and others are a really good > thing. > > Voilà, that was just my two cents on the subject. :) > > -- > Serge Lages > http://www.magrathea-engine.org > ___ > osg-users mailing list > 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
