Re: [osg-users] Tiny normals: osgviewer vs osgcompositeviewer

[Per Nordqvist]

Hello Claudio / Julien,

This is still an unsolved problem for me, it normally occurs when I
integrate purchased models
in Remo3d (osg-based tool). Last time we discussed this I used osg
optimizer as a workaround
to rescale the normals but I would be really happy for a permanent fix.

I am not in a position to test Juliens code at the moment, but if anyone
does I am interested.

Cheers,
Per

On Sat, 9 Feb 2019 at 06:37, Julien Valentin 
wrote:

> In fact perhaps there's something wrong with the code:
> According the comment, and considering M=transpose(M)*invert(M) is
> orthogonal
> shoudn't it be something like:
> (*itr) = osg::Matrix::transform3x3(inverse(_im),(*itr));
> or
>  (*itr) =
> osg::Matrix::transform3x3((*itr),transpose(inverse(_im)));
>
> Perahps it would be wiser to use a simple premult for normals
>  (*itr) = osg::Matrix::transform3x3((*itr),im));
>
> try these solution with your model and give feedback
>
>
>
> mp3butcher wrote:
> > Hi,
> > Normals transformation happen in osgUtil/TransformAttributeFunctor.cpp
> l.44
> >
> > Code:
> > for (osg::Vec3d* itr=begin;itr > {
> > // note post mult by inverse for normals.
> > (*itr) = osg::Matrix::transform3x3(_im,(*itr));
> > (*itr).normalize();
> > }
> >
> >
> > All seams right ..
> > perhaps forcing orthogonality of the 3x3 with pseudo inverse and remove
> normalization could give better result...Don't know
> > Cheers
> >
> > Bonghi wrote:
> > > Hi Per,
> > >
> > > I'm finding the same problem as I'm trying to build a viewer that
> integrates a variety of models coming in different units (eg. mm vs. m).
> > >
> > > Have you had any further look at the code to include a fix?
> > >
> > > My thinking is that normals should only be rotated by the transform
> matrix, but I've not invested time yet to understand where this should
> happen in the code.
> > >
> > > Thanks,
> > > Claudio
> > [/code]
>
>
> 
> Twirling twirling twirling toward freedom
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=75611#75611
>
>
>
>
>
> ___
> 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 apps on gpu cluster

[Per Nordqvist]

Thank you Robert, these are great leads, will check them out.

There is one more variant I wonder about:
If I run two osg apps on one screen, with multiple graphics cards,
can I then share the loads between the GPUs?
Something like "GPU Affinity"?

Kind regards
Per


On Tue, 2 Oct 2018 at 09:54, Robert Osfield 
wrote:

> Hi Nick & Per,
>
> On Tue, 2 Oct 2018 at 06:12, Per Nordqvist  wrote:
> > I and Nick are working to utilize as much of the GPUs as possible,
> either on single machine or cluster.
> > So hardware is not yet decided, but let's assume ubuntu 16+, multiple
> modern Nvidia gaming cards, but still single screen.
>
> osgViewer has been written from the ground up to support multiple GPUs
> on a single machine with a single application.
>
> The basic concept is the View's master Camera controls the overall
> view, and a series of slave Camera's assign to the View handle the
> rendering for each graphics card/display.  The osgwindow example is
> the simplistic example of this in action.  A search for addSlave in
> the OSG codebase will reveal lots of other examples of it in action -
> it can be used for a wide range of tasks.
>
> The OSG out of the box will default to DrawThreadPerContext
> ThreadingModel on modern machines, you might find
> CullDrawThreadPerContext more appropriate, you could even try
> CullThreadPerCameraDrawThreadPerContext if you have plenty of cores to
> throw at it.
>
> In 3.6.x you also have support for explicitly controlling Affinity so
> you can lock various threads to particular cores.
>
> Another variable you could play with is that you can set up the
> OS/desktop so that one single graphics context can span multiple
> cards.
>
> Modern graphics cards are beast so you might well be able to handle
> quite a few displays just from one card.
>
> 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] osg apps on gpu cluster

[Per Nordqvist]

Hello Chris, thanks for chipping in.

I and Nick are working to utilize as much of the GPUs as possible, either
on single machine or cluster.
So hardware is not yet decided, but let's assume ubuntu 16+, multiple
modern Nvidia gaming cards, but still single screen.

Cheers
Per

On Mon, 1 Oct 2018, 21:22 Chris Hanson,  wrote:

> I think Robert advised me on tweaking this probably 4 years ago for a
> Windows system with 16 display outputs all running from one EXE, ensuring
> there were the proper number of contexts and threads all playing nicely so
> as not to jam up the bus.
>
> What's your hardware profile look like? Which Linux OS? What CPUs and how
> many, what display cards, and how many, how many outputs, etc. The exact
> best mechanism may not be invariant across all situations.
>
> On Mon, Oct 1, 2018 at 7:43 PM Trajce Nikolov NICK <
> trajce.nikolov.n...@gmail.com> wrote:
>
>> Hi Community,
>>
>> I am totally new to this topic and that is the reason I am pinging you
>> this time. Anyone with some experience or hints? I am after running (Linux)
>> osg app N times so each app to have dedicated GPU, something in this
>> fashion.
>>
>> I will investigate this too, but any word from you is highly appreciated.
>>
>> 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
>>
>
>
> --
> 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 • Forensics • Imaging • UAVs • 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 7

[Per Nordqvist]

Hi Robert,

No problem, I mostly wanted to flag this issue to others on the list.
If time allows I will dig into the source and see if I can find something.

Cheers,
Per

On 28 May 2018 at 12:47, Robert Osfield <robert.osfi...@gmail.com> wrote:

