Re: [osg-users] mygui integration (for Wang Rui)

[Nickolai Medvedev]

Oops, sorry, my mistake...
I used bad model. Everything perfectly works with others!

Thank you!

Cheers,
Nickolai

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





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

[osg-users] OT: Interest in Vulkan?

[Chris Hanson]

  Just trying to judge what degree of interest and participation there is
in Vulkan, Khronos' new next-gen API.

  Is anyone currently actually developing anything with Vulkan right now?

  FWIW, the Vulkan Programming Guide (Kessenich and Sellers) is coming
along well and i think will help a lot of people get into Vulkan. There are
some good tutorial collections out there now as well and there's starting
to be some basic libraries built to help with some things.

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

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

On 6/9/2016 9:15 AM, Robert Osfield wrote:

Hi Stuart,

On 9 June 2016 at 12:39, Stuart Mentzer  wrote:

Robert, it occurs to me that you could just do a find_library for PNG and
then, if found, add the PNG lib to the freetype plugin libraries, even if
freetype didn't actually depend on PNG. Maybe that isn't super rigorous but
linking in a library that isn't needed should be harmless. This simpler task
I can do for the freetype plugin CMakeLists.txt file if you want.

I don't feel this is appropriate.  If someone cherry picked plugins
for release then could end up with problems if they didn't copy across
png as well even though it shouldn't be needed.

With CMake you can run build tests to test if certain capabilities
work or not and then toggle settings accordingly, perhaps this might
be useful on the FreeType front.  If not then have a CMake option for
the FreeType where you can add additional libraries or toggle on the
requirement for linking to PNG.  The later is the route I'd suggest
for now.

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

Good points, Robert. I'm not the one to do this fancier CMake setup.

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

Re: [osg-users] Play 3D animated Characters in Android

[Chris Hanson]

I've used export from Maya via osgMaya. I've also tried the FBX loader with
mixed results.

On Thu, Jun 9, 2016 at 5:57 PM, Ernesto de la Cruz Guevara Ramírez <
elguev...@uci.cu> wrote:

> Hello everybody,
> I'm using OpenSceneGraph with ARToolkit in Android to produce Augmented
> Reality applications I've managed to do it with some effort and results are
> great. Now I'm want to load 3D animated characters, but I have no idea of
> how to do this. If somebody has done this or know how to do this please
> give me a hint.
>
> Thanks in advance
> Ernesto
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

[osg-users] Play 3D animated Characters in Android

[Ernesto de la Cruz Guevara Ramírez]

Hello everybody,
I'm using OpenSceneGraph with ARToolkit in Android to produce Augmented Reality 
applications I've managed to do it with some effort and results are great. Now 
I'm want to load 3D animated characters, but I have no idea of how to do this. 
If somebody has done this or know how to do this please give me a hint. 

Thanks in advance
Ernesto  

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

Re: [osg-users] mygui integration (for Wang Rui)

[Trajce Nikolov NICK]

 I don't understand you .. It works just fine for me .. Can you make a
video or provide a code that demonstrates this?

On Thu, Jun 9, 2016 at 3:49 PM, Nickolai Medvedev 
wrote:

> Actually, not everything is as good as it seemed.
> When loading large Nodes, in case of turn of the camera to it, GUI
> disappears.
>
> Cheers,
> Nickolai
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=67553#67553
>
>
>
>
>
> ___
> 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

[osg-users] [build] NVTT 3rdParty x64 libs for OSG...

[Shayne Tueller]

Hi,

I was wondering if anyone out there in OSG land has had success building the 
Nvidea texture tools version 2.0.8 using VS2013 for x64 to use with the nvtt 
plugin in the OSG.

I've set the NVTT_SHARED=1 so that the libs are built as shared libraries. All 
libraries compile just fine. However, when I compile and link the nvtt.lib, I 
get a bunch of linker errors (LNK2019 and LNK2001 unresolved external symbols) 
dealing with functions found in the nvimage library. I suspect is has something 
to do with the calling convention __cdecl when the libs are built as shared 
libs.

When I set NVTT_SHARED=0, all the libs compile and link just fine but then the 
OSG no longer builds for the obvious reasons when it tries to compile the 
nvtt-dependent plugin

If anyone can help or suggest something that will result in getting rid of the 
linker errors, that would be great.

Cheers,
Shayne

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





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

Re: [osg-users] [osg-submissions] GL3 Mac OS X needs VertexArrayObject

[Mathieu MARACHE]

it prevents annoying Warnings from Apple GL Headers
relevant part of gl3.h :

#if defined __gl_h_ && !(defined
GL_DO_NOT_WARN_IF_MULTI_GL_VERSION_HEADERS_INCLUDED)
#warning gl.h and gl3.h are both included.  Compiler will not invoke errors
if using removed OpenGL functionality.
#endif


--
nǝıɥʇɐƜ

On 9 June 2016 at 18:36, Robert Osfield  wrote:

