Re: [osg-users] [vpb] Speed of first frame rendering

[Boon Wah]

Hi Roberto,

My terrain database is about 3GB in size, and measures about 3 by 5 
pixels just for the textures alone.

I have written a single frame renderer based on the OSG Viewer code base. 
The load time for first frame rendering takes close to 10s for the DEM terrain 
database. My each tile size is around 8MB. For the flat terrain database, the 
load time is almost instantaneous ( < 1s ).

Thank you!

Cheers,
Boon Wah

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49655#49655





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to exclude LOD-disabled nodes from PolytopeIntersector results?

[Michael Schanne]

I solved my problem...

For reference, the code I am referencing from the OSG Quick Start Guide is this:


Code:
double w( .05 ), h( .05 );
osgUtil::PolytopeIntersector* picker =
new osgUtil::PolytopeIntersector(
osgUtil::Intersector::PROJECTION,
x-w, y-h, x+w, y+h );
osgUtil::IntersectionVisitor iv( picker );
viewer->getCamera()->accept( iv );



Shortly after I posted, I saw that osgUtil::IntersectionVisitor contains a 
function setLODSelectionMode().  I tried setting this to 
USE_EYE_POINT_FOR_LOD_LEVEL_SELECTION but it had no effect.  I did a bit more 
investigating and saw that this enum is referenced in 
IntersectionVisitor::getDistanceToEyePoint().  However, LOD::traverse() calls 
NodeVisitor::getDistanceToViewPoint(), which is not implemented in 
IntersectionVisitor.

I was able to derive from IntersectionVisitor and implement 
getDistanceToViewPoint() similarly to getDistanceToEyePoint():


Code:
if (_lodSelectionMode==USE_EYE_POINT_FOR_LOD_LEVEL_SELECTION)
{
return (pos-getViewPoint()).length();
}
else
{
return 0.0f;
}



then used the subclass in my picking code, after which I got the desired effect.

Is this something that should be added to osgUtil::IntersectionVisitor?

... 

Thank you!

Cheers,
Michael

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49653#49653





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] How to exclude LOD-disabled nodes from PolytopeIntersector results?

[Michael Schanne]

Hi,

I have a CAD app in which I am using LOD nodes to hide features at different 
zoom levels.  I have also implemented picking using PolytopIntersector similar 
to the example in the Quick Start Guide.  I have noticed that the 
PolytopeIntersector returns intersections that include nodes which are turned 
off by the LOD.  I would like to exclude these from the intersections.  Does 
OSG provide a way to do this?

... 

Thank you!

Cheers,
Michael

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49652#49652





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [vpb] Speed of first frame rendering

[Robert Osfield]

Hi Boon Wah,

Have a look at the on screen stats between the two datasets, there
will be a difference, in particular with the number of vertices per
tiles, and perhaps even the number of tiles as osgdem has a default
limit of tile 64x64 for height fields and 256x256 for texels so when
you introduce the DEM's it may be the DEM's that limits the number of
tiles.

In general one wouldn't expect the initial load time to be high on any
paged database, normally it's very fast indeed and not really
noticeable.  So please tell us just what time to load you are seeing.

Robert.

On 28 August 2012 18:02, Boon Wah  wrote:
> Hi,
>
> I am a user of osgDEM and used this to generate a terrain database.
>
> When the terrain data is first loaded by osgViewer, there would be an 
> initial load time. I am trying to reduce this load time drastically.
>
> I prepared two sets of terrain database for comparison of the initial 
> load time. The first set has a flat terrain (i.e. all vertices have height z 
> = 0) and the second set has uneven terrain (i.e. different vertices have 
> different heights). Both database uses the same texture and have been 
> compiled with osgDEM with the same parameters, with the exception the second 
> set was provided with a DEM map.
>
> What I have found out is that the first set initial load time is much 
> faster (more than 10x) than the second set. Why is this so, even the size of 
> the textures and the number of vertices remain the same for the 2 sets?
>
>
> Thank you!
>
> Cheers,
> Boon Wah
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49641#49641
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External projects on the Joomla wiki

[Paul Martz]

Glad to help where I can. I know the new web page does need some help, and I've 
done very little in that area (it's been a busy summer for me).


I'll port the OpenFlight info from the old KnowledgeBase, once the old web site 
is back online and I can get to the info.

   -Paul


On 8/28/2012 12:11 PM, Jordi Torres wrote:

Hi Paul,



2012/8/28 Paul Martz mailto:pma...@skew-matrix.com>>

Since no one has contributed to this page since its inception 4 months ago,
and since there were no guidelines on the page itself, I didn't know you (or
anyone else) had any plans for it.


You are right I don't have a strong opinion on that, and I was expecting that
each external project have the time to fill their own article. It was a initial
conception, but it is not written in a stone, so I will change the layout to fit
your article. Anyway I think I asked in the lists about this particular section
and its layout, and nobody answered at all.

Because each external project has its own web page with plenty of
information, doesn't it make more sense for our Joomla page to just have a
brief 1-line description and a link to the external project page? Having an
entire article devoted to each external project seems like overkill.


Ok thumbs up.

So I've already done as I described above. It's a wiki; you (or anyone else)
are welcome to change what I've done, if you feel strongly about it.
-Paul


Any help is appreciated, if you see the migration tasks section you will make
yourself an idea of the status of the work and what the community still have to
do. We need to push the work on the new web as much as we can. So thank you for
your collaboration with the migration!! :)

Cheers.




On 8/28/2012 11:14 AM, Jordi Torres wrote:

The community projects page has a blog layout, so you have to add a new
article
for each new project you want to add. We could have this page as a 
single
article page, but I think is more reasonable that each project have
their own
article.

Cheers.


2012/8/28 Paul Martz mailto:pma...@skew-matrix.com> __>>


 That's very confusing. In my head, I don't want to create a new
article, I
 just want to edit an existing one... but now I know what to do, so
thanks.
 -Paul



 On 8/28/2012 10:54 AM, Jordi Torres wrote:

 Hi Paul,

 Once you are logged in you should see two new items in the
login menu
 key. One
 of them is submit new article, set the category "community
projects" for
 your
 article ant it should be published in the right place. The 
author
 guidelines are
 not completed yet, but there is some useful information.

 Cheers.

 2012/8/28 Paul Martz mailto:pma...@skew-matrix.com>
__>

__>__>>



  I thought I'd start work on the Community->Projects page,
enumerating
  projects external to the OSG distribution. But there
doesn't seem
 to be a
  way to edit the page, even after I'm logged in. Am I
missing something?

  Thanks,
  -Paul


  _
  osg-users mailing list
  osg-users@lists.__openscenegraph.org
 
__open__scenegraph.org

>>

http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org

>




>>





 --
 Jordi Torres Fabra

 gvSIG 3D blog
http://gvsig3d.blogspot.com
 Instituto de Automática e Informática Industrial
http://www.ai2.upv.es


 

Re: [osg-users] [forum] Site web down

[Thomas Hogarth]

Hi Jordi,

Thanks for that, will be a load off your mind when the new site is up ay :).

Regarding that I did make a few pages in the Platform specifics section which 
i've set to 'Awaiting Review'. If you flag them as ok I'll try set aside some 
time to start migrating more pages.

Thanks again
Tom

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49649#49649





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes (partially resolved)

[Judson Weissert]

On 8/27/2012 3:14 PM, Jeremy Moles wrote:
> A Drawable can have a special ComputeBoundsCallback() (something like
> that, I'm on my phone right now and can't look it up), so you could use
> that as well...
Here is the code I came up with after your suggestion that does resolve
my problem (I attach the callback directly to the PAT in question):

[code]