> Hi Per,
>
> I'm afraid I've already tagged the stable 3.6.1 so any further fixes
> that may be needed will have to go into 3.6.2.  I asked for lots of
> testing and waited a long as I could before tagging 3.6.1, I have to
> move on though as there is always other work to complete.
>
> I will be busy with client work through this week so don't am not
> scheduling time to chase up bugs on the OSG.  Others are welcome to
> chip in.  Fixes that are made to OSG master or the 3.6 branch will
> contribute to 3.6.2, I'll go for this once any fixes settle down.  I
> probably won't attempt to go for 3.6.2 until September as these
> releases, even point releases take a lot of me time.
>
> Cheers,
> Robert.
>
>
> On 28 May 2018 at 10:29, Per Nordqvist <nordqv...@gmail.com> wrote:
> > Just tested OpenSceneGraph-3.6.1-rc7 with my application, it builds fine
> but
> > some of my
> > animated FBX models are flipped upside down.
> >
> > To display them correctly with osgviewer I have to use the metaloader:
> > osgviewer mymodel.fbx.(180,0,0).rot
> > Oddly, they load fine in osganimationviewer.
> >
> > Not exactly a showstopper but I wonder if anyone else are seeing this?
> > (Static fbx models work fine, only some of the animated are broken)
> >
> > I'm on xubuntu 16.04, fbx SDK version 2017_1 and I haven't seen this
> problem
> > on
> > my previous version (osg 3.5.5).
> >
> > I can share a sample privately if it helps.
> >
> > Thanks!
> >
> > /Per
> >
> > On 23 May 2018 at 20:58, Robert Osfield <robert.osfi...@gmail.com>
> wrote:
> >>
> >> Hi All,
> >>
> >> And around we go again!! Release candidate 7:
> >>
> >>
> >> https://github.com/openscenegraph/OpenSceneGraph/
> tree/OpenSceneGraph-3.6.1-rc7
> >>
> >> Please test folks and let us know of success/failure.
> >>
> >> Thankyou :-)
> >> Robert.
> >>
> >> -- ChangeLog since rc6
> >>
> >> Wed, 23 May 2018 19:53:12 +0100
> >> Author : Robert Osfield
> >> Updates for 3.6.1-rc7
> >>
> >> Wed, 23 May 2018 17:02:28 +0100
> >> Author : Robert Osfield
> >> Updated REMOVE_SERIALIZER( ImageAttachment ); block to use 154 version
> >> to retain compatibility with binaries made with 153 SOVERSION prior to
> >> the Imageattachement change
> >>
> >> Wed, 23 May 2018 14:30:31 +0100
> >> Author : Robert Osfield
> >> Implemented StateGraph reuse in in scene graph Canera's RenderStage.
> >>
> >> Wed, 23 May 2018 14:13:27 +0100
> >> Author : Robert Osfield
> >> Fixed warning of RenderLeaf's having multiple references in
> >> CullVisitor::createOrReuseRenderLeaf() but forcing a clean up of the
> >> StateGraph at the end of RenderStage::draw()
> >>
> >> Wed, 23 May 2018 07:47:15 +0100
> >> Author : Robert Osfield
> >> Added check to make sure that glEnablei and glDisablei are only called
> >> when the capability is non zero to fix GL invalid value error.
> >>
> >> Wed, 23 May 2018 06:32:42 +0100
> >> Author : Robert Osfield
> >> Fixed type of Timer_t under Windows
> >> ___
> >> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 7

[Per Nordqvist]

Just tested OpenSceneGraph-3.6.1-rc7 with my application, it builds fine
but some of my
animated FBX models are flipped upside down.

To display them correctly with osgviewer I have to use the metaloader:
osgviewer mymodel.fbx.(180,0,0).rot
Oddly, they load fine in osganimationviewer.

Not exactly a showstopper but I wonder if anyone else are seeing this?
(Static fbx models work fine, only some of the animated are broken)

I'm on xubuntu 16.04, fbx SDK version 2017_1 and I haven't seen this
problem on
my previous version (osg 3.5.5).

I can share a sample privately if it helps.

Thanks!

/Per

On 23 May 2018 at 20:58, Robert Osfield  wrote:

> Hi All,
>
> And around we go again!! Release candidate 7:
>
>https://github.com/openscenegraph/OpenSceneGraph/
> tree/OpenSceneGraph-3.6.1-rc7
>
> Please test folks and let us know of success/failure.
>
> Thankyou :-)
> Robert.
>
> -- ChangeLog since rc6
>
> Wed, 23 May 2018 19:53:12 +0100
> Author : Robert Osfield
> Updates for 3.6.1-rc7
>
> Wed, 23 May 2018 17:02:28 +0100
> Author : Robert Osfield
> Updated REMOVE_SERIALIZER( ImageAttachment ); block to use 154 version
> to retain compatibility with binaries made with 153 SOVERSION prior to
> the Imageattachement change
>
> Wed, 23 May 2018 14:30:31 +0100
> Author : Robert Osfield
> Implemented StateGraph reuse in in scene graph Canera's RenderStage.
>
> Wed, 23 May 2018 14:13:27 +0100
> Author : Robert Osfield
> Fixed warning of RenderLeaf's having multiple references in
> CullVisitor::createOrReuseRenderLeaf() but forcing a clean up of the
> StateGraph at the end of RenderStage::draw()
>
> Wed, 23 May 2018 07:47:15 +0100
> Author : Robert Osfield
> Added check to make sure that glEnablei and glDisablei are only called
> when the capability is non zero to fix GL invalid value error.
>
> Wed, 23 May 2018 06:32:42 +0100
> Author : Robert Osfield
> Fixed type of Timer_t under Windows
> ___
> 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] Tiny normals: osgviewer vs osgcompositeviewer

[Per Nordqvist]

Hi there, thanks for your quick input.

@Robert; The use case is pretty common: the original model assumes mm, I
assume meters. Hence the extreme scaling.
Yes I noticed the transforms are flattened, which is probably a good thing
in my case but it shouldn't
change the rendering. (The model is exported by a 3rd party software so I
don't have full control)

@Sebastian: Yes you are probably right, I thought that some normals were
completely lost though due to
the scaling (rescaling = division by 0) but maybe I was lucky this time.

Thanks again,
Per


On 4 December 2017 at 10:38, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

>
>
> Hi Per,
>
> Just a thought:
> Maybe the Optimizer simply applies normal-rescaling?
>
> Cheers
> Sebastian
>
>> Hi all,
>>
>> I came across something strange recently;
>> the attached model is a red triangle scaled down by a factor 1000.
>> The normals are squashed and I see some rendering problems in my app,
>> which uses osgcompositeviewer.
>>
>> Confirmed with
>> osgcompositeviewer red.osgt  - renders with white color (incorrect)
>> BUT
>> osgviewer red.osgt - renders with red color (correct)
>>
>> I did some digging in the OSG code, it seems the difference is that
>> osgviewer always
>> optimizes the scene graph, something that osgcompositeviewer never does.
>> Adding an optimizer to osgcompositeviewer fixes the rendering.
>>
>> So first question; would it be better if the two viewers applied same
>> optimizer settings?
>> Since users would expect them to display things in the exact same way.
>>
>> Second and more interesting; how can optimizer correct a "broken" model?
>>
>> Thank you!
>>
>> /Per
>>
>>
>>
>> ___
>> 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] Tiny normals: osgviewer vs osgcompositeviewer

[Per Nordqvist]

Hi all,

I came across something strange recently;
the attached model is a red triangle scaled down by a factor 1000.
The normals are squashed and I see some rendering problems in my app,
which uses osgcompositeviewer.

Confirmed with
osgcompositeviewer red.osgt  - renders with white color (incorrect)
BUT
osgviewer red.osgt - renders with red color (correct)

I did some digging in the OSG code, it seems the difference is that
osgviewer always
optimizes the scene graph, something that osgcompositeviewer never does.
Adding an optimizer to osgcompositeviewer fixes the rendering.

So first question; would it be better if the two viewers applied same
optimizer settings?
Since users would expect them to display things in the exact same way.

Second and more interesting; how can optimizer correct a "broken" model?

Thank you!

/Per


red.osgt
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph for driving simulation framework?

[Per Nordqvist]

Hi Florian. I second Chris, OSG won't let you down on speed.
Here at Volvo (trucks) we have been using OSG in our driving simulator for
10 years, no plans
of switching. Several others are also using OSG in their driving simulators.