> Hi Mathieu,
>
> Changes look like they are close to what will work.  We could stick
> with the simple object ID but I'd be inclined towards having a object
> for it so you could share objects between osg::Geometry, as we all as
> having the ability to store data such as the osg::Array associated
> with the VAO.  I haven't really thought enough about the issue yet to
> know for sure whether going the Object route is required so take this
> as me just mulling things over.
>
> What is the addition the CMakeLists.txt:
>
>   add_definitions(-DGL_DO_NOT_WARN_IF_MULTI_GL_VERSION_HEADERS_INCLUDED)
>
> For?  Is this a hint the the Apple GL headers to do something special?
>
> Robert.
>
> Robert.
>
> On 9 June 2016 at 16:40, Mathieu MARACHE 
> wrote:
> > I've finally made my mods against master branch on my clone for the
> > OpenSceneGraph repo.
> >
> >
> https://github.com/openscenegraph/OpenSceneGraph/compare/master...mathieu:feature/CoreProfileMacOSX?expand=1
> >
> > I use the example osgsimplegl3 to display files, I've added the
> > osgUtil::Optimizer to retessellate since CoreProfile doesn't do QUADS or
> > POLYGONS.
> >
> > I've hacked into Geometry only to create a VAO and bind it. If I unbind
> it I
> > don't get anything displayed with the osgsimplegl3 example.
> >
> > However this doesn't look good since only the first geometry gets
> > displayed...
> >
> > WIP
> >
> >
> > --
> > nǝıɥʇɐƜ
> >
> > On 9 June 2016 at 11:57, Mathieu MARACHE 
> wrote:
> >>
> >> Hi Robert,
> >>
> >> Indeed VAO support is needed (in obligatory sense) for Macosx Core
> Profile
> >> targets but would be useful to other platforms also since it would make
> the
> >> system more efficient.
> >>
> >> I'm putting osg-users's mailing list in copy to see if someone has more
> >> insight into VAO.
> >>
> >> I've tried to setup VAO inside Geometry and make appropriate calls when
> >> needed but fail to show more than one geometry...
> >>
> >> I was on OpenSceneGraph-3.4 branch, I will try to setup a working branch
> >> from master to show what I came up with. We can discuss on what would
> the
> >> appropriate route should be to implement this. As you mentioned it would
> >> imply osg::Geometry and maybe also osg::State modifications...
> >>
> >> Regards
> >>
> >> --
> >> nǝıɥʇɐƜ
> >>
> >> On 9 June 2016 at 09:19, Robert Osfield 
> wrote:
> >>>
> >>> Hi Mathieu,
> >>>
> >>> On 9 June 2016 at 07:44, Mathieu MARACHE 
> >>> wrote:
> >>> > I'm struggling to understand what to do. I merely put up a solution
> >>> > that was
> >>> > explained in a staled thread from 2012 (!), subject was : OpenGL 3.2
> >>> > support
> >>> > in OS X 10.7 (Lion)
> >>>
> >>> This was clearly just a hack to get things "working" not an actual
> >>> solution.
> >>>
> >>>
> >>> > I see your points, you are right this is not a general solution.
> >>> >
> >>> > I'll be reading a bit more on VAO and try to add VAO support directly
> >>> > in
> >>> > Geometry is possible...
> >>>
> >>> I would be worth just moving the discussion about VAO support to
> >>> osg-users so we can all discuss the what solution.  I'm happy to pitch
> >>> in some time to getting this resolved for 3.6.
> >>>
> >>> Right now from what I've learnt that natural place for binding the VAO
> >>> would be in osg::Geometry.  It may be that osg::State would be the
> >>> part of the OSG that does the binding as it already manages the vertex
> >>> arrays and associated buffer objects.The VAO essentially wraps up
> >>> all the vertex array settings in one place so that once it's set up
> >>> one just binds a single VAO object rather than a VBO and then specify
> >>> the individual vertex arrays within this.  In theory this should mean
> >>> the system is more efficient - as long as we get the design and
> >>> implementation right.
> >>>
> >>> Robert.
> >>> ___
> >>> osg-submissions mailing list
> >>> osg-submissi...@lists.openscenegraph.org
> >>>
> >>>
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >>
> >>
> >
> >
> > ___
> > osg-submissions mailing list
> > osg-submissi...@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >
> ___
> osg-submissions mailing list
> osg-submissi...@lists.openscenegraph.org
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>

Re: [osg-users] [osg-submissions] GL3 Mac OS X needs VertexArrayObject

[Robert Osfield]

Hi Mathieu,

Changes look like they are close to what will work.  We could stick
with the simple object ID but I'd be inclined towards having a object
for it so you could share objects between osg::Geometry, as we all as
having the ability to store data such as the osg::Array associated
with the VAO.  I haven't really thought enough about the issue yet to
know for sure whether going the Object route is required so take this
as me just mulling things over.

What is the addition the CMakeLists.txt:

  add_definitions(-DGL_DO_NOT_WARN_IF_MULTI_GL_VERSION_HEADERS_INCLUDED)

For?  Is this a hint the the Apple GL headers to do something special?

Robert.

Robert.

