Re: [osg-users] Seeking advice: Efficient method for large grid rendering (terrain) with unique state per grid square

[Robert Osfield]

Hi John,

When dealing with large amounts of data the best approach is typically to
use paging, you can use the osg::PageLOD node to support this when
generating your own scene graphs, or use VirtualPlanetBuilder to creat a
paged database offline, or osgEarth to create the paged database at runtime
on demand.  Either of these approaches may be appropriate for your dataset.

You don't say much about the nature of your dataset.  The area of coverage
of each tile isn't important, what is important is the amount of data.
Typically one needs to balance the amount of data per tile, so the area of
the tile you will want to build will be governed by the amount of data you
want to use per tile.  In OSG-3.4 there is support in osgTerrain for
sharing the osg::Geometry between tiles and assigning seperate texture
layers to each tile, this drastically cuts the memory footprint and
bandwidth needs.  Even you don't use osgTerrain/osgEarth etc. this sharing
approach might be appropriate for you.

Robert.


On 8 September 2015 at 23:35, John Peterson  wrote:

> Hello everyone,
>
> I am seeking some advice on the best way to implement a particular task
> using OSG. Hopefully I can articulate what I'd like to do in a way that
> makes sense--please do not hesitate to ask if I need to clarify.
>
> Essentially, I'd like to use OSG to render a large grid which is basically
> a heightfield representing a terrain. Each square of the grid will
> represent a fairy large amount of area, about 5000 m^2 per grid square, and
> I envision having a large number of these grid squares--on the order of a
> couple hundred thousand. I'd like to be able to assign a unique state
> consisting of one or more textures to each grid square. For instance, one
> grid square may have a water texture, another square a grass texture,
> another a road segment, etc. My camera will almost always be just above the
> terrain, similar to what the DriveManipulator accomplishes. I do not
> foresee having to 'fly' high above the terrain; I don't know if that allows
> for some sort of optimization.
>
> I've tried creating my own geometry objects, one per grid square, which
> allows me to set a unique StateSet per square. Performance scales poorly
> with total number of grid squares added, as one might expect. I thought OSG
> would cull the grid squares that were out out the viewport, but I suppose
> traversing all those geometries is CPU-intensive. That said, I did add all
> my objects to the root of the scene; I did not try grouping them
> hierarchically in any way (for instance, breaking down the grid into
> quadrants, then breaking those quadrants into four, etc.) If I built up a
> tree in this manner using osg::Groups, would OSG know to cull the entire
> group if its bounding box were outside the viewport, or does it just
> iterate over all the children each time? Is there a facility I should look
> into that can accomplish this?
>
> My application sounds like a perfect fix for osgTerrain and its
> constituent classes, but my understanding (which may be incorrect) from
> reading osgTerrainTile is that while it can be assigned an elevation layer
> with many rows and columns, a colour layer for a texture will cover the
> entire tile. If I were to use osgTerrainTile, I'd be creating tiles with
> one row and column (one height value), and setting layers for my textures.
> This basically sounds like my existing solution and seems like an abuse (or
> horrible misuse? underuse?) of the terrain facilities, and again I'm
> concerned about performance.
>
> Are there any techniques that I should look into to ensure a performant
> application? I'll admit that this is not my area of expertise. I appreciate
> any pointers in the right direction.
>
> Best regards,
> John
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65071#65071
>
>
>
>
>
> ___
> 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] pfObject::getNamedUserDataSlot

[Robert Osfield]

Hi Tony,

As Nick says there is the Node::setUserValue(..) template method and
Node::setUserData().  When you use UserValue it creates a UserDataContainer
to hold the values in a vector of osg::Object*, so this UserDataContainer
kinda has "slots".  The UserDataContainer is only created on demand and
when it is used it attached to the Node(or any osg::Object) via the
setUserData().

Another approach you could take it is create your own version of
UserDataContainer that uses a map rather than a vector and attach this as
UserData.

As a general note, the OSG is designed to be extensible and configurable,
while Performer is just configurable.  In Performer you have few options to
do things that aren't originally anticipated by the API, but with the OSG
the door is open to doing completely different things with it.

Robert.

On 10 September 2015 at 06:56, Tony Vasile  wrote:

> Is there an equivalent function to the Performer
> pfObject::getNamedUserDataSlot? Our code uses it a lot to store object
> data. I'm guessing we could just store the data in a map and uses the slot
> id returned as a key.
>
> 
> Tony V
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65084#65084
>
>
>
>
>
> ___
> 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] pfObject::getNamedUserDataSlot

[Robert Osfield]

Hi Tony,

On 10 September 2015 at 09:30, Tony Vasile  wrote:

> Unfortunately we have a tight schedule to do this port. The usual 6 months
> of work in 4 months type of affair. Thanks for the advice.
>

