[osg-users] osgTerrain renaming

[Alan Harris]

Robert

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


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

--
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] Windows Vista

[Paul Speed]

Well, and it seems like service pack 2 is always the magic number...
-Paul

Paul Sherman wrote:

Two years is what we decided as well for the general adoption period (and 
probably 4 or 5 for government agencies). The (not so funny) quip I am using 
right now is that "I am going to wait for the lawsuits to die down."


- Paul

On Wednesday 21 February 2007 05:13, Gordon Tomlinson 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


___
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] premake?

[Mike Weiblen]

Hi,

Oh well, premake doesn't seem to support XCode.
For OSG, I realize that's a deal breaker.   rats.

-- mew



Mike Weiblen wrote:
> Hi,
> 
> fwiw I played around w/ premake a bit today, and it seems pretty cool.  I'm
> going to try it on a real project, try to find if it has any stubborn 
> limitations.
> 
> -- mew
> 
> 
> Robert Osfield wrote:
> 
>>Hi Mike,
>>
>>On 2/20/07, Mike Weiblen <[EMAIL PROTECTED]> wrote:
>>
>>
>>>there's previously been mention of premake (http://premake.sf.net) as
>>>a soln to
>>>OSG's multiplatform build requirements.  has anyone come to any
>>>conclusions?  I
>>>was going to give it an eval.
>>
>>
>>I have just followed the link to the project description
>>(http://premake.sourceforge.net/about) and could but help laugh at the
>>sentence:
>>
>>"Premake allows you to manage your project configuration in one place
>>and still support those pesky IDE-addicted Windows coders and/or
>>cranky Linux command-line junkies. "
>>
>>Yep that describes us bunch pretty well :-)
>>
>>It'd be great if members of the community you explore premake.
>>
>>Robert.
>>___
>>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] GraphicsWindowWin32 is here! :-)

[Brian Keener]

[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 0x122a03b0completing with 0 to 0
Group::~Group() for group 0x1229fd18completing with 0 to 0
Group::~Group() for group 0x1229fa80completing with 0 to 0
Group::~Group() for group 0x1229efd8completing with 0 to 0
Program::~Program() finishing with 0 shaders
Projection::~Projection() terminating
Group::~Group() for group 0x1229ea28completing with 0 to 0
Group::~Group() for group 0x1229e7c0completing with 0 to 0
Group::~Group() for group 0x1229e340completing with 0 to 0
Group::~Group() for group 0x1229c788completing with 0 to 0
Group::~Group() for group 0x1229b940completing with 0 to 0
Group::~Group() for group 0x12299760completing with 0 to 0
Viewport::~Viewport() terminating

Not sure if any of this makes sense but trying to piece it together and the one 
thing I notice above is that at the end of osgwindows I never see the line for 

Win32WindowingSystem::~Win32WindowingSystem() completing

since I have to kill it at the above Viewport::~Viewport() line.
 
> A little bit of hope is that perhaps the hang on exit you see if
> related to the OSX X11 hang on exit.

Well in this case we are not attempting to use the X11 for Cygwin but simply 
keeping in the standard windows logic.

bk



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

Re: [osg-users] runtime plugin discovery

[Hartmut Seichter]

Found the discussion, thanks for the pointer. I certainly prefer the 
one-by-one method Robert was mentioning. It is just an addition to the 
existing method of loading on-demand.


/Hartmut


Paul Martz wrote:

I recently added the ability to load the extension map from a configuration
file. Currently the application has to call into the registry and pass the
name of the configuration file, then the Registry sets the map contents from
the file.

As I made that change, it did bring up the discussion of runtime plugin
discovery. You might search the archives for about 1 month back to see what
was discussed.
   -Paul



-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
Hartmut Seichter

Sent: Wednesday, February 21, 2007 3:07 PM
To: osg users
Subject: [osg-users] runtime plugin discovery


Hi there,

I was wondering how others here around would solve the 
following "feature":


An end user application should be able to fill up the file 
dialog with a list (to filter files) of available 3D model 
formats (or Image file) depending on what plugins are known 
to the registry.


Brute force version of this would be to load all osgdb_* 
plugins and query the map (unfortunately protected) ... but 
there we run into all kinds of problems with: which plugin 
was first? hence, which one should be used/ has priority as 
the alias will be overwritten by the latest one loaded.


Ideally osgDB::Registry should be really a registry which 
doesn't hardcode the alias maps. I would argue the plugins 
themself know better what they can be used for. And I think 
somebody already seen the problems:


line 191 in osgDB/Registry.cpp:
// really need to decide this at runtime...

Any thoughts welcome!

/Hartmut





___
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] runtime plugin discovery