/// This callback is used to prevent the bounding sphere associated with a
/// osg::PositionAttitudeTransform from modifying the bounding sphere due to
/// its scaling factor.
class keep_bounding_sphere_t : public
osg::Node::ComputeBoundingSphereCallback
{
public:
  keep_bounding_sphere_t ();

  keep_bounding_sphere_t (const osg::Vec3 &axes);

  keep_bounding_sphere_t (
const keep_bounding_sphere_t &other, const osg::CopyOp copyop
  );

  META_Object (anonymous, keep_bounding_sphere_t);

  /* * * osg::Node * * */

  virtual osg::BoundingSphere
  computeBound (const osg::Node &node) const;

private:
  /// The axes that might be scaled and should be checked.
  /// e.g. osg::Z_AXIS to check only the z-axis.
  osg::Vec3 axes_;
};

keep_bounding_sphere_t::keep_bounding_sphere_t ()
: ComputeBoundingSphereCallback (),
  axes_ (1.0f, 1.0f, 1.0f)
{
}

keep_bounding_sphere_t::keep_bounding_sphere_t (const osg::Vec3 &axes)
: ComputeBoundingSphereCallback (),
  axes_ (axes)
{
}

keep_bounding_sphere_t::keep_bounding_sphere_t (
  const keep_bounding_sphere_t &other, const osg::CopyOp copyop )
: ComputeBoundingSphereCallback (other, copyop),
  axes_ (other.axes_)
{
}

osg::BoundingSphere
keep_bounding_sphere_t::computeBound (const osg::Node &node) const
{
  osg::BoundingSphere out = node.computeBound ();

  const osg::PositionAttitudeTransform *pat =
dynamic_cast  (&node);
  if (!pat)
return out;

  osg::Vec3d scale = pat->getScale ();

  double sscale = 1.0;
  if (axes_.x ())
sscale = scale.x ();
  if (axes_.y () && scale.y () > sscale)
sscale = scale.y ();
  if (axes_.z () && scale.z () > sscale)
sscale = scale.z ();

  if (sscale)
out.set (out.center () , out.radius () / sscale);

  return out;
}

[/code]

My understanding of Transform::computeBound() could be better, but in my
case, it was effectively multiplying the bounding sphere radius by the
scaling factor even though the scaling factor only applied to a single
axis and should not have been a factor when calculating the boundary sphere.

Thus, the code above works provided the extent of the geometry along the
axis being scaled will never be larger than the extent of the geometry
along the other axes. I can think of a few improvements to this code
(like compute the bounds of the child node(s) directly then determine
what to do with the scale values). However, does this seem like a
proper/common approach to solving this problem? Another approach might
be to override the PositionAttitudeTransform node directly?

Regards,

Judson
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External projects on the Joomla wiki

[Jordi Torres]

Hi Paul,



2012/8/28 Paul Martz 

> Since no one has contributed to this page since its inception 4 months
> ago, and since there were no guidelines on the page itself, I didn't know
> you (or anyone else) had any plans for it.
>
>
You are right I don't have a strong opinion on that, and I was expecting
that each external project have the time to fill their own article. It was
a initial conception, but it is not written in a stone, so I will change
the layout to fit your article. Anyway I think I asked in the lists about
this particular section and its layout, and nobody answered at all.



> Because each external project has its own web page with plenty of
> information, doesn't it make more sense for our Joomla page to just have a
> brief 1-line description and a link to the external project page? Having an
> entire article devoted to each external project seems like overkill.
>
>
Ok thumbs up.


> So I've already done as I described above. It's a wiki; you (or anyone
> else) are welcome to change what I've done, if you feel strongly about it.
>-Paul
>
>
Any help is appreciated, if you see the migration tasks section you will
make yourself an idea of the status of the work and what the community
still have to do. We need to push the work on the new web as much as we
can. So thank you for your collaboration with the migration!! :)

Cheers.


>
>
> On 8/28/2012 11:14 AM, Jordi Torres wrote:
>
>> The community projects page has a blog layout, so you have to add a new
>> article
>> for each new project you want to add. We could have this page as a single
>> article page, but I think is more reasonable that each project have their
>> own
>> article.
>>
>> Cheers.
>>
>>
>> 2012/8/28 Paul Martz > pma...@skew-matrix.com**>>
>>
>>
>> That's very confusing. In my head, I don't want to create a new
>> article, I
>> just want to edit an existing one... but now I know what to do, so
>> thanks.
>> -Paul
>>
>>
>>
>> On 8/28/2012 10:54 AM, Jordi Torres wrote:
>>
>> Hi Paul,
>>
>> Once you are logged in you should see two new items in the login
>> menu
>> key. One
>> of them is submit new article, set the category "community
>> projects" for
>> your
>> article ant it should be published in the right place. The author
>> guidelines are
>> not completed yet, but there is some useful information.
>>
>> Cheers.
>>
>> 2012/8/28 Paul Martz >  > __>>
>>
>>
>>
>>  I thought I'd start work on the Community->Projects page,
>> enumerating
>>  projects external to the OSG distribution. But there doesn't
>> seem
>> to be a
>>  way to edit the page, even after I'm logged in. Am I missing
>> something?
>>
>>  Thanks,
>>  -Paul
>>
>>
>>  __**_
>>  osg-users mailing list
>>  
>> osg-users@lists.__openscenegra**__ph.org<
>> http://openscenegraph.org>
>> 
>> 
>> 
>> > >>
>> http://lists.openscenegraph.__**__org/listinfo.cgi/osg-users-_**
>> ___openscenegraph.org 
>> 
>> 
>> >
>>
>> > openscenegraph.org 
>> > openscenegraph.org
>> >>
>>
>>
>>
>>
>>
>> --
>> Jordi Torres Fabra
>>
>> gvSIG 3D blog
>> http://gvsig3d.blogspot.com
>> Instituto de Automática e Informática Industrial
>> http://www.ai2.upv.es
>>
>>
>> __**___
>> osg-users mailing list
>> osg-users@lists.__openscenegra**ph.org
>> 
>> > >
>> http://lists.openscenegraph.__**org/listinfo.cgi/osg-users-__**
>> openscenegraph.org 
>> > openscenegraph.org
>> >
>>
>> __**___
>> osg-users mailing list
>> osg-users@lists.__openscenegra**ph.org 
>> > osg-users@lists.**openscenegraph.org 
>> >
>> http://lists.openscenegraph.__**org/listinfo.cgi/osg-users-__**
>> openscenegraph.org 

Re: [osg-users] External projects on the Joomla wiki

[Paul Martz]

Since no one has contributed to this page since its inception 4 months ago, and 
since there were no guidelines on the page itself, I didn't know you (or anyone 
else) had any plans for it.


Because each external project has its own web page with plenty of information, 
doesn't it make more sense for our Joomla page to just have a brief 1-line 
description and a link to the external project page? Having an entire article 
devoted to each external project seems like overkill.


So I've already done as I described above. It's a wiki; you (or anyone else) are 
welcome to change what I've done, if you feel strongly about it.

   -Paul



On 8/28/2012 11:14 AM, Jordi Torres wrote:

The community projects page has a blog layout, so you have to add a new article
for each new project you want to add. We could have this page as a single
article page, but I think is more reasonable that each project have their own
article.

Cheers.


2012/8/28 Paul Martz mailto:pma...@skew-matrix.com>>

That's very confusing. In my head, I don't want to create a new article, I
just want to edit an existing one... but now I know what to do, so thanks.
-Paul



On 8/28/2012 10:54 AM, Jordi Torres wrote:

Hi Paul,

Once you are logged in you should see two new items in the login menu
key. One
of them is submit new article, set the category "community projects" for
your
article ant it should be published in the right place. The author
guidelines are
not completed yet, but there is some useful information.

Cheers.

2012/8/28 Paul Martz mailto:pma...@skew-matrix.com> __>>


 I thought I'd start work on the Community->Projects page, 
enumerating
 projects external to the OSG distribution. But there doesn't seem
to be a
 way to edit the page, even after I'm logged in. Am I missing 