On 9 June 2016 at 16:40, Mathieu MARACHE  wrote:
> I've finally made my mods against master branch on my clone for the
> OpenSceneGraph repo.
>
> https://github.com/openscenegraph/OpenSceneGraph/compare/master...mathieu:feature/CoreProfileMacOSX?expand=1
>
> I use the example osgsimplegl3 to display files, I've added the
> osgUtil::Optimizer to retessellate since CoreProfile doesn't do QUADS or
> POLYGONS.
>
> I've hacked into Geometry only to create a VAO and bind it. If I unbind it I
> don't get anything displayed with the osgsimplegl3 example.
>
> However this doesn't look good since only the first geometry gets
> displayed...
>
> WIP
>
>
> --
> nǝıɥʇɐƜ
>
> On 9 June 2016 at 11:57, Mathieu MARACHE  wrote:
>>
>> Hi Robert,
>>
>> Indeed VAO support is needed (in obligatory sense) for Macosx Core Profile
>> targets but would be useful to other platforms also since it would make the
>> system more efficient.
>>
>> I'm putting osg-users's mailing list in copy to see if someone has more
>> insight into VAO.
>>
>> I've tried to setup VAO inside Geometry and make appropriate calls when
>> needed but fail to show more than one geometry...
>>
>> I was on OpenSceneGraph-3.4 branch, I will try to setup a working branch
>> from master to show what I came up with. We can discuss on what would the
>> appropriate route should be to implement this. As you mentioned it would
>> imply osg::Geometry and maybe also osg::State modifications...
>>
>> Regards
>>
>> --
>> nǝıɥʇɐƜ
>>
>> On 9 June 2016 at 09:19, Robert Osfield  wrote:
>>>
>>> Hi Mathieu,
>>>
>>> On 9 June 2016 at 07:44, Mathieu MARACHE 
>>> wrote:
>>> > I'm struggling to understand what to do. I merely put up a solution
>>> > that was
>>> > explained in a staled thread from 2012 (!), subject was : OpenGL 3.2
>>> > support
>>> > in OS X 10.7 (Lion)
>>>
>>> This was clearly just a hack to get things "working" not an actual
>>> solution.
>>>
>>>
>>> > I see your points, you are right this is not a general solution.
>>> >
>>> > I'll be reading a bit more on VAO and try to add VAO support directly
>>> > in
>>> > Geometry is possible...
>>>
>>> I would be worth just moving the discussion about VAO support to
>>> osg-users so we can all discuss the what solution.  I'm happy to pitch
>>> in some time to getting this resolved for 3.6.
>>>
>>> Right now from what I've learnt that natural place for binding the VAO
>>> would be in osg::Geometry.  It may be that osg::State would be the
>>> part of the OSG that does the binding as it already manages the vertex
>>> arrays and associated buffer objects.The VAO essentially wraps up
>>> all the vertex array settings in one place so that once it's set up
>>> one just binds a single VAO object rather than a VBO and then specify
>>> the individual vertex arrays within this.  In theory this should mean
>>> the system is more efficient - as long as we get the design and
>>> implementation right.
>>>
>>> Robert.
>>> ___
>>> osg-submissions mailing list
>>> osg-submissi...@lists.openscenegraph.org
>>>
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>>
>
>
> ___
> osg-submissions mailing list
> osg-submissi...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-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-submissions] GL3 Mac OS X needs VertexArrayObject

[Mathieu MARACHE]

I've finally made my mods against master branch on my clone for the
OpenSceneGraph repo.

https://github.com/openscenegraph/OpenSceneGraph/compare/master...mathieu:feature/CoreProfileMacOSX?expand=1

I use the example osgsimplegl3 to display files, I've added the
osgUtil::Optimizer to retessellate since CoreProfile doesn't do QUADS or
POLYGONS.

I've hacked into Geometry only to create a VAO and bind it. If I unbind it
I don't get anything displayed with the osgsimplegl3 example.

However this doesn't look good since only the first geometry gets
displayed...

WIP


--
nǝıɥʇɐƜ

On 9 June 2016 at 11:57, Mathieu MARACHE  wrote:

> Hi Robert,
>
> Indeed VAO support is needed (in obligatory sense) for Macosx Core Profile
> targets but would be useful to other platforms also since it would make the
> system more efficient.
>
> I'm putting osg-users's mailing list in copy to see if someone has more
> insight into VAO.
>
> I've tried to setup VAO inside Geometry and make appropriate calls when
> needed but fail to show more than one geometry...
>
> I was on OpenSceneGraph-3.4 branch, I will try to setup a working branch
> from master to show what I came up with. We can discuss on what would the
> appropriate route should be to implement this. As you mentioned it would
> imply osg::Geometry and maybe also osg::State modifications...
>
> Regards
>
> --
> nǝıɥʇɐƜ
>
> On 9 June 2016 at 09:19, Robert Osfield  wrote:
>
>> Hi Mathieu,
>>
>> On 9 June 2016 at 07:44, Mathieu MARACHE 
>> wrote:
>> > I'm struggling to understand what to do. I merely put up a solution
>> that was
>> > explained in a staled thread from 2012 (!), subject was : OpenGL 3.2
>> support
>> > in OS X 10.7 (Lion)
>>
>> This was clearly just a hack to get things "working" not an actual
>> solution.
>>
>>
>> > I see your points, you are right this is not a general solution.
>> >
>> > I'll be reading a bit more on VAO and try to add VAO support directly in
>> > Geometry is possible...
>>
>> I would be worth just moving the discussion about VAO support to
>> osg-users so we can all discuss the what solution.  I'm happy to pitch
>> in some time to getting this resolved for 3.6.
>>
>> Right now from what I've learnt that natural place for binding the VAO
>> would be in osg::Geometry.  It may be that osg::State would be the
>> part of the OSG that does the binding as it already manages the vertex
>> arrays and associated buffer objects.The VAO essentially wraps up
>> all the vertex array settings in one place so that once it's set up
>> one just binds a single VAO object rather than a VBO and then specify
>> the individual vertex arrays within this.  In theory this should mean
>> the system is more efficient - as long as we get the design and
>> implementation right.
>>
>> Robert.
>> ___
>> osg-submissions mailing list
>> osg-submissi...@lists.openscenegraph.org
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Community Feedback Required : What minimum CMake version should we require?