[Paul Martz]

I recently added the ability to load the extension map from a configuration
file. Currently the application has to call into the registry and pass the
name of the configuration file, then the Registry sets the map contents from
the file.

As I made that change, it did bring up the discussion of runtime plugin
discovery. You might search the archives for about 1 month back to see what
was discussed.
   -Paul


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Hartmut Seichter
> Sent: Wednesday, February 21, 2007 3:07 PM
> To: osg users
> Subject: [osg-users] runtime plugin discovery
> 
> 
> Hi there,
> 
> I was wondering how others here around would solve the 
> following "feature":
> 
> An end user application should be able to fill up the file 
> dialog with a list (to filter files) of available 3D model 
> formats (or Image file) depending on what plugins are known 
> to the registry.
> 
> Brute force version of this would be to load all osgdb_* 
> plugins and query the map (unfortunately protected) ... but 
> there we run into all kinds of problems with: which plugin 
> was first? hence, which one should be used/ has priority as 
> the alias will be overwritten by the latest one loaded.
> 
> Ideally osgDB::Registry should be really a registry which 
> doesn't hardcode the alias maps. I would argue the plugins 
> themself know better what they can be used for. And I think 
> somebody already seen the problems:
> 
> line 191 in osgDB/Registry.cpp:
> // really need to decide this at runtime...
> 
> Any thoughts welcome!
> 
> /Hartmut
> 
> 
> 
> 
> 
> ___
> 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] premake?

[Hartmut Seichter]

Mike Weiblen wrote:

Hi all,

there's previously been mention of premake (http://premake.sf.net) as a soln to
OSG's multiplatform build requirements.  has anyone come to any conclusions?  I
was going to give it an eval.



Maybe you can also have a look into bakefile:

http://bakefile.sourceforge.net


/Hartmut



cheers
-- mew
___
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] runtime plugin discovery

[Hartmut Seichter]

Hi there,

I was wondering how others here around would solve the following "feature":

An end user application should be able to fill up the file dialog with a 
list (to filter files) of available 3D model formats (or Image file) 
depending on what plugins are known to the registry.


Brute force version of this would be to load all osgdb_* plugins and 
query the map (unfortunately protected) ... but there we run into all 
kinds of problems with: which plugin was first? hence, which one should 
be used/ has priority as the alias will be overwritten by the latest one 
loaded.


Ideally osgDB::Registry should be really a registry which doesn't 
hardcode the alias maps. I would argue the plugins themself know better 
what they can be used for. And I think somebody already seen the problems:


line 191 in osgDB/Registry.cpp:
// really need to decide this at runtime...

Any thoughts welcome!

/Hartmut





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

Re: [osg-users] Names for Thread and Terrain classes

[Rafa Gaitan]

Hi Robert,

I vote for OpenPlanetBuilder or VirtualWorldBuilder, any of them likes to
me!

I'm not sure if this is the thread to talk about the desing or structures,
but in our
project we are making some development to work with different layers but all
the work is done on the fly,
maybe you could have these kind of uses on mind. ;)

Rafa

On 2/21/07, Adrian Egli <[EMAIL PROTECTED]> wrote:


hi robert,

i vote for names like: VirtualWorldBuilder, TerraBuilder

2007/2/21, Jean-Sebastien Guay <[EMAIL PROTECTED] >:
>
> Hello Robert,
>
> > (Open)TerrainBuilder?  (Open)PlanetBuilder?
>
> I would vote for one of these. Probably the second (with or without the
> "open"
> prefix) as it sparks the imagination more. Also, you avoid the religious
> implications of using the Genesis term, which might be good these days
> (even
> though I'm a fan of Star Trek myself and seeing that name gave me
> visions of
> what would be possible with such a tool! :-).
>
> J-S
> --
> __
> Jean-Sebastien Guay [EMAIL PROTECTED]
> http://whitestar02.webhop.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] Names for Thread and Terrain classes

[Gordon Tomlinson]

Hi

I think we may have TM/Copyright  issues using TerrainBuilder  or
WorldBuilder they are well used terms, also whatch out for MS as they have
sucked up a lot of names that have any thing to do with  VE  I think MPI
have WorldBuilder trademarked  its the old name of CTS


Best Regards



Gordon

__

