[osg-users] osgTerrain re-factoring

[Alan Harris]

Robert

As it appears you are starting to re-factor osgTerrain I have a few 
suggestions.


1) DataSet is something of a behemoth (approx 5000 lines) and would 
benefit from being broken down into standalone classes (and files). It 
already lends itself to that as there are a number of classes.


2) My recent submission on osgTerrain building in specific support for 
vector data sets should be considered. I should be stronger and say that 
height data by default should be considered as vector rather than 
raster. The majority of height data from various agencies around the 
World are vector data sets.


GDAL incorporates vector data via OGR (I think) but the formats are 
fairly limited.


3) With the use of vector data an expansion of HeightField might be 
useful. I derived a class from HeightField which allows better 
definition of the normals at the edge of tiles (you need to expand the 
field somehow to get the next point off the tile). I also added direct 
Node generation into the class rather than use the Shape / Drawable method.


4) I have a problem with my derived version of osgTerrain in that it 
crashes on my largest test case (20km x 20km at 0.5m resolution aerial 
photo). It used to crash on smaller cases, but adding tests where, for 
example, new Geodes fail to be created, appeared to cure those. So it 
may be a memory problem. It also fails at a different point each time 
(usually about 30% of the way through) which is after about 30 minutes. 
I have to sort this but it leads to a useful suggestion.


The set up of the database does not take long (about 5% of the total 
time). It would make sense to create a file containing the 
DestinationTile information at that point. Couple this with updating 
(and flushing) the archive index after every file write means that, by 
comparing the DestinationFile structure with the files already in the 
database, it would be feasible to re-start a database creation from the 
point where it failed.


It also allows repair of a database with re-generating the whole thing.


--

Regards
Alan Harris

ReSoft Ltd
Cornwallis, Burycroft Road
Hook Norton
Banbury, OX15 5PR, UK
Tel: +44 (0) 1608 730707
Email: [EMAIL PROTECTED]
Web: www.resoft.co.uk
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] GraphicsWindowWin32 is here! :-)

[Robert Osfield]

Hi Brian,

I wouldn't worry too much about scene graph destruction, this is
likely to be working just fine unless the compiler has screwed up.
Scene graph memory management is a pretty thoroughly exercised and
bedded down part of the OSG, so if there are problems here there is a
good chance its just a symptom of problems elsewhere.

The news parts of the code are osgViewer, and in particular the
threading and graphics window management.  So this is the most likely
place of any new issues that have been introduced.

osgViewer has undergone a huge amount of development of the past
months and during the last couple weeks has been bedding down, with
various bugs being fixed, in particular around the window, graphics
context and threading management.  Touch wood things are now working
pretty stable under Windows (VS build), Unix and OSX, even when
running mulit-threaded.  Due to all these improvements I'd strongly
recommend keeping up to date with the latest in SVN as there is always
that the problems you are seeing have been fixed thanks to other
improvements.

So the next question has to be which version are you working with right now?

Another note, the run method is a simply frame loop that just iterates
until the Viewer _done  is set to true - have a look at the code in
src/osgViewer/Viewer.cpp.   I don't think this be a factor in the
hang.  Most likely its the threads not cancelling for some reason.

Robert.



On 2/21/07, Brian Keener <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED]>

Robert Osfield wrote:
> The debug output doesn't look too suspicious. A stack trace is what
> is really required.

 Well,  in addition to the programs that I posted that do and do not terminate
successfully Ihave also managed to find at least come up with this.  Several
that I have looked at that do and do not terminate all have as the last line
(or nearly last line ) - in this case this is from osghangglide

 return viewer.run()

 if you do a bt in the debugger immediately on return from this line you get:

 (gdb) bt
#0  main (argc=1, argv=0x12294610) at ../osghangglide.cpp:185

and you will be at the main closing brace and then by stepping you get:

(gdb) s
0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll

(gdb) bt
#0  0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll
#1  0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll
#2  0x in ?? ()

(gdb)

 As I say the above is from osghangglide (which does not hang) and when I step
through osgviewer and osgwindows which also both use return viewer.run() at the
end of their main and do a bt I get the same as above.

I have inserted a lot of osg::notify in the code attempting to trace this
further and I am now curious about Group.  When a group is destructed is its
children supposed to be destructed too - should the children count decrease
each time the parent reference is remove from one - should there be a lot of
Groups created that never seem to have any children added.  I won't burden you
with the output (well actually I did - couldn't resist) but in osghangglide I
can see groups created and children added and then I can see the parent child
link being removed but the child count never decrements on the parent.  Where
as in osgwindows I see a lot of groups created that never have any children
added.  Just trying to get a handle on what those groups are.

For example the end of osghangglide with my notifies shows this:
Group::~Group() for group 0x122975b0completing with 4 to 4
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() for group 0x12297648completing with 1 to 1
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() for group 0x122977e0completing with 2 to 2
Image::~Image() completing
Image::~Image() completing
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() removing Parent for iterator which has 1 parents
Group::~Group() for group 0x1229c628completing with 9 to 9
Image::~Image() completing
Image::~Image() completing
Image::~Image() completing
Win32WindowingSystem::~Win32WindowingSystem() completing

[EMAIL PROTECTED] /usr/src/OpenSceneGraph/src
$

but notice the end of osgwindows with my notifies looks like this:
Image::~Image() completing
Group::~Group() for group 0x122a1308completing with 0 to 0
Group::~Group() for group 0x122a0cb0completing with 0 to 0
Group::~Group() for group 0x122a0728completing with 0 to 0
Group::~Group() for group 0x122a03b0comp

Re: [osg-users] osgTerrain renaming

[Robert Osfield]

HI Alan,

osgTerrain itself isn't being renamed, its the terrain building
classes and osgdem which will be moving out into their own project, to
its a new name.

On 2/22/07, Alan Harris <[EMAIL PROTECTED]> wrote:

Robert

New name? I prefer osgPlanet of those suggested. However, could lighten
up with:


osgPlanet is taken already :-)


osg42 or osgFortyTwo for ThoseThatPreferLongNames - I am an orphan of
MS-DOS (and originally CP/M) and love short cryptic names.

On the planet / world etc theme other possibilities come to mind:

osgUniverse
osgGalaxy
osgConstellation
osgOrionor other star / constellation
osgAndomeda   " "  ""

Scientist links:

osgCopernicus
osgGalileo
osgNewton


While there is certainly scope for developing NodeKits like the above
the project in question will be about building terrain including whole
planets, it won't be about rendering them or providing extensions to
the scene graph to support them.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osgTerrain renaming

[Ulrich Hertlein]

Alan Harris wrote:
New name? I prefer osgPlanet of those suggested. However, could lighten 


Personally I like PlanetBuilder. (Reminds me of 'Ringworld Engineers' if 
anyone remembers that.)


/Ulrich

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osgTerrain re-factoring

[Robert Osfield]

Hi Alan,

On 2/22/07, Alan Harris <[EMAIL PROTECTED]> wrote:

As it appears you are starting to re-factor osgTerrain I have a few
suggestions.

1) DataSet is something of a behemoth (approx 5000 lines) and would
benefit from being broken down into standalone classes (and files). It
already lends itself to that as there are a number of classes.


Indeed DataSet grew and grew and grew, I think Roald Dahl must have
spinkled some magic dust on it from beyond the grave :-)

Eventually I'd expect to see DataSet replaced, but in the first cut of
the code once its moved out of the core OSG would be consider
flattening the classes, so that they sit in their own files and not in
the DataSet scope.


