Re: [osg-users] OSG Ellipsoid to Sphere Conversion

[Wojciech Lewandowski]

Hi,

Not sure if this helps but I believe you may define own Ellipsoid with
EllipsoidModel. Just define it with both Radii the same and voila you have
the sphere ...

Cheers,
Wojtek Lewandowski

2016-09-26 23:54 GMT+02:00 Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de>:

> Hi Inna,
>
> It still doesn't make a lot of sense, The ellipsoid model is to abstract
> geographic coordinates to geocentric coords. Lat, long however is spherical
> coordinates and can be mapped to an ellipsoid...
> So please try  to rephrase your question: What is it what you want to do,
> or present some code that is not working for you.
>
> Cheers
> Sebastian
>
>> Hi Mr. Robert, geoc
>>
>> Thanks for the reply. Sorry , Seems  I explained very badly . Well , my
>> issue is that I want to make sphere  and text on it. I was able to do with
>> the EllipsoidModel and using log , lat and height. I want to do the same
>> with same Sphere. But I dont have idea how to do with sphere the same
>> thing. I want to make sphere with radius which varys basing on the screen
>> coordinates. In osg::Sphere I can see setradius(), but how can i set radius
>> to screen coordinates ?
>>
>> ...
>>
>> Thank you!
>>
>> Cheers,
>> Inna
>>
>> --
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=68777#68777
>>
>>
>>
>>
>>
>> ___
>> 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] OSG Ellipsoid to Sphere Conversion

[Sebastian Messerschmidt]

Hi Inna,

It still doesn't make a lot of sense, The ellipsoid model is to abstract 
geographic coordinates to geocentric coords. Lat, long however is 
spherical coordinates and can be mapped to an ellipsoid...
So please try  to rephrase your question: What is it what you want to 
do, or present some code that is not working for you.


Cheers
Sebastian

Hi Mr. Robert, geoc

Thanks for the reply. Sorry , Seems  I explained very badly . Well , my issue 
is that I want to make sphere  and text on it. I was able to do with the 
EllipsoidModel and using log , lat and height. I want to do the same with same 
Sphere. But I dont have idea how to do with sphere the same thing. I want to 
make sphere with radius which varys basing on the screen coordinates. In 
osg::Sphere I can see setradius(), but how can i set radius to screen 
coordinates ?

...

Thank you!

Cheers,
Inna

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





___
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] OSG Ellipsoid to Sphere Conversion

[Inna Reddy]

Hi Mr. Robert, 

Thanks for the reply. Sorry , Seems  I explained very badly . Well , my issue 
is that I want to make sphere  and text on it. I was able to do with the 
EllipsoidModel and using log , lat and height. I want to do the same with same 
Sphere. But I dont have idea how to do with sphere the same thing. I want to 
make sphere with radius which varys basing on the screen coordinates. In 
osg::Sphere I can see setradius(), but how can i set radius to screen 
coordinates ? 

... 

Thank you!

Cheers,
Inna

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





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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

HI Temia,

On 26 September 2016 at 19:41, Temia Eszteri  wrote:
> Just let it drop!

Drop what?  The project leadership?  Doing support for free?

Investigating issues and getting to the bottom of them?  If you've
actually followed this thread and read what's been written I've done
far more than talk, I've been reproduce issues, finding solutions,
finding solutions for inadequacies of C++ threads and members code.

Asking members of the community to avoid being rude or manipulative?

I include you post in this, you comment is wholly lacking in technical
contribution.  Did you not consider that that your comment wouldn't
come as obnoxious/insulting.  Of all the posts to this thread you is
most inappropriate.

I have had to put up with lot of non technical crap in this thread,
lots of opinions paraded as "facts" that on investigation have been
proven to be pretty unsubstantiated or mis-judged. The main issue in
this thread is entirely down to users making broad assumptions and
believing that when these assumptions are proven to not always hold
they don't get the results they expected based on their assumptions of
how things "should" work.

Of course I'm going to get irritated when not everyone is contribute
positively to a thread, you know I'm human.

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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

When reviewing doing a code review of the affinity code in OpenThreads
today I noticed that OpenThreads doesn't fully expose all the
functionality available for setting or resetting the thread affinity,
as OpenThrreads just allowed you to specify a single cpu number for a
thread to have affinity with.

To improve the flexibility of setting the Thread processor affinity I
have introduced a new function:

/**
 *  Set the processor affinity mask of current thread.  If you want to
allow thread to run on any processor core use ~0ul for the cpumask
 */
extern OPENTHREAD_EXPORT_DIRECTIVE int
SetProcessorAffinityMaskOfCurrentThread(unsigned long cpumask);


And a new Thread method:

  * If you want this threadd to run on any processor core then use
a cpumask of ~0ul
  * This call must be made before
  * start() or startThread() and has no effect after the thread
  * has been running. Returns 0 on success, implementation's
  * error on failure, or -1 if ignored.
  */
int setProcessorAffinityMask( unsigned long cpumask);

I have implemented these for pthreads so far, creating a git branch
openthreads_affinity_mask:


https://github.com/openscenegraph/OpenSceneGraph/tree/openthreads_affinity_mask

It's experimental, the API isn't settled yet, but it's a start.  I
will need to boot into Windows tomorrow and implement the Windows
side.  Members of the community are welcome to dive in and beat me to
this.

As a test of this new API I have modified the thread testing example
that Christian wrote and I extended earlier today, the addition simple
is:

if (arguments.read("--reset"))
{
OpenThreads::SetProcessorAffinityMaskOfCurrentThread(~0);
}

What this does is set the affinity of the main thread to run on all
threads.  With this change even the troublesome C++11 threads now work
fine even if the OSG viewer sets the affinity initialize to CPU 0.

This addresses a serious short coming in C++11 threads without needing
to just move all code across to OpenThreads, this call above is
sufficient to fix the lack of affinity support in C++ threads.  Since
OSG applications that might use C++11 threads will be using
OpenThreads anyway this doesn't add any extra dependencies.

This could be used more widely as well, for instance is you want to
set the affinity to just four of the CPU cores this can easily be done
by just setting up the mask appropriately.

I'm tempted to tweak the previous affinity API to:

 OpenThreads::SetProcessorAffinityOfCurrentThread(unsigned int
basecpunum, unsgined int numcores=1)

Which would allow you to say set the affinity for cores 4,5,6,7 via:

 OpenThreads::SetProcessorAffinityOfCurrentThread(4,4)

I'll sleep on this bit of the API.

These changes in some form will make it into OSG-3.6.  They also could
potentially utilized in osgViewer.

Robert.
#include 
#include 
#include 

#include 

class ComputeThread : public osg::Referenced, public OpenThreads::Thread
{
public:

int _numOperations;

ComputeThread(int n):_numOperations(n) {}

virtual void run()
{
for(volatile int n = 0; n != _numOperations; ++n)
{
++n;
--n;
}
std::cout << "Thread " << this << " done\n";
}
};