Gordon Tomlinson
Email  : gordon.tomlinson @ overwatch.com
YIM/AIM: Gordon3dBrit
MSN IM : Gordon3dBrit @ 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


  -Original Message-
  From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Adrian Egli
  Sent: Wednesday, February 21, 2007 3:54 PM
  To: osg users
  Subject: Re: [osg-users] Names for Thread and Terrain classes


  hi robert,

  i vote for names like: VirtualWorldBuilder, TerraBuilder


  2007/2/21, Jean-Sebastien Guay <[EMAIL PROTECTED] >:
Hello Robert,

> (Open)TerrainBuilder?  (Open)PlanetBuilder?

I would vote for one of these. Probably the second (with or without the
"open"
prefix) as it sparks the imagination more. Also, you avoid the religious
implications of using the Genesis term, which might be good these days
(even
though I'm a fan of Star Trek myself and seeing that name gave me
visions of
what would be possible with such a tool! :-).

J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.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] Names for Thread and Terrain classes

[Adrian Egli]

hi robert,

i vote for names like: VirtualWorldBuilder, TerraBuilder

2007/2/21, Jean-Sebastien Guay <[EMAIL PROTECTED]>:


Hello Robert,

> (Open)TerrainBuilder?  (Open)PlanetBuilder?

I would vote for one of these. Probably the second (with or without the
"open"
prefix) as it sparks the imagination more. Also, you avoid the religious
implications of using the Genesis term, which might be good these days
(even
though I'm a fan of Star Trek myself and seeing that name gave me visions
of
what would be possible with such a tool! :-).

J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.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] Names for Thread and Terrain classes

[Jean-Sebastien Guay]

Hello Robert,

> (Open)TerrainBuilder?  (Open)PlanetBuilder?

I would vote for one of these. Probably the second (with or without the "open"
prefix) as it sparks the imagination more. Also, you avoid the religious
implications of using the Genesis term, which might be good these days (even
though I'm a fan of Star Trek myself and seeing that name gave me visions of
what would be possible with such a tool! :-).

J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] huge frame rate increase win32

[Zach Deedler]

Important question,

On windows XP and OSG1.2,
Anybody know why my frame rate goes up from 174 to 235 when I press alt-tab
to bring the command prompt window into the foreground, or run maximized
instead of fullscreen?  The draw time seems to go down about 0.2ms.  Update,
cull, and GPU look unaffected.

Zach

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

Re: [osg-users] Windows Vista

[Paul Sherman]

Two years is what we decided as well for the general adoption period (and 
probably 4 or 5 for government agencies). The (not so funny) quip I am using 
right now is that "I am going to wait for the lawsuits to die down."

- Paul

On Wednesday 21 February 2007 05:13, Gordon Tomlinson 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
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] multi-threading

[Guy Lifchitz]

Hello,
I'm using OSG as the rendering engine in MFC multi-document application.
I'm planning each child window to show different scene, therefore I create
different osgProducer::Viewer for each child window, and set in each one
different scene data. To have continuous update on each of those windows I
create different thread that updates the relevant view.
Now having more than one window, sometimes leads to crush of the
application. When I use synchronize mechanism for the threads to prevent
simultanious "viewer.sync()" "viewer.update()" & "viewer.frame()" it works
well, but I think with performance cost.
To farther investigate the subject I changed the code of the osgviewer demo
application to create few threads, each having different osgProducer::Viewer
and data. Here no crush happened even with no synchronization.

I wanted to ask, what might be the problem? could it be accessing of static
class members? because nothing else is common to the different threads, or
maybe you think it's windows mechanism problem.

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

Re: [osg-users] Windows Vista

[Adrian Egli]

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   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] osg::CullStack reflector

[Mike Wittman]

Hi Robert,

> To go over the hurdle I have gone ahead and changed the affected
> methods to return RefMatrix* rather than RefMatrix&.  So CullStack now
> works fine in the wrappers, but it did require a number of changes to
> the OSG.  Using a pointer rather than a & is no bad thing in this
> instance so I'm happy with this change.

Ok, thanks.  That resolves the immediate problem.

> Being able to to properly hanve T& and const T& is important for the
> wrappers though, as this problem has arisen a number of times, and
> converting to * isn't alway approrpriate.  There is also a performance
> penalty involved in constructor objects you don't need to construct.

There's also an object slicing problem if the function returns a
subclass of the declared return type.  I'll see if I can't resolve the
reference-return issue with the change I mentioned.

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

Re: [osg-users] osg::CullStack reflector

[Robert Osfield]