2) My recent submission on osgTerrain building in specific support for
vector data sets should be considered. I should be stronger and say that
height data by default should be considered as vector rather than
raster. The majority of height data from various agencies around the
World are vector data sets.

GDAL incorporates vector data via OGR (I think) but the formats are
fairly limited.


I haven't had a chance to review these changes yet.  When you say
vector data, what exactly do you mean?  It could cover a huge range of
data usage, do you mean lines? Do you mean clouds of x,y,z point?


3) With the use of vector data an expansion of HeightField might be
useful. I derived a class from HeightField which allows better
definition of the normals at the edge of tiles (you need to expand the
field somehow to get the next point off the tile). I also added direct
Node generation into the class rather than use the Shape / Drawable method.


I am planning to separate out the rendering of height fields into a
proper NodeKit style extension of the core OSG.  I don't have an API
for it yet.  I do plan to use vertex and fragment shaders extensively.
The height fields would be effectively a displacement map, with the
base mesh typically regular but would support irregular base mesh.

The terrain building tools could then use the height field rendering
or create polygon osg::Geometry meshes as done at present.


4) I have a problem with my derived version of osgTerrain in that it
crashes on my largest test case (20km x 20km at 0.5m resolution aerial
photo). It used to crash on smaller cases, but adding tests where, for
example, new Geodes fail to be created, appeared to cure those. So it
may be a memory problem. It also fails at a different point each time
(usually about 30% of the way through) which is after about 30 minutes.
I have to sort this but it leads to a useful suggestion.

The set up of the database does not take long (about 5% of the total
time). It would make sense to create a file containing the
DestinationTile information at that point. Couple this with updating
(and flushing) the archive index after every file write means that, by
comparing the DestinationFile structure with the files already in the
database, it would be feasible to re-start a database creation from the
point where it failed.

It also allows repair of a database with re-generating the whole thing.


Early in osgTerrain we used to have crashes, but I haven't personally
seen a crash for over a year.  Fixing the crash would be certainly be
important, but since you've working with your own extensions to
osgTerrain I can't really comment on what might be the cause.

Allow a build to restart once begun is something that I have planned
for the new terrain building project.  The move to place the existing
terrain building code out into its own distribution will be done
first, and osgTerrain will be developed further as a NodeKit dedicated
to rendering terrain, but not building it.   The terrain building
project will come later, but I won't actually get to this until April
at the earliest.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Crash with DrawThreadPerContext

[Tugkan Calapoglu]

Robert Osfield wrote:

HI Tugkan,

The most likely cause is state or drawables being updated while the
draw thread is still reading from them, the mechanism to prevent the
them overlapping this is based on the use of DataVariance being set to
DYNAMIC.  See my previous posts on this topic.




Hi Robert,

I've worked more on the subject and repeated the crash in a simple 
application derived from osgviewer. You can find it attached. Unlike our 
application it also happens in SingleTreaded mode here. As far as I 
understand the new threading system it should be safe to access the 
scene graph outside the frame() method. And anyway it is single threaded 
mode here.


As I was working on this problem I ran into another problem also. If I 
call viewer.getCamera()->getOrCreateStateSet()->setDataVariance( 
osg::Object::DYNAMIC ) before the main loop and switch to 
DrawThreadPerContext mode using 'm' application freezes.


See if blocks at the end of the main(). First block is for freezing and 
the second block is for crash.




Tugkan

-
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone+49.8031.463640
fax  +49.8031.463645
email[EMAIL PROTECTED]
internet www.vires.com
-
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein  HRB 10410
Geschaeftsfuehrer: Marius Dupuis
   Wunibald Karl
-


osgviewer.cpp.tar.gz
Description: GNU Zip compressed data
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

AW: [osg-users] osgTerrain re-factoring

[Schmidt, Richard, SDGE1]

Hi,
We just did some work using the pagedLOD stuff, which fits the topic
well. But instead of pregenerating tiles, we are generating the tiles on
the fly. Our geometry generator is implemented as a osg plugin, so we
can use the databasepager as a background worker. :-) Well, it's kind of
a hack but since the pager is implemented really nice we get the
requested tiles fast. Infact we can create (rastered) vmap level 0 tiles
using this online process.

Well, if I will continue working on that, I would make the following
design decisions:

* Split up the code into the rasterizer and the stuff for generating
paged hierarchies. Both are mostly independent from another and require
just a small interface. We would have like three interfaces for
** landscape geometry
** scene geometry
** landscape textures
and there you are allowed to attach your arbitrary GIS tool.

* Allow pagedLOD setup loading nodes from a cache as well as requesting
them via "pseudo plugin" which generates stuff online.

* Cache online generated nodes and invalidate nodes to create the online
again.

* If you still want the whole process offline, just write a node visitor
which writes the files to an archive.

So that our heading, would be great if we could use some stuff from
osgDem (again).

Richard Schmidt
System Design Center Germany
EADS, Defence and Security

EADS Deutschland GmbH
Registered Office: Ottobrunn
District Court of Munich HRB 107 648
Chairman of the Supervisory Board: Dr. Thomas Enders
Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht
 
This E-mail and any attachment(s) to it are for the addressee's use
only.  It is strictly confidential and may contain legally privileged
information. No confidentiality or privilege is waived or lost by any
mistransmission. If you are not the intended addressee, then please
delete it from your system and notify the sender immediately. You are
hereby notified that any use, disclosure, copying or any action taken in
reliance on it is strictly prohibited and may be unlawful.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osgTerrain re-factoring

[Serge Lages]

Hi all,

On 2/22/07, Schmidt, Richard, SDGE1 <[EMAIL PROTECTED]> wrote:


Hi,
We just did some work using the pagedLOD stuff, which fits the topic
well. But instead of pregenerating tiles, we are generating the tiles on
the fly. Our geometry generator is implemented as a osg plugin, so we
can use the databasepager as a background worker. :-) Well, it's kind of
a hack but since the pager is implemented really nice we get the
requested tiles fast. Infact we can create (rastered) vmap level 0 tiles
using this online process.



On my project we do both, we load pregenerated tiles then switch to
procedurals one when there is no more tiles to load. It's also implemented
with an osg plugin.

Well, if I will continue working on that, I would make the following

design decisions:

* Split up the code into the rasterizer and the stuff for generating
paged hierarchies. Both are mostly independent from another and require
just a small interface. We would have like three interfaces for
** landscape geometry
** scene geometry
** landscape textures
and there you are allowed to attach your arbitrary GIS tool.



It is what we have done, we don't use osgdem and we have made another tool
allowing to preprocess terrain, textures and content (scenes on the terrain)
separately. Like that you can process any layer of textures that you want
and blend them at run-time for example. We have made a custom PagedLOD
allowing to recompose the nodes at run-time (by taking the terrain geometry,
the textures and the content).

* Allow pagedLOD setup loading nodes from a cache as well as requesting

them via "pseudo plugin" which generates stuff online.

* Cache online generated nodes and invalidate nodes to create the online
again.

* If you still want the whole process offline, just write a node visitor
which writes the files to an archive.

So that our heading, would be great if we could use some stuff from
osgDem (again).



Currently our system allows loading all the data from :
- separated ive files (like osgdem).
- one big archive (not an osga one, we have done a special archive type
special for lod trees)
- databases, like pgsql, mysql or sqlite.

I hope that most of these features should be integrated to OpenPlanetBuilder
(or VirtualWorldBuilder, or anything :)).