something?

 Thanks,
 -Paul


 ___
 osg-users mailing list
 osg-users@lists.__openscenegra__ph.org 
>

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


>





--
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es


_
osg-users mailing list
osg-users@lists.__openscenegraph.org


http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org



_
osg-users mailing list
osg-users@lists.__openscenegraph.org 

http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org 





--
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] Site web down

[Jordi Torres]

Hi Thomas et al,

The university machine is (and was) working, and we have restored the
strange dreamhost redirection. It should be working in a few hours (the
redirection). In the meanwhile you can access openscenegraph.org content at
http://158.42.9.50/projects/osg

Cheers.

2012/8/28 Jordi Torres 

> Hi Thomas,
>
> I have been in the university this morning trying to reboot the server,
> but I have no physical access to the machine and the people who has are on
> vacations. I wrote them whitout any answer yet. Anyway the IP serving this
> message now of error id: "bad_httpd_conf" is not of the university is of
> dreamhost, I am going to write Robert in case his is not aware of this
> thread.
>
> I hope I can give you a solution soon. Sorry again.
>
> Cheers.
>
> 2012/8/28 Thomas Hogarth 
>
>> Hi Jordi
>>
>> Did you get a chance to reboot the server?, i have a few clients that
>> have been trying to access with no joy.
>>
>> Also looks like google may have cached the downed version
>>
>> This is Google's cache of http://www.openscenegraph.org/. It is a
>> snapshot of the page as it appeared on 22 Aug 2012 15:45:17 GMT.
>>
>> I know there is the effort to get the new site up and running, but things
>> have stalled on it lately (I've been pretty busy). Could we do anything like
>> copy the content of the old server somewhere for instances like this. I
>> have some webspace we could use for it.
>>
>> Cheers
>> Tom
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> --
> Jordi Torres Fabra
>
> gvSIG 3D blog
> http://gvsig3d.blogspot.com
> Instituto de Automática e Informática Industrial
> http://www.ai2.upv.es
>



-- 
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External projects on the Joomla wiki

[Jordi Torres]

The community projects page has a blog layout, so you have to add a new
article for each new project you want to add. We could have this page as a
single article page, but I think is more reasonable that each project have
their own article.

Cheers.


2012/8/28 Paul Martz 

> That's very confusing. In my head, I don't want to create a new article, I
> just want to edit an existing one... but now I know what to do, so thanks.
>-Paul
>
>
>
> On 8/28/2012 10:54 AM, Jordi Torres wrote:
>
>> Hi Paul,
>>
>> Once you are logged in you should see two new items in the login menu
>> key. One
>> of them is submit new article, set the category "community projects" for
>> your
>> article ant it should be published in the right place. The author
>> guidelines are
>> not completed yet, but there is some useful information.
>>
>> Cheers.
>>
>> 2012/8/28 Paul Martz > pma...@skew-matrix.com**>>
>>
>>
>> I thought I'd start work on the Community->Projects page, enumerating
>> projects external to the OSG distribution. But there doesn't seem to
>> be a
>> way to edit the page, even after I'm logged in. Am I missing
>> something?
>>
>> Thanks,
>> -Paul
>>
>>
>> __**___
>> osg-users mailing list
>> osg-users@lists.__openscenegra**ph.org 
>> > osg-users@lists.**openscenegraph.org 
>> >
>> http://lists.openscenegraph.__**org/listinfo.cgi/osg-users-__**
>> openscenegraph.org  <
>> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
>> openscenegraph.org
>> >
>>
>>
>>
>>
>>
>> --
>> Jordi Torres Fabra
>>
>> gvSIG 3D blog
>> http://gvsig3d.blogspot.com
>> Instituto de Automática e Informática Industrial
>> http://www.ai2.upv.es
>>
>>
>> __**_
>> osg-users mailing list
>> osg-users@lists.**openscenegraph.org 
>> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
>> openscenegraph.org
>>
> __**_
> osg-users mailing list
> osg-users@lists.**openscenegraph.org 
> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
> openscenegraph.org
>



-- 
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] Site web down

[Jordi Torres]

Hi Thomas,

I have been in the university this morning trying to reboot the server, but
I have no physical access to the machine and the people who has are on
vacations. I wrote them whitout any answer yet. Anyway the IP serving this
message now of error id: "bad_httpd_conf" is not of the university is of
dreamhost, I am going to write Robert in case his is not aware of this
thread.

I hope I can give you a solution soon. Sorry again.

Cheers.

2012/8/28 Thomas Hogarth 

> Hi Jordi
>
> Did you get a chance to reboot the server?, i have a few clients that have
> been trying to access with no joy.
>
> Also looks like google may have cached the downed version
>
> This is Google's cache of http://www.openscenegraph.org/. It is a
> snapshot of the page as it appeared on 22 Aug 2012 15:45:17 GMT.
>
> I know there is the effort to get the new site up and running, but things
> have stalled on it lately (I've been pretty busy). Could we do anything like
> copy the content of the old server somewhere for instances like this. I
> have some webspace we could use for it.
>
> Cheers
> Tom
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External projects on the Joomla wiki

[Paul Martz]

That's very confusing. In my head, I don't want to create a new article, I just 
want to edit an existing one... but now I know what to do, so thanks.

   -Paul


On 8/28/2012 10:54 AM, Jordi Torres wrote:

Hi Paul,

Once you are logged in you should see two new items in the login menu key. One
of them is submit new article, set the category "community projects" for your
article ant it should be published in the right place. The author guidelines are
not completed yet, but there is some useful information.

Cheers.

2012/8/28 Paul Martz mailto:pma...@skew-matrix.com>>

I thought I'd start work on the Community->Projects page, enumerating
projects external to the OSG distribution. But there doesn't seem to be a
way to edit the page, even after I'm logged in. Am I missing something?

Thanks,
-Paul


_
osg-users mailing list
osg-users@lists.__openscenegraph.org 

http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org 





--
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [vpb] Speed of first frame rendering

[Boon Wah]

Hi,

I am a user of osgDEM and used this to generate a terrain database.

When the terrain data is first loaded by osgViewer, there would be an 
initial load time. I am trying to reduce this load time drastically.

I prepared two sets of terrain database for comparison of the initial load 
time. The first set has a flat terrain (i.e. all vertices have height z = 0) 
and the second set has uneven terrain (i.e. different vertices have different 
heights). Both database uses the same texture and have been compiled with 
osgDEM with the same parameters, with the exception the second set was provided 
with a DEM map.

What I have found out is that the first set initial load time is much 
faster (more than 10x) than the second set. Why is this so, even the size of 
the textures and the number of vertices remain the same for the 2 sets?


Thank you!

Cheers,
Boon Wah

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49641#49641





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] Site web down

[Thomas Hogarth]

Hi Jordi

Did you get a chance to reboot the server?, i have a few clients that have
been trying to access with no joy.

Also looks like google may have cached the downed version

This is Google's cache of http://www.openscenegraph.org/. It is a snapshot
of the page as it appeared on 22 Aug 2012 15:45:17 GMT.

I know there is the effort to get the new site up and running, but things
have stalled on it lately (I've been pretty busy). Could we do anything like
copy the content of the old server somewhere for instances like this. I
have some webspace we could use for it.

Cheers
Tom
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] External projects on the Joomla wiki

[Jordi Torres]

Hi Paul,

Once you are logged in you should see two new items in the login menu key.
One of them is submit new article, set the category "community projects"
for your article ant it should be published in the right place. The author
guidelines are not completed yet, but there is some useful information.

Cheers.

2012/8/28 Paul Martz 

> I thought I'd start work on the Community->Projects page, enumerating
> projects external to the OSG distribution. But there doesn't seem to be a
> way to edit the page, even after I'm logged in. Am I missing something?
>
> Thanks,
>-Paul
>
>
> __**_
> osg-users mailing list
> osg-users@lists.**openscenegraph.org 
> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
> openscenegraph.org
>