HI Mike,

On 2/21/07, Mike Wittman <[EMAIL PROTECTED]> wrote:

Hi Robert,

I also tried enabling the osg::CullStack reflector after I sent that
email and got the same errors you did.  I looked into it a bit and it
appears that the problem is the Value constructor treating everything
that's not a T* or const T* as a value type.  The problem occurs at the
implicit construction of the return value of the invoke member function.

I don't think there's a way to distinguish between T, T& and const T&
via type inference, but it should be possible by explicitly specifying
the function return type as a template parameter to a factory function.
I'll give that a shot and see if I can resolve the problem in
osgIntrospection.


To go over the hurdle I have gone ahead and changed the affected
methods to return RefMatrix* rather than RefMatrix&.  So CullStack now
works fine in the wrappers, but it did require a number of changes to
the OSG.  Using a pointer rather than a & is no bad thing in this
instance so I'm happy with this change.

Being able to to properly hanve T& and const T& is important for the
wrappers though, as this problem has arisen a number of times, and
converting to * isn't alway approrpriate.  There is also a performance
penalty involved in constructor objects you don't need to construct.

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

RE: [osg-users] osg::CullStack reflector

[Mike Wittman]

Hi Robert,

I also tried enabling the osg::CullStack reflector after I sent that
email and got the same errors you did.  I looked into it a bit and it
appears that the problem is the Value constructor treating everything
that's not a T* or const T* as a value type.  The problem occurs at the
implicit construction of the return value of the invoke member function.

I don't think there's a way to distinguish between T, T& and const T&
via type inference, but it should be possible by explicitly specifying
the function return type as a template parameter to a factory function.
I'll give that a shot and see if I can resolve the problem in
osgIntrospection.

-Mike

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:osg-users-
> [EMAIL PROTECTED] On Behalf Of Robert Osfield
> Sent: Wednesday, February 21, 2007 4:20 AM
> To: osg users
> Subject: Re: [osg-users] osg::CullStack reflector
> 
> Hi Mike,
> 
> On 2/21/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
> > I don't recall the reason, but I'd guess because it was causing
> > problems with wrapping.  genwrapper and osgIntrospection have moved
on
> > since so perhaps will be able to cope now.
> >
> > I'll rebuild the wrappers with CullStack suppression turned off and
> > see what happens.
> 
> When CullStack is run through genwrapper to methods that return
> RefMatrix& are forcing osgIntrospection wrappers to built that require
> try to constrcut a RefMatrix, but you can't without using a new
> because of the protected destructor, so it fails.
> 
> Changed CullStack so that the methods return a RefMatrix* rather than
> a RefMatrix& fixes the wrapper building as it no longer attempts to
> construct a RefMatrix.  I have had to make this fix a couple of times
> in other parts of the OSG API just to get the wrappers to build
> cleanly.
> 
> I can change osg::CullStack to use RefMatrix* but this will return a
> number of changes to the OSG to get it to build as they assume
> RefMatrix& is passed back.  This isn't a huge change but more than
> just a simple tweak.  Most users shouldn't be affected by this change
> either as its an implementation details of CullVisitor that most users
> won't touch.
> 
> The other alternative is to fix genwrapper/osgIntrospection so that it
> handles Object& like at Object* rather than a Object.  I'm out of my
> depth on this one though, anybody care to jump in here?
> 
> Robert.
> ___
> 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] Crash with DrawThreadPerContext

[Robert Osfield]

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.


Robert.

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


Hi,

I've run into a problem regarding DrawThreadPerContext mode. At the
moment our application is stable with other threading modes but in
DrawThreadPerContext mode it crashes in a few seconds.

I've updated OSG from SVN today in the morning. Platform is SusE9.3,
Intel Core 2 Duo.