--
Serge Lages
http://www.magrathea-engine.org
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Crash with DrawThreadPerContext

[Robert Osfield]

Hi Tugkan,

Thanks for the example code.  I've enable the compile of each of the
three #if #elif sections in term and they are run and exit cleanly.
Nothing appers to be amiss.  Are you using the latest OSG in SVN?

W.r.t when its safe to modify the scene graph, its safe to modify any
DYNAMIC scene graph leaves (Drawable + StateSet) any time outwith the
Viewer::renderingTraversals() call.  When you aren't running
DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext there
isn't even the limitation of modification of just DYNAMIC scene graph
leaves.

As to what might be amiss at your end I don't know.

Robert.


On 2/22/07, Tugkan Calapoglu <[EMAIL PROTECTED]> wrote:

I've worked more on the subject and repeated the crash in a simple
application derived from osgviewer. You can find it attached. Unlike our
application it also happens in SingleTreaded mode here. As far as I
understand the new threading system it should be safe to access the
scene graph outside the frame() method. And anyway it is single threaded
mode here.

As I was working on this problem I ran into another problem also. If I
call viewer.getCamera()->getOrCreateStateSet()->setDataVariance(
osg::Object::DYNAMIC ) before the main loop and switch to
DrawThreadPerContext mode using 'm' application freezes.

See if blocks at the end of the main(). First block is for freezing and
the second block is for crash.



Tugkan

-
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone+49.8031.463640
fax  +49.8031.463645
email[EMAIL PROTECTED]
internet www.vires.com
-
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein  HRB 10410
Geschaeftsfuehrer: Marius Dupuis
Wunibald Karl
-

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/



___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Producer::Render Surface to osg::Camera attachment?

[May, Scott]

Is there a straight forward way to take the Producer's RenderSurface and
Make it a texture or image?

I want try the example where osg::Camera has an attach image feature and
then updated from the camera, but we are set-up using Producer camera's.


Thanks for your time,
- Scott

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Crash with DrawThreadPerContext

[Tugkan Calapoglu]

Hi Robert,

Hi Tugkan,

Thanks for the example code.  I've enable the compile of each of the
three #if #elif sections in term and they are run and exit cleanly.
Nothing appers to be amiss.  Are you using the latest OSG in SVN?



This seems strange.

I have made the tests with SVN version from yesterday morning.

After your email I made one more update and recompiled everything. I 
still observe the problems.


I went on to a different computer (different HW and OS version) and made 
a fresh checkout. Still the same crash (with the same backtrace) and freeze.


Here are the test systems:
Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46
Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46

I'd like to debug it myself here but I don't know what to look for.


--
Tugkan Calapoglu

-
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone+49.8031.463640
fax  +49.8031.463645
email[EMAIL PROTECTED]
internet www.vires.com
-
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein  HRB 10410
Geschaeftsfuehrer: Marius Dupuis
   Wunibald Karl
-
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Crash with DrawThreadPerContext

[Robert Osfield]

Hi Tugkan,

Are you able to get a stack trace?

Robert.

On 2/22/07, Tugkan Calapoglu <[EMAIL PROTECTED]> wrote:

Hi Robert,
> Hi Tugkan,
>
> Thanks for the example code.  I've enable the compile of each of the
> three #if #elif sections in term and they are run and exit cleanly.
> Nothing appers to be amiss.  Are you using the latest OSG in SVN?
>

This seems strange.

I have made the tests with SVN version from yesterday morning.

After your email I made one more update and recompiled everything. I
still observe the problems.

I went on to a different computer (different HW and OS version) and made
a fresh checkout. Still the same crash (with the same backtrace) and freeze.

Here are the test systems:
Suse 9.3 , Core 2 Duo , GF7900GTX x 2 , NV driver 97.46
Suse 10.2, Core 2 Duo, Quaddro GX 4500 , NV driver 97.46

I'd like to debug it myself here but I don't know what to look for.


--
Tugkan Calapoglu

-
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone+49.8031.463640
fax  +49.8031.463645
email[EMAIL PROTECTED]
internet www.vires.com
-
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein  HRB 10410
Geschaeftsfuehrer: Marius Dupuis
Wunibald Karl
-
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] osgkeyboard

[ha.public]

hi,

I am new to osg and so I have some beginner troubles

one is, that when I write a eventhandler for keyboardinput, keyup und
keydown events repeat when a key is pressed for a longer time (0.5 secund
or so)
is this the normal behavior?
is there a chance to avoid the repeat of up and down events while a key is
pressed?

code for eventhandler looks like this, from the samples

//header
class MyEventHandler : public osgGA::GUIEventHandler {

public:
MyEventHandler();
virtual ~MyEventHandler();
virtual bool handle(const osgGA::GUIEventAdapter&
ea,osgGA::GUIActionAdapter&);

};


//impl
MyEventHandler::MyEventHandler()
{

}

//---

MyEventHandler::~MyEventHandler()
{

}

//---

bool
MyEventHandler::handle(const osgGA::GUIEventAdapter&
ea,osgGA::GUIActionAdapter& aa)
{

switch(ea.getEventType())   {

case(osgGA::GUIEventAdapter::KEYDOWN): {
std::cout << "KEYDOWN" << std::endl;
break;
}

case(osgGA::GUIEventAdapter::KEYUP): {
std::cout << "KEYUP" << std::endl;
break;
}
}


}


thanks for help

gwg
harri


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osgkeyboard

[ha.public]

additional info, i have forgotten to write befor, sory

the osgkeyboard sample i have has the same problem

eg. I press the f key and hold it, screen writes

Press some keys.. fff

until i let the f key off

system is slackware 11

lg
harri

> hi,
>
> I am new to osg and so I have some beginner troubles
>
> one is, that when I write a eventhandler for keyboardinput, keyup und
> keydown events repeat when a key is pressed for a longer time (0.5
> secund or so)
> is this the normal behavior?
> is there a chance to avoid the repeat of up and down events while a key
> is pressed?
>
> code for eventhandler looks like this, from the samples
>
> //header
> class MyEventHandler : public osgGA::GUIEventHandler {
>
> public:
> MyEventHandler();
> virtual ~MyEventHandler();
> virtual bool handle(const osgGA::GUIEventAdapter&
> ea,osgGA::GUIActionAdapter&);
>
> };
>
>
> //impl
> MyEventHandler::MyEventHandler()
> {
>
> }
>
> //---
>
> MyEventHandler::~MyEventHandler()
> {
>
> }
>
> //---
>
> bool
> MyEventHandler::handle(const osgGA::GUIEventAdapter&
> ea,osgGA::GUIActionAdapter& aa)
> {
>
>   switch(ea.getEventType())   {
>
>   case(osgGA::GUIEventAdapter::KEYDOWN): {
>   std::cout << "KEYDOWN" << std::endl;
>   break;
>   }
>
>   case(osgGA::GUIEventAdapter::KEYUP): {
>   std::cout << "KEYUP" << std::endl;
>   break;
>   }
>   }
>
>
> }
>
>
> thanks for help
>
> gwg
> harri
>
>
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/



___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Windows Vista

[Mihai Radu]

Hi,

I had problems with Vistan on a MacBook pro, svn compiled fine with 
VS2005(sp1 + patch), but when the viewer was realized, all I got was a 
black screen, and the machine froze (looks like the graphics froze).


I blame ATI and their drivers (using the latest mobility drivers from 
the ati site)