I can sympathise with impossible tight schedules, my point still stands
though.  The OSG isn't Performer, it's something FAR more flexible.

Once you get familiar with having this flexibility you can often short cut
problems and get right to a solution far quicker.  Things that took lots of
code before can be done much more easily, things that were impossible
before now become possible.

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

Re: [osg-users] Change picked points' color ---why can't work in the pick function?

[Yexin Wang]

Thank you so much, dear Trajce! That's exactly what I want!  :D  :D  :D 




Trajce Nikolov NICK wrote:
> Hi,
> 
> can you try geom->dirtyDisplayLists() after changing the color?
> 
> Nick
> 
> 


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





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

[osg-users] Seeking advice: Efficient method for large grid rendering (terrain) with unique state per grid square

[John Peterson]

Hello everyone,

I am seeking some advice on the best way to implement a particular task using 
OSG. Hopefully I can articulate what I'd like to do in a way that makes 
sense--please do not hesitate to ask if I need to clarify.

Essentially, I'd like to use OSG to render a large grid which is basically a 
heightfield representing a terrain. Each square of the grid will represent a 
fairy large amount of area, about 5000 m^2 per grid square, and I envision 
having a large number of these grid squares--on the order of a couple hundred 
thousand. I'd like to be able to assign a unique state consisting of one or 
more textures to each grid square. For instance, one grid square may have a 
water texture, another square a grass texture, another a road segment, etc. My 
camera will almost always be just above the terrain, similar to what the 
DriveManipulator accomplishes. I do not foresee having to 'fly' high above the 
terrain; I don't know if that allows for some sort of optimization.

I've tried creating my own geometry objects, one per grid square, which allows 
me to set a unique StateSet per square. Performance scales poorly with total 
number of grid squares added, as one might expect. I thought OSG would cull the 
grid squares that were out out the viewport, but I suppose traversing all those 
geometries is CPU-intensive. That said, I did add all my objects to the root of 
the scene; I did not try grouping them hierarchically in any way (for instance, 
breaking down the grid into quadrants, then breaking those quadrants into four, 
etc.) If I built up a tree in this manner using osg::Groups, would OSG know to 
cull the entire group if its bounding box were outside the viewport, or does it 
just iterate over all the children each time? Is there a facility I should look 
into that can accomplish this?

My application sounds like a perfect fix for osgTerrain and its constituent 
classes, but my understanding (which may be incorrect) from reading 
osgTerrainTile is that while it can be assigned an elevation layer with many 
rows and columns, a colour layer for a texture will cover the entire tile. If I 
were to use osgTerrainTile, I'd be creating tiles with one row and column (one 
height value), and setting layers for my textures. This basically sounds like 
my existing solution and seems like an abuse (or horrible misuse? underuse?) of 
the terrain facilities, and again I'm concerned about performance.

Are there any techniques that I should look into to ensure a performant 
application? I'll admit that this is not my area of expertise. I appreciate any 
pointers in the right direction.

Best regards,
John

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





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

Re: [osg-users] pfObject::getNamedUserDataSlot

[Tony Vasile]

Hi Nick & Robert,
   That's not quite the same functionality as it appears that in Performer 
there is some sort of memory/map that is used to map a user defined name as a 
string to a slot number. You then add data to the node using this slot number. 
Performer does have a call to setUserData which takes the data as its argument 
but it installs the data in slot 0. There is another setUserData that takes two 
argument, with the first argument being a slot number. I assume that  
getNamedUserDataSlot is just an allocation scheme between the string name and 
and a magic number which represents the slot. 

That's cool this sort of functionality I could easily replicated with a couple 
of maps or a vector.

Thanks for your help.


Tony V

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





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

Re: [osg-users] [Questio nabout StateSet.cpp] truncated attribute override value?

[Voerman, L.]

Hi Julien,
it's OFF, the enum for StateAttribute::OFF is 0x0, so anything not ON has
value OFF.
Regards, Laurens.


On Wed, Sep 9, 2015 at 7:45 PM, Julien Valentin 
wrote:

> Hi,
> Iwould like to introspect StateSet in order to know which override value
> is activated for a particular stateset.
> I parse AttributeList for this
>
> Code:
> for( osg::StateSet::AttributeList::const_iterator
> it=ss->getAttributeList().begin();it!=ss->getAttributeList().end() ; it++)
> {
> if((*it).second.first ==stateattribute)
> {
> if( (*it).second.second & osg::StateAttribute::ON)
> return(1);
> else return(0);
> }
>
>
>
> but according to StateSet.cpp l.1662
>
> Code:
> attributeList[attribute->getTypeMemberPair()] =
> RefAttributePair(attribute,value&(StateAttribute::OVERRIDE|StateAttribute::PROTECTED));
>
>
>
> the ON OFF bit is removed from the given user value. So I can't determine
> if an osg::Attribute is ON or OFF but only if it's OVERRIDE or PROTECTED
> I would like to know if there's a known reason behind this logic & and
> further if you know a mean to retrieve the ON/OFF bit.
>
> Thank you!
>
> Cheers,
> Julien
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65081#65081
>
>
>
>
>
> ___
> 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] how to get the handle of opengl texture that corresponds to a OSG::Texture