Stack trace is at the end of the email. Note the 'attribute=0x0' in the
beginning (#0)

osgviewer alone works well with the same models. So something that is
done in runtime should be the reason. However I can not see what can be
done wrong to have a NULL attribute there ( StateSet::setAttribute*
methods check whether the input argument is NULL so I think that
possiblity is ruled out).

I've simplified our application to such a degree that it does not render
anything. It just starts a viewer and thats it. Still it crashes.



#0  0x40ddbf9e in osg::State::applyAttribute (this=0x813e750,
attribute=0x0, [EMAIL PROTECTED]) at ../../../include/osg/State:927
#1  0x40e88cfc in osg::State::applyAttributeList (this=0x813e750,
[EMAIL PROTECTED], [EMAIL PROTECTED]) at
../../../include/osg/State:1422
#2  0x40e84981 in osg::State::apply (this=0x813e750, dstate=0xa4c4848)
at ../State.cpp:301
#3  0x4124fbe2 in osgUtil::RenderLeaf::render (this=0x8105648,
[EMAIL PROTECTED], previous=0x0) at ../RenderLeaf.cpp:71
#4  0x412461f4 in osgUtil::RenderBin::drawImplementation
(this=0xf14ebf8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at
../RenderBin.cpp:427
#5  0x41245f45 in osgUtil::RenderBin::draw (this=0xf14ebf8,
[EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370
#6  0x4124638c in osgUtil::RenderBin::drawImplementation
(this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at
../RenderBin.cpp:457
#7  0x41256400 in osgUtil::RenderStage::drawImplementation
(this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at
../RenderStage.cpp:1004
#8  0x41245f45 in osgUtil::RenderBin::draw (this=0x80de7e8,
[EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370
#9  0x412556c6 in osgUtil::RenderStage::drawInner (this=0x80de7e8,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
at ../RenderStage.cpp:718
#10 0x41255e5a in osgUtil::RenderStage::draw (this=0x80de7e8,
[EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:880
#11 0x41264864 in osgUtil::SceneView::draw (this=0xbf526d8) at
../SceneView.cpp:1305
#12 0x41709776 in ViewerDoubleBufferedRenderingOperation::draw
(this=0x8104bf8) at ../Viewer.cpp:411
#13 0x4170765b in ViewerDoubleBufferedRenderingOperation::operator()
(this=0x8104bf8, object=0x80f9a78) at ../Viewer.cpp:544
#14 0x40e1ba0f in osg::GraphicsContext::runOperations (this=0x80f9a78)
at ../GraphicsContext.cpp:426
#15 0x41707ca3 in ViewerRunOperations::operator() (this=0xf1fbba8,
object=0x80f9a78) at ../Viewer.cpp:969
#16 0x40e21416 in osg::OperationsThread::run (this=0x91b7910) at
../GraphicsThread.cpp:290
#17 0x414528f5 in OpenThreads::ThreadPrivateActions::StartThread () from
/usr/local/lib/libOpenThreads.so
#18 0x414fdaa7 in start_thread () from /lib/tls/libpthread.so.0
#19 0x40b96c2e in clone () from /lib/tls/libc.so.6


--
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] Crash with DrawThreadPerContext

[Tugkan Calapoglu]

Hi,

I've run into a problem regarding DrawThreadPerContext mode. At the 
moment our application is stable with other threading modes but in 
DrawThreadPerContext mode it crashes in a few seconds.


I've updated OSG from SVN today in the morning. Platform is SusE9.3, 
Intel Core 2 Duo.


Stack trace is at the end of the email. Note the 'attribute=0x0' in the 
beginning (#0)


osgviewer alone works well with the same models. So something that is 
done in runtime should be the reason. However I can not see what can be 
done wrong to have a NULL attribute there ( StateSet::setAttribute* 
methods check whether the input argument is NULL so I think that 
possiblity is ruled out).


I've simplified our application to such a degree that it does not render 
anything. It just starts a viewer and thats it. Still it crashes.




#0  0x40ddbf9e in osg::State::applyAttribute (this=0x813e750, 
attribute=0x0, [EMAIL PROTECTED]) at ../../../include/osg/State:927
#1  0x40e88cfc in osg::State::applyAttributeList (this=0x813e750, 
[EMAIL PROTECTED], [EMAIL PROTECTED]) at 
../../../include/osg/State:1422
#2  0x40e84981 in osg::State::apply (this=0x813e750, dstate=0xa4c4848) 
at ../State.cpp:301
#3  0x4124fbe2 in osgUtil::RenderLeaf::render (this=0x8105648, 
[EMAIL PROTECTED], previous=0x0) at ../RenderLeaf.cpp:71
#4  0x412461f4 in osgUtil::RenderBin::drawImplementation 
(this=0xf14ebf8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at 
../RenderBin.cpp:427
#5  0x41245f45 in osgUtil::RenderBin::draw (this=0xf14ebf8, 
[EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370
#6  0x4124638c in osgUtil::RenderBin::drawImplementation 
(this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at 
../RenderBin.cpp:457
#7  0x41256400 in osgUtil::RenderStage::drawImplementation 
(this=0x80de7e8, [EMAIL PROTECTED], [EMAIL PROTECTED]) at 
../RenderStage.cpp:1004
#8  0x41245f45 in osgUtil::RenderBin::draw (this=0x80de7e8, 
[EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderBin.cpp:370
#9  0x412556c6 in osgUtil::RenderStage::drawInner (this=0x80de7e8, 
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) 
at ../RenderStage.cpp:718
#10 0x41255e5a in osgUtil::RenderStage::draw (this=0x80de7e8, 
[EMAIL PROTECTED], [EMAIL PROTECTED]) at ../RenderStage.cpp:880
#11 0x41264864 in osgUtil::SceneView::draw (this=0xbf526d8) at 
../SceneView.cpp:1305
#12 0x41709776 in ViewerDoubleBufferedRenderingOperation::draw 
(this=0x8104bf8) at ../Viewer.cpp:411
#13 0x4170765b in ViewerDoubleBufferedRenderingOperation::operator() 
(this=0x8104bf8, object=0x80f9a78) at ../Viewer.cpp:544
#14 0x40e1ba0f in osg::GraphicsContext::runOperations (this=0x80f9a78) 
at ../GraphicsContext.cpp:426
#15 0x41707ca3 in ViewerRunOperations::operator() (this=0xf1fbba8, 
object=0x80f9a78) at ../Viewer.cpp:969
#16 0x40e21416 in osg::OperationsThread::run (this=0x91b7910) at 
../GraphicsThread.cpp:290
#17 0x414528f5 in OpenThreads::ThreadPrivateActions::StartThread () from 
/usr/local/lib/libOpenThreads.so

#18 0x414fdaa7 in start_thread () from /lib/tls/libpthread.so.0
#19 0x40b96c2e in clone () from /lib/tls/libc.so.6


--
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] Windows Vista

[Anders Backman]

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   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] Windows Vista

[Gerrick Bivins]

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/

RE: [osg-users] Windows Vista

[Gordon Tomlinson]

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/

Re: [osg-users] Names for Thread and Terrain classes

[Serge Lages]

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


Hi All,

There are a couple of classes/projects I'd like to open out
suggestions for naming of.


-- New Thread class naming

The first up is a proposed addition to OpenThreads sent in by Anders
Backman, the new class is called ThreadEvent, the naming of it
relating to the Win32 thread event.  Its not a conventional event
though, its really a means for syncronizing threads.   On review the
code turned out to remarkably similiar in role to the osg::Block that
I wrote for the syncronization support for osg::GraphicsThread which
is used in the new osgViewer library.

So... API wise it makes sense to combine Anders' ThreadEvent with my
Block so that we have only one class for one role, this will just
require a couple of minor tweaks since they are already similar.  The
combined class does belong in OpenThreads, but what to call it?
OpenThreads:::ThreadEvent?  OpenThreads::Block?  Something else?

The class is in essence a means for making one thread wait for another
thread to release it, there is already a Wait class in OpenThreads
that is used in the implementations of these more specialist forms for
wait.  As another point on the map, Producer has a Block class too,
fulfilling the same role  to osg::Block/ThreadEvent.


-- New terrain building project name

I think I might have raised this before - its my plan to refactor
osgTerrain so that it becomes a pure NodeKit without any external
dependencies, and it'll focus on the rendering of terrain data.  The
database building facilities will move out into its own separate
project.  I know what it'll take to do all this separation work, but
we do need a cool name to capture what this database building project
will be all about.

Previously I've thought about names myself, and also got suggestions
from the community, but haven't yet come across a project name that
really fits well.

While thinking about it this morning the word Genesis seems to be a
good name, as the tool would be about the creation of virtual worlds
and landscapes.  However, a quick search of the web shows that there
are a number of projects/organizations that use Genesis as part of
their name.  Fans of Star trek of the band Genesis will no doubt prick
their ears up too.  And yes I have most of the early Genesis albums in
my collection and even got to meet one of the original band members
while doing OSG consulting... but that's another story... ;-)

VirtualGenesisProject?  OpenGenesisProject?  (Genesis Project and
Project Genesis are already out there in the wild).

(Open)TerrainBuilder?  (Open)PlanetBuilder?

Geez I don't know!! Help mee... :-)



I really like OpenPlanetBuilder, and it should fit the purpose of my
project... :)