Still you have a lot of work in front of you, it is a dream system you are
sketching.
You can easily spend 2-3 years just tweaking your moving platform - so make
sure you have the
right research questions before coming up with solutions.

Across the river here in Gothenburg sits Electronic Arts, they create Need
For Speed.
To get the graphics they use ~5 people full time in Maya - hand painting
the roads and scenes.

When creating our graphics we use Maya, 3ds, Blender  Remo3d (OSG based).
We also purchase models from turbosquid etc.

Feel free to contact me directly for non-OSG simulator discussions.

Cheers,

/Per Nordqvist

On 10 June 2015 at 15:10, Chris Hanson xe...@alphapixel.com wrote:

 OSG is certainly fast enough. You could couple in osgBullet for the
 physics support.

 What you propose to do is a lot of work, in any toolkit.

 On Wed, Jun 10, 2015 at 3:33 AM, Florian Weidner leflar...@gmail.com
 wrote:

 Hey,

 how are you? At first, thanks for the effort put in the development of
 OpenSceneGraph.
 For a bigger research project, i need to develop a first person driving
 simulator - or in other words, a framework supporting driving simulation.
 It should be like a customizable racing game which connects to a real life
 test bench for car physics, a motion platform as well as different input
 and visualization devices

 For this i need a very realistic environment (buildings, trees, traffic
 participants, rain, wind...) as well as a simple scenario editor. The
 editor should allow an easy configuration of maps and support certain
 triggers. A basic physics engine is also required but it does not need to
 be very sophisticated bc I'm going to use parameters from the real-life
 test bench.

 Currently, I'm looking for a nice open source engine which makes the
 development a little bit easier through having some built-in features.
 From the wiki and the forum I got the idea that OpenSceneGraph might be a
 good choice bc of it's openness, basic structure and the extensibility. Now
 i want to ask you, if anyone has some feedback for me?
 Is OpenSceneGraph be the right choice? Or do you suggest using another
 engine? (I'm especially concerned about the graphics. Is OpenSceneGraph
 suitable or fast enough?)

 Of course, all results of my research will be published and open source
 as well :)
 Any feedback is welcome!
 Thx in advance!

 Cheers,
 Florian

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





 ___
 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 https://twitter.com/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


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

Re: [osg-users] SmoothingVisitor normals doesn't seem right

[Per Nordqvist]

Hi AP,

two ideas:

Play with sv-setCreaseAngle(something else than default PI)
or
yourNode-getOrCreateStateSet()-setAttributeAndModes(new
osg::FrontFace(osg::FrontFace::COUNTER_CLOCKWISE),
osg::StateAttribute::ON);

(CLOCKWISE or COUNTER_CLOCKWISE that is)

Hope this helps,

/Per


On 27 January 2015 at 11:54, Ash Pat ash_zz...@yahoo.com wrote:
 Hi,

 I am trying to use the SmoothingVisitor to generate the normals. I am not 
 explicitly setting the normals array. However, when rendered it appears as 
 though the normals generated are flipped. The geometry consists of triangle 
 and quad primitives.

 I tried it in two ways.

 Code:
 osgUtil::SmoothingVisitor::smooth(*pGeometry);



 Code:
 osgUtil::SmoothingVisitor sv;
 pGeode-accept(sv);



 Any suggestions?
 Is there something more to be done?

 Thank you!

 Cheers,
 AP

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





 ___
 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] Self built 3.2.1 3x slower than repo's 3.2.0

[Per Nordqvist]

Thanks Robert, fix looks good.
The README.txt is still somewhat confusing so I have updated it
accordingly, see attached file.

Regards,

/Per

On 19 November 2014 18:47, Robert Osfield robert.osfi...@gmail.com wrote:
 Hi Per et. al,

 I have merged something very similar to Per's/simgear's script, and now the
 cmake . defaults to building Release I have also removed the old configure
 script file that provided a simply means for setting the release type, as
 this isn't required any more - standard cmake invocation will work fine.  I
 have also updated the READEME.txt to reflect this.

 Cheers,
 Robert.



 On 21 August 2014 10:25, Per Nordqvist nordqv...@gmail.com wrote:

 Hi Robert, sorry for the late follow up, but I have now tested the cmake
 trick from James,
 it seems to do exactly what we want, i.e. replace the need for the
 configure script.
 I submit it here for further testing and review.
 (osg trunk rev 14407, tested on Xubuntu 12.04 Cmake 2.8.7)

 Maybe we can't remove the configure script entirely (there might be
 install scripts still depending on it) but at least
 we can stop advocating its use in README.txt.

 Regards,

 /Per



 On 5 August 2014 18:36, James Turner zakal...@mac.com wrote:


 On 25 Jul 2014, at 07:09, Robert Osfield robert.osfi...@gmail.com
 wrote:

 No, but when we created the cmake scripts we couldn't find a way of
 setting it to default on.  I ended up including the cofigure script to
 workaround this.

 We've had cmake for quite a while now so it will have changed
 substantially since we first adopted so perhaps this inability to set the
 default will now be gone, or perhaps a bit more experience with cmake magic
 amongst our community might find a way to do it,


 For SimGear / FlightGear we do:


 https://gitorious.org/fg/simgear/source/d1f5d92a7bab73d8fd0617d50bbfb7743e2f6565:CMakeLists.txt#L55

 Which could equally set a default value instead of warning.

 James


 ___
 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

Welcome to the OpenSceneGraph (OSG).

For up-to-date information on the project, in-depth details on how to
compile and run libraries and examples, see the documentation on the
OpenSceneGraph website:

http://www.openscenegraph.org/index.php/documentation

For support subscribe to our public mailing list or forum, details at:

http://www.openscenegraph.org/index.php/support

For the impatient, we've included quick build instructions below, these
are are broken down is three parts:

  1) General notes on building the OpenSceneGraph
  2) OSX release notes
  3) iOS release notes

If details below are not sufficient then head over to the openscenegraph.org
to the Documentation/GettingStarted and Documentation/PlatformSpecifics 
sections for
more indepth instructions.

Robert Osfield.
Project Lead.
24th July 2013.

--

Section 1. How to build the OpenSceneGraph
==

The OpenSceneGraph uses the CMake build system to generate a
platform-specific build environment.  CMake reads the CMakeLists.txt
files that you'll find throughout the OpenSceneGraph directories,
checks for installed dependenciesand then generates the appropriate
build system.

If you don't already have CMake installed on your system you can grab
it from http://www.cmake.org, use version 2.4.6 or later.  Details on the
OpenSceneGraph's CMake build can be found at:

http://www.openscenegraph.org/projects/osg/wiki/Build/CMake

Under unices (i.e. Linux, IRIX, Solaris, Free-BSD, HP-Ux, AIX, OSX)
use the cmake or ccmake command-line utils. Note that cmake . defaults
to building Release to ensure that you get the best performance from
your final libraries/applications.

cd OpenSceneGraph
cmake .
make
sudo make install