[Mathieu MARACHE]

+1 for 2.8

--
nǝıɥʇɐƜ

On 9 June 2016 at 16:59, michael kapelko  wrote:

> Hi.
> For all of my projects I use 2.8 as minimum. I remember that I started
> using CMake when it was 2.6.
> Looking at CMake release history (
> https://cmake.org/Wiki/CMake_Released_Versions ) 2.8.0 was released in
> 2009.
> Debian 6 ( https://archive.debian.net/squeeze/devel/cmake , released in
> 2011)  had 2.8.2.
> Ubuntu 12.04 LTS Precise (
> http://packages.ubuntu.com/search?keywords=cmake=names=precise=all
> , released in 2012 and supported up to 2017) had 2.8.7.
> For Windows and OS X it's easy to download the most up-to-date version.
>
> So I suggest using 2.8 as minimum. Distros that was released in 2012 and
> after are definitely covered.
>
> 2016-06-08 23:49 GMT+07:00 Robert Osfield :
>
>> Hi All,
>>
>> We have various optional script paths in our CMake build system to try
>> and keep things working on older CMake versions, the minimum currently
>> is set in OpenSceneGraph/CMakeLists.txt:
>>
>> 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)
>>
>>
>> This bit of script is ancient though, something coded in when we first
>> added CMake build system.  Fast forward today, can we up the require
>> version to 2.6?  2.8?
>>
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Use of getCameraContainingPosition in OSG 3.4.0 (deprecated?)

[Rick Irons]

Hi Robert,

Thank you for the clarifications.

Regards,
Rick

-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, June 8, 2016 10:54 AM
To: OpenSceneGraph Users 
Cc: Xing Gao 
Subject: Re: [osg-users] Use of getCameraContainingPosition in OSG 3.4.0 
(deprecated?)

Hi Rick.

I deprecated the function as the interpretation of how it should behave is 
ambiguous for certain combinations of viewer Camera set up - it simply can't 
guarantee to give the correct camera and x,y location that you might be 
expecting as the interface doesn't provide enough information for the function 
to work correctly in all cases as it has to make assumptions for this missing 
data.  For simple viewers you won't hit up against this but as you add more 
complex set ups set as multiple overlapping cameras/distortion correction etc. 
exactly how a mouse coordinate maps can varying widely.

The resolve the task of where a mouse coordinate maps osgGA::GUEventAdapter now 
"has a" stack of  PointerData that hold how the coordinate maps to the 
successive camera's in the stake.  If you look at View you'll now see 
computeIntersections(..) methods that take the GUIEventAdapter object directly 
rather than the orphaned x,y mouse cooridnates.  This extra information enables 
the intersection traversal correctly.

The PonterData holds the Camera information, if you look at the
View::computeIntersections(..) methods you'll see how it's used:

bool View::computeIntersections(const osgGA::GUIEventAdapter& ea, 
osgUtil::LineSegmentIntersector::Intersections&
intersections,osg::Node::NodeMask traversalMask) { #if 1
if (ea.getNumPointerData()>=1)
{
const osgGA::PointerData* pd =
ea.getPointerData(ea.getNumPointerData()-1);
const osg::Camera* camera = pd->object.valid() ?
pd->object->asCamera() : 0;
if (camera)
{
return computeIntersections(camera, 
osgUtil::Intersector::PROJECTION, pd->getXnormalized(),
pd->getYnormalized(), intersections, traversalMask);
}
}
#endif
return computeIntersections(ea.getX(), ea.getY(), intersections, 
traversalMask); }

The old code is still there as a fallback, the new bit is in the #if 1 #endif 
block.

I realise this will seem like an extra level of complexity, but for most users 
they shouldn't be using the getCameraContainingPosition() method directly and 
won't need to look at the PointerData either.
What the PointerData gives you is a robust way of getting the mouse position 
relative to the active cameras.

Robert.







Robert.

On 8 June 2016 at 15:34, Rick Irons  wrote:
> Hi,
>
>
>
> We are working on updating an application from OSG 3.0.1 to 3.4.0.  We 
> have previously relied on getCameraContainingPosition() for selection, 
> but now we are noticing that the function is marked as deprecated.  
> Can someone identify the deprecation plan for this API?  Is it still 
> safe to use with the understanding that it will not be available in a 
> future release?  Or, should we stop using the function now?  Our 
> efforts to locate information on the deprecation of this API have not been 
> successful.
>
>
>
> I am asking since the function is not behaving as expected following 
> our update.  It is not clear if this behavior is due to the function 
> no longer being supported or if some changes on our end are necessary 
> to use the 3.4.0 version of the API.
>
>
>
> Thanks for any help you can offer.
>
>
>
> Rick
>
>
> ___
> 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] Community Feedback Required : What minimum CMake version should we require?

[michael kapelko]