--
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] Re: Windows Vista

[Robert Osfield]

On 2/21/07, Adrian Egli <[EMAIL PROTECTED]> wrote:

Latest CVS version doesn't work on pre default windows vista system, i will
try to download and install latest graphic driver from vendors internet
site. and retest
our CVS version.


What problems did you see?

You might want to try the SVN version, rather than the CVS version.
There haven't been any fixes that would make much of difference
though, but going forward it'd be good to stick with SVN as this is
where all the changes will be made.

As a general note, tech sites testing Vista have found the OpenGL
support lacking in performance and functionality.  It should be
possible to get OpenGL working once the drivers have been fixed up,
reading various news about drivers graphics under Vista it looks MS
have made it more difficult to get drivers written, I presume due to
changes in the OS, and also the DRM packed in to the heart of the OS
and drivers.

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

[osg-users] Re: Windows Vista

[Adrian Egli]

Latest CVS version doesn't work on pre default windows vista system, i will
try to download and install latest graphic driver from vendors internet
site. and retest
our CVS version.

/adegli

2007/2/21, Adrian Egli <[EMAIL PROTECTED]>:


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] Names for Thread and Terrain classes

[Robert Osfield]

Hi All,

There are a couple of classes/projects I'd like to open out
suggestions for naming of.


-- New Thread class naming