Alternatively, you can create an out-of-source build directory and run
cmake or ccmake from there. The advantage to this approach is that the
temporary files created by CMake won't clutter the OpenSceneGraph
source directory, and also makes it possible to have multiple
independent build targets by creating multiple build directories. In a
directory alongside the OpenSceneGraph use:

mkdir build
cd build
cmake ../OpenSceneGraph
make
sudo make install

Under Windows use the GUI tool CMakeSetup to build your VisualStudio
files. The following page on our wiki dedicated to the CMake build
system should help guide you through the process:


http://www.openscenegraph.org/index.php/documentation/platform

Re: [osg-users] First time render hiccup

[Per Nordqvist]

Hi Vaclav, it's good to hear I'm not alone with this problem. It took me a
while
to understand it's nature so I could describe it here.
You are right of course, once the HW memory is out, I'm back in trouble.

For incremental compilation I found two examples: osganalysis and
osgthreadedterrain.
Maybe they could serve as a starter if Nicks solution is not enough one day.
Or I just buy a bigger card ;-)

Cheers

/Per



On 3 September 2014 20:56, Vaclav Bilek vabi-...@centrum.cz wrote:

  Hi Nick  Per

 You have to reduce the amount of data transferred by the driver to the
 card. I have been dealing with the same issue and the solution that worked
 for me is to chop the data to smaller chunks and/or spread the GL compile
 phase into more frames . To spread the number of GL compile call in case of
 the OpenSceneGraph you have to modify it a bit to do this task.

 By the way the solution Nick mentioned works only if you have enough of
 resources. Once your per frame data are bigger then the HW resources
 available, the driver will do its own magic that causes the occasional
 jerky movement/frame freezes.

 Have fun!
 Vaclav


 On 09/02/14 12:06, Trajce Nikolov NICK wrote:

 Hi Per,

  this is a trick from the old days from scenegraph managers like
 Quantum3D OpenGVS. What they did to avoid this they preloaded the models at
 the very beginning to let OpenGL compile objects and then used in the
 scene. Maybe you can do the same way

  Nick


 On Tue, Sep 2, 2014 at 2:03 PM, Cary, Karl A. karl.a.c...@leidos.com
 wrote:

 We have been having the same issue and haven't found a solution yet
 either, though it hasn't been our main priority yet. I will be following
 any responses closely and will contribute if I can.

 -Original Message-
 From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
 Behalf Of Robert Osfield
 Sent: Tuesday, September 02, 2014 8:01 AM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] First time render hiccup

 Hi Per,


 Stalls like you describe are typically when the graphics driver has to
 compile new OpenGL objects.  There are range of things that can cause
 compilation to be slow, I haven't to head off line right now so will have
 to leave you with that hint...

 Robert.



 On 2 September 2014 12:27, Per Nordqvist nordqv...@gmail.com wrote:


 Hi all,


 Another open-ended question I'm afraid, but maybe someone
 has seen this before:


 I sometimes see hiccups (rendering pauses) in my driving
 simulation,

 I noticed it only happens with some vehicles, and only when they
 appear in the frustum for the first time. I wonder how to
 minimize this effect.

 Clues:
 -Once the model has been displayed there is no more hiccup.
 -Differerent models produce different hiccup delays (consistently)
 -Hiccup problem does not scale with .ive size or nr of polygons
 -In bad cases I can see the osgstats cull part go to zero for
 about 1 sec.
 -Using ProxyNode makes no difference.


 Suggestions? Some caching options I can try?
 Anything nasty to look for in the .ive models?


 (Most are 3DS format made by 3rd party, converted with osgconv,
 sorry I can't share them)


 I'm using OSG 3.01, compositeviewer, linux, Nvidia (different
 cards, same problem.)


 Thanks!



 /Per



 ___
 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




  --
 trajce nikolov nick


 ___
 osg-users mailing 
 listosg-users@lists.openscenegraph.orghttp://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

[osg-users] First time render hiccup

[Per Nordqvist]

Hi all,

Another open-ended question I'm afraid, but maybe someone
has seen this before:

I sometimes see hiccups (rendering pauses) in my driving simulation,
I noticed it only happens with some vehicles, and only when they
appear in the frustum for the first time. I wonder how to minimize this
effect.

Clues:
-Once the model has been displayed there is no more hiccup.
-Differerent models produce different hiccup delays (consistently)
-Hiccup problem does not scale with .ive size or nr of polygons
-In bad cases I can see the osgstats cull part go to zero for about 1 sec.
-Using ProxyNode makes no difference.

Suggestions? Some caching options I can try?
Anything nasty to look for in the .ive models?

(Most are 3DS format made by 3rd party, converted with osgconv,
sorry I can't share them)

I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same
problem.)

Thanks!

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

Re: [osg-users] First time render hiccup

[Per Nordqvist]

Thanks guys for the answers! I guess it's OK to take a hit at the beginning
if things run smoothly afterwards,
so I don't think I need a incremental compilation.

Based on your answers I found a similar question here
http://forum.openscenegraph.org/viewtopic.php?t=4997

So I tried this:
 osgViewer::Renderer* renderer =

dynamic_castosgViewer::Renderer*(viewer-getCamera()-getRenderer());
  renderer-setCompileOnNextDraw(true);


which is promising beacuse it creates exactly the same stall that I was
seeing before.
However, if I have hidden objects under a switch or if it's outside the
frustum, I still see a recompilation
triggered automatically once it is in the frustum and visible under the
switch.
So how to compile the _entire_ scene?

/Per



On 2 September 2014 14:21, Glenn Waldron gwald...@gmail.com wrote:

 Per,
 If you don't want to pre-compile your GL objects, the
 IncrementalCompileOperation might help too. But you might need a newer
 version of OSG.

 Glenn Waldron / @glennwaldron


 On Tue, Sep 2, 2014 at 7:27 AM, Per Nordqvist nordqv...@gmail.com wrote:

 Hi all,

 Another open-ended question I'm afraid, but maybe someone
 has seen this before:

 I sometimes see hiccups (rendering pauses) in my driving simulation,
 I noticed it only happens with some vehicles, and only when they
 appear in the frustum for the first time. I wonder how to minimize this
 effect.

 Clues:
 -Once the model has been displayed there is no more hiccup.
 -Differerent models produce different hiccup delays (consistently)
 -Hiccup problem does not scale with .ive size or nr of polygons
 -In bad cases I can see the osgstats cull part go to zero for about 1 sec.
 -Using ProxyNode makes no difference.

 Suggestions? Some caching options I can try?
 Anything nasty to look for in the .ive models?

 (Most are 3DS format made by 3rd party, converted with osgconv,
 sorry I can't share them)

 I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same
 problem.)

 Thanks!

 /Per


 ___
 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] First time render hiccup

[Per Nordqvist]

Thanks Robert for the detailed answer, I see the point of incremental
compilation now but for my particular
use case where I basically load everything at the beginning (but hide some
things from the camera) I think
my magic wand still is this Performer parading trick. I'm happy to break
many frames as long as I can make it
happen in the beginning, so compile time is not a major issue here.

I just did some initial parade tests and I can confirm the stalls are
gone now so it seems to work out great.