int main(int argc, char** argv)
{
// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(,argv);

int numThreads = 16;
int numOperations = 10;

osgViewer::Viewer viewer;

while (arguments.read("--num-threads", numThreads)) {}
while (arguments.read("--num-operatins", numOperations)) {}

if (arguments.read("--SingleThreaded"))
{
viewer.setThreadingModel(osgViewer::ViewerBase::ThreadingModel::SingleThreaded);
}

viewer.realize();

if (arguments.read("--ot"))
{
typedef std::list Threads;
Threads threads;
for(int i = 0; i != numThreads; ++i)
{
threads.push_back(new ComputeThread(numOperations));
}

for(Threads::iterator itr = threads.begin();
itr != threads.end();
++itr)
{
(*itr)->startThread();
}

for(Threads::iterator itr = threads.begin();
itr != threads.end();
++itr)
{
(*itr)->join();
}

}
else
{
if (arguments.read("--reset"))
{
OpenThreads::SetProcessorAffinityMaskOfCurrentThread(~0);
}

const auto compute = [] (const int i, const int numOps)
{
for(volatile int n = 0; n != numOps; ++n)
{
++n;
--n;
}
std::cout << "Thread " << i << " done\n";
};

std::vector futures;
for(int i = 0; i != numThreads; ++i)
{
futures.push_back(std::async(std::launch::async, compute, i, numOperations));
}

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Temia Eszteri]

Hey Robert,

Just let it drop!

Love, Temia

On Mon, 26 Sep 2016 16:38:19 +0100
Robert Osfield  wrote:

> HI Christian,
> 
> When it comes to perspectives of what is right or wrong for the OSG it
> absolutely has everything to do with my experience.  I more than
> anyone else in the community I witness how the OSG gets used across
> the broad spectrum of users.  There is no one else who provides more
> support to users, fix more bug, work with users and clients across
> many professional domains and usage cases.
> 
> When I say something is a "very specific usage case" then it's based
> on this experience. You then said "you strongly disagree" with this,
> then I leaves me wondering how you can speak from greater authority on
> how the OSG users use the OSG.
> 
> What you can say is that you know your usage model for your
> application more than I.  I could understand how this to you is the
> most important thing from your perspective, this is exactly what I
> expect of OSG users and is positive thing.  However, where I feel
> you've overstepped the make is making broad statements that your usage
> case is the general case from the OSG perspective.
> 
> It's my job as project lead to look at all the usage cases and issues
> that the OSG users have and guide the OSG in the right direction, I
> take not of usage cases like your own, but it's just part of wider
> project.  Just in the same way I also need to know the wider context
> of where the OSG sits, it's not something that is static, it evolves
> over time.  An import thing for a project lead is that you do take to
> whimns and move the rudder of the ship left then right randomly in
> response to the latest greatest opinion.
> 
> --
> 
> Repeatedly in this thread people like yourself have strongly asserted
> how wrong the OSG is doing things.
> 
> As spent the time investigating the issue I've found that it's
> actually that this standpoint has been based entirely on the
> assumptions made by those having problems.
> 
> The assumption that the thread affinity will not be set, and for some
> it seems it should never be set, is building your house on sand.  If
> you are writing a multi-threaded application one should be aware of
> and make conscious decisions about thread affinity.
> 
> The OSG and OpenThtreads don't make assumptions that thread affinity
> will be correct in it's default, inherited state, it where appropriate
> explicitly sets the affinity.  It may not do a perfect job in this,
> but it does at least try to do what it can.
> 
> From what I have learnt this is is far more an education issue rather
> than a technical one.  Partly is educating about what the OSG does and
> why it does it, but it's also more general than this - the assumptions
> about thread affinity being made in end users applications is clearly
> insufficient.  This lack of education of this later issue is far
> bigger than the OSG project.  Sadly the lack of education on threading
> issues is not helped by the lack of affinity functionality of C++11
> threading as an issue ignored is not one that is solved.
> 
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

Re: [osg-users] OSG Ellipsoid to Sphere Conversion

[Robert Osfield]

Hi Inna,

You don't say what you've tried, only that you tried something
relating changing from EllipsoidModel to Sphere, you don't say what
you changed the code to, what the result you got.

Without knowing what you are specifically having a problem with we
can't start helping you achieve what you want to achieve.

Robert.

On 26 September 2016 at 18:05, Inna Reddy  wrote:
> Hi all,
>
> I am a new bie here. I was playing with some examples. From the FadeText 
> Example 
> http://trac.openscenegraph.org/projects/osg//browser/OpenSceneGraph/trunk/examples/osgfadetext/osgfadetext.cpp
>  .  In this example, I have the ellipsoid model from the lat, long and 
> height. It's clear, then I tried to change this to Sphere. For me it seems, 
> not possible to convert the Elliposid to sphere.
>
>
> Code:
> osgText::Text* createText(osg::EllipsoidModel* ellipsoid, double latitude, 
> double longitude, double height, const std::string& str)
> {
>
> double X, Y, Z;
>
> 
> ellipsoid->convertLatLongHeightToXYZ(osg::DegreesToRadians(latitude), 
> osg::DegreesToRadians(longitude), height, X, Y, Z);
>
> osgText::Text* text = new osgText::FadeText;
> text->setDrawMode(osgText::Text::TEXT | 
> osgText::Text::BOUNDINGBOX);
>
> osg::Vec3 normal = ellipsoid->computeLocalUpVector(X, Y, Z);
> text->setCullCallback(new 
> osg::ClusterCullingCallback(osg::Vec3(X, Y, Z), normal, 0.0));
>
>
>
> ...
>
>  I am out of ideas, to do this possible to make same thing with sphere. Could 
> youe please some one help me to do this.
>
>
> thanks and cheers,
> Inna [/code]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68770#68770
>
>
>
>
>
> ___
> 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] OSG Running with modern OpenGL

[Gedalia Pasternak]

Thanks Chris,
   OSG earth does have some fixes for materials and lighting, but it would
be cleaner if it was part of OSG core. I'm pursing those as well, just
seems like the core libraries should function out of the box, without
spending a week applying patches or workarounds. We've been pursing using
nsight and renderdoc, which really won't function with the deprecated
stuff.
yup, I'll be at IITSEC.
-gedalia

On Mon, Sep 26, 2016 at 12:28 PM, Chris Hanson  wrote:

> Well, probably a good facsimile would be the situation for OpenGL ES,
> which lacks all of those same features.
>
> We did a bunch of work involving this, writing custom FFP to shader
> generators, as well as doing the grunt work of making osgEarth work on
> mobile devices (Android and iOS) through OpenGL ES.
>
> I don't think there's specifically a roadmap, but if you have questions
> about something in particular, shoot me an email. Are you going to IITSEC?
> ​
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] different materials for a geometry and highlight

[Trajce Nikolov NICK]

Gianni,

you should call geometry->dirtyDisplayList(); at the end of your move
function ... Not sure about the rest of the logic of your code now though
  Maybe better idea then these email iterations is to write us what is
your goal with this code since I see no smart logic in there (sorry :-) )