-- 
Jordi Torres Fabra

gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] External projects on the Joomla wiki

[Paul Martz]

I thought I'd start work on the Community->Projects page, enumerating projects 
external to the OSG distribution. But there doesn't seem to be a way to edit the 
page, even after I'm logged in. Am I missing something?


Thanks,
   -Paul


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdparty] osgWidget and rotation

[Jeremy Moles]

On Tue, 2012-08-28 at 16:59 +0200, Miguel Lokida wrote:
> So i see what you mean. But how can I declare the position of my widget 
> relative to the parented window ?
> 
> Here's the code I use:
> 
> [code]
> const unsigned int MASK_2D = 0xF000;
> 
> // note: osgViewer::Viewer* ptrViewer;
> // note: osg::ref_ptr _rootScene;
> // note: ptrViewer->setSceneData(_rootScene);
> 
> osgWidget::WindowManager* wm = new osgWidget::WindowManager( 
>   ptrViewer,
>   ptrViewer->width(),
>   ptrViewer->height(),
>   MASK_2D,
>   osgWidget::WindowManager::WM_PICK_DEBUG
>  );
> 
> osgWidget::Window* box = new osgWidget::Box("HBOX", osgWidget::Box::VERTICAL, 
> true);
> 
> osgWidget::Widget * testWidget = new osgWidget::Widget("test", 100.0f, 
> 100.0f);
> testWidget->setColor(1, 0, 0, 1.0);
> box->addWidget(testWidget);
> 
> //box->setAnchorHorizontal(osgWidget::Window::HA_RIGHT);
> //box->setAnchorVertical(osgWidget::Window::VA_TOP);
> 
> box->setVisibilityMode(osgWidget::Window::VM_ENTIRE);
> 
> wm->addChild(box);
> 
> // rotation
> box->setRotate(45.0);
> 
> osg::Group*  group  = new osg::Group();
> osg::Camera* camera = wm->createParentOrthoCamera();
> 
> _rootScene->addChild(camera);
> 
> wm->resizeAllWindows();
>  
> [/code]
> 
> may be I am wrong with this code ?

I've done some testing and you aren't really doing anything wrong here;
it is simply a weakness in osgWidget I never thought of. I'm not sure
how to best proceed, but you have at least two reasonable options:

1) An osgWidget::Window is a MatrixTransform, and an osgWidget::Widget
is just an osg::Geometry. You could attach an
osg::Drawable::UpdateCallback to your widget, but you'd need to do some
fancy calculations to get it to rotate in place. I tried quickly doing
this, but couldn't get the math right in the few minutes I had to test
it... I've attached this code, but you'll need to "fix" it to make it
work.

2) Create one Window for your compass outline and another for your
compass spinner; add the spinner to the outline and call setRotate() on
the spinner window as needed.

In the long run, osgWidget should be rewritten to be more modern and use
my (and utilizing feedback from the community) improved understanding of
OSG in general. Alas, the bills don't stop coming, and the little free
time I have (I do Linux development as my 40+/week) goes to the
occasional contract I can secure or other such activities.

I would really like to go back and fix all the things I know are wrong,
I just need a solid, uninterrupted 2 weeks to do so. :)

> Thanks !
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49635#49635
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

#include 
#include 
#include 
#include 
#include 

const unsigned int MASK_2D = 0xF000;

class SpinnerCallback: public osg::Drawable::UpdateCallback {
	virtual void update(osg::NodeVisitor* nv, osg::Drawable* drawable) {
		static osg::Matrix::value_type r = 0.0f;
		static double  t = 0.0f;
		
		double time = nv->getFrameStamp()->getSimulationTime();

		if(time - t > 0.1f) {
			r += 1.0f;
			t  = time;

			OSG_WARN << r << std::endl;

			osgWidget::Widget* widget = dynamic_cast(drawable);
			osgWidget::PointArray* points = dynamic_cast(widget->getVertexArray());

			osg::Matrix rotate= osg::Matrix::rotate(osg::DegreesToRadians(r), osg::Vec3(0.0f, 0.0f, 1.0f));
			osg::Matrix translate = osg::Matrix::translate(osg::Vec3(0.0f, 0.0f, 0.0f));

			for(
osgWidget::PointArray::iterator i = points->begin();
i != points->end();
i++
			) {
*i = rotate * translate * *i;
			}
		}
	}
};

int main(int argc, char** argv) {
	osgViewer::Viewer viewer;

	osgWidget::WindowManager* wm = new osgWidget::WindowManager(
		&viewer,
		640.0f,
		480.0f,
		MASK_2D,
		osgWidget::WindowManager::WM_PICK_DEBUG
	);

	osgWidget::Box*outline = new osgWidget::Box("Outline", osgWidget::Box::VERTICAL, true);
	osgWidget::Widget* spinner = new osgWidget::Widget("Spinner", 100.0f, 100.0f);

	spinner->setPadding(100.0f);
	spinner->setColor(1.0f, 0.0f, 0.0f, 1.0f);
	spinner->setUpdateCallback(new SpinnerCallback());

	outline->addWidget(spinner);
	outline->getBackground()->setColor(1.0f, 1.0f, 1.0f, 1.0f);
	outline->attachMoveCallback();

	wm->addChild(outline);

	return osgWidget::createExample(viewer, wm);
}

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] RESOLVED Re: Repository broken with SVN >=1.7.5?

[Fred Smith]

Thanks for the heads up. I have set up the git repository.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49636#49636





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdparty] osgWidget and rotation

[Miguel Lokida]

So i see what you mean. But how can I declare the position of my widget 
relative to the parented window ?

Here's the code I use:

[code]
const unsigned int MASK_2D = 0xF000;

// note: osgViewer::Viewer* ptrViewer;
// note: osg::ref_ptr _rootScene;
// note: ptrViewer->setSceneData(_rootScene);

osgWidget::WindowManager* wm = new osgWidget::WindowManager( 
ptrViewer,
ptrViewer->width(),
ptrViewer->height(),
MASK_2D,
osgWidget::WindowManager::WM_PICK_DEBUG
   );

osgWidget::Window* box = new osgWidget::Box("HBOX", osgWidget::Box::VERTICAL, 
true);

osgWidget::Widget * testWidget = new osgWidget::Widget("test", 100.0f, 100.0f);
testWidget->setColor(1, 0, 0, 1.0);
box->addWidget(testWidget);

//box->setAnchorHorizontal(osgWidget::Window::HA_RIGHT);
//box->setAnchorVertical(osgWidget::Window::VA_TOP);

box->setVisibilityMode(osgWidget::Window::VM_ENTIRE);

wm->addChild(box);

// rotation
box->setRotate(45.0);

osg::Group*  group  = new osg::Group();
osg::Camera* camera = wm->createParentOrthoCamera();

_rootScene->addChild(camera);

wm->resizeAllWindows();
 
[/code]

may be I am wrong with this code ?

Thanks !

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49635#49635





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] a bug or feature in the osgb writer?

[Wang Rui]

Hi John,

Oh, so you are talking about the saving/reading of geometry shaders,
not just geometries. :-)

After checking the osg::Program serializer, I can confirm this is a
bug. As GL_POINTS is defined as 0, the serializer will ignore it as
incorrectly recognize it as GL_NONE. And when you load the file again,
the Program class will use a default value for GeometryInputType, that
is, GL_TRIANGLES.

I'll submit the patch to osg-submissions at once. You can also modify
the line at src/osgWrappers/serializers/osg/Program.cpp:

#define PROGRAM_PARAMETER_FUNC( PROP, NAME ) \
static bool check##PROP(const osg::Program& attr) \
{ return attr.getParameter(NAME)!=GL_NONE; } \

to