Still this solution is a bit hacky, so if Carl or somebody else proceeds
with the incremental path I'm curios to see an
example of how complex it gets.

/Per


On 2 September 2014 16:02, Robert Osfield robert.osfi...@gmail.com wrote:

 Hi Per,


 On 2 September 2014 14:18, Per Nordqvist nordqv...@gmail.com wrote:


 Thanks guys for the answers! I guess it's OK to take a hit at the
 beginning if things run smoothly afterwards,
 so I don't think I need a incremental compilation.

 Based on your answers I found a similar question here
 http://forum.openscenegraph.org/viewtopic.php?t=4997

 So I tried this:
   osgViewer::Renderer* renderer =

 dynamic_castosgViewer::Renderer*(viewer-getCamera()-getRenderer());
   renderer-setCompileOnNextDraw(true);


 This simply runs the GLObjectVisitor on the next frame to run GL object
 compile on objects in scene graph, which, if you have lots of new GL
 objects to be compiled will result in a frame stall.

 which is promising beacuse it creates exactly the same stall that I was
 seeing before.


 Best case is setCompileOnNextDraw(true) will perform the same as just
 rendering it without if everything is on screen, if some elements would
 otherwise be culled the frame time will actually be longer as all the GL
 objects that need to be compiled will be compiled at the same time.  The
 advantage comes in subsequent frames as no new objects will enter the view
 frustum and then have to be compiled.

 However, if I have hidden objects under a switch or if it's outside the
 frustum, I still see a recompilation
 triggered automatically once it is in the frustum and visible under the
 switch.
 So how to compile the _entire_ scene?


 You need to slow down and understand the basic mechanics of what is going
 on.  The OSG has lots of features to help with these issues but it's an
 advanced topic with no magic wand so best take bit by bit.

 Part of the solution will be use of the
 ogUtil::IncrementalCompileOperation as it designed to load balance the
 number of GL compilations and deletes that happen each frame so that no one
 frame gets overload and causes a frame break. The OSG's DatabasePager
 utilizes the ogUtil::IncrementCompileOperation to avoid frame breaks, and
 osgViewer::Viewer/CompositeViewer have support for
 IncrementalCompileOperation built in, so the infrastructure is all there
 waiting to be utilized.

 When you incremental compile objects you have to submit a subgraph to be
 compiled and this is done by bit until all parts are compiled and when they
 are these subgraphs are placed in a ready to be merged list, you can also
 get a callback to get informed that a subgraph is ready.  There are lots of
 controls in the IncrementalCompileOperation to tune how quickly GL objects
 get compiled - you can balance the speed of compilation vs the risk of
 breaking frame.

 Another part of the work to make this efficient is make sure that the GL
 objects in the scene graph are efficient to compile.  Various drivers have
 different strengths and weakness so what might be slow on one
 driver/hardware might be fast on another.  There are however general
 rules.  For instance generating of texture mipmaps can be a bottleneck so
 precomputing mipmaps and storing them on disk can help, compressing imagery
 in an OpenGL native compression format can also be very helpful.

 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] Self built 3.2.1 3x slower than repo's 3.2.0

[Per Nordqvist]

Hi Robert, sorry for the late follow up, but I have now tested the cmake
trick from James,
it seems to do exactly what we want, i.e. replace the need for the
configure script.
I submit it here for further testing and review.
(osg trunk rev 14407, tested on Xubuntu 12.04 Cmake 2.8.7)

Maybe we can't remove the configure script entirely (there might be install
scripts still depending on it) but at least
we can stop advocating its use in README.txt.

Regards,

/Per



On 5 August 2014 18:36, James Turner zakal...@mac.com wrote:


 On 25 Jul 2014, at 07:09, Robert Osfield robert.osfi...@gmail.com wrote:

 No, but when we created the cmake scripts we couldn't find a way of
 setting it to default on.  I ended up including the cofigure script to
 workaround this.

 We've had cmake for quite a while now so it will have changed
 substantially since we first adopted so perhaps this inability to set the
 default will now be gone, or perhaps a bit more experience with cmake magic
 amongst our community might find a way to do it,


 For SimGear / FlightGear we do:


 https://gitorious.org/fg/simgear/source/d1f5d92a7bab73d8fd0617d50bbfb7743e2f6565:CMakeLists.txt#L55

 Which could equally set a default value instead of warning.

 James


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


set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE)
set_property(GLOBAL PROPERTY USE_FOLDERS ON)

IF(WIN32)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
IF(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
ELSE(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.4 FATAL_ERROR)
ENDIF(APPLE)
ENDIF(WIN32)

if(COMMAND cmake_policy)
# Works around warnings libraries linked against that don't
# have absolute paths (e.g. -lpthreads)
cmake_policy(SET CMP0003 NEW)

# Works around warnings about escaped quotes in ADD_DEFINITIONS
# statements.
cmake_policy(SET CMP0005 NEW)

# tell CMake to prefer CMake's own CMake modules when available
# only available from cmake-2.8.4
if(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 8 AND 
${CMAKE_PATCH_VERSION} GREATER 3)
cmake_policy(SET CMP0017 NEW)
endif()

# cmake-2.6.1 introduces policy cmp0008 decide how to treat full path 
libraries that do not appear to be valid library file names
# quote from cvslog Such libraries worked by accident in the VS IDE and 
Xcode generators in CMake 2.4 and below.
if(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4 AND 
${CMAKE_PATCH_VERSION} GREATER 0)
cmake_policy(SET CMP0008 OLD)
endif()

# disable autolinking to qtmain as we have our own main() functions (new in 
Qt 5.1)
if((${CMAKE_MAJOR_VERSION} EQUAL 2 OR ${CMAKE_MAJOR_VERSION} GREATER 2) AND
   (${CMAKE_MINOR_VERSION} EQUAL 8 OR ${CMAKE_MINOR_VERSION} GREATER 8) AND
${CMAKE_PATCH_VERSION} GREATER 10)
cmake_policy(SET CMP0020 OLD)
endif()
# nicer version check - but needs at least CMake 2.6.2? Worth upgrading the 
requirements?
#if(${CMAKE_VERSION} VERSION_GREATER 2.8.10)


endif()

PROJECT(OpenSceneGraph)

SET(OPENSCENEGRAPH_MAJOR_VERSION 3)
SET(OPENSCENEGRAPH_MINOR_VERSION 3)
SET(OPENSCENEGRAPH_PATCH_VERSION 3)
SET(OPENSCENEGRAPH_SOVERSION 115)

# set to 0 when not a release candidate, non zero means that any generated
# svn tags will be treated as release candidates of given number
SET(OPENSCENEGRAPH_RELEASE_CANDIDATE 0)

SET(OPENSCENEGRAPH_VERSION 
${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION})

SET(OSG_PLUGINS osgPlugins-${OPENSCENEGRAPH_VERSION})

SET(OSG_PLUGIN_PREFIX )

IF (CYGWIN)
SET(OSG_PLUGIN_PREFIX cygwin_)
ENDIF()

IF(MINGW)
SET(OSG_PLUGIN_PREFIX mingw_)
ENDIF()