void move(osg::Geometry* geometry, unsigned int sourcePrimitiveSetIndex,
unsigned int elementIndex, unsigned int destinationPrimitiveIndex)
{
osg::DrawElementsUInt* sourcePrimitiveSet =
dynamic_cast(geometry->getPrimitiveSet(sourcePrimitiveSetIndex));
osg::DrawElementsUInt* destinationPrimitiveSet =
dynamic_cast(geometry->getPrimitiveSet(destinationPrimitiveIndex));
destinationPrimitiveSet->push_back(sourcePrimitiveSet->at(elementIndex *
3));
destinationPrimitiveSet->push_back(sourcePrimitiveSet->at(elementIndex * 3
+ 1));
destinationPrimitiveSet->push_back(sourcePrimitiveSet->at(elementIndex * 3
+ 2));
sourcePrimitiveSet->erase(sourcePrimitiveSet->begin() + elementIndex * 3);
sourcePrimitiveSet->erase(sourcePrimitiveSet->begin() + elementIndex * 3);
sourcePrimitiveSet->erase(sourcePrimitiveSet->begin() + elementIndex * 3);

sourcePrimitiveSet->dirty();
destinationPrimitiveSet->dirty();
geometry->dirtyDisplayList();
}



On Mon, Sep 26, 2016 at 4:03 PM, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

> Hi Gianni,
>
> A very simplistic solution using a outline triangle:
>
>
> 
> #include 
> #include 
> #include 
> #include 
>
> #include 
> #include 
>
> #include 
> #include 
> #include 
> #include 
>
> //#include 
>
> #include 
>
> const osg::Vec4 selectedColor(1.0f, 1.0f, 1.0f, 0.5f);
> const osg::Vec4 color1(1.0f, 0.0f, 0.0f, 1.0f);
> const osg::Vec4 color2(0.0f, 1.0f, 0.0f, 1.0f);
> const osg::Vec4 color3(0.0f, 0.0f, 1.0f, 1.0f);
> const osg::Vec4 color4(1.0f, 0.0f, 1.0f, 1.0f);
>
> class SelectModelHandler : public osgGA::GUIEventHandler
> {
> public:
> SelectModelHandler(osg::ref_ptr group)
> : _selector(0), currentPrimitiveSetIndex(0), _root(group)
> {}
>
> virtual bool handle(const osgGA::GUIEventAdapter& ea,
> osgGA::GUIActionAdapter& aa)
> {
>
> if (ea.getEventType() == osgGA::GUIEventAdapter::RELEASE &&
> ea.getButton() == osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON &&
> ea.getModKeyMask() & osgGA::GUIEventAdapter::MODKEY_CTRL)
> {
> osgViewer::View* viewer = dynamic_cast();
> if (viewer)
> {
> osg::ref_ptr intersector = new
> osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, ea.getX(),
> ea.getY());
> osgUtil::IntersectionVisitor iv(intersector.get());
> osg::Camera* camera = viewer->getCamera();
> camera->accept(iv);
>
> if (intersector->containsIntersections())
> {
> osgUtil::LineSegmentIntersector::Intersection result
> = *(intersector->getIntersections().begin());
> doUserOperations(result);
> }
> }
> }
>
> return false;
> }
>
> virtual void doUserOperations(osgUtil::Line
> SegmentIntersector::Intersection& result)
> {
> osg::Geometry* geom = dynamic_cast(r
> esult.drawable.get());
>
> //first solution: add some outline
> if (_root->getNumChildren())
> {
> _root->removeChildren(0, _root->getNumChildren());
> }
> else if (result.indexList.size() > 2)
> {
> osg::DrawElementsUInt* elements = new
> osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES);
> osg::Vec3Array* vertices = new osg::Vec3Array;
> osg::Vec4Array* colors = new osg::Vec4Array;
> colors->push_back(osg::Vec4(1, 0, 0, 1));
> const osg::Vec3Array& org_vertices = dynamic_cast osg::Vec3Array&>(*geom->getVertexArray());
>
> vertices->push_back(org_vertices[result.indexList[0]]);
> vertices->push_back(org_vertices[result.indexList[1]]);
> vertices->push_back(org_vertices[result.indexList[2]]);
> (*elements).push_back(0);
> (*elements).push_back(1);
> (*elements).push_back(2);
>
> osg::Geode* geode = new osg::Geode;
> osg::Geometry* geometry = new osg::Geometry;
> geode->addDrawable(geometry);
> geometry->setVertexArray(vertices);
> geometry->setColorArray(colors, osg::Array::BIND_OVERALL);
> geometry->addPrimitiveSet(elements);
> geometry->getOrCreateStateSet()->setAttribute(new osg::PolygonMode(
> osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE));
> geometry->getOrCreateStateSet()->setAttribute(new osg::LineWidth(3.0));
> _root->addChild(geode);
> }
>
>
> }
>
> protected:
> osg::ref_ptr _selector;
> unsigned int currentPrimitiveSetIndex;
> osg::ref_ptr _root;
> };
>
> osg::Vec3Array* 

[osg-users] OSG Ellipsoid to Sphere Conversion

[Inna Reddy]

Hi all, 

I am a new bie here. I was playing with some examples. From the FadeText 
Example 
http://trac.openscenegraph.org/projects/osg//browser/OpenSceneGraph/trunk/examples/osgfadetext/osgfadetext.cpp
 .  In this example, I have the ellipsoid model from the lat, long and height. 
It's clear, then I tried to change this to Sphere. For me it seems, not 
possible to convert the Elliposid to sphere. 