Hi.
For all of my projects I use 2.8 as minimum. I remember that I started
using CMake when it was 2.6.
Looking at CMake release history (
https://cmake.org/Wiki/CMake_Released_Versions ) 2.8.0 was released in 2009.
Debian 6 ( https://archive.debian.net/squeeze/devel/cmake , released in
2011)  had 2.8.2.
Ubuntu 12.04 LTS Precise (
http://packages.ubuntu.com/search?keywords=cmake=names=precise=all
, released in 2012 and supported up to 2017) had 2.8.7.
For Windows and OS X it's easy to download the most up-to-date version.

So I suggest using 2.8 as minimum. Distros that was released in 2012 and
after are definitely covered.

2016-06-08 23:49 GMT+07:00 Robert Osfield :

> Hi All,
>
> We have various optional script paths in our CMake build system to try
> and keep things working on older CMake versions, the minimum currently
> is set in OpenSceneGraph/CMakeLists.txt:
>
> 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)
>
>
> This bit of script is ancient though, something coded in when we first
> added CMake build system.  Fast forward today, can we up the require
> version to 2.6?  2.8?
>
> 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] mygui integration (for Wang Rui)

[Nickolai Medvedev]

Actually, not everything is as good as it seemed.
When loading large Nodes, in case of turn of the camera to it, GUI disappears.

Cheers,
Nickolai

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





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

Re: [osg-users] nVidia HW: Lens Matched Shading, Single Pass Stereo - exposed in OpenGL?

[Sebastian Messerschmidt]

Hi,

Hi Christian,
I have the Single Pass Stereo working with ARB_viewport_array and and 
a shader (attached). The required support for GL_ARB_viewport_array is 
on the osg-submissions list. I have not done any work on the culling 
yet, as the eyes are sufficiently close together to get a decent 
impression of performance. bringing in light render passes would 
probably require a smart adaptation of the cull frustum.
The nvidia stereo_view_rendering seems to be to limiting for my 
purposes, as I think it requires the display to be aligned with the 
eyes, and we are working with head-tracked systems where the user is 
able to rotate their head.
The big deal about this extension is that the vertex and geometry shader 
isn't invoked twice. This might quite save a bit if you are limited at 
the those stages. But thank you for the example.


Cheers
Sebastian


Regards, Laurens.
in the vertex shader do:
gl_Position = gl_ModelViewMatrix * gl_Vertex;
instead of
gl_Position   = gl_ModelViewProjectionMatrix * gl_Vertex;
For the rest of the shaders I rely on the osg shadergenerator with 
base shaders from osg-data.
new osg::Shader(osg::Shader::GEOMETRY, "#version 450\n" "#extension 
GL_ARB_gpu_shader5 : enable\n" "layout (triangles, invocations = 2) 
in;" "layout (triangle_strip, max_vertices = 3) out;" "uniform mat4 
transform_block[2];" "in vec4 vbasecolor[];" "in vec2 vtexcoord[];" 
"out vec4 basecolor;" "out vec2 texcoord;" "out int gl_Layer;" "void 
main(void) {" " for (int i = 0; i < gl_in.length(); i++)" " {" " 
basecolor = vec4(1,1,1,1);" " texcoord = vtexcoord[i];" " gl_Position 
= transform_block[gl_InvocationID] * gl_in[i].gl_Position;" " 
gl_ViewportIndex = gl_InvocationID;" " EmitVertex();" " }" " 
EndPrimitive();" "}" );


On Thu, Jun 9, 2016 at 1:24 PM, Sebastian Messerschmidt 
> wrote:



Hi Christian

Hi all,

has anybody looked at these new features of nVidia hardware?

Lens Matched Shading and Single Pass Stereo are using new
hardware and driver features that allow the GPU to perform
single pass transform+shading of up to 16 independent view
matrices.

Isn't the change-set of single pass stereo
(https://www.opengl.org/registry/specs/NV/stereo_view_rendering.txt)
shader only?
So basically we need the NV_viewport_array2 support on the
osg-side to implement it.
Btw.: How is the relationship between viewports and bound FBOs for
instance? Suppose I need to render to different MRTs for each
viewport? Can anyone point to a good example here?


This could accelerate OSG's stereo rendering, provided that
the features are exposed thorugh documented OpenGL extensions.

Also rendering of cubemaps for reflections and shadows could
be greatly accelerated (six views in one pass).

That would require some deeper changes in the culling/camera-setup
I suppose, as multiple frusta have to be taken into account per
draw-invocation.


Christian

Cheers
Sebstian
___
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] freetype build support on Windows

[Robert Osfield]

Hi Stuart,

On 9 June 2016 at 12:39, Stuart Mentzer  wrote:
> Robert, it occurs to me that you could just do a find_library for PNG and
> then, if found, add the PNG lib to the freetype plugin libraries, even if
> freetype didn't actually depend on PNG. Maybe that isn't super rigorous but
> linking in a library that isn't needed should be harmless. This simpler task
> I can do for the freetype plugin CMakeLists.txt file if you want.

I don't feel this is appropriate.  If someone cherry picked plugins
for release then could end up with problems if they didn't copy across
png as well even though it shouldn't be needed.

With CMake you can run build tests to test if certain capabilities
work or not and then toggle settings accordingly, perhaps this might
be useful on the FreeType front.  If not then have a CMake option for
the FreeType where you can add additional libraries or toggle on the
requirement for linking to PNG.  The later is the route I'd suggest
for now.

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

Re: [osg-users] [build] 64 bit 3rdParty libs

[Shayne Tueller]

The nvtt plugin in the OSG uses it. Other apps use it as well that use the OSG 
such as VirtualPlanetBuilder and osgEarth.

I did find the link you provided for the source for the nvidia texture tools 
but I haven't had luck in getting them built. I'm getting a bunch of linker 
errors when trying to build the libs using VS2013.

Thanks for your feedback.

Shayne

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





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

Re: [osg-users] freetype build support on Windows

[Stuart Mentzer]

Robert, it occurs to me that you could just do a find_library for PNG and then, 
if found, add the PNG lib to the freetype plugin libraries, even if freetype 
didn't actually depend on PNG. Maybe that isn't super rigorous but linking in a 
library that isn't needed should be harmless. This simpler task I can do for 
the freetype plugin CMakeLists.txt file if you want.

Stuart

On 6/8/2016 1:42 AM, Stuart Mentzer wrote:

Hi Robert,

If we do this in FindFreetype.cmake it will prevent us from using CMake's 
version (once the patch goes in). So that means doing it in the CMakeLists.txt 
for the freetype plugin. Anyway, I don't know enough CMake to find another 
package's dependencies (something with pkg_config maybe?) but I'm sure someone 
here has done this before.

Stuart

On 6/6/2016 3:37 AM, Robert Osfield wrote:

Hi Stuart,

I believe it should be possible to have the FindFreetype.cmake detect
that PNG is used and create an additional libraries var or just add it
into FREETYPE_LIBRARIES var.  Have a look at how the other Free*.cmake
modules handle extra dependencies that need to be linked in.  If this
is done right it should be possible to have the OSG's freetype plugin
to work without any special manual settings to add the PNG dependency.

Robert.

On 5 June 2016 at 22:51, Stuart Mentzer  wrote:

Hi Robert,

OK, I am testing a patched FindFreetype.cmake with OSG now. If that works
I'll submit it to CMake and to OSG. If it is better to post it to the
osg-submissions list rather than here I can do that but it is then separate
from the context of this discussion.

It doesn't seem practical for us to fix freetype but I'll file a suggestion
with them to reconsider this build approach. For now, with a wiki note on
refreshing the source, the only freetype improvement we can benefit from is
making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other
freetype optional libs?) to the target libraries if needed. I don't know
enough CMake yet to do that automatically and adding a variable to pass to
the cmake call seems like cruft. If OSG has no benefit from PNG support in
freetype then a note not to enable it is probably the way to go.