#define PROGRAM_PARAMETER_FUNC( PROP, NAME ) \
static bool check##PROP(const osg::Program& attr) \
{ return true; } \

and see if it can work.

Thanks,

Wang Rui


2012/8/28 John Kelso :
> Hi,
>
> I apologize for the delay in responding.
>
> Here's my attempt to provide a simple example. I am attaching the three
> referenced files.
>
> I run my program and dump the node in question into two files: dump.osgt and
> dump.osg.
>
> If I grep for "Geometry" in the two files I see:
>
> dump.osgt:553:  GeometryVerticesOut GL_GEOMETRY_VERTICES_OUT_EXT
> 4 dump.osgt:554:  GeometryOutputType GL_GEOMETRY_OUTPUT_TYPE_EXT
> 5 dump.osgt:696:osg::Geometry {
> dump.osg:49:GeometryVerticesOut 4
> dump.osg:50:GeometryInputType POINTS
> dump.osg:51:GeometryOutputType TRIANGLE_STRIP
> dump.osg:661:  Geometry {
>
> That is, the osgt file seems to be missing the line
>   GeometryInputType GL_GEOMETRY_INPUT_TYPE_EXT 0
>
> If I convert dumop.osgt file to an osg file and diff it with the original
> osg
> file I see:
>>
>> diff dumpFromOsgt.osg dump.osg
>
> 46c50
> < GeometryInputType TRIANGLES
> ---
>>
>> GeometryInputType POINTS
>
>
> I think the problem is just in the writer, not the reader, because if I
> manually add the missing line to the osgt file it works. And, it if convert
> the modified osgt file to an osg file the input type is now points, not
> triangles.
>
> I seem to get the same results for osgb as I do for osgt.
>
> I'm not sure how to answer the question about setVertexArray versus
> setVertexAttribArray. But points.osg is the point data that's loaded.
>
> I hope this helps. Please let me know if you need anything else that might
> help with solving the problem.
>
> Thanks,
>
> John
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Error while loading OSG model on Android

[Jordi Torres]

Hi koduri,

Make sure you have added the macro USE_OSGPLUGIN(osg) in your code, maybe
this is the problem.

Cheers
El 28/08/2012 13:44, "Koduri Lakshmi"  escribió:

> Hi,
>
> I build OSGAndroid example on Ubuntu device. I loaded and displayed OSG
> model successfully on my mobile device.
>
> Now I used the OSG lib in my project which are using some other libs.
> I made changes to Android.mk and Application.mk and compiled successfully.
> But to load model I gave static path to readNodeFile as
> "/mnt/sdcard/OSG/lz.osg".
>
> When I run as Android Application I got "Model not loaded" message on cat
> log.
>
> If I give the same static path in OSGAndroid example then it is working.
>
> I am using Android 2.2 and OpenGl1.1 versions.
>
> Do i need to add any other things to my project.
>
> Can you please help me why the model is not loading?
> ...
>
> Thank you!
>
> Cheers,
> Koduri
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49621#49621
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] RESOLVED Re: Repository broken with SVN >=1.7.5?

[Jordi Torres]

Hi fred et al,

Today I have been in the university trying to restore the osg server.
Unfortunately I don't have physical access to the server and the people who
has this access are still on holydays. I wrote to these  people in order to
reboot the machine but I haven't received any answer yet. :-(.

Try to use the git or mercurial mirrors to get the code and use google
cache or the new web for documentation. Sorry for the inconveniences.

Cheers
El 28/08/2012 15:11, "Fred Smith"  escribió:

> Hi,
>
> I have problems accessing SVN repositories today using a 1.6.7 client (!
> maybe I should upgrade). On a side note, I can't access
> www.openscenegraph.org either.
>
> Cheers,
> Fred
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49623#49623
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdparty] osgWidget and rotation

[Jeremy Moles]

On Tue, 2012-08-28 at 11:05 +0200, Miguel Lokida wrote:
> Hi,
> 
> I want to use an osgWidget to draw a compass. So, I need to use the rotation. 
> The problem is that the origin of the osgWidget is at the bottom left and not 
> at the center of the widget. 
> 
> How can I specify the center of my widget (since set Origin only move the 
> widget) in order to have a good rotation.

A Widget's origin should be relative to the Window it is parented in.
Rotations should occur properly in that respect, can you provide some
code that isn't behaving properly?

> Thank you!
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49609#49609
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Trouble with LightSpacePerspectiveShadowMap artifacts.

[Dario Minieri]

Hi,

Thanks for your reply. Yes, I see now the polygonoffsetfactor and 
polygonoffsetunits variables even if there are no methods to set them (osg 
3.0.0), they are setted as attribute camera StateSet because shadow map 
generation. I can try to tweak these values in some way. You speaks about two 
stuffs which I would to discuss:

1. You say that the model must be closed, but what do you means precisely? 
"Closed" in term of vertex mesh or "closed" in terms of shape? For example a 
cube is a "closed" model, my truck obviously not... 

2. I can set the cull faces on my objects stateset via GL_CULL_FACE, do you 
means that? 

Many thanks

Thank you!

Cheers,
Dario

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49624#49624





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] RESOLVED Re: Repository broken with SVN >=1.7.5?

[Fred Smith]

Hi,

I have problems accessing SVN repositories today using a 1.6.7 client (! maybe 
I should upgrade). On a side note, I can't access www.openscenegraph.org either.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49623#49623





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Weird polygons on nVidia NVS cards

[Robert Osfield]

HI Carsten,

On 28 August 2012 11:00, Carsten Scharfe  wrote:
> I tried it out now.
> Windows are appearing, and shaders work on each view.
> But polygon corruption still persists.
>
> It seems to me that this is a driver issue.

It could well be, trying a different OS/hardware/drivers would help
determine if it is a driver issues.

Another route you could take is to create a single GraphicsWindow for
all your views and just manage the Camera Viewport's of each of the
View so that each appears separately.  The osgcompositeviewer
illustrate this in action.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Error while loading OSG model on Android

[Koduri Lakshmi]

Hi,

I build OSGAndroid example on Ubuntu device. I loaded and displayed OSG model 
successfully on my mobile device.

Now I used the OSG lib in my project which are using some other libs. 
I made changes to Android.mk and Application.mk and compiled successfully.
But to load model I gave static path to readNodeFile as 
"/mnt/sdcard/OSG/lz.osg".

When I run as Android Application I got "Model not loaded" message on cat log.

If I give the same static path in OSGAndroid example then it is working. 

I am using Android 2.2 and OpenGl1.1 versions.

Do i need to add any other things to my project.

Can you please help me why the model is not loading?
... 

Thank you!

Cheers,
Koduri

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49621#49621




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] how to do culling with shader tranformed geometry?

[Alexej Fink]

Hello Sebastian,

unfortunately I cannot create bigger sets with more GL geometry in them, cause 
I need the geometry to be addressable. :(



Sebastian Messerschmidt wrote:
> Hello Alexej, Robert
> 
> I think the reason for Alexej to think that disabling the culling would 
> improve render time in any way, is that he measuring the time of the 
> cull traversal.
> Indeed the cull traversal time is culling + preparing the drawing of the 
> geometries. I've fallen for this in the beginning.
> So maybe the problem lies with the number of drawables (i.e. there are 
> too many too small batches). So being clever at this point would rather 
> mean to make bigger yet fewer sets.
> 
> cheers
> Sebastian
> 


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49620#49620





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] how to do culling with shader tranformed geometry?

[Alexej Fink]

Hellor Robert,

Every day I try to think a bit less, but it does not work for me... ;)

But seriously:
OSG is a framework, which tries to fit several different use cases. And it is 
natural, that it will not fit perfect for every possible job. Thus I want to 
figure out, how I can use it in the best way for my purpose. 