hardware:
Intel Core Duo
ati X1600 mobile 128mb
1.5 Gb ram

Anybody has any experience with vista & ati ?

Cheers
Mihai

Adrian Egli wrote:

Hi,

(1) Windows Vista and OSG works, after we installed the latest graphic 
driver, everything works like on an other windows (xp) machine.


(2) everybody in my country talk about the engery troubles and clime 
change we will go in in the next few years. why should the world go 
using vista? i don't know, or
is the microsoft company powered by the engery like 2u bush. :-) 
Anders do you have some benchmark showing exactly the issue 20% more 
energy conumption using vista compared to xp. so may we can write some 
nice things, i guess there will be some politics being interested in 
such a idee, in switzerland the will add some extra tax / penalties 
for huge energy consumption cars, machnines and so on.


2007/2/21, Anders Backman <[EMAIL PROTECTED] >:

Well, if 20% of all windowsXP users switch to vista today, the CPU
energy consumption (even on idle) will go up quite a lot (my
laptop is averaging on 20% doing nothing), the fan is running
constantly, its always warm. So I would say it consumes about
twice as much energy...

This would also make the energyconsumption go up quite a bit.

Not what you would like to see for the world, right?

People will by newer faster machine to cope with VISTA, which will
make the energy consumption go up even higher.

Didn't Bill look at "An Inconvenient Truth"?

Funny article regarding updating to Vista:

  http://www.theregister.co.uk/2007/02/14/pricey_beta_bugger/



/Anders


On 2/21/07, *Gerrick Bivins* < [EMAIL PROTECTED]
> wrote:

Our app (VE-Suite) has been running on Vista as usual. We've
installed it on various configs such as a laptop with a 6800
Go card and even a lowly p4 with fx 5200. No problems. The
5200 is using driver 97.46 (which is the only one that
supports the 5200) and the lappy is using the latest and
greatest. biv

 
On 2/21/07, *Gordon Tomlinson* < [EMAIL PROTECTED]

> wrote:

OpenGL Sucks on Vista right now and direct X is not
much better
 
Thats what we have found any way, Nvidia is hurting on

Vista at this time.
 
As a company we do see Vista a a platform right now, our

customer base wont
touch it for at least 2 years
 


__
/
Gordon Tomlinson
// Email /: [EMAIL PROTECTED]
/
YIM/AIM/: Gordon3dBrit
/MSN IM /: [EMAIL PROTECTED]
/
Website/   : www. 3dscenegraph.com

__