Code:
osgText::Text* createText(osg::EllipsoidModel* ellipsoid, double latitude, 
double longitude, double height, const std::string& str)
{

double X, Y, Z;


ellipsoid->convertLatLongHeightToXYZ(osg::DegreesToRadians(latitude), 
osg::DegreesToRadians(longitude), height, X, Y, Z);

osgText::Text* text = new osgText::FadeText;
text->setDrawMode(osgText::Text::TEXT | 
osgText::Text::BOUNDINGBOX);

osg::Vec3 normal = ellipsoid->computeLocalUpVector(X, Y, Z);
text->setCullCallback(new 
osg::ClusterCullingCallback(osg::Vec3(X, Y, Z), normal, 0.0));



...

 I am out of ideas, to do this possible to make same thing with sphere. Could 
youe please some one help me to do this. 


thanks and cheers, 
Inna [/code]

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





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

Re: [osg-users] OSG and Qt

[Inna Reddy]

Hi,

Thanks for your reply and that'S super. Hopefully, It will be good start for 
me. 
... 

Thank you!

Cheers,
Inna

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





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

Re: [osg-users] OSG Running with modern OpenGL

[Chris Hanson]

Well, probably a good facsimile would be the situation for OpenGL ES, which
lacks all of those same features.

We did a bunch of work involving this, writing custom FFP to shader
generators, as well as doing the grunt work of making osgEarth work on
mobile devices (Android and iOS) through OpenGL ES.

I don't think there's specifically a roadmap, but if you have questions
about something in particular, shoot me an email. Are you going to IITSEC?
​
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Running OSG in a trhead on Mac OSX

[Kevin Gucwa]

Hi Robert,

Thank you for the reply.  I had been coming to that conclusion myself but 
wanted confirmation from someone who knew more than I did.

I will look into catching all events from the main thread and passing them 
along.  I am not sure that it is even possible in my use case, but it is a 
great place to start and certainly better than rewriting the main logic of my 
program.

... 

Thank you!

Cheers,
Kevin

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





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

Re: [osg-users] Problematic call of flushDeletedGLObjects

[Robert Osfield]

Hi Valerian,

On 26 September 2016 at 16:27, Valerian Merkling  wrote:
> I didn't managed to get a running example, but working on it made me find a 
> solution.
>
> It seems that I need to use the releaseGLObjects functions on nodes that I 
> totally remove from the scene graph.
>
> With that call, my shaders are flagged for destruction AND destroyed when 
> closing the view => everythings seems to be ok now !

Great to hear you've sorted the problem.  The OSG does try to manage
the GL objects during open/closing of contexts but alas if you remove
a subgraph from the sight of the viewer it then will not know that
there are objects that need to be cleaned up there.  For these as you
have found you'll need to call releaseGLObjects() prior to closing the
garphics context.

If you attempt the GL object clean up after the graphics context has
been closed then you'll need to call subgraph->releaseGLObjects() then
call osg::discardAllGLObjects(contextID) for the context.

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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

HI Christian,

On 26 September 2016 at 15:49, Christoph Weiss  wrote:
> Robert, I'm not quite sure what prompts you to bring in personal attributes
> here.  Nor do I see any hyperbole to begin with.  I stated that I strongly
> disagree.  You can in turn disagree.  I never was my intention to make this
> personal, and quite frankly I do not see how I should have.

When it comes to perspectives of what is right or wrong for the OSG it
absolutely has everything to do with my experience.  I more than
anyone else in the community I witness how the OSG gets used across
the broad spectrum of users.  There is no one else who provides more
support to users, fix more bug, work with users and clients across
many professional domains and usage cases.

When I say something is a "very specific usage case" then it's based
on this experience. You then said "you strongly disagree" with this,
then I leaves me wondering how you can speak from greater authority on
how the OSG users use the OSG.

What you can say is that you know your usage model for your
application more than I.  I could understand how this to you is the
most important thing from your perspective, this is exactly what I
expect of OSG users and is positive thing.  However, where I feel
you've overstepped the make is making broad statements that your usage
case is the general case from the OSG perspective.

It's my job as project lead to look at all the usage cases and issues
that the OSG users have and guide the OSG in the right direction, I
take not of usage cases like your own, but it's just part of wider
project.  Just in the same way I also need to know the wider context
of where the OSG sits, it's not something that is static, it evolves
over time.  An import thing for a project lead is that you do take to
whimns and move the rudder of the ship left then right randomly in
response to the latest greatest opinion.

--

Repeatedly in this thread people like yourself have strongly asserted
how wrong the OSG is doing things.

As spent the time investigating the issue I've found that it's
actually that this standpoint has been based entirely on the
assumptions made by those having problems.

The assumption that the thread affinity will not be set, and for some
it seems it should never be set, is building your house on sand.  If
you are writing a multi-threaded application one should be aware of
and make conscious decisions about thread affinity.

The OSG and OpenThtreads don't make assumptions that thread affinity
will be correct in it's default, inherited state, it where appropriate
explicitly sets the affinity.  It may not do a perfect job in this,
but it does at least try to do what it can.

>From what I have learnt this is is far more an education issue rather
than a technical one.  Partly is educating about what the OSG does and
why it does it, but it's also more general than this - the assumptions
about thread affinity being made in end users applications is clearly
insufficient.  This lack of education of this later issue is far
bigger than the OSG project.  Sadly the lack of education on threading
issues is not helped by the lack of affinity functionality of C++11
threading as an issue ignored is not one that is solved.

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

Re: [osg-users] Problematic call of flushDeletedGLObjects

[Valerian Merkling]

I didn't managed to get a running example, but working on it made me find a 
solution.

It seems that I need to use the releaseGLObjects functions on nodes that I 
totally remove from the scene graph.

With that call, my shaders are flagged for destruction AND destroyed when 
closing the view => everythings seems to be ok now !

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





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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Christoph Weiss]

Hi Robert,

On 09/26/2016 04:35 PM, Robert Osfield wrote:

HI Christoph,

On 26 September 2016 at 14:20, Christoph Weiss  wrote:

I strongly disagree with the last sentence.  It is the most general use case
possible:  using standard C++ features.


Please quite the hyperbole.  It does you no favours.

I am been writing C++ programs since 1992, been the project lead of
the OSG since 1999, the OSG has been started to embrace
mulit-ithreading in 2001.  I've interacted with thousands of
developers over the years. Strongly disagree with you may, but think
twice, between me and you who might know the most general use case for
the OSG?

I'm not some wet behind the ears engineer that knows nothing about
C++, threading or performance, these are things that make the OSG what
it is.

When I say we are talking about a very specific usage case it's
because in my 1i8 years as the project lead of the OSG it in my
experience it is a specific usage case rather than a common one.


Robert, I'm not quite sure what prompts you to bring in personal 
attributes here.  Nor do I see any hyperbole to begin with.  I stated 
that I strongly disagree.  You can in turn disagree.  I never was my 
intention to make this personal, and quite frankly I do not see how I 
should have.


I did not question your authority on software development in general, or 
OSG specifically.  If you think I put this on a personal level, please 
point out where.  Otherwise, please refrain from arguments by authority, 
they do you no favors.


My only interest here is to improve OSG.  For me, it doesn't matter at 
all if the behavior of OSG is changed or not -- I already fixed it in 
our code base by using your suggestion for white I'm grateful.  I can 
quite clearly see future users run into the same issues that I had, and 
I'd like to see OSG improved and not make that happen.


However, since it feels as if this is turning into something about who's 
right, not technical aspects, I'll quit the entire discussion now.


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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

HI Christoph,

On 26 September 2016 at 14:20, Christoph Weiss  wrote:
> I strongly disagree with the last sentence.  It is the most general use case
> possible:  using standard C++ features.

Please quite the hyperbole.  It does you no favours.

I am been writing C++ programs since 1992, been the project lead of
the OSG since 1999, the OSG has been started to embrace
mulit-ithreading in 2001.  I've interacted with thousands of
developers over the years. Strongly disagree with you may, but think
twice, between me and you who might know the most general use case for
the OSG?

I'm not some wet behind the ears engineer that knows nothing about
C++, threading or performance, these are things that make the OSG what
it is.

When I say we are talking about a very specific usage case it's
because in my 1i8 years as the project lead of the OSG it in my
experience it is a specific usage case rather than a common one.

> OSG's behavior changes the behavior of programs that, apart from OSG, rely
> solely on the C++ specification.  This is the most general problem possible,
> and far more important than the behavior of some specific libraries like
> pthreads or OpenThreads.