I try to use shaders to project flat world geometry on a sphere to keep the 
scene graph simple. But cannot tune the culling stage to fit this situation 
(yet) and have to deal with a pretty crude workaround distorting the bounding 
boxes, which breaks the idea of keeping the flat world scene graph simple. 

I highly appreciate your help, but that does not imply, that I shall not have 
an own vision, of how to do certain things.

Therefore I still think (being clever), that adapting the culling visitor would 
be a cleaner way. But unfortunately don't know, how to do it now, and since the 
OSG API is nearly undocumented, it is a hard way to go.
All I want is a custom flat-world culler, set up of four clipping planes and a 
fitting AND/OR conjunction (for full-inside or warp-on-border cases). Is this 
that hard to do with OSG?

Cheers,
Alexej

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49619#49619





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Switch inactive children callback

[Sebastian Messerschmidt]

Hi Sergey,

But this way I will not recognize if the switch is set to a mask where 
my "cloned" lightsource wouldn't be on.
So what I need more than not receiving update visiting is the state 
transition.
My idea here would be to add a dummy node to the position where my 
lightsource originally was. It would have to publish the "lightsource 
on" state every traversal and the cloned lightsource would have to be 
switched on/off accordingly ..


cheers
Sebastian

Hi, Sebastian

There are nodevisitor traversal modes, and one of those is 
TRAVERSE_ACTIVE_CHILDREN, try to set this on your update visitor, and you'll be 
in good shape.

Cheers,
Sergey.

27.08.2012, 22:45, "Sebastian Messerschmidt" :

Hello,

My current challenge seems to be a hard one ;-)
In my pipeline I effectively removed all lightsources from the original
scenegraph and copied to a separate graph.
Instead of the original lightsources I install an update callback to
transform the lightsources like in the original graph, so I can render
them as light-volumes with the correct pose in another pass.
This is working very well, even with dynamic transforms as childs of the
original light sources. Now the problem with this approach is, that
light sources below a switch or osgSim::Multiswitch node will not work
as expected.
As the update callback is called for every node, regardless of being
active or inactive, the light source will be transformed an active in my
case.
Has anybody an idea how to find out if the current traversal originated
from an inactive parent?
I don't see a simple solution, but maybe the experts here can help me
out. Does the NodeVisitor somehow collect this state, or is there any
way to install a callback on the parental switches to find out when a
subgraph is disabled?

cheers
Sebastian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Switch inactive children callback

[Sergey Polischuk]

Hi, Sebastian

There are nodevisitor traversal modes, and one of those is 
TRAVERSE_ACTIVE_CHILDREN, try to set this on your update visitor, and you'll be 
in good shape.

Cheers,
Sergey.

27.08.2012, 22:45, "Sebastian Messerschmidt" :
> Hello,
>
> My current challenge seems to be a hard one ;-)
> In my pipeline I effectively removed all lightsources from the original
> scenegraph and copied to a separate graph.
> Instead of the original lightsources I install an update callback to
> transform the lightsources like in the original graph, so I can render
> them as light-volumes with the correct pose in another pass.
> This is working very well, even with dynamic transforms as childs of the
> original light sources. Now the problem with this approach is, that
> light sources below a switch or osgSim::Multiswitch node will not work
> as expected.
> As the update callback is called for every node, regardless of being
> active or inactive, the light source will be transformed an active in my
> case.
> Has anybody an idea how to find out if the current traversal originated
> from an inactive parent?
> I don't see a simple solution, but maybe the experts here can help me
> out. Does the NodeVisitor somehow collect this state, or is there any
> way to install a callback on the parental switches to find out when a
> subgraph is disabled?
>
> cheers
> Sebastian
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Questions

[Sergey Polischuk]

Hi

I've seen such problems in windows on nvidia card with static osg build in 
singlethreaded app on several machines, you could reproduce this in couple of 
runs with just opening model with embedded compressed textures in 
osgstaticviewer example under windows (dont know if this same for dynamic 
build), on linux all work great. I have no idea if this is driver issue or 
plugin problem or whatever.

Cheers.

27.08.2012, 20:23, "Robert Osfield" :
> Opps.. I wrote:
>
> On 27 August 2012 17:22, Robert Osfield  wrote:
>
>>  Also try cutting down the number of textures used.
>
> I meant to say "try cutting down the number THREADS used." :-)
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Weird polygons on nVidia NVS cards

[Carsten Scharfe]

I tried it out now.
Windows are appearing, and shaders work on each view.
But polygon corruption still persists.

It seems to me that this is a driver issue.

Carsten.



-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Carsten Scharfe
Sent: Tuesday, August 28, 2012 11:48 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Weird polygons on nVidia NVS cards

I'll try that out.

Carsten

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Tuesday, August 28, 2012 11:45 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Weird polygons on nVidia NVS cards

Hi Carsten,

In principle what you are doing should work, what might be wrong I
can't say though.  I don't use windows so can't comment on the
specifics of this type of setup.  The only thing I can think of that
might cause one window to work but others not is for the OpenGL object
management to be set up incorrectly, this should however be done for
you by the OSG.

As a sanity test could you try creating windows using osgViewer's
window creation without using the WindowData feature.

Robert.