Cheers,
Stuart


On 6/5/2016 7:41 AM, Robert Osfield wrote:

HI Stuart,

It sounds like taking the CMake FindFreetype.cmake modifying to work
and then getting this checked over by the cmake community as being
suitable for them to merge and then sending the final rev along to me
to merge would enable us to roll out the improved support prior to the
next CMake release.  If the CMake release is made before we push out
3.6 then we wouldn't need to add it locally.

With the freetype wiring to PNG+ZLIB, this sounds like the could
improve things with their own source/build system.  I don't know
freetype well enough to know how easy it would be to fix things to
make it easier to switch.  This type of issue is why the OSG has
plugins and NodeKits - the core libraries are kept with minimal
dependencies, this way the dependency chain doesn't pollute anything
more than it needs to.

Robert.



On 5 June 2016 at 02:35, Stuart Mentzer  wrote:

Hi Robert,

I have asked the CMake community about updating their FindFreetype.cmake
to
support Windows debug library naming and I will follow up to try and get
that fixed in upcoming releases. I was pointed to how they do it
correctly
for zlib so I could make a variant of their FindFreetype.cmake for OSG to
use until their fix is released. This would retain their support for the
old
and new include structure. If you'd like me to submit that let me know.

Wrt the PNG on/off issue, I now understand the approach they use. The
upshot
is that as long as you refresh the freetype source tree you are building
with from the original code before each build you can switch PNG support
on
or off in the cmake command with -DWITH_PNG=ON or OFF and without
manually
editing ftoption.h. (Same holds for ZLIB support.) The reason is that the
build goes in and modifies ftoption.h in the source tree (as well as
making
a copy in the build tree) and the modification only uncomments those
defines, so you can't build with PNG enabled and then PNG disabled
without
refreshing the source first. This is an unfortunate approach but that is
what we are stuck with. Most builders don't switch the PNG or ZLIB
support
on and off so this probably doesn't often trip people up. The best we can
probably do is add a note on an appropriate wiki page. I added this
refresh
step to my build scripts.

Stuart

On 6/4/2016 3:36 PM, Robert Osfield wrote:

Hi Stuart,

It sounds like the version of Freestyle is broken or it requires a tweak
to
configuration. Have you approached the freetype community about these
issues.

The debug vs release issue is something that would be worth raising with
the
cake community as it sounds like a revision to their Findfreetype.cmake.

Robert

On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" 

Re: [osg-users] nVidia HW: Lens Matched Shading, Single Pass Stereo - exposed in OpenGL?

[Sebastian Messerschmidt]

Hi Christian

Hi all,

has anybody looked at these new features of nVidia hardware?