[Robert Osfield]

Hi Qingjie,

This is no longer about the OSG, it's about C++.  Your mistake is straight
forward C++ issue of not matching the base classes parameters when
overidding a method:  The Camera::DrawCallback base class is:


/** Draw callback for custom operations.*/
struct OSG_EXPORT DrawCallback : virtual public Object
{
DrawCallback() {}

DrawCallback(const DrawCallback&,const CopyOp&) {}

META_Object(osg, DrawCallback);

/** Functor method called by rendering thread. Users will
typically override this method to carry tasks such as screen capture.*/
virtual void operator () (osg::RenderInfo& renderInfo) const;

/** Functor method, provided for backwards compatibility,
called by operator() (osg::RenderInfo& renderInfo) method.*/
virtual void operator () (const osg::Camera& /*camera*/) const
{}
};

Please look carefully at your own code to see your mistake.

Robert.



On 10 September 2015 at 04:42, Qingjie Zhang <305479...@qq.com> wrote:

> Hi Robert,
> To get the handle of opengl texture, I attached a DrawCallback to the main
> camera, doing like these codes:
> struct MyCameraPostDrawCallback : public osg::Camera::DrawCallback
> {
> virtual void operator()(const osg::RenderInfo )
> {
> int contextID = renderInfo.getContextID();
> GLuint frontTexHandle =
> m_frontTex->getTextureObject(contextID)->id();
> GLuint backTexHandle =
> m_backTex->getTextureObject(contextID)->id();
> }
> };
> camera->setPostDrawCallback(new MyCameraPostDrawCallback);
>
> But the function operator() int the callback does not run, I tried
> setPostDrawCallback() and setFinalDrawCallback(), they were the same.
> I was thinking that the DrawCallback would run every frame...
> Can you tell me when the callback runs?
> And, to get the handle,  is it right to attach DrawCallback to camera? If
> not, can you tell me the detailed method to get the handle?
>
> Thank you,
>
> Qingjie.
>
>
> robertosfield wrote:
> > Hi Qingjie,
> > On 9 September 2015 at 09:27, Qingjie Zhang < ()> wrote:
> >
> > > Do you mean the DrawCallback in the Camera class, which contains
> > > virtual void operator () (osg::RenderInfo& renderInfo) ? And here I
> can use the RenderInfo right?
> > >
> >
> >
> > Yes.  You can attach draw callbacks to Drawables, StateAtttribute and
> Camera's.
> >
> >
> >
> >
> > >
> > > As I know, the following code can get a contextID:
> > > camera->getGraphicsContext()->getState()->getContextID();
> > > Is this contextID same as the upper one?
> > >
> >
> >
> > If you only need the contexID then getting it from the graphics context
> is perfectly fine.  What route to take depends on when you need to do your
> queries.
> >
> >
> > I would add that the TextureObject for each context is only created by
> the draw thread for each context, so the TextureObject won't exist right
> away when you create your osg::Texture and assign them to the scene graph.
> >
> >
> >
> > Robert.
> >
> >
> >
> >  --
> > Post generated by Mail2Forum
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65083#65083
>
>
>
>
>
> ___
> 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] pfObject::getNamedUserDataSlot

[Robert Osfield]

Hi Tony,

Spend some time with OSG code, you'll find it far more flexible than
anything that Performer had.  It's investing time into learning the OSG
rather than just working out how to do something equivalent to Performer
because your original design may well have been compromised by the
limitations of Perfomer, with the OSG it is extensible so you mold it to
how you want to work rather than moulding how you work to fit limitations
in front of you.

Robert.

On 10 September 2015 at 08:46, Tony Vasile  wrote:

> Hi Nick & Robert,
>That's not quite the same functionality as it appears that in Performer
> there is some sort of memory/map that is used to map a user defined name as
> a string to a slot number. You then add data to the node using this slot
> number. Performer does have a call to setUserData which takes the data as
> its argument but it installs the data in slot 0. There is another
> setUserData that takes two argument, with the first argument being a slot
> number. I assume that  getNamedUserDataSlot is just an allocation scheme
> between the string name and and a magic number which represents the slot.
>
> That's cool this sort of functionality I could easily replicated with a
> couple of maps or a vector.
>
> Thanks for your help.
>
> 
> Tony V
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65089#65089
>
>
>
>
>
> ___
> 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] pfObject::getNamedUserDataSlot