On 28 August 2012 10:34, Carsten Scharfe  wrote:
> Hi Robert,
>
> Thank you for your answer.
> I've tried and set the sharedContext member to 0 for all views,
> as you've suggested.
> The result was the same, corrupted polygons in one or more views.
> But now with the difference that shaders work only in one view, which
> is the one first created.
>
> Maybe there is still an error in initializing the views, so I've added
> the code used for creating a view:
>
> osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
> osg::ref_ptr windata = new
> osgViewer::GraphicsWindowWin32::WindowData(hwnd,false);
> CRect winRect;
>
> ::GetClientRect(hwnd,&winRect);
>
> // init graphics traits
> traits->x = 0;
> traits->y = 0;
> traits->width = winRect.Width();
> traits->height = winRect.Height();
> traits->windowDecoration = false;
> traits->doubleBuffer = true;
> traits->sharedContext = 0;
> traits->setInheritedWindowPixelFormat = true;
> traits->inheritedWindowData = windata;
> traits->supportsResize = true;
> traits->useMultiThreadedOpenGLEngine = true;
> traits->alpha = 8;
> traits->red = 8;
> traits->green = 8;
> traits->blue = 8;
> traits->depth = 24;
> traits->stencil = 8;
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
> osgViewer::View *posgViewNew = new osgViewer::View;
> osg::DisplaySettings *posgDs = new osg::DisplaySettings;
>
> posgDs->setDefaults();
> posgDs->setDisplayType(osg::DisplaySettings::MONITOR);
> posgDs->setDepthBuffer(true);
> posgDs->setStereo(false);
> posgDs->setDoubleBuffer(true);
>
> // and make that camera display its contents in this context
> posgViewNew->getCamera()->setClearMask(GL_DEPTH_BUFFER_BIT |
> GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
> posgViewNew->getCamera()->setClearStencil(0);
>
> posgViewNew->getCamera()->setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
> posgViewNew->getCamera()->setDisplaySettings(posgDs);
> posgViewNew->getCamera()->setGraphicsContext(gc.get());
> posgViewNew->getCamera()->setViewport(0,0, winRect.Width(),
> winRect.Height());
>
> On start our application creates 4 views this way, right after creating and
> setting up the
> composite viewer as single threaded.
> What puzzles me is that assigned shaders work only in one view and that
> other views
> have still corrupted polygons.
> Besides displaying the views (i.e. adding them to the composite viewer) take
> a long time on NVS cards.
> Do you have seen such behavior?
>
> We observed this on an NVS4200M and on other NVS systems. Are the drivers so
> bad, that only one context
> is supported on NVS cards?
>
> Sadly, the other approach, you've suggested, by using the view's viewports
> in the same window is for several
> reason unapplicable.
>
> Regards,
> Carsten.
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
> Osfield
> Sent: Monday, August 27, 2012 3:57 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Weird polygons on nVidia NVS cards
>
> Hi Carsten,
>
> On 27 August 2012 11:57, Carsten Scharfe  wrote:
>> Both views share the same context. This context is created first, with no
>> inherited window data.
>>
>> When I create a new view, I create a new context for this view and set the
>> sharedContext member
>>
>> to the shared context. I set the inherited window data too for embedding
>> the
>

Re: [osg-users] Trouble with LightSpacePerspectiveShadowMap artifacts.

[Wojciech Lewandowski]

Hi, Dario,

LispSM is setup by default to cast shadows using light space backfacing
polygons. That approach works well if models are closed and build with face
culling in mind. If your model does not utilize cull faces (and your truck
looks like that case), all front polygons will cast shadows. So the
artifact you see is false self shadowing on front polygons. To work around
that you will have to switch the sign of polygon offset factors and maybe
further tweak polygon offset factors magnitude if your field of view gets
big. You will find current polygon offset values in StandardShadowMap setup
code. There is a method to set new polygon offset for the technique.

PS:  I highly recommend reading some papers on principles of ShadowMaping.
There is a Mark Kilkgard presentation on the web that explains many of the
problems.

Cheers,
Wojtek Lewandowski

2012/8/28 Dario Minieri 

> Hi!
>
> Nice to hear for the new your technique, I will try today checking the
> svn. Is a ShadowMap tech, so the shaders are the same of
> StandardShadowMap.cpp file?
>
> Meantime, I attach a debug shadow snapshot with CAST and NOCAST setted on
> terrain. I'm not sure to understand well the result...the artifacts are the
> same in both cases, but the depth calculation seems to be different to
> me...You can see some specific stuffs?
>
> Thanks again for your suggestions.
>
> Best regards
>
>
> robertosfield wrote:
> > Hi Dario,
> >
> > On 27 August 2012 17:13, Dario Minieri <> wrote:
> >
> > > I've tried to use the CASTS_SHADOW_TRAVERSAL_MASK on my terrain but
> the final result is pretty the same.
> > >
> > > Code:
> > > GfxTerr->setNodeMask(m_GfxTerr->getNodeMask() &
> ~CASTS_SHADOW_TRAVERSAL_MASK);
> > >
> >
> > Run the debug shadow view to see if it's taking into account the terrain.
> >
> > Or... just try the ViewDependentShadowMap technique that now is
> > available in svn/trunk.  This new technique is more robust than LispSM
> > and offers similar functionality w.r.t projections.  It may or may not
> > solve your problem, but as I'm the author of this particular technique
> > I have a better chance of understand and helping address the issues.
> > I'm not the author or or the implementator the OSG's LispSM technique
> > so am a bit of disadvantage here.
> >
> > Robert.
> > ___
> > osg-users mailing list
> >
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >  --
> > Post generated by Mail2Forum
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49608#49608
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Weird polygons on nVidia NVS cards

[Carsten Scharfe]

I'll try that out.

Carsten

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Tuesday, August 28, 2012 11:45 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Weird polygons on nVidia NVS cards

Hi Carsten,

In principle what you are doing should work, what might be wrong I
can't say though.  I don't use windows so can't comment on the
specifics of this type of setup.  The only thing I can think of that
might cause one window to work but others not is for the OpenGL object
management to be set up incorrectly, this should however be done for
you by the OSG.

As a sanity test could you try creating windows using osgViewer's
window creation without using the WindowData feature.

Robert.

On 28 August 2012 10:34, Carsten Scharfe  wrote:
> Hi Robert,
>
> Thank you for your answer.
> I've tried and set the sharedContext member to 0 for all views,
> as you've suggested.
> The result was the same, corrupted polygons in one or more views.
> But now with the difference that shaders work only in one view, which
> is the one first created.
>
> Maybe there is still an error in initializing the views, so I've added
> the code used for creating a view:
>
> osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
> osg::ref_ptr windata = new
> osgViewer::GraphicsWindowWin32::WindowData(hwnd,false);
> CRect winRect;
>
> ::GetClientRect(hwnd,&winRect);
>
> // init graphics traits
> traits->x = 0;
> traits->y = 0;
> traits->width = winRect.Width();
> traits->height = winRect.Height();
> traits->windowDecoration = false;
> traits->doubleBuffer = true;
> traits->sharedContext = 0;
> traits->setInheritedWindowPixelFormat = true;
> traits->inheritedWindowData = windata;
> traits->supportsResize = true;
> traits->useMultiThreadedOpenGLEngine = true;
> traits->alpha = 8;
> traits->red = 8;
> traits->green = 8;
> traits->blue = 8;
> traits->depth = 24;
> traits->stencil = 8;
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
> osgViewer::View *posgViewNew = new osgViewer::View;
> osg::DisplaySettings *posgDs = new osg::DisplaySettings;
>
> posgDs->setDefaults();
> posgDs->setDisplayType(osg::DisplaySettings::MONITOR);
> posgDs->setDepthBuffer(true);
> posgDs->setStereo(false);
> posgDs->setDoubleBuffer(true);
>
> // and make that camera display its contents in this context
> posgViewNew->getCamera()->setClearMask(GL_DEPTH_BUFFER_BIT |
> GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
> posgViewNew->getCamera()->setClearStencil(0);
>
> posgViewNew->getCamera()->setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
> posgViewNew->getCamera()->setDisplaySettings(posgDs);
> posgViewNew->getCamera()->setGraphicsContext(gc.get());
> posgViewNew->getCamera()->setViewport(0,0, winRect.Width(),
> winRect.Height());
>
> On start our application creates 4 views this way, right after creating and
> setting up the
> composite viewer as single threaded.
> What puzzles me is that assigned shaders work only in one view and that
> other views
> have still corrupted polygons.
> Besides displaying the views (i.e. adding them to the composite viewer) take
> a long time on NVS cards.
> Do you have seen such behavior?
>
> We observed this on an NVS4200M and on other NVS systems. Are the drivers so
> bad, that only one context
> is supported on NVS cards?
>
> Sadly, the other approach, you've suggested, by using the view's viewports
> in the same window is for several
> reason unapplicable.
>
> Regards,
> Carsten.
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
> Osfield
> Sent: Monday, August 27, 2012 3:57 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Weird polygons on nVidia NVS cards
>
> Hi Carsten,
>
> On 27 August 2012 11:57, Carsten Scharfe  wrote:
>> Both views share the same context. This context is created first, with no
>> inherited window data.
>>
>> When I create a new view, I create a new context for this view and set the
>> sharedContext member
>>
>> to the shared context. I set the inherited window data too for embedding
>> the
>> view in the desired window.
>
> I think you are a little confused by what is a context and what is a
> shared context.  You description implies that you have two graphics
> context, the second graphics context sharing OpenGL objects with the
> first context (this is what a shared context means), but is still a
> separate graphics context.
>
> It could be that there is an issue with the viewer setup, but equally
> is could be an issue in the OpenGL dri

Re: [osg-users] Weird polygons on nVidia NVS cards

[Robert Osfield]

Hi Carsten,

In principle what you are doing should work, what might be wrong I
can't say though.  I don't use windows so can't comment on the
specifics of this type of setup.  The only thing I can think of that
might cause one window to work but others not is for the OpenGL object
management to be set up incorrectly, this should however be done for
you by the OSG.

As a sanity test could you try creating windows using osgViewer's
window creation without using the WindowData feature.

Robert.

On 28 August 2012 10:34, Carsten Scharfe  wrote:
> Hi Robert,
>
> Thank you for your answer.
> I've tried and set the sharedContext member to 0 for all views,
> as you've suggested.
> The result was the same, corrupted polygons in one or more views.
> But now with the difference that shaders work only in one view, which
> is the one first created.
>
> Maybe there is still an error in initializing the views, so I've added
> the code used for creating a view:
>
> osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
> osg::ref_ptr windata = new
> osgViewer::GraphicsWindowWin32::WindowData(hwnd,false);
> CRect winRect;
>
> ::GetClientRect(hwnd,&winRect);
>
> // init graphics traits
> traits->x = 0;
> traits->y = 0;
> traits->width = winRect.Width();
> traits->height = winRect.Height();
> traits->windowDecoration = false;
> traits->doubleBuffer = true;
> traits->sharedContext = 0;
> traits->setInheritedWindowPixelFormat = true;
> traits->inheritedWindowData = windata;
> traits->supportsResize = true;
> traits->useMultiThreadedOpenGLEngine = true;
> traits->alpha = 8;
> traits->red = 8;
> traits->green = 8;
> traits->blue = 8;
> traits->depth = 24;
> traits->stencil = 8;
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
> osgViewer::View *posgViewNew = new osgViewer::View;
> osg::DisplaySettings *posgDs = new osg::DisplaySettings;
>
> posgDs->setDefaults();
> posgDs->setDisplayType(osg::DisplaySettings::MONITOR);
> posgDs->setDepthBuffer(true);
> posgDs->setStereo(false);
> posgDs->setDoubleBuffer(true);
>
> // and make that camera display its contents in this context
> posgViewNew->getCamera()->setClearMask(GL_DEPTH_BUFFER_BIT |
> GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
> posgViewNew->getCamera()->setClearStencil(0);
>
> posgViewNew->getCamera()->setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
> posgViewNew->getCamera()->setDisplaySettings(posgDs);
> posgViewNew->getCamera()->setGraphicsContext(gc.get());
> posgViewNew->getCamera()->setViewport(0,0, winRect.Width(),
> winRect.Height());
>
> On start our application creates 4 views this way, right after creating and
> setting up the
> composite viewer as single threaded.
> What puzzles me is that assigned shaders work only in one view and that
> other views
> have still corrupted polygons.
> Besides displaying the views (i.e. adding them to the composite viewer) take
> a long time on NVS cards.
> Do you have seen such behavior?
>
> We observed this on an NVS4200M and on other NVS systems. Are the drivers so
> bad, that only one context
> is supported on NVS cards?
>
> Sadly, the other approach, you've suggested, by using the view's viewports
> in the same window is for several
> reason unapplicable.
>
> Regards,
> Carsten.
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
> Osfield
> Sent: Monday, August 27, 2012 3:57 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Weird polygons on nVidia NVS cards
>
> Hi Carsten,
>
> On 27 August 2012 11:57, Carsten Scharfe  wrote:
>> Both views share the same context. This context is created first, with no
>> inherited window data.
>>
>> When I create a new view, I create a new context for this view and set the
>> sharedContext member
>>
>> to the shared context. I set the inherited window data too for embedding
>> the
>> view in the desired window.
>
> I think you are a little confused by what is a context and what is a
> shared context.  You description implies that you have two graphics
> context, the second graphics context sharing OpenGL objects with the
> first context (this is what a shared context means), but is still a
> separate graphics context.
>
> It could be that there is an issue with the viewer setup, but equally
> is could be an issue in the OpenGL driver with sharing GL objects
> between contexts.
>
> Personally I would avoid sharing contexts historically has been be
> problematic with some drivers, and brings up limitations in the way
> that you can use the OSG i.e. you can't use it multi-threaded and you
> have to be careful about cleanup.  The OSG can ha

[osg-users] GL 4.3 compute shader integration

[Fred Smith]

Hi,

Anybody working on basic compute shader integration? Just the new shader type 
and a way to kick off the job using DispatchCompute would be awesome.
Might look into this next month if nobody is up for it.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49611#49611





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Weird polygons on nVidia NVS cards

[Carsten Scharfe]

Hi Robert,

Thank you for your answer.
I've tried and set the sharedContext member to 0 for all views,
as you've suggested.
The result was the same, corrupted polygons in one or more views.
But now with the difference that shaders work only in one view, which
is the one first created.

Maybe there is still an error in initializing the views, so I've added
the code used for creating a view:

osg::ref_ptr traits = new 
osg::GraphicsContext::Traits;
osg::ref_ptr windata = new 
osgViewer::GraphicsWindowWin32::WindowData(hwnd,false);
CRect winRect;

::GetClientRect(hwnd,&winRect);

// init graphics traits
traits->x = 0;
traits->y = 0;
traits->width = winRect.Width();
traits->height = winRect.Height();
traits->windowDecoration = false;
traits->doubleBuffer = true;
traits->sharedContext = 0;
traits->setInheritedWindowPixelFormat = true;
traits->inheritedWindowData = windata;
traits->supportsResize = true;
traits->useMultiThreadedOpenGLEngine = true;
traits->alpha = 8;
traits->red = 8;
traits->green = 8;
traits->blue = 8;
traits->depth = 24;
traits->stencil = 8;

osg::ref_ptr gc = 
osg::GraphicsContext::createGraphicsContext(traits.get());

osgViewer::View *posgViewNew = new osgViewer::View;
osg::DisplaySettings *posgDs = new osg::DisplaySettings;

posgDs->setDefaults();
posgDs->setDisplayType(osg::DisplaySettings::MONITOR);
posgDs->setDepthBuffer(true);
posgDs->setStereo(false);
posgDs->setDoubleBuffer(true);

// and make that camera display its contents in this context
posgViewNew->getCamera()->setClearMask(GL_DEPTH_BUFFER_BIT | 
GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
posgViewNew->getCamera()->setClearStencil(0);

posgViewNew->getCamera()->setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
posgViewNew->getCamera()->setDisplaySettings(posgDs);
posgViewNew->getCamera()->setGraphicsContext(gc.get());
posgViewNew->getCamera()->setViewport(0,0, winRect.Width(), 
winRect.Height());

On start our application creates 4 views this way, right after creating and 
setting up the
composite viewer as single threaded.
What puzzles me is that assigned shaders work only in one view and that other 
views
have still corrupted polygons.
Besides displaying the views (i.e. adding them to the composite viewer) take a 
long time on NVS cards.
Do you have seen such behavior?

We observed this on an NVS4200M and on other NVS systems. Are the drivers so 
bad, that only one context
is supported on NVS cards?

Sadly, the other approach, you've suggested, by using the view's viewports in 
the same window is for several
reason unapplicable.

Regards,
Carsten.

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Monday, August 27, 2012 3:57 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Weird polygons on nVidia NVS cards

Hi Carsten,

On 27 August 2012 11:57, Carsten Scharfe  wrote:
> Both views share the same context. This context is created first, with no
> inherited window data.
>
> When I create a new view, I create a new context for this view and set the
> sharedContext member
>
> to the shared context. I set the inherited window data too for embedding the
> view in the desired window.

I think you are a little confused by what is a context and what is a
shared context.  You description implies that you have two graphics
context, the second graphics context sharing OpenGL objects with the
first context (this is what a shared context means), but is still a
separate graphics context.

It could be that there is an issue with the viewer setup, but equally
is could be an issue in the OpenGL driver with sharing GL objects
between contexts.

Personally I would avoid sharing contexts historically has been be
problematic with some drivers, and brings up limitations in the way
that you can use the OSG i.e. you can't use it multi-threaded and you
have to be careful about cleanup.  The OSG can handle multiple
contexts just fine, just don't set the sharedContext info when setting
up your new context.  Alternatively just share the same graphics
context with both view's viewports on the same window - this approach
will lead to the best performance.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [3rdparty] osgWidget and rotation

[Miguel Lokida]

Hi,

I want to use an osgWidget to draw a compass. So, I need to use the rotation. 
The problem is that the origin of the osgWidget is at the bottom left and not 
at the center of the widget. 

How can I specify the center of my widget (since set Origin only move the 
widget) in order to have a good rotation.

Thank you!

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49609#49609





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org