Lens Matched Shading and Single Pass Stereo are using new hardware and 
driver features that allow the GPU to perform single pass 
transform+shading of up to 16 independent view matrices.
Isn't the change-set of single pass stereo 
(https://www.opengl.org/registry/specs/NV/stereo_view_rendering.txt) 
shader only?
So basically we need the NV_viewport_array2 support on the osg-side to 
implement it.
Btw.: How is the relationship between viewports and bound FBOs for 
instance? Suppose I need to render to different MRTs for each viewport? 
Can anyone point to a good example here?




This could accelerate OSG's stereo rendering, provided that the 
features are exposed thorugh documented OpenGL extensions.


Also rendering of cubemaps for reflections and shadows could be 
greatly accelerated (six views in one pass).
That would require some deeper changes in the culling/camera-setup I 
suppose, as multiple frusta have to be taken into account per 
draw-invocation.


Christian

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

Re: [osg-users] MSVS2015 3rdparty build

[Björn Blissing]

memory_leak wrote:
> I have built everything for x64, both release and debug to be honest I didn't 
> even tryed x86. And as said before, VS 2015 CE. 
> 
> By the way, it might be that you have strings.h defined as a dummy or some 
> port elsewhere in your include path. It is an old *nix file and is not 
> impossible that you got it with some other project. I reinstalled windows 
> like day before I did build, so I have built on pretty clean system.


Tried this a minute ago. I do not get the same warning for giflib (the missing 
strings.h warning). 

I did a web search for the problem and found this blog post from Microsoft:
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

So these libraries are now installed separately, which I must have done. But it 
is strange that your compiler only complains about string.h. There are other 
header files used in giflib which also are included from the universal CRT 
folder. It should complain about all the others as well.

Anyhow, maybe we should change something to make this work on a clean installed 
machine (i.e. Visual Studio only). Or at least write something in the readme 
that the universal CRT are required to build giflib.


memory_leak wrote:
> Regarding curl, is it really worth putting time & effort if it anyway builds 
> just fine with build file supplied by curl itself. It is just a matter of 
> executing cmake. Just my $0.02  as people from usa put it.


Building cUrl or any of the other dependencies manually is always an option. 
But my goal was to automate the most common dependencies. Original I did not 
include cUrl, but as it was sent to me as a working pull request I saw no 
problem with including it. But of course if any of the libraries start to be 
hard to maintain I may be forced to remove them.

Regretfully it is not an option to just link to the CMake file inside the cUrl 
project. That CMake file expects cUrl to be the only project, so it would not 
work if included inside the osg-3rdparty-cmake scripts. Maybe it could be done 
using some form of custom target script, but that is something I do not have 
time to write just now. But I would gladly merge any Pull Request which offered 
this functionality. 

Regards
Björn

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





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

Re: [osg-users] Setting up travis for OSG in github

[Jordi Torres]

Already done it. :).

2016-06-09 12:23 GMT+02:00 Robert Osfield :

> Hi Joridi.
>
> On 9 June 2016 at 11:20, Jordi Torres  wrote:
> > Ok, fixed it, this is how it should look like
> > https://github.com/jtorresfabra/osg/tree/changeReadmeToMD. Note the
> badge is
> > working and showing buld-passing icon.
>
> Looks good, go head a create a pull request :-)
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Setting up travis for OSG in github

[Robert Osfield]

Hi Joridi.

On 9 June 2016 at 11:20, Jordi Torres  wrote:
> Ok, fixed it, this is how it should look like
> https://github.com/jtorresfabra/osg/tree/changeReadmeToMD. Note the badge is
> working and showing buld-passing icon.

Looks good, go head a create a pull request :-)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Setting up travis for OSG in github

[Jordi Torres]

Ok, fixed it, this is how it should look like
https://github.com/jtorresfabra/osg/tree/changeReadmeToMD. Note the badge
is working and showing buld-passing icon.

2016-06-09 12:11 GMT+02:00 Jordi Torres :

> Oh,
> I just realized that we are using Readme.txt instead of Readme.md (
> markdown ). That's why it is not showing the badge correctly. Let me fix
> that one chaning the file to markdown.
>
> Sorry for the inconvenience.
>
> 2016-06-09 12:02 GMT+02:00 Robert Osfield :
>
>> Hi Jordi,
>>
>> On 9 June 2016 at 10:53, Jordi Torres  wrote:
>> > Great, so now we have continuous integration and it can be checked in
>> > https://travis-ci.org/openscenegraph/OpenSceneGraph . I just created a
>> PR to
>> > add the status label to github site. And it seems it is working so far
>> > because it started a build with my last PR :).
>>
>> I have just merged the change but the result is just a link rather
>> than an embedded icon.  When I click on the link I don't get anything
>> useful - just a build|unkown icon in the top left of the window.
>>
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
>
> --
> Jordi Torres
>
>
>


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

Re: [osg-users] Setting up travis for OSG in github

[Jordi Torres]

Oh,
I just realized that we are using Readme.txt instead of Readme.md (
markdown ). That's why it is not showing the badge correctly. Let me fix
that one chaning the file to markdown.

Sorry for the inconvenience.

2016-06-09 12:02 GMT+02:00 Robert Osfield :

> Hi Jordi,
>
> On 9 June 2016 at 10:53, Jordi Torres  wrote:
> > Great, so now we have continuous integration and it can be checked in
> > https://travis-ci.org/openscenegraph/OpenSceneGraph . I just created a
> PR to
> > add the status label to github site. And it seems it is working so far
> > because it started a build with my last PR :).
>
> I have just merged the change but the result is just a link rather
> than an embedded icon.  When I click on the link I don't get anything
> useful - just a build|unkown icon in the top left of the window.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Setting up travis for OSG in github

[Robert Osfield]