# We want to build SONAMES shared librariess
SET(OPENSCENEGRAPH_SONAMES TRUE)
SET(OPENTHREADS_SONAMES TRUE)

SET(OpenThreads_SOURCE_DIR ${OpenSceneGraph_SOURCE_DIR})

# We have some custom .cmake scripts not in the official distribution.
# Maybe this can be used override existing behavior if needed?
SET(CMAKE_MODULE_PATH 
${OpenSceneGraph_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH})

# If build type not specified, set to Release
IF(NOT CMAKE_BUILD_TYPE)
SET(CMAKE_BUILD_TYPE Release CACHE STRING
Choose the type of build, options are: None Debug Release RelWithDebInfo 
MinSizeRel.
FORCE)
ENDIF(NOT CMAKE_BUILD_TYPE)

## Option to enable Android build using AndroidNDK
OPTION(OSG_BUILD_PLATFORM_ANDROID OFF)
IF(OSG_BUILD_PLATFORM_ANDROID)

CMAKE_MINIMUM_REQUIRED(VERSION 2.8.0 FATAL_ERROR)

INCLUDE(OsgAndroidMacroUtils)
SET(ANDROID TRUE)
IF(NOT ANDROID_PLATFORM)
MESSAGE(Warning Android Platform version NOT defined, Default selected 
version: 5)
SET(ANDROID_PLATFORM 5)
ENDIF()
IF(NOT ANDROID_ABI)
MESSAGE(Warning Android ABI 

Re: [osg-users] Self built 3.2.1 3x slower than repo's 3.2.0

[Per Nordqvist]

 By default cmake doesn't select the Release build type so doesn't compile the 
 OSG with any
 optimization enabled.

Robert: just curious, is there a reason not to use Release as default?

Simon: 3x slower?? Sounds like you should search for the problem somewhere else,
especially if you are on a Linux system. Happy if you could post your findings,
I'm on xubuntu 12.04 and about to upgrade to 14.04.

/Per







On 24 July 2014 09:43, Robert Osfield robert.osfi...@gmail.com wrote:
 HI Simon,

 By default cmake doesn't select the Release build type so doesn't compile
 the OSG with any optimization enabled.

 If you use the simple configure script placed in root OpenSceneGraph
 directory it'll select the Release build for you i.e

 cd OpenSceneGraph
 rm CMakeCache.txt // only required if you've already run cmake
 ./configure
 make -j 8

 The -j8 selects the number of processes to use when building - so if you
 have a multicore system then you'll want to use this.

 The configure script is simply:

 cmake . -DCMAKE_BUILD_TYPE=Release $@

 You can also select the Release build by running ccmake . and selecting
 setting the CMAKE_BUILD_TYPE.

 Robert.


 On 24 July 2014 17:31, si...@mungewell.org wrote:

 No doubt I missed some useful options, but this document suggests I did
 build with optimization on.

 http://trac.openscenegraph.org/projects/osg//wiki/Support/UserGuides/Make

 I did
 --
 $ cmake .
 $ make
 --

 On my system (Quadro FX4600) I got following FPS with same code base.
 --
 OSG 3.2.1 (self compiled): 80+ in normal, 20-30 in Rift
 OSG 3.2.0 (repo): 270+ in normal, 60 in Rift
 --

 Is there something (obvious) that I'm missing? On 64bit Xubuntu 14.04LTS.
 Simon

 ___
 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::notify + \n does not work

[Per Nordqvist]

Correct, \n gives me a newline but since the flush is not there I miss out on
almost all of my notifications. So I had to replace all \n with std::endl.
Several osg examples has the same flaw so they should probably
be changed to std::endl.

I wanted to raise this because more people could be in the same situation
without knowing it. It is quite subtle but potentially dangerous IMHO.

 /Per

On 14 July 2014 01:32, Robert Osfield robert.osfi...@gmail.com wrote:
 Hi Per,

 I think you'll find that \n is working - it creates a newline, but just
 isn't doing a flush like you want it to.  For a flush you need to do use
 std::endl.  I believe this is appropriate std::ostream behaviour.

 Robert.


 On 9 July 2014 13:38, Per Nordqvist nordqv...@gmail.com wrote:

 Hi Robert  all,

 When I run the program below I only see notice 2+3.
 When I uncomment the 4th notice they all appear but in order 2314.
 So it seems that osg::notify waits for a std::endl to flush, but
 shouldn't \n do the job as well?

 (I am on xubuntu 12.04, OSG 3.0.1, OSG_NOTIFY_LEVEL=NOTICE)

 Thanks!

 Per Nordqvist

 --
 #include osg/Notify
 #include iostream

 int main(int argc, char* argv[])
 {
   osg::notify(osg::NOTICE)  1 notify with \\n\n;
   std::cout  2 cout with \\n\n;
   std::cout  3 cout with endl  std::endl;

   // uncomment to display first notice
   //osg::notify(osg::NOTICE)  4 notify with endl  std::endl;

   return 0;
 }
 --
 ___
 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

[osg-users] osg::notify + \n does not work

[Per Nordqvist]

Hi Robert  all,

When I run the program below I only see notice 2+3.
When I uncomment the 4th notice they all appear but in order 2314.
So it seems that osg::notify waits for a std::endl to flush, but
shouldn't \n do the job as well?

(I am on xubuntu 12.04, OSG 3.0.1, OSG_NOTIFY_LEVEL=NOTICE)

Thanks!

Per Nordqvist

--
#include osg/Notify
#include iostream

int main(int argc, char* argv[])
{
  osg::notify(osg::NOTICE)  1 notify with \\n\n;
  std::cout  2 cout with \\n\n;
  std::cout  3 cout with endl  std::endl;

  // uncomment to display first notice
  //osg::notify(osg::NOTICE)  4 notify with endl  std::endl;

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

[osg-users] OpenFlight road support in OSG?

[Per Nordqvist]

Hi all,

I just noticed that the OpenFlight Plugin contains some support for
RoadSegments and RoadPath records (RoadRecords.cpp) so I was wondering if
somebody is using this
and how.

Background: I'm developing a driving simulator in OSG 3.01 and have lots of
legacy flt-based roads that I am using. Each flt file is accompanied by a
path file which carries the road logic, essentially ASCII file containing
XYZ + Normal
XYZ + Normal
XYZ + Normal
...
similar to path beads, page 34:
ftp://ftp.uni-duisburg.de/FlightGear/OpenFlight/of_spec_14_2.pdf

Problem is I want to modify my roads but keep the paths in synk.

Thanks,

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

Re: [osg-users] Osg + Maya status?

[Per Nordqvist]

Haha, whatever you say :-)

My pipeline is more complicated, since I have existing .3ds + .ive
files I need to update in Maya,
then export back to my application.
For the import to maya I'm looking at the FBX format, for the export
I'll probably need the
osgmaya plugin to get full control.

My application (based on OSG 3.01) is not integrated with maya, so I'm
free to use whatever
OSG version for the plugin as long as the final exported .ive files work.
I have tested compiling against 2.8.3 and 3.01 without success so far,
but only with the existing solution file.
I can't find 2.9.x on the osg website. Might be I have to use svn to
get hold of it.

I'll try some more with cmake and maybe talk to Javier about it. I'll
post here if there is some progress.

Thanks again J-S, impressive that you find the time to help us all.

/Per


On 7 September 2012 01:21, Jean-Sébastien Guay jean_...@videotron.ca wrote:
 Hello Per,

 There is no such thing as noise for the OSG list, especially not when it's
 so directly related to a project in the OSG ecosystem. It's totally relevant
 and will be useful to someone else I'm sure. So I'm putting this back on the
 list :-)

 I didn't go from any pre-existing solution file, I just generated my own
 with maya2osg's cmake build system (similar to OSG's own).

 IIRC, I built maya2osgwith an OSG off the SVN trunk, probably close to 3.0.
 It's been a while though (at my previous employer which I left over 9 months
 ago) so depending on whether your OSG version is more or less recent it may
 or may not compile. In that case, you can probably collaborate with Javier
 Taibo and / or PP (Peter Particle I think it stood for) who were active
 developers of the project back then and probably still monitor this list.
 You can also subscribe to its own mailing list at

 https://lists.sourceforge.net/lists/listinfo/maya2osg-users

 though I think they are on both so they should see these messages too.

 Another thing I remember, I would compile maya2osg with an SVN trunk version
 of OSG, but the models exported from maya in .osg format would read fine in
 an OSG 2.8.3 viewer. So that's what we did, since our own software needed to
 use a stable / released / numbered version of OSG, not OSG from SVN). Our
 pipeline looked like this:

 1. Create models in maya
 2. Export with maya2osg (compiled against OSG 2.9.x or whatever) in .osg
 format
 3. Optimize the .osg model and save it as .ive using a custom tool based on
 osgconv (built using OSG 2.8.3, so the binary .ive format was compatible
 with our software)
 4. Use the .ive or the unoptimized .osg in our software (built using OSG
 2.8.3)

 So as I see it you have 2 options depending on the version of OSG you were
 using to build maya2osg:

 1. If it was a recent version (3.1 and up, or current SVN trunk) I'm sure
 the maya2osg folks will want to update the plugin to build against that
 version, so you can try to make it work and submit the changes to them or
 talk to them to see if they're willing to do it.
 2. If it was an older version, for example the version you need to build
 your own software with, you could adopt a pipeline like the one I outlined
 above.

 As an alternative to option 2, you could also modify maya2osg to compile
 against that version of OSG (using #ifdefs with the OSG version to make sure
 you don't break its compilation against newer versions). But I think that
 might make the code very messy, so the maya2osg folks might not accept to
 merge those changes back in, which I think is understandable, and then you'd
 be left with having to maintain your own private fork of the plugin...

 Hope this helps,

 J-S



 On 06/09/2012 10:49 AM, Per Nordqvist wrote:

 Hi J-S, thanks for responding. I assume you started from the Maya 2011
 solution,
 with Visual Studio 2008?
 Im trying to compile now but I'm probably using the wrong version of OSG,
 getting lots of API related errors during compile time.
 Do you remember which version of OSG you used that matches Maya 2011?

 (I'm posting off the list to reduce the noise. If I succeed I'll post
 the conclusions there)

 /Per

 On 6 September 2012 12:45, Jean-Sébastien Guay jean_...@videotron.ca
 wrote:

 Hello Per,

 I've used Maya2osg with Maya 2012 x64. I compiled the plugin myself
 though.

 J-S



 On 06/09/2012 3:22 AM, Per Nordqvist wrote:

 Hi all,

 I'm trying to find a working pipeline between osg 3.01  Maya 2013.
 I started with intermediate formats (3ds, flt, obj) but no joy,
 material settings are all messed up.

 Now I am looking at the native osgMaya:
 http://maya2osg.sourceforge.net/
 but it only supports older version of Maya, i.e 2009/10/11.

 Has there been any efforts on this plugin for Maya 2013?

 Thanks,

 /Per Nordqvist

 p.s. the community page
 http://www.openscenegraph.org/projects/osg/wiki/Community/Plugins
 points to http://www.diosoft.com/soft/osgmaya/ but this page seems dead.
 ___
 osg-users mailing list

[osg-users] Osg + Maya status?

[Per Nordqvist]

Hi all,

I'm trying to find a working pipeline between osg 3.01  Maya 2013.
I started with intermediate formats (3ds, flt, obj) but no joy,
material settings are all messed up.

Now I am looking at the native osgMaya:
http://maya2osg.sourceforge.net/
but it only supports older version of Maya, i.e 2009/10/11.

Has there been any efforts on this plugin for Maya 2013?

Thanks,

/Per Nordqvist

p.s. the community page
http://www.openscenegraph.org/projects/osg/wiki/Community/Plugins
points to http://www.diosoft.com/soft/osgmaya/ but this page seems dead.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] which version od Autodesk FBX SDK is used

[Per Nordqvist]

There is a SDK archive here
http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112id=10775892
but the 2012.2 link seems to point to 2013.2.
Maybe ping them about it, this used to work before.

/Per

On 27 August 2012 14:07, Trajce Nikolov NICK
trajce.nikolov.nick@gmail.com wrote:
 Hi Sergey,

 any idea from where can I get 2012.2 ? I tried to build it against the
 recent FBX SDK which is 2013.2 and it failed - the sdk is different (as
 expected). I am using OSG-3.0.1

 Thanks

 Nick

 On Mon, Aug 27, 2012 at 1:59 PM, Sergey Polischuk pol...@yandex.ru wrote:

 Hi, Nick.

 You can check it in ReaderWriterFBX.h header in osgPlugins/fbx dir.
 I use 2012.2 with some half recent osg svn version (osgversion says its
 3.1.3).

 Cheers,
 Sergey.
 27.08.2012, 13:48, Trajce Nikolov NICK
 trajce.nikolov.nick@gmail.com:

 Hi Community,
 Anyone has clue which version of the FBX SDK is used in the osg fbx
 plugin? The one that is actual seams is not FBX SDK 2013.2. Also any hint
 from where it can be downloaded?
 Thanks a bunch
 Cheers,
 Nick

 ___
 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

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

Re: [osg-users] [build] make-ing error with osg

[Per Nordqvist]

Not an OSG question actually; I believe newer gcc linker enforces
stricter rules about linking,
a workaround is to replace -lOpenThreads with -l/usr/lib/OpenThreads.so
or whereever you have installed your .so file.

/Per

On 1 February 2012 12:35, Alberto Luaces alua...@udc.es wrote:
 Hobbes Pierre writes:

 /usr/bin/ld: note: 'OpenThreads::Atomic::operator--()' is defined in
 DSO /home/kati/Downloads/OpenSceneGraph-3.0.1/lib/libOpenThreads.so.12
 so try adding it to the linker command line

 It seems they are not linking with OpenThreads, but the linker says they
 should. I have inspected their Makefile, and I would add -lOpenThreads
 to the list of libraries listed under the LIBS variable.

 --
 Alberto

 ___
 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] GLSL shaders and projective texturing