OK, lets get some facts down.

OpenThreads pre-dates C++11 by over a decade.

Yet it still doesn't offers MORE threading control and functionality
that native C++11 threads.

Does C++11 threads have support for processor affinity?  NO.

Processor affinity is essentially for any serious threading library.
So C++ threading support is a bit of fail in this respect.

YES you can add processor affinity via the native_handle.  You'll need
to dip into pthreads or other native threading libs for this, but this
rather defeats the point of having "portable" C++ threading.

If you own code example you make the ASSUMPTION that the affinity mask
of the thread creating your threads allows it to run on all threads.
Now if you've never done performance critical mult-threading the idea
of processor affinity may be alien, but it's not robust approach to
muli-threading.

Why do you make this assumption about thread affinity?  Why don't you
set the thread affinity explicitly?

If you want to make your own code more robust remove the assumptions,
it'll make your own code more portable.

I've put in the effort to re-create the problem, I've found a number
of different solutions, none of which require any modifications to the
core OSG.  If there was a flaw on the OSG side then we wouldn't be
able to provide these solutions.

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

[osg-users] OSG Running with modern OpenGL

[Gedalia Pasternak]

Hello,
   I'm working on a OSG based rendering engine and we're trying to switch
OSG to run without OSG_GL_FIXED_FUNCTION_AVAILABLE and all the other
deprecated pipeline functions disabled. I'm wondering if there's a road map
for getting OSG to support all the various bits of functionality that
currently printf endlessly.
I managed to fix the osgText and stat drawing, which a number of people
have pointed out just need reasonable shaders associated with the draw
nodes. But Materials/lights/Alpha discard all seem a bit trickier requiring
either a ton of additional uniforms and more elaborate state tracking when
shaders switch or using uniform buffers, I'd rather not reinvent the wheel
or wind up patching osg endlessly with kludgy workarounds.
Thanks,
-Gedalia

-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Creating a flame of rocket

[Suraj Paul]

Hi Jannik,

Here's my code i am using the create the particle system and emitter. I am 
creating two particle systems--one for each exhaust of the rocket.:--
int main()
{
osg::ref_ptr mt = new osg::MatrixTransform;
osg::ref_ptr mt_2 = new osg::MatrixTransform;
osg::ref_ptr trans= new osg::MatrixTransform;

osg::ref_ptr lan = osgDB::readNodeFile("cessna.osg");
trans->setMatrix( osg::Matrix::translate(0.0f, 0.0f, 0.0f) );
trans->addChild(lan); 


//create two particle systems at different locations 
mt->setMatrix( osg::Matrix::translate(5.0f, -5.0f, 0.0f) );
osgParticle::ParticleSystem* ps = createParticleSystem( mt.get());

mt_2->setMatrix( osg::Matrix::translate(-5.0f, -5.0f, 0.0f) );
osgParticle::ParticleSystem* ps_2 = createParticleSystem( mt_2.get());

//attach the two Particle system to 'trans' node
trans->addChild(mt.get());  trans->addChild(mt_2.get());  

//give motion to 'trans' using osg::AnimationPath::LOOP

trans->addUpdateCallback( createAnimationPathCallback(100.0f, 30.0) );

//add updater to each of the particle system
osg::ref_ptr updater =new 
osgParticle::ParticleSystemUpdater;
updater->addParticleSystem( ps );
updater->addParticleSystem( ps_2 );

//add the trans and updater to a group node called root

osg::ref_ptr root = new osg::Group;
root->addChild( updater.get() );
root->addChild(trans.get());
osgViewer::Viewer viewer;
viewer.setSceneData( root.get() );
return viewer.run();

 }  /***end of main/

/createparticleSystem func ***/

osgParticle::ParticleSystem* createParticleSystem( osg::Group* parent )
{
 osg::ref_ptr ps =new 
osgParticle::ParticleSystem;
 ps->getDefaultParticleTemplate().setShape(osgParticle::Particle::QUAD); 
 ps->getDefaultParticleTemplate().setLifeTime( 0.50f ); 
 ps->getDefaultParticleTemplate().setSizeRange( osgParticle::rangef(0.5f, 0.1f) 
); 
 ps->getDefaultParticleTemplate().setAlphaRange( osgParticle::rangef(0.5f, 
0.0f) );
 
ps->getDefaultParticleTemplate().setColorRange(osgParticle::rangev4(osg::Vec4(45.0/255.0f,179.0/255.0,217/255.0f,1.0f),
 osg::Vec4(172.0/255.0f,225.0/255.0f,240/255.0f,1.0f)) );
 ps->setDefaultAttributes("smoke.rgb", true, false );

 osg::ref_ptr rrc =  new 
osgParticle::RandomRateCounter;
 rrc->setRateRange( 100, 200 ); 
 osg::ref_ptr emitter =new 
osgParticle::ModularEmitter;
 emitter->setParticleSystem( ps.get() );
 emitter->setCounter( rrc.get() );
 osg::ref_ptr shooter = new 
osgParticle::RadialShooter;
 shooter->setThetaRange(osg::DegreesToRadians(-0.50), 
osg::DegreesToRadians(0.50) );

 shooter->setInitialSpeedRange( 1.5f, 1.0f );
 emitter->setShooter( shooter.get() );
 ps->setUseShaders(true);

 osg::ref_ptr program =   new 
osgParticle::ModularProgram;
 program->setParticleSystem( ps.get() );

osg::ref_ptr geode = new osg::Geode;
geode->addDrawable( ps.get() );
parent->addChild( emitter.get() );
parent->addChild( program.get() );
parent->addChild( geode.get() );
return ps.get();
}

... 

Thank you!

Cheers,
Suraj

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





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

Re: [osg-users] Creating a glowing sun in scene

[David Heitbrink]

I think looking at the osgblenddrawbuffers or osgmultiplerendertargets might be 
a good start. Neither of these are really doing what you are aiming for, but  
shows you how to add the color buffers and shaders.

You might also look at the OSGPPU project. It I think it has some more relevant 
examples, although the OSG PPU project is not being actively maintained at this 
time.

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





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

Re: [osg-users] different materials for a geometry and highlight

[Sebastian Messerschmidt]

Hi Gianni,

A very simplistic solution using a outline triangle:



#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 

//#include 

#include 

const osg::Vec4 selectedColor(1.0f, 1.0f, 1.0f, 0.5f);
const osg::Vec4 color1(1.0f, 0.0f, 0.0f, 1.0f);
const osg::Vec4 color2(0.0f, 1.0f, 0.0f, 1.0f);
const osg::Vec4 color3(0.0f, 0.0f, 1.0f, 1.0f);
const osg::Vec4 color4(1.0f, 0.0f, 1.0f, 1.0f);