"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
- */Master Tambo Tetsura/*

 
 




*From:* [EMAIL PROTECTED]
 [mailto:
[EMAIL PROTECTED]
] *On Behalf
Of *Adrian Egli
*Sent:* Wednesday, February 21, 2007 6:29 AM
*To:* osg users
*Subject:* [osg-users] Windows Vista

 
hi


i have a windows vista since yesterday, i will test osg on
it as soon as possible, what are others expirience ?


/Adegli

___
osg-users mailing list
osg-users@openscenegraph.net

http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/



___
osg-users mailing list
osg-users@openscenegraph.net 
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/




-- 




Anders Backman   

Re: [osg-users] osgText: font aliasing issue

[Bruno Fanini]

I'm still having these issues.

It's not related to font resolution, I tried the exact settings of osgText
examples, the issue is about aliasing.
In the first post of this thread there are 2 screenshots, it's clear how
black arrows (it's a character) are blocky and also the 'a' - for example -
is aliased bad.
In the osgText examples instead (screenshot attachment "osgtext.gif") they
are smooth, well antialiased.

So I tried enabling lots of stateset GL modes, but none worked... still
having "blocky" and bad fonts

How can I solve this?

--
Bruno


On 2/6/07, Robert Osfield <[EMAIL PROTECTED]> wrote:


On 2/6/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> Hi Bruno,
>
> The clue to the solution is in the line:
>
>Label.get()->setFontResolution(40,40);

Forgot to mention, ref_ptr is a smart pointer, you can often treat it
just like a normal C pointer so the above doesn't need the get() to
return a C pointer, the following works just fine:

   label->setFontResolution(40,40);

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] osgTerrain renaming

[Norman Vine]

Robert Osfield  writes:
> 
> osgTerrain itself isn't being renamed, its the terrain 
> building classes and osgdem which will be moving out into 
> their own project, to its a new name.
> 
> On 2/22/07, Alan Harris <[EMAIL PROTECTED]> wrote:
> > Robert
> >
> > New name? I prefer osgPlanet of those suggested. However, could 
> > lighten up with:
> 
> osgPlanet is taken already :-)

Robert

First the bad news 
osgPlanet has renamed itself to ossimPlanet.

Now the good news.
Please feel free to use the osgPlanet name  :-)

Cheers

Norman


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osgkeyboard

[ha.public]

found the solution

_viewer->realize();
_viewer->getKeyboardMouse()->setAutoRepeatMode(false);

(autorepeat must be called after realize or it will block)

thats it,

sorry for just making traffic on the mail list, but for a beginner its
realy hard to find out wich funktion is where and what i does (or not)
(the _autorepead in Producer::KeyboardMouse where I looked first confused
me so  I search at the complet wrong place)


lg
harri

> additional info, i have forgotten to write befor, sory
>
> the osgkeyboard sample i have has the same problem
>
> eg. I press the f key and hold it, screen writes
>
> Press some keys.. fff
>
> until i let the f key off
>
> system is slackware 11
>
> lg
> harri



___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] using osgdem with thousands of input files

[Wojciech Lewandowski]

Is there a way to run osgdem with list of files to proceed given as separate 
file ? 
I am looking for some solution where command line would be simple and look like 
this:

> osgdem -t images.filelist -d elevation.filelist -o output.ive 

where images.filelist is a text file containing list of files to process 
separated by newlines 

[contents of images.filelist]
image_raster1.tiff
...
image_rasterN.tiff
[eof]

and elevation.filelist contains dem files to proceed. 

[contents of elevation.filelist]
elevation_raster1.aux
...
elevation_rasterM.aux
[eof]


When we run command line with thousand of "-t/-d file"  arguments windows give 
up. Command line too long. Under linux it may work but unfortunately we use OSG 
with Windows ;-(. Directory option does not work for either because some of the 
unknown extensions in the directory are not read correctly and osgdem crashes. 
For example we have a DEM directory with .aux .dem and .rrd files. Only .aux 
files should be passed as arguments. .rrd and .dems cause crash when we use -d 
directory option. On the other hand .dem files cannot be removed from this 
directory because they are indirectly used by GDAL when .aux are loaded.

Any workaround ideas ? 

Best Regards,
Wojtek Lewandowski
  ___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osgText: font aliasing issue

[Robert Osfield]

Hi Bruno.

Try text->setFontResolution(120,120);

Robert.

On 2/22/07, Bruno Fanini <[EMAIL PROTECTED]> wrote:

I'm still having these issues.

It's not related to font resolution, I tried the exact settings of osgText
examples, the issue is about aliasing.
In the first post of this thread there are 2 screenshots, it's clear how
black arrows (it's a character) are blocky and also the 'a' - for example -
is aliased bad.
In the osgText examples instead (screenshot attachment "osgtext.gif") they
are smooth, well antialiased.

So I tried enabling lots of stateset GL modes, but none worked... still
having "blocky" and bad fonts

How can I solve this?

--
Bruno



On 2/6/07, Robert Osfield <[EMAIL PROTECTED] > wrote:
> On 2/6/07, Robert Osfield <[EMAIL PROTECTED] > wrote:
> > Hi Bruno,
> >
> > The clue to the solution is in the line:
> >
> >Label.get()->setFontResolution(40,40);
>
> Forgot to mention, ref_ptr is a smart pointer, you can often treat it
> just like a normal C pointer so the above doesn't need the get() to
> return a C pointer, the following works just fine:
>
>label->setFontResolution(40,40);
>

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] using osgdem with thousands of input files

[Robert Osfield]

Hi Wojciech,

Perhaps you could tweak osgdem to use a filename file of the
directories, or create a text file with a list of all the files then
add support into osgdem for reading the list of files from the text
file instead of the command line.

Another thing you could try is Cygwin see if it has better command line support.

Robert.

On 2/22/07, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:



Is there a way to run osgdem with list of files to proceed given as separate
file ?
I am looking for some solution where command line would be simple and look
like this:

> osgdem -t images.filelist -d elevation.filelist -o output.ive

where images.filelist is a text file containing list of files to process
separated by newlines

[contents of images.filelist]
image_raster1.tiff
...
image_rasterN.tiff
[eof]

and elevation.filelist contains dem files to proceed.

[contents of elevation.filelist]
elevation_raster1.aux
...
elevation_rasterM.aux
[eof]


When we run command line with thousand of "-t/-d file"  arguments windows
give up. Command line too long. Under linux it may work but unfortunately we
use OSG with Windows ;-(. Directory option does not work for either because
some of the unknown extensions in the directory are not read correctly and
osgdem crashes. For example we have a DEM directory with .aux .dem and .rrd
files. Only .aux files should be passed as arguments. .rrd and .dems cause
crash when we use -d directory option. On the other hand .dem files cannot
be removed from this directory because they are indirectly used by GDAL when
.aux are loaded.

Any workaround ideas ?

Best Regards,
Wojtek Lewandowski

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] using osgdem with thousands of input files

[Wojciech Lewandowski]

Thanks, I will do it if there is no other option. I hoped that maybe GDAL 
has undocumented support for such filelists ;-).


Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>

To: "osg users" 
Sent: Thursday, February 22, 2007 6:03 PM
Subject: Re: [osg-users] using osgdem with thousands of input files



Hi Wojciech,

Perhaps you could tweak osgdem to use a filename file of the
directories, or create a text file with a list of all the files then
add support into osgdem for reading the list of files from the text
file instead of the command line.

Another thing you could try is Cygwin see if it has better command line 
support.


Robert.

On 2/22/07, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:



Is there a way to run osgdem with list of files to proceed given as 
separate

file ?
I am looking for some solution where command line would be simple and 
look

like this:

> osgdem -t images.filelist -d elevation.filelist -o output.ive

where images.filelist is a text file containing list of files to process
separated by newlines

[contents of images.filelist]
image_raster1.tiff
...
image_rasterN.tiff
[eof]

and elevation.filelist contains dem files to proceed.

[contents of elevation.filelist]
elevation_raster1.aux
...
elevation_rasterM.aux
[eof]


When we run command line with thousand of "-t/-d file"  arguments windows
give up. Command line too long. Under linux it may work but unfortunately 
we
use OSG with Windows ;-(. Directory option does not work for either 
because
some of the unknown extensions in the directory are not read correctly 
and
osgdem crashes. For example we have a DEM directory with .aux .dem and 
.rrd
files. Only .aux files should be passed as arguments. .rrd and .dems 
cause
crash when we use -d directory option. On the other hand .dem files 
cannot
be removed from this directory because they are indirectly used by GDAL 
when

.aux are loaded.

Any workaround ideas ?

Best Regards,
Wojtek Lewandowski

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/




___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] OpenFlight LightPoint Problem

[Brian R Hill]

Folks,

Light points in external references aren't being loaded.

When I load the individual files the light points are fine. When I load 
them as external references in another file the lightpointnodes are 
created but they are empty (zero light points).

Any ideas?

Thanks,

Brian


This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] OpenFlight LightPoint Problem (OpenFlight version 15.7)

[Brian R Hill]

Folks, 

Clarification: These are Creator 2.5.1 files (OpenFlight 15.7)

Light points in external references aren't being loaded. 

When I load the individual files the light points are fine. When I load 
them as external references in another file the lightpointnodes are 
created but they are empty (zero light points). 

Any ideas? 

Thanks, 

Brian___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] using osgdem with thousands of input files

[Alan Harris]

Hi Wojtek

I believe osgdem already accepts a folder as opposed to a file name and 
processes all the files in the folder (function processFile()).


Cheers
Alan

Wojciech Lewandowski wrote:
Thanks, I will do it if there is no other option. I hoped that maybe 
GDAL has undocumented support for such filelists ;-).


Cheers,
Wojtek

- Original Message - From: "Robert Osfield" 
<[EMAIL PROTECTED]>

To: "osg users" 
Sent: Thursday, February 22, 2007 6:03 PM
Subject: Re: [osg-users] using osgdem with thousands of input files



Hi Wojciech,

Perhaps you could tweak osgdem to use a filename file of the
directories, or create a text file with a list of all the files then
add support into osgdem for reading the list of files from the text
file instead of the command line.

Another thing you could try is Cygwin see if it has better command 
line support.


Robert.

On 2/22/07, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:



Is there a way to run osgdem with list of files to proceed given as 
separate

file ?
I am looking for some solution where command line would be simple 
and look

like this:

> osgdem -t images.filelist -d elevation.filelist -o output.ive

where images.filelist is a text file containing list of files to 
process

separated by newlines

[contents of images.filelist]
image_raster1.tiff
...
image_rasterN.tiff
[eof]

and elevation.filelist contains dem files to proceed.

[contents of elevation.filelist]
elevation_raster1.aux
...
elevation_rasterM.aux
[eof]


When we run command line with thousand of "-t/-d file"  arguments 
windows
give up. Command line too long. Under linux it may work but 
unfortunately we
use OSG with Windows ;-(. Directory option does not work for either 
because
some of the unknown extensions in the directory are not read 
correctly and
osgdem crashes. For example we have a DEM directory with .aux .dem 
and .rrd
files. Only .aux files should be passed as arguments. .rrd and .dems 
cause
crash when we use -d directory option. On the other hand .dem files 
cannot
be removed from this directory because they are indirectly used by 
GDAL when

.aux are loaded.

Any workaround ideas ?

Best Regards,
Wojtek Lewandowski

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/




___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Glimpse into future support for distortion correction

[Anders Backman]

If that is your "image" of Umeå, I don't think you have seen Umeå from its
best side...
A CPP file :-)

I know we are coding quite a lot, but I would have expected some more colors
in your image of Umeå!!


Did you forget to attach an image?

/Anders

On 2/22/07, Robert Osfield <[EMAIL PROTECTED]> wrote:


Hi All,

One of the tasks bubbling along in the background is support for
distortion correction in osgViewer.  osgViewer itself won't provide
the support but will allow you to set up the required cameras and
distortion meshes as custom scene graph elements.   This week I
generalised a couple of components in osgViewer, SceneView and Camera
to allow to work, ableit in app hardwired way.

Eventually you'll be able to set this all up from a configuration file
which will specify both the camera set up and the distortion
correction mesh, then in any osgViewer::Viewer app you'll just need to
load the configuration file and your app will be able to support novel
displays without the need for extra distortion correction hardware, or
coding from yourself.

As a proof of concept the osgdistortion example now has an extra code
path that creates 6 RTT Camera's to generate a cube environment map
and one HUD camera for distorion correction all within a single
osgViewer::Viewer.  The user of the viewer only sees the result of the
last HUD camera, so it'll feel like you using one fancy camera rather
than 7...

What do the results look like?  See attached image of the town of Umea
(thanks for VRLab for the model :-)

The distortion correction here is for a mythical 360 degree projector
at the center of dome, no such beast exists, but the code in
osgdistortion is about proof of concept.  Proper math models for the
distortion correction of real physical display configurations will
follow, although not this week.

Robert.

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/





--



Anders Backman   Email:[EMAIL PROTECTED]
HPC2N/VRlab  Phone:+46 (0)90-786 9936
Umea university  Cellular: +46 (0)70-392 64 67
S-901 87 UMEA SWEDEN Fax:  +46 90-786 6126
  http://www.cs.umu.se/~andersb
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] using osgdem with thousands of input files

[Thom DeCarlo]

There is already directory loading support in osgdem. However, it tries to
load _all_ of the files in the named directories. That means it will fail if
the data format requires more than one file per dataset. (e.g., Edas Imagine
format which uses *.img, *.ige, *.rde, etc.)

But, if you can translate your data into a single file per dataset format
(such as geoTIFF) then you may see more success. I know that it has worked
for me.

Thom

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:osg-users-
> [EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski
> Sent: Thursday, February 22, 2007 12:10 PM
> To: osg users
> Subject: Re: [osg-users] using osgdem with thousands of input files
> 
> Thanks, I will do it if there is no other option. I hoped that maybe GDAL
> has undocumented support for such filelists ;-).
> 
> Cheers,
> Wojtek
> 
> - Original Message -
> From: "Robert Osfield" <[EMAIL PROTECTED]>
> To: "osg users" 
> Sent: Thursday, February 22, 2007 6:03 PM
> Subject: Re: [osg-users] using osgdem with thousands of input files
> 
> 
> > Hi Wojciech,
> >
> > Perhaps you could tweak osgdem to use a filename file of the
> > directories, or create a text file with a list of all the files then
> > add support into osgdem for reading the list of files from the text
> > file instead of the command line.
> >
> > Another thing you could try is Cygwin see if it has better command line
> > support.
> >
> > Robert.
> >
> > On 2/22/07, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> Is there a way to run osgdem with list of files to proceed given as
> >> separate
> >> file ?
> >> I am looking for some solution where command line would be simple and
> >> look
> >> like this:
> >>
> >> > osgdem -t images.filelist -d elevation.filelist -o output.ive
> >>
> >> where images.filelist is a text file containing list of files to
> process
> >> separated by newlines
> >>
> >> [contents of images.filelist]
> >> image_raster1.tiff
> >> ...
> >> image_rasterN.tiff
> >> [eof]
> >>
> >> and elevation.filelist contains dem files to proceed.
> >>
> >> [contents of elevation.filelist]
> >> elevation_raster1.aux
> >> ...
> >> elevation_rasterM.aux
> >> [eof]
> >>
> >>
> >> When we run command line with thousand of "-t/-d file"  arguments
> windows
> >> give up. Command line too long. Under linux it may work but
> unfortunately
> >> we
> >> use OSG with Windows ;-(. Directory option does not work for either
> >> because
> >> some of the unknown extensions in the directory are not read correctly
> >> and
> >> osgdem crashes. For example we have a DEM directory with .aux .dem and
> >> .rrd
> >> files. Only .aux files should be passed as arguments. .rrd and .dems
> >> cause
> >> crash when we use -d directory option. On the other hand .dem files
> >> cannot
> >> be removed from this directory because they are indirectly used by GDAL
> >> when
> >> .aux are loaded.
> >>
> >> Any workaround ideas ?
> >>
> >> Best Regards,
> >> Wojtek Lewandowski
> >>
> >> ___
> >> osg-users mailing list
> >> osg-users@openscenegraph.net
> >> http://openscenegraph.net/mailman/listinfo/osg-users
> >> http://www.openscenegraph.org/
> >>
> > ___
> > osg-users mailing list
> > osg-users@openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
> 
> 
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] OpenFlight LightPoint Problem (OpenFlight version 15.7)

[Paul Martz]

Set a breakpoint at ReaderWriterFLT.cpp line 206 and make sure the parent
light point palette isn't overriding the ext ref. From the description of
your model, this shouldn't be happening (unless you have mis-configured the
parent model ext ref record).
 
A breakpoint at LightPointRecords.cpp line 78 might also be illuminating
(excuse the pun) then step through the code if that breakpoint gets hit.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian R Hill
Sent: Thursday, February 22, 2007 10:47 AM
To: osg users
Subject: [osg-users] OpenFlight LightPoint Problem (OpenFlight version 15.7)



Folks, 

Clarification: These are Creator 2.5.1 files (OpenFlight 15.7) 

Light points in external references aren't being loaded. 

When I load the individual files the light points are fine. When I load them
as external references in another file the lightpointnodes are created but
they are empty (zero light points). 

Any ideas? 

Thanks, 

Brian

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Glimpse into future support for distortion correction

[Rafa Gaitan]

just change .cpp extension to .gif ;)

On 2/22/07, Anders Backman <[EMAIL PROTECTED]> wrote:


If that is your "image" of Umeå, I don't think you have seen Umeå from its
best side...
A CPP file :-)

I know we are coding quite a lot, but I would have expected some more
colors in your image of Umeå!!


Did you forget to attach an image?

/Anders

On 2/22/07, Robert Osfield <[EMAIL PROTECTED] > wrote:

> Hi All,
>
> One of the tasks bubbling along in the background is support for
> distortion correction in osgViewer.  osgViewer itself won't provide
> the support but will allow you to set up the required cameras and
> distortion meshes as custom scene graph elements.   This week I
> generalised a couple of components in osgViewer, SceneView and Camera
> to allow to work, ableit in app hardwired way.
>
> Eventually you'll be able to set this all up from a configuration file
> which will specify both the camera set up and the distortion
> correction mesh, then in any osgViewer::Viewer app you'll just need to
> load the configuration file and your app will be able to support novel
> displays without the need for extra distortion correction hardware, or
> coding from yourself.
>
> As a proof of concept the osgdistortion example now has an extra code
> path that creates 6 RTT Camera's to generate a cube environment map
> and one HUD camera for distorion correction all within a single
> osgViewer::Viewer.  The user of the viewer only sees the result of the
> last HUD camera, so it'll feel like you using one fancy camera rather
> than 7...
>
> What do the results look like?  See attached image of the town of Umea
> (thanks for VRLab for the model :-)
>
> The distortion correction here is for a mythical 360 degree projector
> at the center of dome, no such beast exists, but the code in
> osgdistortion is about proof of concept.  Proper math models for the
> distortion correction of real physical display configurations will
> follow, although not this week.
>
> Robert.
>
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
>


--



Anders Backman   Email: [EMAIL PROTECTED]
HPC2N/VRlab  Phone:+46 (0)90-786 9936
Umea university  Cellular: +46 (0)70-392 64 67
S-901 87 UMEA SWEDEN Fax:  +46 90-786 6126
   
http://www.cs.umu.se/~andersb
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Glimpse into future support for distortion correction

[Robert Osfield]

Forgot to mention, to try it out:

osgdistortion mymodel.osg --dome

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Glimpse into future support for distortion correction

[Toshiyuki TAKAHEI]

Hi Robert,

On Thu, 22 Feb 2007 17:33:28 +
"Robert Osfield" <[EMAIL PROTECTED]> wrote:
> 
> One of the tasks bubbling along in the background is support for
> distortion correction in osgViewer.  osgViewer itself won't provide
> the support but will allow you to set up the required cameras and
> distortion meshes as custom scene graph elements.   This week I
> generalised a couple of components in osgViewer, SceneView and Camera
> to allow to work, ableit in app hardwired way.

Nice work! It represents promising possibility of the osgViewer.

By the way, 'distortion meshes as custom scene graph elements' is
reasonable, but in my experiences, I need 'pixel level' distortion
in many cases. So I made a distortion/blending map creation tool
'Projection Designer', and also defined the distortion map
as an image file which encodes pixel warp mapping in color of pixels.
http://orihalcon.jp/projdesigner/
(Projection Designer is currently Windows version only, but its Linux
version is almost done.)

I also made osgdistortion based real-time distortion viewer:
http://orihalcon.jp/download/osgdistortviewer_src.zip
At that time I used Producer's camera configuration file to
specify the off-screen rendering matrixes. Maybe osgViewer also
need such kind of configuration data.

Regards,



Forwarded by Toshiyuki TAKAHEI <[EMAIL PROTECTED]>
--- Original Message ---
From:Toshiyuki TAKAHEI <[EMAIL PROTECTED]>
To:  osg-users@openscenegraph.net
Date:Mon, 07 Aug 2006 15:08:56 +0900
Subject: [osg-users] BOF presentation : osgDirector, ProjectionDesigner and 
osgdistortviewer


Hi all,

At the end of the Siggraph2006 BOF, I showed some of my OSG related
works.

1) osgDirector and Orihalcon framework

Last year I released osgDirector and Orihalcon framework
at http://orihalcon.sourceforge.net/.
osgDirector is a wxWidgets based graphical scene graph editor.
It contains some libraries which wrap and extend the OSG features.

2) ProjectionDesigner and osgdistortviewer

The second topic is about my recent work.
ProjectionDesigner is a geometry correction and edge blending
setup tool for immersive environment with a curved screen.
I made it for full dome projection with 13 channels.
http://orihalcon.jp/projdesigner/
Once you complete the projector configuration with it,
you can export a distortion map file, a blend map file and
camera configuration file (for Producer).

This is a sample OSG program using them for real-time
geometry / edge blending correction.
http://orihalcon.jp/download/osgdistortviewer_src.zip
I made it based on osgprerender, and add some additional arguments.
Ex.
osgdistortviewer.exe --distortionmap distort.png --blendmap blend.png 
dumptruck.osg
(distortion with a polygon mesh)
Ex.
osgdistortviewer.exe --shaderDistortion --distortionmap distort.png --blendmap 
blend.png dumptruck.osg
(distortion with GLSL shaders)

It's not easy to set up many projectors with it,
but anyway, you can do it.


I hope these projects would be helpful for you.

-- 
Toshiyuki TAKAHEI <[EMAIL PROTECTED]>


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] GraphicsWindowWin32 is here! :-)

[Brian Keener]

[EMAIL PROTECTED]>

My apologies if this is a double post - I relaized my first response was not 
under my subscriber email address

Robert Osfield wrote:
> recommend keeping up to date with the latest in SVN as there is always
> that the problems you are seeing have been fixed thanks to other
> improvements.

Yep I've noticed changes flying pretty rapidly

> So the next question has to be which version are you working with right now?

I've tried to stay current but with trying to work through this and get some 
displays to give me an idea whats happening I am sure I've fallen back some - 
I'll update from svn to get current and see how it looks.  Now that I have 
just tried I realize I must be farther back than I recall - I still have cvs 
not svn - bahh.  So does anyone know an easy way to update from the CVS version 
to the SVN - only thing I can think of (if you have some differences like I do) 
is create diff patch file from the cvs, checkout the SVN version and then apply 
the diff patch.
 
> Another note, the run method is a simply frame loop that just iterates
> until the Viewer _done  is set to true - have a look at the code in
> src/osgViewer/Viewer.cpp.   I don't think this be a factor in the
> hang.  Most likely its the threads not cancelling for some reason.

Yeah I've found the frame loop in src/osgViewer/Viewer.cpp and stepped through 
it but where I really need to get (as that loop runs pretty quick and by the 
time _done tests true is really to late I think) is I need to catch the ESC in 
the Windows which starts the terminate and then trace from there.  I was 
thinking either thread not cancelling or some object not destroying which 
might still be related but I need to catch that ESCAPE to terminate.  Tracing 
in the loop is too much code and once you drop out of the frame loop then most 
everything has either started destroying or is destroyed (I think).

bk





___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Glimpse into future support for distortion correction

[Robert Osfield]

Hi Toshiyuki,

On 2/22/07, Toshiyuki TAKAHEI <[EMAIL PROTECTED]> wrote:

Nice work! It represents promising possibility of the osgViewer.

By the way, 'distortion meshes as custom scene graph elements' is
reasonable, but in my experiences, I need 'pixel level' distortion
in many cases.


The general approach I've take could easily use a texture map to set
up the normals, its just a matter of setting up the scene graph
approrpriate, you can use all the normal scene graph primitive for the
rendering of the distortion mesh.

In this instance the distortion mesh usedis just an osg::Geometry
convering the full screen, with vertices arranged as a grid, with each
vertex having a Vec3 tex coord normal pointing into the cubemap.  The
graphics hardware interpolates between the tex coords so that
resulting tex coord used to look up the cubemap should be interpolated
reasonably well.


So I made a distortion/blending map creation tool
'Projection Designer', and also defined the distortion map
as an image file which encodes pixel warp mapping in color of pixels.
http://orihalcon.jp/projdesigner/
(Projection Designer is currently Windows version only, but its Linux
version is almost done.)


Cool, would a OSX port be possible as well? ;-)

My hope for the config file support for osgViewer is that it'll make
it possible for you to output a configuration file that could be
loaded my osgViewer based apps.



I also made osgdistortion based real-time distortion viewer:
http://orihalcon.jp/download/osgdistortviewer_src.zip
At that time I used Producer's camera configuration file to
specify the off-screen rendering matrixes. Maybe osgViewer also
need such kind of configuration data.


The osgViewer config file would contain both the camera setup and the
distortion mesh (and any textures required).  The config file format
will be an extension of the .osg file format so it'll be possible to
embed mini scene graphs directly into the config file, so things like
external references to texture maps will all be possible.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] GraphicsWindowWin32 is here! :-)

[Robert Osfield]

Hi Brian,

On 2/22/07, Brian Keener <[EMAIL PROTECTED]> wrote:

I've tried to stay current but with trying to work through this and get some
displays to give me an idea whats happening I am sure I've fallen back some -
I'll update from svn to get current and see how it looks. Now that I have
justtried I realize I must be farther back than I recall - I still have cvs
not svn - bahh.  So does anyone know an easy way to update from the CVS version
to the SVN - only thing I can think of (if you have some differences like I do)
is create diff patch file from the cvs, checkout the SVN version and then apply
the diff patch.


Why can't you just check out the SVN respositories?

svn checkout http://www.openscenegraph.com/svn/osg/OpenSceneGraph/trunk
OpenSceneGraph

svn checkout http://www.openscenegraph.com/svn/osg/OpenThreads/trunk OpenThreads


> Another note, the run method is a simply frame loop that just iterates
> until the Viewer _done is set to true - have a look at the code in
> src/osgViewer/Viewer.cpp. I don't think this be a factor in the
> hang. Most likely its the threads not cancelling for some reason.

Yeah I've found the frame loop in src/osgViewer/Viewer.cpp and stepped through
it but where I really need to get (as that loop runs pretty quick and by the
time _done tests true is really to late I think) is I need to catch the ESC in
the Windows which starts the terminate and then trace from there. I was
thinking either thread not cancelling or some object not destroying which
mightstill be related but I need to catch that ESCAPE to terminate. Tracing
in the loop is too much code and once you drop out of the frame loop then most
everything has either started destroying or is destroyed (I think).


Perhaps the easist would be to run the app for a fix number of frames
and let it exit itself then see if that works OK.  To help do
experiments with this I've added support for using an env var to set
the number of frames for the app to run:

 export OSG_RUN_FRAME_COUNT=10

 osgviewer cow.osg

osgviewer will run fro 10 frames and then exit.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Glimpse into future support for distortion correction

[Toshiyuki TAKAHEI]

Hi Robert,

On Thu, 22 Feb 2007 20:35:48 +
"Robert Osfield" <[EMAIL PROTECTED]> wrote:
> >
> > By the way, 'distortion meshes as custom scene graph elements' is
> > reasonable, but in my experiences, I need 'pixel level' distortion
> > in many cases.
> 
> The general approach I've take could easily use a texture map to set
> up the normals, its just a matter of setting up the scene graph
> approrpriate, you can use all the normal scene graph primitive for the
> rendering of the distortion mesh.
> 
> In this instance the distortion mesh usedis just an osg::Geometry
> convering the full screen, with vertices arranged as a grid, with each
> vertex having a Vec3 tex coord normal pointing into the cubemap.  The
> graphics hardware interpolates between the tex coords so that
> resulting tex coord used to look up the cubemap should be interpolated
> reasonably well.

Interesting. My distortion setup tool is intended to use with multiple
projections, and each PC renders only minimum required area into off-screen
buffer, not full cubemap, because of rendering performance.
Anyway, when I have time to work, I'll try to support these
distortion mesh output in my tool.


> > So I made a distortion/blending map creation tool
> > 'Projection Designer', and also defined the distortion map
> > as an image file which encodes pixel warp mapping in color of pixels.
> > http://orihalcon.jp/projdesigner/
> > (Projection Designer is currently Windows version only, but its Linux
> > version is almost done.)
> 
> Cool, would a OSX port be possible as well? ;-)

OK, I'll try. ;-)


> My hope for the config file support for osgViewer is that it'll make
> it possible for you to output a configuration file that could be
> loaded my osgViewer based apps.
> 
> 
> > I also made osgdistortion based real-time distortion viewer:
> > http://orihalcon.jp/download/osgdistortviewer_src.zip
> > At that time I used Producer's camera configuration file to
> > specify the off-screen rendering matrixes. Maybe osgViewer also
> > need such kind of configuration data.
> 
> The osgViewer config file would contain both the camera setup and the
> distortion mesh (and any textures required).  The config file format
> will be an extension of the .osg file format so it'll be possible to
> embed mini scene graphs directly into the config file, so things like
> external references to texture maps will all be possible.

Yes, the native support of camera setup configuration will
make the distortion/blending and cluster rendering be
transparent to contents. It's a really desirable solution!

Regards,

-- 
Toshiyuki TAKAHEI <[EMAIL PROTECTED]>


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] pysosg trouble to install

[elekis]

hi all,
I try to install pyosg, but I have that error after  have made scons

[EMAIL PROTECTED]:~/Desktop/pyosg_devel$ scons
scons: Reading SConscript files ...
WARNING: no OSG_ROOT env var set, defaulting to /usr/local/lib

scons: *** Path for option PYTHON_INCLUDES does not exist:
/usr/include/python2.3
File "/home/elekis/Desktop/pyosg_devel/SConstruct", line 78, in 
[EMAIL PROTECTED]:~/Desktop/pyosg_devel$


I ve tried export PYTHON_INCLUDES /usr/include/python2.5 but nothing change
and I don't no where OSG_ROOT is it.

any idea ?

thanks

a++
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] obscure state bug

[Terry Welsh]

I have a really weird bug that shows up in one of my apps.  Sometimes
objects get the wrong StateSet applied to them.  I have not been able
to produce a simple enough test case to send in yet, but I wanted to
know if anyone else has seen this problem in the last month.

The problem was introduced when RenderBin.cpp went from v1.46 to
v1.47.  The problem goes away if I add state.popAllStateSets(); at
line 386.
--
Terry Welsh - mogumbo 'at' gmail.com
www.reallyslick.com  |  www.mogumbo.com
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] lights, sceneview and multiply displays

[Gerrick Bivins]

Hi All,
A quick question about lighting and multiple displays. If we have a
configuration (vr envrionment) with multiple displays and a
scene view for each display/context:
1) does a sceneview require a light to be associated with it?
2) if so does EACH sceneview require a light?

biv
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] lights, sceneview and multiply displays

[Paul Martz]

Hi Gerrick -- The modes GL_LIGHTING and at least one light (such as
GL_LIGHT0) need to be enabled in each rendering context. You can enable
these modes in the scene graph; if that scene graph is assigned to multiple
SceneViews, it should "just work".
 
Does that answer your question?
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
303 859 9466
 

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gerrick Bivins
Sent: Thursday, February 22, 2007 5:18 PM
To: osg users
Subject: [osg-users] lights, sceneview and multiply displays


Hi All,
A quick question about lighting and multiple displays. If we have a
configuration (vr envrionment) with multiple displays and a 
scene view for each display/context:
1) does a sceneview require a light to be associated with it? 
2) if so does EACH sceneview require a light?
   
biv



___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] SVN .dsp problems

[John Swan-Stone]

F.Y.I.,

I just got the 'trunk' version out of SVN and double-clicking the 
OpenSceneGraph\VisualStudio\OpenSceneGraph.dsw file generates these errors in 
DevStudio6, SP6.

www.cs.utexas.edu/~jss/OSG/error1.jpg
www.cs.utexas.edu/~jss/OSG/error2.jpg
www.cs.utexas.edu/~jss/OSG/error3.jpg


Double-clicking the OpenThreads\win32_src\OpenThreads.dsw generates these erros 
in DevStudio6, SP6

Configuration: OpenThreads - Win32 Debug
Compiling...
Command line warning D4028 : minimal rebuild failure, reverting to normal build
WIN32Condition.cpp
c:\projects\openscenegraph-svn\openthreads\win32_src\win32condition.cpp(0) : 
fatal error C1033: cannot open program database '\\vc60.pdb'
Win32Mutex.cpp
c:\projects\openscenegraph-svn\openthreads\win32_src\win32mutex.cpp(0) : fatal 
error C1033: cannot open program database '\\vc60.pdb'
Win32Thread.cpp
c:\projects\openscenegraph-svn\openthreads\win32_src\win32thread.cpp(0) : fatal 
error C1033: cannot open program database '\\vc60.pdb'
Win32ThreadBarrier.cpp
c:\projects\openscenegraph-svn\openthreads\win32_src\win32threadbarrier.cpp(0) 
: fatal error C1033: cannot open program database '\\vc60.pdb'
Error executing cl.exe.

OpenThreadsWin32d.dll - 4 error(s), 1 warning(s)
The following environment variables were not found
$(PlatformName)
$(ConfigurationName)

J.___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/