[Per Nordqvist]

I also struggled with this issue once and I believe osgspotlight suffers
from exactly the same quadrant defect if you look closely.
Would be really nice if somebody submitted a fix.

/Per

On 29 September 2011 01:59, Brad Colbert bcolb...@rscusa.com wrote:

 Glenn,

 ** **

 Bingo!  That was it.  I wasn’t quite sure that would work with TexGen but
 there you go!

 ** **

 Thanks!

 ** **

 

 ** **

 -B

 ** **

 *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
 osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Glenn Waldron
 *Sent:* Wednesday, September 28, 2011 4:40 PM

 *To:* OpenSceneGraph Users
 *Subject:* Re: [osg-users] GLSL shaders and projective texturing

 ** **

 Brad,

 I once had the same issue; calcuating my texgen matrix like this worked:**
 **

 ** **

 texGenMat =

 modelViewMat *

 projectionMat *

 osg::Matrix::translate(1, 1, 1) *

 osg::Matrix::scale(0.5, 0.5, 0.5);

 ** **


 Glenn Waldron / Pelican Mapping / @glennwaldron

 

 On Wed, Sep 28, 2011 at 7:34 PM, Brad Colbert bcolb...@rscusa.com wrote:
 

 Hi Chris,

 Thanks!  I found that one too but it still doesn't help me figure out how
 to fix the coordinates so that my projected texture renders in the center of
 the projection frustum instead of the upper right quadrant.  It's strange
 and I can't figure it out.

 -B



 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org [mailto:
 osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon'
 Hanson
 Sent: Wednesday, September 28, 2011 3:31 PM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] GLSL shaders and projective texturing

 On 9/27/2011 7:21 PM, Brad Colbert wrote:
  I am closer!

  Looks like the other example I have is FFP not GLSL. Here's a working GLSL
 implementation (not OSG) that should be relatively easy to feed with OSG
 uniforms and such:

 http://www.ozone3d.net/tutorials/glsl_texturing_p08.php#part_8

 --
 Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
 http://www.alphapixel.com/
  Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting.
 Contracting.