class SelectModelHandler : public osgGA::GUIEventHandler
{
public:
SelectModelHandler(osg::ref_ptr group)
: _selector(0), currentPrimitiveSetIndex(0), _root(group)
{}

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

{

if (ea.getEventType() == osgGA::GUIEventAdapter::RELEASE &&
ea.getButton() == osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON &&
ea.getModKeyMask() & osgGA::GUIEventAdapter::MODKEY_CTRL)
{
osgViewer::View* viewer = dynamic_cast();
if (viewer)
{
osg::ref_ptr intersector = new 
osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, ea.getX(), 
ea.getY());

osgUtil::IntersectionVisitor iv(intersector.get());
osg::Camera* camera = viewer->getCamera();
camera->accept(iv);

if (intersector->containsIntersections())
{
osgUtil::LineSegmentIntersector::Intersection 
result = *(intersector->getIntersections().begin());

doUserOperations(result);
}
}
}

return false;
}

virtual void 
doUserOperations(osgUtil::LineSegmentIntersector::Intersection& result)

{
osg::Geometry* geom = 
dynamic_cast(result.drawable.get());


//first solution: add some outline
if (_root->getNumChildren())
{
_root->removeChildren(0, _root->getNumChildren());
}
else if (result.indexList.size() > 2)
{
osg::DrawElementsUInt* elements = new 
osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES);

osg::Vec3Array* vertices = new osg::Vec3Array;
osg::Vec4Array* colors = new osg::Vec4Array;
colors->push_back(osg::Vec4(1, 0, 0, 1));
const osg::Vec3Array& org_vertices = dynamic_castosg::Vec3Array&>(*geom->getVertexArray());


vertices->push_back(org_vertices[result.indexList[0]]);
vertices->push_back(org_vertices[result.indexList[1]]);
vertices->push_back(org_vertices[result.indexList[2]]);
(*elements).push_back(0);
(*elements).push_back(1);
(*elements).push_back(2);

osg::Geode* geode = new osg::Geode;
osg::Geometry* geometry = new osg::Geometry;
geode->addDrawable(geometry);
geometry->setVertexArray(vertices);
geometry->setColorArray(colors, osg::Array::BIND_OVERALL);
geometry->addPrimitiveSet(elements);
geometry->getOrCreateStateSet()->setAttribute(new osg::PolygonMode(
osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE));

geometry->getOrCreateStateSet()->setAttribute(new osg::LineWidth(3.0));
_root->addChild(geode);
}


}

protected:
osg::ref_ptr _selector;
unsigned int currentPrimitiveSetIndex;
osg::ref_ptr _root;
};

osg::Vec3Array* buildVertices() {
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices->push_back(osg::Vec3(0, 0, 0));
vertices->push_back(osg::Vec3(10, 0, 0));
vertices->push_back(osg::Vec3(10, 10, 0));
vertices->push_back(osg::Vec3(0, 10, 0));
vertices->push_back(osg::Vec3(20, 0, 0));
vertices->push_back(osg::Vec3(20, 10, 0));
vertices->push_back(osg::Vec3(20, 20, 0));
vertices->push_back(osg::Vec3(10, 20, 0));
vertices->push_back(osg::Vec3(0, 20, 0));
return vertices;
}

osg::DrawElementsUInt* buildElements()
{
osg::DrawElementsUInt* element = new 
osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES);

element->push_back(0);
element->push_back(1);
element->push_back(2);
element->push_back(0);
element->push_back(2);
element->push_back(3);
//
element->push_back(1);
element->push_back(4);
element->push_back(5);
element->push_back(1);
element->push_back(5);
element->push_back(2);
//
element->push_back(2);
element->push_back(5);
element->push_back(6);
element->push_back(2);
element->push_back(6);
element->push_back(7);
//
element->push_back(3);
element->push_back(2);
element->push_back(7);
element->push_back(3);
element->push_back(7);
element->push_back(8);

return element;
}



osg::Vec4Array* buildColors() 

Re: [osg-users] different materials for a geometry and highlight

[Sebastian Messerschmidt]

Hi Gianni,

One question,
why should I use a "vertex" shader/attribute when I need to colour a triangle 
uniformly?

Long story short: There is no such thing as per-primitive colors.

Long story long:
In order to color your primitives you need to assign a color to each 
vertex. That is how modern GPU-pipelines work. Another way to tackle 
your problem is to simply assign a different color-array holding 
per-vertex colors that is updated with your selections.

I'll try to create a small example for you to make things less foggy.

Cheers
Sebastian


Regards,
Gianni

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





___
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] SingleThreaded leading to whole application just running on one core

[Christoph Weiss]

Hi Robert,


If you are using OpenThreads for your threads then you have no problem
at all anyway, you can create them before or after viewer.realizer()
without any problem.

It's only if you create your threads afterwards using another
threading library that doesn't set the affinity mask in any way so
just inherits the infinity mask.

A number of contributors to this thread have made it out to be a
general problem, it's not, it's a very specific usage case issue.


I strongly disagree with the last sentence.  It is the most general use 
case possible:  using standard C++ features.


OSG's behavior changes the behavior of programs that, apart from OSG, 
rely solely on the C++ specification.  This is the most general problem 
possible, and far more important than the behavior of some specific 
libraries like pthreads or OpenThreads.


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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

Hi Sebastian,

On 26 September 2016 at 12:15, Sebastian Messerschmidt
 wrote:
> Would a small function to enable/disable the affinity in SingleThreaded mode
> be a big breaking change? Defaulting to using the affinity mask, making it
> up to the advanced user to sacrifice the performance.

I would rather avoid small code changes that don't actual offer any
path forward.  Adding a bool for the affinity would just be a
workaround for an issue which is somewhere else entirely, it would be
just another hack.

> I would argue that the the issue isn't that specific when seen in a greater
> context. In my case OSG is used behind an interface, so it might not be
> possible to use create threads before the viewer.

If you are using OpenThreads for your threads then you have no problem
at all anyway, you can create them before or after viewer.realizer()
without any problem.

It's only if you create your threads afterwards using another
threading library that doesn't set the affinity mask in any way so
just inherits the infinity mask.

A number of contributors to this thread have made it out to be a
general problem, it's not, it's a very specific usage case issue.

> Also it simply feels like an inappropriate side-effect which is buried
> without having control/access over/to it.

The side effect is only in certain circumstances, it's unwanted, but
it's not something that most users will likely hit up against.  You
also do have control over, you can set the affinity mask for your
threads rather than inherit what ever mask has be previously set.

--

I would add though I'm not opposed to adding more control of the
affinity to OpenThreads/OSG.  What API form this extra control might
take I can't say at this point as I haven't had to time to reflect on
the issue enough.  I still have plenty of other tasks to get on with.

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

Re: [osg-users] different materials for a geometry and highlight

[Gianni Ambrosio]

One question,
why should I use a "vertex" shader/attribute when I need to colour a triangle 
uniformly?

Regards,
Gianni

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





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

Re: [osg-users] different materials for a geometry and highlight

[Gianni Ambrosio]

Well, Nick,
I have to say I didn't understand what Sebastian suggested since I'm not 
familiar with shaders. As far as I understood a shader can not be debugged and 
I don't know if they are testable. Moreover the code is in a place different 
from the usual code, so something that has effect in the application but in 
some way disjoined. I'm not sure I would like such a solution.