The first up is a proposed addition to OpenThreads sent in by Anders
Backman, the new class is called ThreadEvent, the naming of it
relating to the Win32 thread event.  Its not a conventional event
though, its really a means for syncronizing threads.   On review the
code turned out to remarkably similiar in role to the osg::Block that
I wrote for the syncronization support for osg::GraphicsThread which
is used in the new osgViewer library.

So... API wise it makes sense to combine Anders' ThreadEvent with my
Block so that we have only one class for one role, this will just
require a couple of minor tweaks since they are already similar.  The
combined class does belong in OpenThreads, but what to call it?
OpenThreads:::ThreadEvent?  OpenThreads::Block?  Something else?

The class is in essence a means for making one thread wait for another
thread to release it, there is already a Wait class in OpenThreads
that is used in the implementations of these more specialist forms for
wait.  As another point on the map, Producer has a Block class too,
fulfilling the same role  to osg::Block/ThreadEvent.


-- New terrain building project name

I think I might have raised this before - its my plan to refactor
osgTerrain so that it becomes a pure NodeKit without any external
dependencies, and it'll focus on the rendering of terrain data.  The
database building facilities will move out into its own separate
project.  I know what it'll take to do all this separation work, but
we do need a cool name to capture what this database building project
will be all about.

Previously I've thought about names myself, and also got suggestions
from the community, but haven't yet come across a project name that
really fits well.

While thinking about it this morning the word Genesis seems to be a
good name, as the tool would be about the creation of virtual worlds
and landscapes.  However, a quick search of the web shows that there
are a number of projects/organizations that use Genesis as part of
their name.  Fans of Star trek of the band Genesis will no doubt prick
their ears up too.  And yes I have most of the early Genesis albums in
my collection and even got to meet one of the original band members
while doing OSG consulting... but that's another story... ;-)

VirtualGenesisProject?  OpenGenesisProject?  (Genesis Project and
Project Genesis are already out there in the wild).

(Open)TerrainBuilder?  (Open)PlanetBuilder?

Geez I don't know!! Help mee... :-)

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

[osg-users] Windows Vista

[Adrian Egli]

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/

Re: [osg-users] osg::CullStack reflector

[Robert Osfield]

Hi Mike,

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

I don't recall the reason, but I'd guess because it was causing
problems with wrapping.  genwrapper and osgIntrospection have moved on
since so perhaps will be able to cope now.

I'll rebuild the wrappers with CullStack suppression turned off and
see what happens.


When CullStack is run through genwrapper to methods that return
RefMatrix& are forcing osgIntrospection wrappers to built that require
try to constrcut a RefMatrix, but you can't without using a new
because of the protected destructor, so it fails.

Changed CullStack so that the methods return a RefMatrix* rather than
a RefMatrix& fixes the wrapper building as it no longer attempts to
construct a RefMatrix.  I have had to make this fix a couple of times
in other parts of the OSG API just to get the wrappers to build
cleanly.

I can change osg::CullStack to use RefMatrix* but this will return a
number of changes to the OSG to get it to build as they assume
RefMatrix& is passed back.  This isn't a huge change but more than
just a simple tweak.  Most users shouldn't be affected by this change
either as its an implementation details of CullVisitor that most users
won't touch.

The other alternative is to fix genwrapper/osgIntrospection so that it
handles Object& like at Object* rather than a Object.  I'm out of my
depth on this one though, anybody care to jump in here?

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