There is no Truth. There is only Perception. To Perceive is to Exist.
 - Xen
 ___
 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


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

[osg-users] Job offer in Gothenburg, Sweden

[Per Nordqvist]

Dear osg-users,

I'm posting a job opportunity today: Volvo Technology in Gothenburg is
looking for
a person to help us develop our in-house truck driving simulator which
is using Openscenegraph since 2008.
It's a fixed-base, 3-channel cylinder projection simulator. This job
is not only about graphics but it's certainly a
big plus if you are familiar with osg.

Note: person must work on site.

More details here:
https://xjobs.brassring.com/1033/asp/tg/cim_jobdetail.asp?jobId=227334PartnerId=25079SiteId=5171type=mailJobReqLang=1recordstart=1JobSiteId=5171JobSiteInfo=227334_5171gqid=259


Best regards,

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

Re: [osg-users] X11 cursor setting - Single- vs Multithread

[Per Nordqvist]

Hi JP,

I had similar problem on 2.8.x, your code doesn't compile for me but
have your tried
wrapping the cursor stuff with

viewer.stopThreading();
..
viewer.startThreading();

/Per

On 26 May 2011 15:40, J.P. Delport jpdelp...@csir.co.za wrote:
 Hi all,

 the attached little app crashes if I don't run it with --SingleThreaded.

 Can anyone on Linux check if the same happens for them? Also let me know
 your OSG version.

 ./test cow.osg

 thanks
 jp

 PS. adding a frame() call before the cursor change also seems to work for
 the default threading case. Not sure why.

 --
 This message is subject to the CSIR's copyright terms and conditions, e-mail
 legal notice, and implemented Open Document Format (ODF) standard. The full
 disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.


 ___
 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] Flicker in osgviewer, multiple channels

[Per Nordqvist]

Hi guys, thanks for the quick replies. My code is ported from SGI Performer
and for some
reason the predraw switching technique used to work in there.
I've tested nodemasks now and they work fine, but I suppose I could
use switches in each
of the slave cameras as well if I want the flexibility to show/hide things
on the fly.

cheers,

/Per
2009/2/26 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hi Daniel,

 This might be too simple a solution, but have you tried assigning nodemasks
 to the objects in question along with the appropriate nodemask for the
 various cameras?  The osgstereoimage example shows how this works.


 That would work too, but you run out of bits in the nodemask pretty quickly
 if you start using the node mask for such simple things. I find adding the
 objects as children of only the required cameras works well.


 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.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

[osg-users] Flicker in osgviewer, multiple channels

[Per Nordqvist]

Hello all,

Kind of a newbie question I'm afraid. I hope somebody can push me into the
right direction.

I am using osgViewer with several attached camera slaves to render multiple
overlapping views of the same scenegraph.
Now I am trying to hide an object (using a osg::Switch) in one channel and
show it in the others.
I am doing the switching in each of the cameras predraw function.
While this works in a singlethreaded setup (at a huge performance loss), it
creates chaotic flickering in any
multithreaded dito probably since I am globally altering the scenegraph from
one thread.

So, am I pushing the limits of osgViewer, do I need to switch
to compositeviewer to achive this
or is there some other way? (I am using Fedora, OSG 2.8)

Thanks in advance,

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

Re: [osg-users] Camera shaking

[Per Nordqvist]

Hi Vincent,

Just a guess:
You may want to doublecheck that actionBetweenFrames is not switching
the node which contains the update callback. That could cause all kinds
of shaking.

Regards,

/Per

2008/7/9 Vincent Bourdier [EMAIL PROTECTED]:
 Hi all,

 I have a similar problem than
 http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-June/012275.html
 but I did not succed to solve the problem...

 This is the whole problem :

 I've done a manipulator (matrix manipulator), which permit to make the
 camera follow a node.
 The node is moved by an UpdateCallback on a other node.
 The manipulator's camera position is computed in a _frame() method :

 bool MyManipulator::handle(const osgGA::GUIEventAdapter ea,
 osgGA::GUIActionAdapter us){
 [...]
 case(osgGA::GUIEventAdapter::FRAME):
 _frame();
 [...]
 }

 In the frame method, I get the world position of the node, and set the
 camera's position doing something like this :

 osg::Matrixd MyManipulator::getInverseMatrix() const{
 return
 osg::Matrixd::translate(_eye+_vCorrectionGoto)*osg::Matrixd::rotate((_rotation).inverse());
 }

 with eye = eye + node_translation

 my render loop is :

 while(!pViewer-done()  !masterKilled )
  {
  pViewer-advance();
  pViewer-eventTraversal();
  pViewer-updateTraversal();

  actionBetweenFrames(contextID); //just update some node in
 the scene graph (switch add and remove child)
  pViewer-renderingTraversals();
   }

 But when I put the camera behind a node, the camera is shaking in the axis
 translation (not allong Z axis when node is moving in XY plane)... It looks
 something must un-synchronized...

 Any idea ?

 thanks.

 Regards,

 Vincent

 ___
 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