Please consider also one more thing I didn't mention so clearly. After changing 
the color of triangles of my surfare, then at a certain point I have to update 
also an underlying code structure according to the new colors. Is there a way 
using a shader also to handle this part of the implementation?

Regards,
Gianni

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





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

Re: [osg-users] different materials for a geometry and highlight

[Trajce Nikolov NICK]

Hi Gianni,

I have stopped looking at the issue since Sebastian's suggestion is really
better (more modern approach and really easier to implement and maintain
once you get a handle of it). If you still want to continue your way I will
have a look later today if I can spot anything .. Will ping you

On Mon, Sep 26, 2016 at 11:33 AM, Gianni Ambrosio 
wrote:

> Dear Nick,
> I'm not sure to use the solution suggested by Sebastian (I've never worked
> with shaders so it is quite difficult to understand). So I would like to
> know if you foud a reason of the problem in my example?
>
> Regards,
> Gianni
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68742#68742
>
>
>
>
>
> ___
> 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] SingleThreaded leading to whole application just running on one core

[Sebastian Messerschmidt]

Hi Robert,


I

Hi All,

I have taken Christoph's test problem and reproduced the affinity
issue on my Kubuntu 16.04, so this is useful first step.

I've also reviewed the OpenThreads code, so have a better idea of the
code in question.  Please note that I'm not the author of OpenThreads,
the project just fell on my shoulders to maintain.  Some of the code
in OpenThreads pthread side made me curious so I modified Christoph's
code to added a code path using OpenThreads rather than C++11 threads
used in Christoph's code and command line options to toggle between
the two, toggle beteween viewer running SingleThreaded or with
defaults (will be DrawThreadPerContext).  Attached is a CmakeLists.txt
file and main.cpp.

For the OpenThreads pathway I get the exactly the same performance
when running the viewer single theaded or multi-threaded.

  time ./threadtest --ot --SingleThreaded
Thread 0x142df50 done
Thread 0x1427750 done
Thread 0x1427690 done
Thread 0x142dcf0 done
Thread 0x142e1f0 done
Thread 0x142e0a0 done
Thread 0x142edc0 done
Thread 0x142e5e0 done
Thread 0x142ec70 done
Thread 0x142e9d0 done
Thread 0x142e340 done
Thread 0x142e490 done
Thread 0x142de20 done
Thread 0x142e880 done
Thread 0x142e730 done
Thread 0x142eb20 done

real0m15.463s
user1m59.612s
sys 0m0.044s


For the C++11 threads I get far worse performance when running single
theaded vs multi-threaded:

$ time ./threadtest --SingleThreaded
Thread 7 done
Thread 11 done
Thread 10 done
Thread 13 done
Thread 12 done
Thread 6 done
Thread 9 done
Thread 8 done
Thread 14 done
Thread 15 done
Thread 5 done
Thread 4 done
Thread 3 done
Thread 2 done
Thread 1 done
Thread 0 done

real1m22.315s
user1m22.064s
sys 0m0.044s


So the code in OpenThreads to set the affinity mask by default for
it's own threads resolve the issue completely (note, the
OpenThreads::Thread that I created above don't set affinity, so they
are free for the OS to place them.)  This may also be why most users
don't see these issues.

This isolates the issues to users who use non OpenThreads threads when
these threads are created after the viewer has been realized and don't
set thread affinity for there threads themselves.  That's three sets
of conditions that any one be changed and the problem will be entirely
resolved.
The problem as Christoph mentioned are threads which are created by 
C++11 features such as std::async. One simply doesn't have any control 
over them and cannot set any affinity whatsoever.

While not ideal that this issue exists at all at least we now have a
handle on it.  Given the issue only occurs with a very specific set of
usage I don't think there is any reason for sweeping changes to the
core OSG, or changes to the defaults.
Would a small function to enable/disable the affinity in SingleThreaded 
mode be a big breaking change? Defaulting to using the affinity mask, 
making it up to the advanced user to sacrifice the performance.
I would argue that the the issue isn't that specific when seen in a 
greater context. In my case OSG is used behind an interface, so it might 
not be possible to use create threads before the viewer.
Also it simply feels like an inappropriate side-effect which is buried 
without having control/access over/to it.


Cheers
Sebastian


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

Re: [osg-users] Running OSG in a trhead on Mac OSX

[Robert Osfield]

Hi Kevin,

This issue with OSX is one we can't workaround, it's very much tied
into how OSX passes events from the OS onto applications.  We hit
against this issue when implementing osgViewer and trying to get the
multi-thread, mulit-context side work.  There isn't anyway to tell OSX
to give events to a thread other than the main one, the only way to
handle it is to catch all the events in the main thread and pass them
on to other threads to handle.  It's a pretty frustrating limitation,
no doubt you like many others, including myself have torn hair over
this limitation, alas there it's futile, you just have to work how
Apple wants you to write your applications even when it doesn't make
much sense for certain type of applications.

Robert.

On 23 September 2016 at 17:46, Kevin Gucwa  wrote:
> Hi,
>
> I am working on a project which requires me to put my OSG updates into a 
> thread so that the main thread can continue for integration into another 
> process.  All OSG events are done in the thread and locked with mutexes when 
> i need to add new nodes.  This works perfectly on Linux and Windows and is 
> deployed currently.  Thank you for such great software!  I am now working on 
> the port to OSX and running into the following issue.  When I run the 
> viewer->frame() updates in a thread, the keyboard and mouse inputs cannot 
> register into my GUIEventHandlers.  Running the frame loop from the main 
> thread and blocking my program allows events to be handled properly but stops 
> my actual code from progressing.
>
> I am new to Mac programming but have been using OSG for a few years now.  Can 
> anyone provide any guidance to Mac problems?  I don't have a minimal example 
> since it is integrated into a large project.  If necessary I can write a new 
> one which should demonstrate the problems.
>
> ...
>
> Thank you!
>
> Cheers,
> Kevin
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68711#68711
>
>
>
>
>
> ___
> 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] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

Hi All,

I have taken Christoph's test problem and reproduced the affinity
issue on my Kubuntu 16.04, so this is useful first step.

I've also reviewed the OpenThreads code, so have a better idea of the
code in question.  Please note that I'm not the author of OpenThreads,
the project just fell on my shoulders to maintain.  Some of the code
in OpenThreads pthread side made me curious so I modified Christoph's
code to added a code path using OpenThreads rather than C++11 threads
used in Christoph's code and command line options to toggle between
the two, toggle beteween viewer running SingleThreaded or with
defaults (will be DrawThreadPerContext).  Attached is a CmakeLists.txt
file and main.cpp.

For the OpenThreads pathway I get the exactly the same performance
when running the viewer single theaded or multi-threaded.

 time ./threadtest --ot --SingleThreaded