Hi Jordi,

On 9 June 2016 at 10:53, Jordi Torres  wrote:
> Great, so now we have continuous integration and it can be checked in
> https://travis-ci.org/openscenegraph/OpenSceneGraph . I just created a PR to
> add the status label to github site. And it seems it is working so far
> because it started a build with my last PR :).

I have just merged the change but the result is just a link rather
than an embedded icon.  When I click on the link I don't get anything
useful - just a build|unkown icon in the top left of the window.

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

Re: [osg-users] [osg-submissions] GL3 Mac OS X needs VertexArrayObject

[Mathieu MARACHE]

Hi Robert,

Indeed VAO support is needed (in obligatory sense) for Macosx Core Profile
targets but would be useful to other platforms also since it would make the
system more efficient.

I'm putting osg-users's mailing list in copy to see if someone has more
insight into VAO.

I've tried to setup VAO inside Geometry and make appropriate calls when
needed but fail to show more than one geometry...

I was on OpenSceneGraph-3.4 branch, I will try to setup a working branch
from master to show what I came up with. We can discuss on what would the
appropriate route should be to implement this. As you mentioned it would
imply osg::Geometry and maybe also osg::State modifications...

Regards

--
nǝıɥʇɐƜ

On 9 June 2016 at 09:19, Robert Osfield  wrote:

> Hi Mathieu,
>
> On 9 June 2016 at 07:44, Mathieu MARACHE 
> wrote:
> > I'm struggling to understand what to do. I merely put up a solution that
> was
> > explained in a staled thread from 2012 (!), subject was : OpenGL 3.2
> support
> > in OS X 10.7 (Lion)
>
> This was clearly just a hack to get things "working" not an actual
> solution.
>
>
> > I see your points, you are right this is not a general solution.
> >
> > I'll be reading a bit more on VAO and try to add VAO support directly in
> > Geometry is possible...
>
> I would be worth just moving the discussion about VAO support to
> osg-users so we can all discuss the what solution.  I'm happy to pitch
> in some time to getting this resolved for 3.6.
>
> Right now from what I've learnt that natural place for binding the VAO
> would be in osg::Geometry.  It may be that osg::State would be the
> part of the OSG that does the binding as it already manages the vertex
> arrays and associated buffer objects.The VAO essentially wraps up
> all the vertex array settings in one place so that once it's set up
> one just binds a single VAO object rather than a VBO and then specify
> the individual vertex arrays within this.  In theory this should mean
> the system is more efficient - as long as we get the design and
> implementation right.
>
> Robert.
> ___
> osg-submissions mailing list
> osg-submissi...@lists.openscenegraph.org
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Setting up travis for OSG in github

[Jordi Torres]

Hi Robert,

Great, so now we have continuous integration and it can be checked in
https://travis-ci.org/openscenegraph/OpenSceneGraph . I just created a PR
to add the status label to github site. And it seems it is working so far
because it started a build with my last PR :).

Thanks.


2016-06-08 17:27 GMT+02:00 Robert Osfield :

> Hi Jordi,
>
> On 3 June 2016 at 12:49, Jordi Torres  wrote:
> > I just sent a PR for adding travis for trusty and OSX builds. It could be
> > improved adding missing dependencies like gdal, etc. to the apt/brew
> > section.
>
> Now merged.
>
> > Once you logged in to travis and set it up for the osg github repo ( it's
> > only a few steps ), it will automatically search for the .travis.yml file
> > and start to make builds on each pull request or push.
>
> Now done:
>
> https://travis-ci.org/profile/openscenegraph
>
> > You can also add a status label to the repo website to know if the build
> is
> > passing (https://docs.travis-ci.com/user/status-images/).
>
> Just had a quick read through, not sure what I'm supposed to be copy
> and placing where yet...
>
> I've got lots of other work to get on with so learning all about
> Travis and setting things up is just one item among many.  I'd welcome
> others chipping in and driving what needs to be done.
>
> I believe we also have the opportunity to link up Travis to the
> Coverity scan of the OSG, again this ain't my area of expertise so
> happy for others to move things along in the right direction.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

[osg-users] nVidia HW: Lens Matched Shading, Single Pass Stereo - exposed in OpenGL?

[Christian Buchner]

Hi all,

has anybody looked at these new features of nVidia hardware?

Lens Matched Shading and Single Pass Stereo are using new hardware and
driver features that allow the GPU to perform single pass transform+shading
of up to 16 independent view matrices.

This could accelerate OSG's stereo rendering, provided that the features
are exposed thorugh documented OpenGL extensions.

Also rendering of cubemaps for reflections and shadows could be greatly
accelerated (six views in one pass).

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

Re: [osg-users] [build] 64 bit 3rdParty libs

[Konstantin Podsvirov]

Interesting!8:32, 9 june 2016 г., Shayne Tueller :This does not help me.Sorry. I need the Nvidia texture tools 64bit dependency which is not available on your website. I already have all the other 64 bit dependencies needed to build OSG 64bit. I'm just missing the Nvidia texture tools.Since no one has any input on this, the next step is to try and build them myself from source. I'm sure this will be an ugly mess...Sometimes we need build other code ;-)I found this link:https://github.com/castano/nvidia-texture-toolsWhat part of OSG use It?Shayne--Read this topic online here:http://forum.openscenegraph.org/viewtopic.php?p=67520#67520
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org