[Trajce Nikolov NICK]

Hi Tony,

you have two options:

- osg::Object:get/setUserData
- osg::Object:setUserValue (for this one you have to #include


Nick

On Thu, Sep 10, 2015 at 7:56 AM, Tony Vasile  wrote:

> Is there an equivalent function to the Performer
> pfObject::getNamedUserDataSlot? Our code uses it a lot to store object
> data. I'm guessing we could just store the data in a map and uses the slot
> id returned as a key.
>
> 
> Tony V
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65084#65084
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] pfObject::getNamedUserDataSlot

[Tony Vasile]

Unfortunately we have a tight schedule to do this port. The usual 6 months of 
work in 4 months type of affair. Thanks for the advice.


Tony V

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





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

Re: [osg-users] [Question about StateSet.cpp] truncated attribute override value?

[Voerman, L.]

Sorry, you are right, i did not read your question properly.
Modes could have a value OFF, attributes do not, they are always ON
Laurens.

On Thu, Sep 10, 2015 at 1:35 PM, Julien Valentin  wrote:

> I think you misread the question:
> You can't know if the flags is ON/OFF as the bit seams ignored and then
> not stored...
> Using the posted code, it never returns 1.
>
>
>
>
> Voerman, L. wrote:
> > Hi Julien,it's OFF, the enum for StateAttribute::OFF is 0x0, so anything
> not ON has value OFF.
> > Regards, Laurens.
> >
> >
> >
> >
> > On Wed, Sep 9, 2015 at 7:45 PM, Julien Valentin < ()> wrote:
> >
> > > Hi,
> > > Iwould like to introspect StateSet in order to know which override
> value is activated for a particular stateset.
> > > I parse AttributeList for this
> > >
> > > Code:
> > > for( osg::StateSet::AttributeList::const_iterator
> it=ss->getAttributeList().begin();it!=ss->getAttributeList().end() ; it++)
> > > {
> > > if((*it).second.first ==stateattribute)
> > > {
> > > if( (*it).second.second & osg::StateAttribute::ON)
> > > return(1);
> > > else return(0);
> > > }
> > >
> > >
> > >
> > > but according to StateSet.cpp l.1662
> > >
> > > Code:
> > > attributeList[attribute->getTypeMemberPair()] =
> RefAttributePair(attribute,value&(StateAttribute::OVERRIDE|StateAttribute::PROTECTED));
> > >
> > >
> > >
> > > the ON OFF bit is removed from the given user value. So I can't
> determine if an osg::Attribute is ON or OFF but only if it's OVERRIDE or
> PROTECTED
> > > I would like to know if there's a known reason behind this logic & and
> further if you know a mean to retrieve the ON/OFF bit.
> > >
> > > Thank you!
> > >
> > > Cheers,
> > > Julien
> > >
> > > --
> > > Read this topic online here:
> > > http://forum.openscenegraph.org/viewtopic.php?p=65081#65081 (
> http://forum.openscenegraph.org/viewtopic.php?p=65081#65081)
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > osg-users mailing list
> > >  ()
> > >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> (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=65095#65095
>
>
>
>
>
> ___
> 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] OSG rendering to live video stream

[Trajce Nikolov NICK]

Hi Community,

I am wondering if someone knows the way to create live stream from OSG
rendering probably in combination with ffmpeg + ffserver, or any other way
- cross-platform preferred though

Thanks a bunch as always,

Cheers,
Nick

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

Re: [osg-users] [Question about StateSet.cpp] truncated attribute override value?

[Julien Valentin]

I think you misread the question:
You can't know if the flags is ON/OFF as the bit seams ignored and then not 
stored...
Using the posted code, it never returns 1.




Voerman, L. wrote:
> Hi Julien,it's OFF, the enum for StateAttribute::OFF is 0x0, so anything not 
> ON has value OFF.
> Regards, Laurens.
> 
> 
> 
> 
> On Wed, Sep 9, 2015 at 7:45 PM, Julien Valentin < ()> wrote:
> 
> > Hi,
> > Iwould like to introspect StateSet in order to know which override value is 
> > activated for a particular stateset.
> > I parse AttributeList for this
> > 
> > Code:
> > for( osg::StateSet::AttributeList::const_iterator 
> > it=ss->getAttributeList().begin();it!=ss->getAttributeList().end() ; it++)
> > {
> >             if((*it).second.first ==stateattribute)
> >             {
> >                 if( (*it).second.second & osg::StateAttribute::ON)
> >                 return(1);
> >                 else return(0);
> > }
> > 
> > 
> > 
> > but according to StateSet.cpp l.1662
> > 
> > Code:
> > attributeList[attribute->getTypeMemberPair()] = 
> > RefAttributePair(attribute,value&(StateAttribute::OVERRIDE|StateAttribute::PROTECTED));
> > 
> > 
> > 
> > the ON OFF bit is removed from the given user value. So I can't determine 
> > if an osg::Attribute is ON or OFF but only if it's OVERRIDE or PROTECTED
> > I would like to know if there's a known reason behind this logic & and 
> > further if you know a mean to retrieve the ON/OFF bit.
> > 
> > Thank you!
> > 
> > Cheers,
> > Julien
> > 
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=65081#65081 
> > (http://forum.openscenegraph.org/viewtopic.php?p=65081#65081)
> > 
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> >  ()
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > (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=65095#65095





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

Re: [osg-users] [Question about StateSet.cpp] truncated attribute override value?

[Julien Valentin]

Thanks,
That's what i suspected...

Have a good day:)


Voerman, L. wrote:
> Sorry, you are right, i did not read your question properly.Modes could have 
> a value OFF, attributes do not, they are always ON
> Laurens.
> 
> 
> On Thu, Sep 10, 2015 at 1:35 PM, Julien Valentin < ()> wrote:
> 
> > I think you misread the question:
> > You can't know if the flags is ON/OFF as the bit seams ignored and then not 
> > stored...
> > Using the posted code, it never returns 1.
> > 
> > 
> > 
> > 
> > Voerman, L. wrote:
> > 
> > > Hi Julien,it's OFF, the enum for StateAttribute::OFF is 0x0, so anything 
> > > not ON has value OFF.
> > > Regards, Laurens.
> > > 
> > > 
> > > 
> > > 
> > > On Wed, Sep 9, 2015 at 7:45 PM, Julien Valentin < ()> wrote:
> > > 
> > > 
> > > > Hi,
> > > > Iwould like to introspect StateSet in order to know which override 
> > > > value is activated for a particular stateset.
> > > > I parse AttributeList for this
> > > > 
> > > > Code:
> > > > for( osg::StateSet::AttributeList::const_iterator 
> > > > it=ss->getAttributeList().begin();it!=ss->getAttributeList().end() ; 
> > > > it++)
> > > > {
> > > >             if((*it).second.first ==stateattribute)
> > > >             {
> > > >                 if( (*it).second.second & osg::StateAttribute::ON)
> > > >                 return(1);
> > > >                 else return(0);
> > > > }
> > > > 
> > > > 
> > > > 
> > > > but according to StateSet.cpp l.1662
> > > > 
> > > > Code:
> > > > attributeList[attribute->getTypeMemberPair()] = 
> > > > RefAttributePair(attribute,value&(StateAttribute::OVERRIDE|StateAttribute::PROTECTED));
> > > > 
> > > > 
> > > > 
> > > > the ON OFF bit is removed from the given user value. So I can't 
> > > > determine if an osg::Attribute is ON or OFF but only if it's OVERRIDE 
> > > > or PROTECTED
> > > > I would like to know if there's a known reason behind this logic & and 
> > > > further if you know a mean to retrieve the ON/OFF bit.
> > > > 
> > > > Thank you!
> > > > 
> > > > Cheers,
> > > > Julien
> > > > 
> > > > --
> > > > Read this topic online here:
> > > > http://forum.openscenegraph.org/viewtopic.php?p=65081#65081 
> > > > (http://forum.openscenegraph.org/viewtopic.php?p=65081#65081) 
> > > > (http://forum.openscenegraph.org/viewtopic.php?p=65081#65081 
> > > > (http://forum.openscenegraph.org/viewtopic.php?p=65081#65081))
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > osg-users mailing list
> > > >   ()
> > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > >  
> > > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > >  
> > > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > >  
> > > > (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=65095#65095 
> > (http://forum.openscenegraph.org/viewtopic.php?p=65095#65095)
> > 
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> >  ()
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > (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=65098#65098





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

Re: [osg-users] [Questio nabout StateSet.cpp] truncated attribute override value?

[Robert Osfield]

Hi Julien,

I don't recall the why and wherefores of this particular bit of code in
StateSet.cpp (i.e. line 1662 and associated code) but it's a lng time
since I wrote it ;-)

My best guess right now is that the ON/OFF for StateAttribute doesn't
affect anything, a StateAttribute isn't like a GL Mode that can be switched
on/off. All you can do with a StateAttribute is call it or not, and if you
don't want to call it you remove it from the StateSet.  This means all
StateAttribute attached to StateSet are implicitly ON if you wanted to
think it about a mode but in the end it's not a mode so it's probably best
not to try and treat it like one.

In the case of the StateSet API we reuse the OverrideValue as a bit mask so
it's used for the mode ON/OFF and the OVERRIDE and PROTECTED switches.  The
ON/OFF is only relevant to store for the Mode which StateAttribute and
Uniform's only the OVERRIDE and PROTECTED are significant to store.

Does this make sense?
Robert.


On 9 September 2015 at 18:45, Julien Valentin 
wrote:

> Hi,
> Iwould like to introspect StateSet in order to know which override value
> is activated for a particular stateset.
> I parse AttributeList for this
>
> Code:
> for( osg::StateSet::AttributeList::const_iterator
> it=ss->getAttributeList().begin();it!=ss->getAttributeList().end() ; it++)
> {
> if((*it).second.first ==stateattribute)
> {
> if( (*it).second.second & osg::StateAttribute::ON)
> return(1);
> else return(0);
> }
>
>
>
> but according to StateSet.cpp l.1662
>
> Code:
> attributeList[attribute->getTypeMemberPair()] =
> RefAttributePair(attribute,value&(StateAttribute::OVERRIDE|StateAttribute::PROTECTED));
>
>
>
> the ON OFF bit is removed from the given user value. So I can't determine
> if an osg::Attribute is ON or OFF but only if it's OVERRIDE or PROTECTED
> I would like to know if there's a known reason behind this logic & and
> further if you know a mean to retrieve the ON/OFF bit.
>
> Thank you!
>
> Cheers,
> Julien
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65081#65081
>
>
>
>
>
> ___
> 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] Seeking advice: Efficient method for large grid rendering (terrain) with unique state per grid square

[John Peterson]

Thank you for your reply, Robert.

You mentioned PagedLOD nodes. While I might not use the paged version of the 
LODs nodes just yet, I've been thinking a lot about whether LOD nodes are the 
way to go in order to get OSG to cull large portions of my terrain without 
having to traverse and render every single grid square in the world. I'd be 
interested to know if the following technique might succeed for my use case, 
which I could later extend to PagedLOD nodes as I increase the area of my 
terrain.

For the purposes of this very simple example, imagine a 4x4 grid where each one 
of the 16 grid squares represents a 5000 m^2 area of terrain. I should have 
been clear in my original post and mentioned that the grid squares are 
literally that--four vertices to render a pair of triangles. (In other words, 
it's not a particular complicated terrain from a geometric standpoint.) I'm 
wondering if I could use LOD nodes hierarchically in order to partition the 
scene in such a way that OSG will simply discard entire quadrants that are too 
far away from the viewer. To illustrate more clearly the scene graph I envision 
(excuse the ASCII art):


Code:
root
  LOD
LOD
  geometry for square at (0,0)
LOD
  geometry for square at (1,0)
LOD
  geometry for square at (0,1)
LOD
  geometry for square at (1,1)
  LOD
LOD
  geometry for square at (2,0)
LOD
  geometry for square at (3,0)
LOD
  geometry for square at (2,1)
LOD
  geometry for square at (3,1)
  LOD
LOD
  geometry for square at (0,2)
LOD
  geometry for square at (1,2)
LOD
  geometry for square at (0,3)
LOD
  geometry for square at (1,3)
  LOD
LOD
  geometry for square at (2,2)
LOD
  geometry for square at (3,2)
LOD
  geometry for square at (2,3)
LOD
  geometry for square at (3,3)



Of course, I'd have to carefully choose the LOD min and max values to ensure 
that I'm neither discarding too much of the scene graph nor including more than 
I actually need.

My question is, is this technique reasonable and scalable? Are there any 
pitfalls that I need to watch for, or any red flags that it raises?

Best regards,
John

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





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

Re: [osg-users] OSG rendering to live video stream

[Chris Hanson]

Basically, you'd just Render To Texture and then feed that image to a
memory-sourced encoder. There's sample code here for a desktop-to-ffmpeg
ecode:
http://stackoverflow.com/questions/29341161/encode-h264-video-using-ffmpeg-library-memory-issues

You'd set up your encode options using options like these specified here:
https://trac.ffmpeg.org/wiki/EncodingForStreamingSites

in order to stream to a live streaming site of your choice.
​
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG rendering to live video stream

[Trajce Nikolov NICK]

Thanks Chris!

Nick

On Thu, Sep 10, 2015 at 6:10 PM, Chris Hanson  wrote:

> Basically, you'd just Render To Texture and then feed that image to a
> memory-sourced encoder. There's sample code here for a desktop-to-ffmpeg
> ecode:
>
> http://stackoverflow.com/questions/29341161/encode-h264-video-using-ffmpeg-library-memory-issues
>
> You'd set up your encode options using options like these specified here:
> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
>
> in order to stream to a live streaming site of your choice.
> ​
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] OSG rendering to live video stream

[Chris Hanson]

No worries. Would be interested to know what you're going to do with it.

On Thu, Sep 10, 2015 at 11:25 AM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> Thanks Chris!
>
> Nick
>
> On Thu, Sep 10, 2015 at 6:10 PM, Chris Hanson 
> wrote:
>
>> Basically, you'd just Render To Texture and then feed that image to a
>> memory-sourced encoder. There's sample code here for a desktop-to-ffmpeg
>> ecode:
>>
>> http://stackoverflow.com/questions/29341161/encode-h264-video-using-ffmpeg-library-memory-issues
>>
>> You'd set up your encode options using options like these specified here:
>> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
>>
>> in order to stream to a live streaming site of your choice.
>> ​
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> --
> trajce nikolov nick
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG rendering to live video stream

[Chris Hanson]

Oohh! I'll use the secret handshake then! ;)​
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] strange behavior

[ted morris]

hi, I am using 3.4.0 with VisualStudio 2013, Win 8.1/x64, which all built
fine (examples all work as expected).

So, I wrote  a very simple program, which unfortunately renders the cube
offset from the horizontal axis, instead of being centered. The bounding
sphere center = 0,0,0.  If I instead add:

view1.setUpViewInWindow(0, 0, image_width, image_height);

then it renders as expected at the center of the window with the default
node trackball camera manipulator.

 Would anyone have a clue why am I observing this behavior and how to
correct the problem?

#include "stdafx.h"
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

int _tmain(int argc, _TCHAR* argv[])
{

float dimx = 2.0, dimy = 2.0, dimz = 2.0;
osg::ref_ptr cube_primitive(new osg::Box(osg::Vec3f(0, 0, 0),
dimx, dimy, dimz));
osg::ref_ptr shape(new
osg::ShapeDrawable(cube_primitive.get()));
shape->setColor(osg::Vec4(8.0, 0.2, 0.0, 1.0));
osg::ref_ptr shapegeode = new osg::Geode;
shapegeode->addDrawable(shape.get());
osg::Group * SceneNode = new osg::Group;
SceneNode->addChild(shapegeode);

osg::BoundingSphere bsphere = SceneNode->getBound();
osg::Vec3d center = bsphere.center();
printf(" *bsphere: %f,%f,%f\n", center.x(), center.y(), center.z());

osgViewer::Viewer view1;
view1.setSceneData(SceneNode);

view1.realize();
view1.run();

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

Re: [osg-users] Reading files and callbacks

[Tony Vasile]

SMesserschmidt wrote:
> Hi Tony
> 
> From examples/osgcallback
> 
> class MyReadFileCallback : public osgDB::Registry::ReadFileCallback
> {
> public:
> virtual osgDB::ReaderWriter::ReadResult readNode(const std::string& 
> fileName, const osgDB::ReaderWriter::Options* options)
> {
> std::cout<<"before readNode"< // note when calling the Registry to do the read you have to 
> call readNodeImplementation NOT readNode, as this will
> // cause on infinite recusive loop.
> osgDB::ReaderWriter::ReadResult result = 
> osgDB::Registry::instance()->readNodeImplementation(fileName,options);
> std::cout<<"after readNode"< return result;
> }
> };
> 
> 

So how would I then process the nodes looking for comment strings in the 
various OpenFlight nodes?


Tony V

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





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

Re: [osg-users] Reading files and callbacks

[Tony Vasile]

Okay I modified the example visit_model.cpp from the OpenSceneGraph 3.0 
Beginner's Guide to print the Descriptions and there was the data I was looking 
for. The sonic boom of comprehension.


Tony V

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





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

Re: [osg-users] Seeking advice: Efficient method for large grid rendering (terrain) with unique state per grid square

[Chris Hanson]

I think it's sometimes useful to step back and ask what the problem is
you're trying to solve.

Many times people pose questions like "Why can't I get hummingbirds to
carry machine guns?" where they have already self-selected a strategy
(hummingbirds) as an implementation requirement, thus making the Venn
diagrams of what is desired and what is possible no longer meet, or meet in
an undesirably small overlap. Often when we ask things about the larger
problem like "what are you trying to do?" we learn that hummingbirds aren't
really a requirement and that a wider view that includes Blackhawk
helicopters and Spectre gunships actually solve the problem better.

I understand the requirements you've self-set in this question, but we
would like to consider if they're really the best way to approach your
problem, or if understanding the real goal would suggest more optimal
solutions you haven't considered.
​
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG rendering to live video stream

[Trajce Nikolov NICK]

TOP SECRET :-)))

Will ping you privately :-)

Nick

On Thu, Sep 10, 2015 at 7:39 PM, Chris Hanson  wrote:

> No worries. Would be interested to know what you're going to do with it.
>
> On Thu, Sep 10, 2015 at 11:25 AM, Trajce Nikolov NICK <
> trajce.nikolov.n...@gmail.com> wrote:
>
>> Thanks Chris!
>>
>> Nick
>>
>> On Thu, Sep 10, 2015 at 6:10 PM, Chris Hanson 
>> wrote:
>>
>>> Basically, you'd just Render To Texture and then feed that image to a
>>> memory-sourced encoder. There's sample code here for a desktop-to-ffmpeg
>>> ecode:
>>>
>>> http://stackoverflow.com/questions/29341161/encode-h264-video-using-ffmpeg-library-memory-issues
>>>
>>> You'd set up your encode options using options like these specified here:
>>> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
>>>
>>> in order to stream to a live streaming site of your choice.
>>> ​
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>>
>> --
>> trajce nikolov nick
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
> http://www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4
> • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
> iPhone/iPad/iOS • Android
> @alphapixel  facebook.com/alphapixel (775)
> 623-PIXL [7495]
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] Seeking advice: Efficient method for large grid rendering (terrain) with unique state per grid square

[Robert Osfield]

Hi John,

LOD (Level Of Detail) is all about providing multiple versions each with
different resolution of geometry and/or texture data so that lower
resolution versions are used at far distances and higher resolution
versions are used at a nearer distance.  LOD's can also be used in
conjunction with a quad tree hierarchy where the low resolution version
covers the area of four geographically smaller tiles.  This quad tree
hierarchy can be go as deep as you want, especially when used with
PagedLOD's rather than LOD's.

However, from your description you aren't talking about this
multi-resoliution management, but simply a quad tree layout that has no
actual need for LOD's.  This leaves me a mixture confused about your intent
or unsure about your level of understanding of basic scene graph concepts.

The way to do a quad tree to enable early culling is to create a hierarchy
of osg::Group nodes that each have four children, nesting down the levels
till you get to the leaf nodes containing the actual geometry and textures
required.

Using a quad tree without LOD's would be fine for an application that only
ever views a relatively fixed number of tiles at one time such as map view
from a fixed height.  For general 3D rendering such a quad tree hierachy of
a big dataset would lead to performance problems as distant views or views
looking out to the horizon would have so many tiles to render that the
system would be overloaded.  In this situations LOD's are essential to load
balance.  From really large dataset PageLOD's become essentially to allow
you to scale to very large ranges and resolutions - the OSG is used with
whole earth visualization systems that have data down to sub m resolution
with ten's of terrabytes of data, all working at solid 60Hz.

Robert.



On 10 September 2015 at 18:17, John Peterson  wrote:

> Thank you for your reply, Robert.
>
> You mentioned PagedLOD nodes. While I might not use the paged version of
> the LODs nodes just yet, I've been thinking a lot about whether LOD nodes
> are the way to go in order to get OSG to cull large portions of my terrain
> without having to traverse and render every single grid square in the
> world. I'd be interested to know if the following technique might succeed
> for my use case, which I could later extend to PagedLOD nodes as I increase
> the area of my terrain.
>
> For the purposes of this very simple example, imagine a 4x4 grid where
> each one of the 16 grid squares represents a 5000 m^2 area of terrain. I
> should have been clear in my original post and mentioned that the grid
> squares are literally that--four vertices to render a pair of triangles.
> (In other words, it's not a particular complicated terrain from a geometric
> standpoint.) I'm wondering if I could use LOD nodes hierarchically in order
> to partition the scene in such a way that OSG will simply discard entire
> quadrants that are too far away from the viewer. To illustrate more clearly
> the scene graph I envision (excuse the ASCII art):
>
>
> Code:
> root
>   LOD
> LOD
>   geometry for square at (0,0)
> LOD
>   geometry for square at (1,0)
> LOD
>   geometry for square at (0,1)
> LOD
>   geometry for square at (1,1)
>   LOD
> LOD
>   geometry for square at (2,0)
> LOD
>   geometry for square at (3,0)
> LOD
>   geometry for square at (2,1)
> LOD
>   geometry for square at (3,1)
>   LOD
> LOD
>   geometry for square at (0,2)
> LOD
>   geometry for square at (1,2)
> LOD
>   geometry for square at (0,3)
> LOD
>   geometry for square at (1,3)
>   LOD
> LOD
>   geometry for square at (2,2)
> LOD
>   geometry for square at (3,2)
> LOD
>   geometry for square at (2,3)
> LOD
>   geometry for square at (3,3)
>
>
>
> Of course, I'd have to carefully choose the LOD min and max values to
> ensure that I'm neither discarding too much of the scene graph nor
> including more than I actually need.
>
> My question is, is this technique reasonable and scalable? Are there any
> pitfalls that I need to watch for, or any red flags that it raises?
>
> Best regards,
> John
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65101#65101
>
>
>
>
>
> ___
> 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