Re: [osg-users] Support for sharing contexts in GraphicsWindowWin32/Carbon and X11

[Stephan Maximilian Huber]

Hi Allan,

Allan Schaffer schrieb:
I don't follow osg-submissions so I'm curious what the original fps of 
the cow in osgviewer was.  If you're seeing more than a small % 
overhead then I'd like to know more.
While osgViewer was developed I started the implementation of a 
GraphicsWindowCarbon and I enabled the Multithreaded GL stuff the 
performance dropped to a third of what I've see without the 
multithreaded OpenGL stuff. (without vsync: 300 -> 1000, with vsync 60 
-> 45, showing only cow.osg)


I did some profiling with Shark and most of the time was spent in 
Barriers, Mutexes etc (75% of the time) (See my posting at 
)



Ok, after your post I reenabled mutithreaded OpenGL-execution, did some 
teste and what happens: it works. The performance on a Mac Pro and on a 
MacBookPro is pretty much the same with and without multithreaded 
OpenGL-execution.


So my suspiction is: at the time as I implemented the carbon-backend, 
the threading code of osg was still in the flux, now, the implementation 
of the different threading-models is well tested and works very nice on 
all plattforms and no interfering with the multitthreaded 
opengl-execution exists.


So, after all, false alarm :)

I will submit a new GraphicsWindowCarbon-class / 
GraphicsContex::Traits-class the next days which will enable 
multithreaded opengl-execution by default, with some other minor 
improvements (setting the screen-size etc)


cheers,
Stephan



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

Re: [osg-users] osg::CullStack reflector

[Robert Osfield]

Hi Mike,

On 2/21/07, Mike Wittman <[EMAIL PROTECTED]> wrote:

The osg::CullStack reflector is suppressed in OpenSceneGraph's
genwrapper.conf.   I just noticed that because it's causing me to crash with
an osgIntrospection::TypeNotDefinedException when I invoke
getAllMethods() on the osg::CollectOccludersVisitor type.  Do you happen to
recall the reasoning behind the suppression of that reflector?


I don't recall the reason, but I'd guess because it was causing
problems with wrapping.  genwrapper and osgIntrospection have moved on
since so perhaps will be able to cope now.

I'll rebuild the wrappers with CullStack suppression turned off and
see what happens.

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

Re: [osg-users] Isosurface and OSG

[Robert Osfield]

Hi Jeremy,

There isn't any tool in the OSG that will build a triangle mesh from a
cloud of 3D data points.  There is the osgUtil::DelaunayTriangulator,
but its works on 2D project.

The best way to create the mesh to build as part of the marching cubes
alogorithm as you'll have all the information required to create the
triangles, a 3D mesh building tool wouldn't have this information so
would not create be able to create the correct mesh.

The other alternative is to not create the iso-surface at all, and
just use the GPU to compute the iso-surface on the fly.  The osgvolume
example has support for this.

Robert.

On 2/20/07, Jeremy <[EMAIL PROTECTED]> wrote:

I have volume data, and I have a simple marching cubes
algorithm that creates an isosurface at any isolevel I
pick.  What's returned from the algorithm is an array
with the x,y,z's (of the triangle vertices) that
construct my isosurface.

My question(s) are the the following:  What are the
best classes/methods in OSG to create an optimized
mesh from a raw vertex list?  And after that, what are
my options for triangle stripping/vertex normals/ etc?

Thanks,
Jeremy




Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
___
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] disabling automatic near far computation

[Tugkan Calapoglu]

Hi Robert,

It works now, thanks for the fix

tugkan



HI Tugkan,

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


It should work, so if it isn't there must be some code missing or
wrong in osgViewer.  The CullSettings should be inherited from the
Viewers master Camera down to any slave Camera, and the SceneView's
created internally should inhert their Cull Settings down from the
Slave or master Camera they are associated with.

A quick scan of the code in src/osgViewer/Viewer.cpp and
src/osgUtil/SceneView.cpp doesn't reveal any code for forcing the
inhertance of the CullSetting like there is in
osgProducer/OsgCameraGroup.cpp.  The right place to add it in
osgViewer will probably the ViewerDoubleBufferedRenderingOperation
class just before the cull traversal.



I have now added in the missing inheritCullSettings calls into
osgViewer::CompositeViewer and Viewer and checked them in.

I modified osgviewer so that is using the line :
  
viewer.getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); 



Testing before and after the fixes problem is now fixed.

Let me know how you get on.

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




--
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/