Thread 0x142df50 done
Thread 0x1427750 done
Thread 0x1427690 done
Thread 0x142dcf0 done
Thread 0x142e1f0 done
Thread 0x142e0a0 done
Thread 0x142edc0 done
Thread 0x142e5e0 done
Thread 0x142ec70 done
Thread 0x142e9d0 done
Thread 0x142e340 done
Thread 0x142e490 done
Thread 0x142de20 done
Thread 0x142e880 done
Thread 0x142e730 done
Thread 0x142eb20 done

real0m15.463s
user1m59.612s
sys 0m0.044s


For the C++11 threads I get far worse performance when running single
theaded vs multi-threaded:

$ time ./threadtest --SingleThreaded
Thread 7 done
Thread 11 done
Thread 10 done
Thread 13 done
Thread 12 done
Thread 6 done
Thread 9 done
Thread 8 done
Thread 14 done
Thread 15 done
Thread 5 done
Thread 4 done
Thread 3 done
Thread 2 done
Thread 1 done
Thread 0 done

real1m22.315s
user1m22.064s
sys 0m0.044s


So the code in OpenThreads to set the affinity mask by default for
it's own threads resolve the issue completely (note, the
OpenThreads::Thread that I created above don't set affinity, so they
are free for the OS to place them.)  This may also be why most users
don't see these issues.

This isolates the issues to users who use non OpenThreads threads when
these threads are created after the viewer has been realized and don't
set thread affinity for there threads themselves.  That's three sets
of conditions that any one be changed and the problem will be entirely
resolved.

While not ideal that this issue exists at all at least we now have a
handle on it.  Given the issue only occurs with a very specific set of
usage I don't think there is any reason for sweeping changes to the
core OSG, or changes to the defaults.

Robert.
cmake_minimum_required(VERSION 2.6)

SET(PROJECT_NAME test)
PROJECT(${PROJECT_NAME})

FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgViewer)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

SET(SOURCES
main.cpp
)

INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})

LINK_DIRECTORIES(${OSG_LIB_DIR})

ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})

TARGET_LINK_LIBRARIES(${PROJECT_NAME}
${OSG_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGVIEWER_LIBRARIES} 
${OSGUTIL_LIBRARIES} ${OSGGA_LIBRARIES}
${OPENTHREADS_LIBRARIES})
cmake_minimum_required(VERSION 2.6)

SET(PROJECT_NAME test)
PROJECT(${PROJECT_NAME})

FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgViewer)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

SET(SOURCES
main.cpp
)

INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})

LINK_DIRECTORIES(${OSG_LIB_DIR})

ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})

TARGET_LINK_LIBRARIES(${PROJECT_NAME}
${OSG_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGVIEWER_LIBRARIES} 
${OSGUTIL_LIBRARIES} ${OSGGA_LIBRARIES}
${OPENTHREADS_LIBRARIES})
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

Hi Christoph,

On 26 September 2016 at 11:01, Christoph Weiss  wrote:
> This sounds a bit as if this was a rare thing to do, or at least a design
> choice that can or should be avoided.  I think on the contrary, explicit
> thread handling is something that is slowly going to die for many
> applications, the future lies in futures (pun pun) and parallel version of
> standard algorithms.  C++17 adds a lot of parallel functionality that the
> user can use without caring about threads themselves.  The code sample that
> I posted yesterday is a typical std::future application.

I think you need to trust me on the scene graph performance front.
Thread affinity is important for performance.  Future threaded support
in languages makes no difference to the cost of threads moving from
core to core.  It's the same problem no matter what API you wrap it up
with.

>> If there was an easy and intuitive route to user control of thread
>> affinity it would have been implemented already.
>
>
> What would be wrong with an osg::setThreadAffinity(...) function a user who
> knows what they're doing can use?

The OSG users don't always know what threads are active, let alone
what ones they need to set to get best performance.  The OSG in it's
defaults try to do the best it can for users.  It's not perfect, but
it at least tries.

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

Re: [osg-users] OSG and Qt

[Gianni Ambrosio]

Hi Inna,
I use OSG in Qt applications for years and I've never had specific problems 
with event handling.
Currently I'm on Qt 5.6 and OSG 3.4.0.

Gianni

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





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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Christoph Weiss]

Dear Robert,

On 09/26/2016 09:39 AM, Robert Osfield wrote:

The only "difficulty" is when using a certain usage model when
threading, it's not a general issue.  The issue looks to be isolated
to the case where users set up threads after the viewer has been
realized.


This sounds a bit as if this was a rare thing to do, or at least a 
design choice that can or should be avoided.  I think on the contrary, 
explicit thread handling is something that is slowly going to die for 
many applications, the future lies in futures (pun pun) and parallel 
version of standard algorithms.  C++17 adds a lot of parallel 
functionality that the user can use without caring about threads 
themselves.  The code sample that I posted yesterday is a typical 
std::future application.



If there was an easy and intuitive route to user control of thread
affinity it would have been implemented already.


What would be wrong with an osg::setThreadAffinity(...) function a user 
who knows what they're doing can use?


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

Re: [osg-users] different materials for a geometry and highlight

[Gianni Ambrosio]

Dear Nick,
I'm not sure to use the solution suggested by Sebastian (I've never worked with 
shaders so it is quite difficult to understand). So I would like to know if you 
foud a reason of the problem in my example?

Regards,
Gianni

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





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

Re: [osg-users] Creating a flame of rocket

[Robert Osfield]

Hi Suraj,

For flames I wouldn't use osgParticle these days. Personal I'd
implement it using shaders and perlin noise.  In
include/osgUtil/PerlinNoise you'll find a helper class from creating
the image that you can assign to a texture.  Also look online for
tutorials on how to use Perlin noise, there are plenty out there and
are fascinating to delver into.

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

Re: [osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

HI Fabien,

On 25 September 2016 at 22:52, Fabian Wiesel  wrote:
> Yes, both cause the threads being distributed across the cores. That is
> probably also why initialising TBB early in main helps, as it creates a pool
> of worker threads. For my app, you can consider it solved.
> But don't you see a difficulty for OSG, if you cannot use any threading
> library without additonal setup code?

The only "difficulty" is when using a certain usage model when
threading, it's not a general issue.  The issue looks to be isolated
to the case where users set up threads after the viewer has been
realized.

I do agree that the inheritance of the affinity to child processes is
not ideal.  It's not something that I was aware of when adding the
processor affinity to osgViewer.  It would good to find a way to
prevent this implicit inheritance when not desired.

Setting the processor affinity is an important part of making a
real-time visualization application run at a solid 60Hz, having thread
jump from core to core breaks cache and can break frame, it's why the
code exists in osgViewer and why it doesn't make sense to just remove
it.

Being able to provide user control over affinity is something I've had
in mind for a number of years, with the decoupled way many of the OSG
threads are set up there isn't an easy 1:1 mapping that the users can
get there hands dirty with to set things i.e. the user doesn't
manually create the threads, the viewer, the databases, the video
plugins all create threads depending upon how they are configured and
whether they are required when certain types of data is loaded or not.
These threads that are created are assigned when possible to sensible
locations, but it's not idea.

If there was an easy and intuitive route to user control of thread
affinity it would have been implemented already.

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