Re: [osg-users] [ANN] Job Opportunity: Research Engineer - Visualization and Driving Simulation

[Björn Blissing]

The submission e-mail address was apparently cut from the previous message.

If you want to apply for the above position via e-mail, send your application 
including cv and other documentation you see as relevant to:
vti(at)vti.se

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





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

[osg-users] [ANN] Job Opportunity: Research Engineer - Visualization and Driving Simulation

[Björn Blissing]

VTI, the Swedish national road and transport research institute, is an 
independent and internationally prominent research institute in the transport 
sector. VTI has a total of some 200 employees. VTI’s head office is in 
Linköping, with offices in Stockholm, Gothenburg, Borlänge and Lund.
We are now employing a research engineer to the research unit "Driving 
Simulation and Visualization" in Linköping.

About the job

VTI puts a lot of effort in developing new methods and tools for research in 
future transport systems on road and rail. A part of this is to use simulators 
for road vehicles, trains and railways, bicycles and pedestrians, as well as 
the visualization of traffic environments. We are now looking for you, who can 
strengthen us in this work, and is enthusiastic about developing virtual- and 
simulation methods to be applied in the research in future transport systems.

As a research engineer you will work in research projects with simulation and 
visualization as your main methods and tools, and to develop these to meet the 
research needs. Also, work with other types of equipment could be possible, 
such as test vehicles and proving grounds. The position as a research engineer 
involves:
• Software development, both programming and systemization in our different 
driving simulators
• Development of novel applied simulators and methods
• Keep in contact with our customers and research partners

There are many activities in Sweden targeting the future transport system. At 
VTI we are addressing the challenges in traffic safety, automatization, 
electrification, connectivity and digitalization of transports on road and rail.

Recently we have also developed simulators for bicycle and pedestrian in order 
to broaden the scope of road users. Our simulators are located in Linköping and 
Gothenburg, and are some of the most advanced driving simulators in the world. 
We use them in order to develop and test future vehicles and traffic 
environments so that they will be safe and attractive to use and operate. Our 
research partners, among others, are vehicle manufacturers, international 
research partners and public organizations. We are also developing simulators 
for special purposes such as for education of train drivers and evaluation of 
driving ability due to medical conditions.

You profile

You are a MSc in Computer Science & IT or equivalent, senior or newly 
graduated. Your majors are software development, computer graphics, signals 
and/or control science. You have training and experience in object oriented 
programming in C++.

Seen as a merit:
• Experience from the automotive industry – e.g. CAN network, Autosar, ISO 26262
• Experience from the gaming industry – e.g. Unity3D, Unreal engine
• Development of embedded systems
• Development using the Qt framework
• Knowledge of Matlab/Simulink
• Experience of driving simulators

In your work you will meet with many customers, test participants, research 
partners and researchers. Therefore, you have good communication skills and is 
a good team player, but you can also take own initiatives.

Application

Welcome to send in your application including cv and other documentation you 
see as relevant. 
Mark the application ”Forskningsingenjör Visualisering dnr. 2019/0212-3.1” and 
send it to:

VTI
Personalenheten
581 95 Linköping
SWEDEN 

or per e-mail to .

Last application date is August 5, 2019.

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





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

Re: [osg-users] [forum] Android can't build osgdb_png

[Björn Blissing]

Hi,

I have no experience of this myself. But have you checked out Michael Kapelko's 
Android tutorials?

https://github.com/OGStudio/openscenegraph-cross-platform-guide/tree/master/1.8.SampleUnderAndroid

Regards,
Björn

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





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

Re: [osg-users] How to setup Msvcp2013 so that header files show syntax highlighting

[Björn Blissing]

Hi,

The correct procedure is described in the following file in the source 
directory: 

https://github.com/openscenegraph/OpenSceneGraph/blob/master/PlatformSpecifics/Windows/VisualStudio_Syntax_Highlighting.txt


Regards,
Björn

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





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

Re: [osg-users] Build error under Windows? Need feedback from Windows users to understand issue

[Björn Blissing]

Hi Robert,

I have previously built it using Visual Studio 2017 without problems.

One thing to note is that the user who opened the pull request says he is using 
Visual Studio version 15.8. This is a version not yet available outside the 
beta program. The latest stable version available for me is 15.7.4. This might 
be the reason for his compiler error and also why no one have reported this 
earlier.

Regards,
Björn

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





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

Re: [osg-users] C++11 for next stable release of OpenSceneGraph?

[Björn Blissing]

I am also in total support to move to C++11.

I am even inclined to favor moving all the way to C++17, which includes some 
nice features (my favorite being allowing initializers in if and switch 
statements). And even Visual Studio is somewhat conformant:
https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/

Regards
Björn

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





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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Björn Blissing]

robertosfield wrote:
> 
> For the OpenSceneGraph, the VulkanSceneGraph I aspire to be a Stardard
> C++ library for real-time graphics.


In my mind (and I also think the general convention is that) the extensionless 
headers are reserved for libraries accepted into the STL by the ISO committee. 
Before that they should stick to .h or .hpp. This is also the process that the 
libraries which originated in boost use, i.e. they used .hpp while being part 
of boost and then removed the extension once they were accepted by the ISO 
committee. 

The boost FAQ answers the question like this:
Why do Boost headers have a .hpp suffix rather than .h or none at all? 
File extensions communicate the "type" of the file, both to humans and to 
computer programs. The '.h' extension is used for C header files, and therefore 
communicates the wrong thing about C++ header files. Using no extension 
communicates nothing and forces inspection of file contents to determine type. 
Using '.hpp' unambiguously identifies it as C++ header file, and works well in 
actual practice. 


robertosfield wrote:
> Really the answer is pretty simple, Visual Studio clearly isn't up to the 
> job... the fact that MS haven't yet fixed this in over two decades doesn't 
> validate that it's not broken.  MS over the years has tried hard to make C++ 
> a pain in the butt to use under Windows.  I can't fix
> what MS choose to do, but also have no desire for bugs in 3rd party tools to 
> dictate decisions on code I personally write, I want code that aspires to 
> something more than lowest common denominators.


Well, Visual Studio is not the only IDE with these types of problems with 
extensionless headers. Other IDEs and other tools suffer the same problem. So 
the assumption that extensionless headers are reserved for ISO standardized 
libraries seems to be persistent outside MS as well.

Also simple file pattern matching in the console is much simpler when the 
header do have a file suffix.

So in my mind these are reasons enough to stick to headers with some form of 
standard file extension, at least if beauty and future aspirations are the only 
counter arguments. 

But once again, the decision is up to you. And we Visual studio developers will 
adapt and overcome, as we always have done. :)

Best regards,
Björn

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





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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Björn Blissing]

robertosfield wrote:
> 
> 
> > And maybe this time we will get header files with the .h extension. ;)
> > 
> 
> Maybe, no decisions made yet, but I'm also not polling for opinions,
> the VulkanSceneGraph isn't a design by committee.
> 
> My initial code experiments have .hpp but frankly it's ugly as hell as
> well as stupid - there's no header plus plus language so I'm rapidly
> tiring of .hpp. Code should to be a thing of beauty not some ugly
> kludge.  .h makes sense as it's a header, .cpp makes sense for source
> files as it's C++. 


The ISO cpp guidelines recommend using .h for headers and .cpp for source:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-file-suffix


robertosfield wrote:
> However, public headers are placed into include
> directories and that's their role, we know they are headers because
> that's why we put them there, so the .h should be superfluous for
> public headers and the standard C++ headers illustrate this.  If 3rd
> party tools/editors can't even handle the extension less C++ standard
> library headers then they aren't really up to the job.
> 


As a Visual Studio user I do disagree (since Visual Studio really seems to 
dislike extensionless headers). But I also recognize that the decision is your 
prerogative to make as creator. 

Regards,
Björn

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





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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Björn Blissing]

Hi Robert,

Very exciting news!

I do not have any strong opinions on the Vulcan parts. But I do have some 
wishes since this project is starting from scratch:

1. Use modern CMake - this will make the project much easier to use.

2. Minimize external dependencies - Preferably the project should be able to be 
used without any external dependencies included at all. 

3. Try to follow the ISO-cpp guidelines as close as possible - This will ensure 
a consistent style when used together with other modern c++ programs. This will 
also help when using static code analysis tools.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md


And maybe this time we will get header files with the .h extension. ;)

Best regards,
Björn

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





___
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

[Björn Blissing]

I am currently building OSG and our application as 64-bit on Visual Studio 2017 
(version 15.7.2). 

Regarding the rest of the community. I noticed today that the link between the 
forum and the mailinglist have been down. 
I have gotten the emails, but I have not seen them on the forum. Until this 
mail which is available at the forum as well.

Regards
Björn



>-Original Message-
>From: osg-users <osg-users-boun...@lists.openscenegraph.org> On Behalf Of
>Robert Osfield
>Sent: Friday, May 25, 2018 1:31 PM
>To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
>Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 7
>
>Hi All,
>
>On 24 May 2018 at 10:36, Björn Blissing <bjorn.bliss...@vti.se> wrote:
>> Just tested this tag on our driving simulator software without problems.
>
>Thanks for the testing Björn, good to hear that rc7 is working well
>for you.  What platforms are you testing on?
>
>I wee reminder to the rest of the community, I'm waiting on feedback
>on testing of 3.6.1-rc7 across a range of build platforms and
>applications.  Once it looks like things are working well across the
>main platforms I'll go ahead and tag the 3.6.1 stable release.
>
>Thanks for your help,
>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] OpenSceneGraph-3.6.1 release candidate 7

[Björn Blissing]

Just tested this tag on our driving simulator software without problems.

Regards
Björn

>-Original Message-
>From: osg-users  On Behalf Of
>Robert Osfield
>Sent: Wednesday, May 23, 2018 8:59 PM
>To: OpenSceneGraph Users 
>Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 7
>
>Hi All,
>
>And around we go again!! Release candidate 7:
>
>
>https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGrap
>h-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] OpenSceneGraph-3.6.1 release candidate 6 tagged

[Björn Blissing]

Hi,

I haven't been able to test the previous release candidates. But I do have some 
troubles reading some of my osgb files. These files work with osg 3.5.9 but 
currently gives a lot of the following warnings and then fails:


...
InputIterator::checkStream() : _in->rdstate() 2, 2
   _in->tellg() = -1
InputIterator::checkStream() : _in->rdstate() 2, 2
   _in->tellg() = -1
InputIterator::checkStream() : _in->rdstate() 2, 2
   _in->tellg() = -1
Error reading file testfile.osgb: read error (InputStream: Failed to read from 
stream. At osg::Group osg::Group osg::Geode osg::Drawable osg::StateSet 
osg::Texture2D )
osgviewer: No data loaded
==

Compiled as 64bit using Visual Studio 2017 15.7.2 

I cannot share these files publicly, but I could probably send a file via some 
form of private channel if Robert want to have a look. (The above file is 
~100mb).

Best regards
Björn

>-Original Message-
>From: osg-users  On Behalf Of
>Robert Osfield
>Sent: Tuesday, May 22, 2018 8:40 AM
>To: OpenSceneGraph Users 
>Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 6 tagged
>
>Hi All,
>
>More testing uncovered more issues to fix, these are now fixed so time
>for yet another release candidate :-)
>
>
>https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGrap
>h-3.6.1-rc6
>
>Please test and let us know of success or failure.  I can't imagine
>there is much left to fix, surely but only more testing will let
>us know.
>
>My plan is tag 3.6.1 this week, if rc6 looks good then I'll tag it tomorrow.
>
>Cheers,
>Robert.
>
>-- ChangeLog since rc5
>
>Mon, 21 May 2018 13:26:04 -0400
>Author : gwaldron
>osgText: perform pixel size computation in double-precision to prevent
>coordinate jitter
>
>Mon, 21 May 2018 18:14:18 +0100
>Author : Robert Osfield
>Moved the rotation to before the scale
>
>Mon, 21 May 2018 13:18:29 +0100
>Author : Robert Osfield
>Fixed typos
>
>Mon, 21 May 2018 13:10:40 +0100
>Author : Robert Osfield
>Restored the REGISTER_WINDOWINGSYSTEMINTERFACE macro to the
>include/osg/GraphicsContext header and removed the OSGVIEWER_EXPORT
>as
>this was causing compatibility issues with osgQt.In
>GraphicsWindowWin32 replaced REGISTER_WINDOWINGSYSTEMINTERFACE
>usage
>with locally implemented equivilant with the required
>OSGVIEWER_EXPORT.
>___
>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] [ANN] Job Opportunity: Research engineers

[Björn Blissing]

Hello,

We are currently looking for candidates for full time research engineer 
positions at the Driving simulation and Visualization group at the Swedish 
National Road and Transport Research Institute. 

Education & Experience:
MSc in Computer Science, or similar.
Strong programming skills, especially in C++
Both junior and senior candidates will be considered.

Meriting Qualifications:
OpenGL, OpenSceneGraph, Unreal, Unity3D
Autosar, HLA, CAN-networks
Matlab/Simulink

Location: 
Gothenburg or Linköping, Sweden. 
Fluency in English is required. Fluency in Swedish is a strong advantage.

Apply before March 19th 2018

Instructions on how to apply here:
https://www.vti.se/sv/archive_platsannonser/forskningsingenjorer/

If you have any question I will try to answer them.

Best regards,
Björn

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





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

Re: [osg-users] [forum] How OpenSource make a profit

[Björn Blissing]

Hi,

There are plenty of ways to make money on open source software.

This wikipedia article sums the most common examples:
https://en.wikipedia.org/wiki/Business_models_for_open-source_software

Regards,
Björn

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





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

Re: [osg-users] How to simulate camera distortion ?

[Björn Blissing]

Hi Jishen,

I did the opposite, i.e. corrected the optical distortion from a captured 
image. This was done by applying the captured camera image to a plane and then 
using a fragment shader to rectify the image.

https://github.com/bjornblissing/osgueye/blob/master/src/camerarectification.frag

You could do the opposite, i.e. render your scene to a texture then apply a 
fragment shader to distort your image according to your camera parameters.

Note that you will have to calculate the correct field of view of the camera 
you wish to simulate and apply this FoV to your osg::Camera before rendering to 
the texture.

Cheers,
Björn

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





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

Re: [osg-users] Exporting to 3D studio?

[Björn Blissing]

Trajce Nikolov NICK wrote:
> Hi Bjorn,
> 
> the LightWave obj exporter can do the job with osgconv. We use this format 
> for interchange amond Blender, 3ds, Modo etc
> 
> 
> Nick
> 
> -- 
> trajce nikolov nick
> 


Worked perfectly!

Thank you for your quick reply!

Regards,
Björn

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





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

[osg-users] Exporting to 3D studio?

[Björn Blissing]

Hi,

Sorry, if this is a basic question. I have tried to find the online, but all 
search results only give me export options from 3D studio.

I need to export a model from native OSG format into a format that can be 
imported into 3D studio Max. There is no need for animations or textures. I 
just need the geometry. Are there any available export formats that can be used 
via osgconv?

Regards,
Björn

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





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

Re: [osg-users] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

Hi Robert,

My idea is that this could evolve into a large set of tutorials. Every header 
in the TOC would be a separate tutorial, responsible for teaching a osg concept.

Each tutorial will have the one markup file containing the "lesson" and then 
the corresponding source code as separate files. The reason for including 
CMakeList files in every tutorial is to be able to do automatic testing.

The main index.md.html will only be used as the table of contents. The 
index.html file is only used as a redirect, as Github pages won't accept 
.md.html files as a landing page.

I took a quick look at readthedocs. Although it produces beautiful docs, it has 
one major drawback. It requires some setup and cannot easily be run for the 
client. Markdeep on the other hand is just a included Javascript file and can 
be viewed instantly on every modern browser, without any additional setup. 
Which makes editing and additions simple for the community.

Hopefully this explains my ideas a bit.

Regards
Björn

Den 20 nov. 2017 12:13 skrev Robert Osfield <robert.osfi...@gmail.com>:
Hi Björn,

Thanks for your efforts on the tutorials.  I had a quick look at what
you have done so far, but am not yet clear how you are thinking it
might evolve.  I noticed both .md and .html files, are both something
that will be maintained?

On 19 November 2017 at 21:18, Björn Blissing <bjorn.bliss...@vti.se> wrote:
> * Is this a tutorial format worth pursuing?

I quite like the idea of using github for tutorials, as it can easily
be placed alongside the main OpenSceneGrpah repository and maintained
in a pretty straight forward way. The format I don't yet have an
strong opinions on though.  Feedback from new members to the community
who are currently learning would probably be really useful.

> * Is Markdeep the right choice?

Possibly.

> * Is CCBY and MIT licenses that should be used for this project?

For a tutorial I think it would be useful having a license that allows
users to just grab source code and insert it directly into their
applications without having to worry about attribution/including
licensing.  Would this be public domain?  I'm not 100% sure.

The documentation parts would naturally fall under creative commons.

> * What C++ standard should the source code be written in (my suggestion is 
> C++98 for maximum compatibility)?

Unless one is demonstrating use with later versions of C++ I think it
would be appropriate to leave it with CMake defaults like the OSG does
at present.

There is real value in having some C++11 and later tutorials as well.

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] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

As I said in my previous email. There is only one example tutorial right now. 
The first one in the basic category: "basic geometry"

The rest is as you say only a TOC.

I haven't checked readthedocs yet. It may be an option. But I like markdeep for 
its feature set.

Regards
Björn



Den 20 nov. 2017 09:00 skrev michael kapelko <korn...@gmail.com>:
Hi.
I can't see any tutorial. It's just a Table Of Contents. I guess at
least one tutorial is necessary to evaluate navigation.

As a side note, https://readthedocs.org/ hosts lots of docs with a
nice navigation, so this might be an option.

On 20 November 2017 at 00:18, Björn Blissing <bjorn.bliss...@vti.se> wrote:
> Hi Robert et al,
>
> As said earlier, I have started to experiment with GitHub pages. I discovered 
> that it was hard to support both single-page and multi-page documents using 
> markdeep (since its limited support for included documents). So having a 
> single-page and multi-page document at the same time will not work unless 
> everything is in a completely flat directory structure, which will be 
> unmaintainable. So I decided to go with a multi-page solution.
>
> I have pushed the current work to a personal repo on GitHub. You can checkout 
> the result at:
> https://bjornblissing.github.io/openscenegraph-tutorials
>
> And the corresponding repo is here:
> https://github.com/bjornblissing/openscenegraph-tutorials
>
> So far I have built a test skeleton for tutorials. This includes a draft 
> version of the table of contents and simple introduction tutorial to see if 
> my test is working. I have included a CMakeList.txt file in the root 
> directory which can be used to generate build files for the tutorials.
>
> The only available tutorial as of now is "Basic Geometry".
>
> But before I continue with any more work I would like some community 
> feedback. There are many questions that I think should be answered:
>
> * Is this a tutorial format worth pursuing?
> * Is Markdeep the right choice?
> * Is CCBY and MIT licenses that should be used for this project?
> * What C++ standard should the source code be written in (my suggestion is 
> C++98 for maximum compatibility)?
>
> Note: This should not be seen as anything more than a very rough draft of how 
> tutorials on GitHub pages could look like. If the community agrees that this 
> is the way forward I will continue the work, as well as transfer the 
> repository to the main OpenSceneGraph GitHub account.
>
> Regards,
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=72416#72416
>
>
>
>
>
> ___
> 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] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

Hi Robert et al,

As said earlier, I have started to experiment with GitHub pages. I discovered 
that it was hard to support both single-page and multi-page documents using 
markdeep (since its limited support for included documents). So having a 
single-page and multi-page document at the same time will not work unless 
everything is in a completely flat directory structure, which will be 
unmaintainable. So I decided to go with a multi-page solution.

I have pushed the current work to a personal repo on GitHub. You can checkout 
the result at: 
https://bjornblissing.github.io/openscenegraph-tutorials

And the corresponding repo is here:
https://github.com/bjornblissing/openscenegraph-tutorials

So far I have built a test skeleton for tutorials. This includes a draft 
version of the table of contents and simple introduction tutorial to see if my 
test is working. I have included a CMakeList.txt file in the root directory 
which can be used to generate build files for the tutorials. 

The only available tutorial as of now is "Basic Geometry".

But before I continue with any more work I would like some community feedback. 
There are many questions that I think should be answered:

* Is this a tutorial format worth pursuing? 
* Is Markdeep the right choice?
* Is CCBY and MIT licenses that should be used for this project?
* What C++ standard should the source code be written in (my suggestion is 
C++98 for maximum compatibility)?

Note: This should not be seen as anything more than a very rough draft of how 
tutorials on GitHub pages could look like. If the community agrees that this is 
the way forward I will continue the work, as well as transfer the repository to 
the main OpenSceneGraph GitHub account. 

Regards,
Björn

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





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

Re: [osg-users] osgoculus viewer picking

[Björn Blissing]

mmaurus wrote:
> No, I actually mean eyetracking!
> I have an integrated eyetracker.
> 


Nice!

Ok.. Well then you have to add the eyetracking rotations on top of the head 
rotations. 

Regards
Björn

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





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

Re: [osg-users] osgoculus viewer picking

[Björn Blissing]

Hi again,

I do not know which version of the OsgOculusViewer you are currently using. I 
just checked my own code and the OculusDevice class have had public interfaces 
to both head position and orientation since 3 years back (SDK version 0.4.2).

Regards,
Björn

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





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

Re: [osg-users] osgoculus viewer picking

[Björn Blissing]

Hi Michael,

I guess you mean head tracking and not eye tracking.

But that should be fairly straight forward. Create a line segment emanating 
from a point between the eyes and use that to calculate the intersections. 
There is no need to go from 2D to 3D in this case. The only thing you need to 
do is to recover the head position and orientation from the OculusDevice class. 
Either by writing your own method that publish that data directly from the 
Oculus SDK or by recovering that from the view matrices (which already have a 
public interface in the OculusDevice class).

Regards,
Björn

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





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

Re: [osg-users] osgoculus viewer picking

[Björn Blissing]

Hi Michael,

The OsgOculusViewer only renders to textures. What you see on your normal 
monitor is mirrored through the facilities provided by the Oculus SDK. I really 
do not know how mouse events are propagated through this window back to the osg 
application.

The second assumption your code makes is that it assumes that there is a valid 
camera connected to the view. OsgOculusViewer uses a master-slave 
configuration, where the master view do not contain a valid camera object. 
Instead it is the slave cameras that is responsible for all rendering. 

A more esoteric question is: Do you really want mouse picking abilities when 
you are using a HMD? Shouldn't you be using the Oculus Touch capabilities for 
object picking inside VR instead?


Regards,
Björn

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





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

Re: [osg-users] about using HTC VIVE VR in OSG

[Björn Blissing]

Jan Ciger wrote:
> 
> There is a project integrating the Oculus Rift with OSG already, maybe that 
> you could use as a starting point - the HMDs work very similarly even though 
> the APIs are obviously different. 
> 



There have even been a fork of the Oculus Rift project which uses 
OpenVR/SteamVR instead:
https://github.com/ChrisDenham/osgopenvrviewer

Although I do not know how active this project is or if it works...

Regards
Björn

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





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

Re: [osg-users] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

robertosfield wrote:
> 
> I don't have a problem with video tutorial's, but as you say if API's change 
> then videos need to be re-shot, but then other resources have to be redone 
> anyway.  If one can make vidoes in a lightweight way then the cost of videos 
> might not be too high.


The problem I have with video tutorials is that it is hard to keep quality 
consistent. This is a problem if the tutorials should be a community effort. 
This should not be seen as criticism of Michael Kapelko's tutorials. But I do 
not see how the community could build consistent video tutorials together. 
Another problem is that videos are next to impossible to change. Minor changes 
might be edited out, but often the videos would have to be re-recorded if the 
API changed or if someone found a bug.

In this aspect text is a much better format. It is easily editable and can be 
stored and diffed using a version control system. There may be language 
differences between tutorials created by different authors, but that difference 
is much more subtle compared to having videos narrated by different persons.

I have started experimenting with a OpenSceneGraph-Tutorials repository at 
home. So far I have made s quick draft of a table of contents, written a first 
tutorial and written the relevant CMakeLists to compile the tutorials. I 
started using markdown, but then I switched to Markdeep: 
https://casual-effects.com/markdeep/

Markdeep have better support for syntax coloring, diagrams etc. It can even be 
used to generate PDFs with acceptable pagination. Another benefit of Markdeep 
is that the content can be viewed locally since the only thing that is needed 
is a browser with decent javascript support.

Before I push this to a public repo I will write a couple of more tutorials 
just to see that the technology scales to a larger set of tutorials. For 
example, I still have not decided if the tutorials should be available as 
multipage (one tutorial per page) or single page (all tutorials in one page). 
The benefits of having a single page design is that you can easily print the 
document.

Regards,
Björn

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





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

Re: [osg-users] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

Hi,

First of all Michael Kapelko's tutorials looks amazing. He must spent a lot of 
time producing these. One problem though is that they do not specify any 
permissive license. Another problem is that they are in video form and those 
are hard to change if anything needs changing (other than rerecording the 
video). So I do not think they should be included in any form of "official" 
tutorial.

My idea of converting some of the older tutorials to github pages was mostly 
meant as proof-of-concept to test out the technology. But I agree with you 
Robert that we should not copy the old but instead create a new set of modern 
OSG tutorials. Before we start doing these I think we need to have an outline 
of the "curriculum". We also need to think of the target audience. What should 
the prerequisite knowledge level be? Knowing C++ and basic computer graphics??

If done correctly I think many of the reoccurring questions on the mailing list 
would disappear.

Regards,
Björn

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





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

Re: [osg-users] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

Chris Hanson wrote:
> I like the idea, assuming we can link them to the main site without problems.
> 


Well, I have little experience on integrating GitHub pages to other sites. 
Maybe there is a simple way to import github markdown documents that could be 
integrated into the main site. 



Chris Hanson wrote:
> But it still means people need to set that up, and migrate/update the 
> tutorials.
> 
> And I'm not hearing much response on that.


I could probably take a stab at some of the basic tutorials, but there is 30 
basic tutorials on the link above (+14 by Franclin Foping). There is probably 
some overlap in content as well. Then there are multiple links to more advanced 
tutorials. It would be impossible for me to do them all.

BUT I could convert a few of them tonight and make a test with the GitHub 
solution on my own account. Then we could evaluate the technical solution, 
before spending too much time.

Regards,
Björn

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





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

Re: [osg-users] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

Hi,

One idea could be to move the tutorials section to GitHub. That is creating a 
new github repository under the OpenSceneGraph account. We already have the 
OpenSceneGraph-Data repo, why not create a OpenSceneGraph-Tutorials repo? 

Each tutorial gets its own folder, which stores both the tutorial, as well as 
the source in compilable form. The tutorials could use the github pages 
function where the tutorial text could use markdown for formatting. Then we 
could link from the openscenegraph homepage to the github tutorial pages.

If setup correctly, it is even possible to have automated testing of the 
tutorials to check if any of them breaks when osg gets updated.

Regards,
Björn

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





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

[osg-users] [EXTERNAL] Re: Is there a binary distribution available for version 3.4.0?

[Björn Blissing]

Hi,

For the third party libraries I used Appveyor, which was pretty simple to 
setup. It has the ability to push built artifacts as to Github as releases. It 
is free for open source libraries, BUT I think their build time limit may 
impose problems. Their maximum allowed build time is 60 minutes and the VMs 
they are using are not super fast. I guess it would be hard to get 
OpenSceneGraph to finish a full build under 60 minutes.

Regards,
Björn

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





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

[osg-users] Automated builds of 3rdParty libraries

[Björn Blissing]

Hi,

I have been successful in completely automating the builds of 3rdParty 
libraries for Visual Studio. This is done using the continuous delivery service 
AppVeyor.

This means that there will be updated prebuilt versions of the 3rdParty 
libraries available to download for different versions of Visual Studio 
(currently 2015 and 2017; both 32-bit and 64-bit). These will be automatically 
rebuilt every time the GitHub repository is updated and the latest successful 
builds will available as download links on the readme page at:
https://github.com/bjornblissing/osg-3rdparty-cmake

The builds currently contain: zlib, libpng, libjpeg, libtiff, FreeType, GLUT, 
GIFLIB, MINIZIP and cURL.

Hopefully this will help others who need prebuilt 3rd party libraries.

If any of you are missing a certain library, please fork the GitHub repository 
and try to add it and then send me a pull request. Or you could add a request 
for a library as an issue in the issue tracker on GitHub.

Regards,
Björn

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





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

Re: [osg-users] [ANN] 3rdParty package precompiled with Visual Studio 2017 released

[Björn Blissing]

Hi Robert,

Good to know and I will probably prune the GLUT library from my supported 
libraries in time.

In the mean time, I have managed to work around the issue. There was a change 
to the glut.h file in the official github repo last year that introduced some 
preprocessor variables which changes the ways the library gets linked. Now you 
need to specify that you are linking with a static library in the parent 
project. Previously this was handled silently. Visual Studio users now need to 
set their runtime library option to /MT instead of /MD to be able to link with 
the static version of the library.

My quick workaround was to make the shared library the default option. And if 
someone tries to build the static library they will get a small warning of what 
to change in their project to be able to link correctly.

Regards
Björn

From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, August 30, 2017 10:10 AM
To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
Subject: Re: [osg-users] [ANN] 3rdParty package precompiled with Visual Studio 
2017 released

On 30 August 2017 at 08:19, Björn Blissing 
<bjorn.bliss...@vti.se<mailto:bjorn.bliss...@vti.se>> wrote:
Hi Pete,

You can try my CMake scripts:
https://github.com/bjornblissing/osg-3rdparty-cmake

There seems to be some problems with GLUT library, at least on my machine. But 
except from that I think that all of the latest third party libraries are 
working correctly with Visual Studio 2017 update 3.

I don't know if it helps but the OSG master no longer uses GLUT as I've removed 
the GLUT example.

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

Re: [osg-users] [ANN] 3rdParty package precompiled with Visual Studio 2017 released

[Björn Blissing]

Hi Pete,

You can try my CMake scripts:
https://github.com/bjornblissing/osg-3rdparty-cmake

There seems to be some problems with GLUT library, at least on my machine. But 
except from that I think that all of the latest third party libraries are 
working correctly with Visual Studio 2017 update 3.

Regards
Björn

>-Original Message-
>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>Behalf Of Pete Stieber
>Sent: Saturday, August 19, 2017 6:45 AM
>To: osg-users@lists.openscenegraph.org
>Subject: Re: [osg-users] [ANN] 3rdParty package precompiled with Visual
>Studio 2017 released
>
>Torben,
>
>Thank you so much for all of your work.
>
>A few days ago VS 2017 was updated to version 15.3.  Is the method you use
>to generate the 3rd party VS packages published anywhere?  I'd really like to
>try it myself with the latest VS 2017.
>
>Best regards,
>Pete
>
>--
>Read this topic online here:
>http://forum.openscenegraph.org/viewtopic.php?p=71461#71461
>
>
>
>
>
>___
>osg-users mailing list
>osg-users@lists.openscenegraph.org
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdParty/maybe OSG general] osgoculusviewer and View matrix

[Björn Blissing]

Hi Nick,

Sorry, I have missed this message. 

I do not really get your issue by the description.

If I understand you correctly you are changing the m_cameraRTTLeft and 
cameraRTTRight to use osg::Camera::ABSOLUTE_RF instead of 
osg::Camera::RELATIVE_RF. And this change is causing some issues.

What types of issues are you seeing?

Regards,

Björn

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





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

Re: [osg-users] Visual Studio 2015 3rd_party

[Björn Blissing]

b.lindahl wrote:
> Thanks Bjorn for the osg-3rdparty-cmake project. It really helped alot. I got 
> stuck on getting libtiff working with osg though and found out after banging 
> my head against the wall for quite some time with the version linked to from 
> the readme on github: libtiff(dot)org
> 
> Not sure if that site is getting moved or something but the last tested 
> version you mention, 4.0.6 is not available from that site and there's many 
> broken links on libtiff(dot)org. 


Hi,

Thanks for making me aware of the broken link on libtiff.org. The maintainer of 
the previous FTP has actually pointed us to a new location: 
http://download.osgeo.org/libtiff/.

I have updated the readme file with the new location.

Regards
Björn

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





___
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:
> 
> Björn ingen är idiot. I know you haven't writen getopt, I am a 20 year+ linux 
> user and programmer I am quite aware where getopt comes from. I didn't 
> insinuate it either :).


I did not say you were either. :)

I only wanted to make the source of the file clear for all readers of this 
thread (present and future).

Anyhow, I have added an explicit WIN32 definition to the GIFLIB subproject. 
Which should solve your issues without needing to change the getopt file.

Regards
Björn

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





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

[osg-users] Masked Occlusion Culling

[Björn Blissing]

Hi,

Some researchers from Intel just published the source code for their Masked 
Occlusion Culling. I don't know if this technology is something that could 
benefit OSG. But the technology looks quite capable, at least when just looking 
at the research paper. They claim a 3X speedup compared to previous methods.

The research paper can be found here:
http://fileadmin.cs.lth.se/graphics/research/papers/2016/culling/culling.pdf

The code is published at: 
https://github.com/GameTechDev/MaskedOcclusionCulling

Cheers,
Björn

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





___
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:
> J :-) and I as well commented on that include defined and possibility 
> that my script maybe messed up includes after I checked it up for the post 
> above, if you read the text you quoted  It is not important, but I don't 
> think Linux people would use your modified getopt.c build which is intended 
> for sole purpose of windows build, and should probably not use strings.h 
> either since it is an obsolete header predating standard, but that just as 
> curiosa .-)
> 
> Anyway thanks for hjälp with your cmakes.


You're welcome. 

And just as a side note. The getopt.c is certainly not something that I have 
written. It is verbatim from:
https://gist.github.com/ashelly/7776712

And it is included due to having to include unistd.h.

Regards
Björn

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





___
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:
> Mnjah, I doubt MS included strings.h with their runtime. 


No, I don't think so either. But the include in getopt.c is actually including 
string.h NOT strings.h. If you look at the first line in the code snippet you 
sent me, there are two conditions.

First: HAVE_STRING_H - Which may or may not be defined depending on your setup 
(it set on my machine due to the libtiff library).

Secondly: WIN32 - This is defined as true on all windows builds, both x86 and 
x64. 

Since the conditions are separated with an "or" sign ||. Only one of them have 
to be true. So I have a really hard time seeing how you would end up trying to 
include the "strings.h" header.


memory_leak wrote:
> My compiler also seems to miss for some reason WIN32, maybe bc I did 64-bit 
> build. Actually haven't checked IDE, just built it from script, mybe some 
> flags got messed up on my part :).


The WIN32 flag should be defined for all Windows build. So If you are building 
from some other external script you may have to include the defines manually to 
get this to build correctly. This use case is hardly something that you could 
expect me to support. Changing the proposed line in getiopt.c would probably 
break stuff for some of the linux people.


memory_leak wrote:
> By the way: do you build collada sucessfully?


No, I have never had the need for Collada. So I have not tried it.

Regards
Björn

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





___
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] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

Hi,

Tried compiling my own project with the latest master got some more warnings 
coming from included header files in OSG:


Code:
OpenSceneGraph\include\osgShadow/ViewDependentShadowTechnique(209): warning 
C4100: 'maxSize': unreferenced formal parameter
OpenSceneGraph\include\osg/GLObjects(64): warning C4100: 'fs': unreferenced 
formal parameter
OpenSceneGraph\include\osg/GLObjects(67): warning C4100: 'out': unreferenced 
formal parameter
OpenSceneGraph\include\osg/GLObjects(68): warning C4100: 'out': unreferenced 
formal parameter




Regards
Björn[/code]

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

robertosfield wrote:
> The HORROR!!! :-) 


What? Don't you approve of using the variable name 'c' throughout the entire 
codebase and in pretty much every scope?   :-)

With these warnings out of the way I only get these warnings:


In the LUA-plugin:


Code:

d:\code\github\openscenegraph\src\osgplugins\lua\lua-5.2.3\src\lapi.c(1110): 
warning C4702: unreachable code




Which is also denoted by a corresponding comment in the code:
"/* code unreachable; will unlock when control actually leaves the kernel */"

So this warning should probably be disabled.


In the OSC-plugin:


Code:
openscenegraph\src\osgPlugins\osc\ip\win32\NetworkingUtils.cpp(80): warning 
C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() instead or define 
_WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings
  C:\Program Files (x86)\Windows Kits\8.1\Include\um\winsock2.h(2238): note: 
see declaration of 'gethostbyname'
openscenegraph\src\osgPlugins\osc\ip\win32\UdpSocket.cpp(401): warning C4456: 
declaration of 'currentTimeMs' hides previous local declaration
  openscenegraph\src\osgPlugins\osc\ip\win32\UdpSocket.cpp(386): note: see 
declaration of 'currentTimeMs'




The first one is self explainatory. The second one is a simple variable 
shadowing. Which I do not think have any unintended consequences.


In the OSG-plugin:


Code:
openscenegraph\src\osgPlugins\osg\ReaderWriterOSG.cpp(257): warning C4459: 
declaration of 'NodeList' hides global declaration
  openscenegraph\include\osg/Group(22): note: see declaration of 'osg::NodeList'




This class defines the following:
typedef std::vector NodeList;

Which is different compared to the definintion in osg/Group, which uses a 
ref_ptr instead.


And finally in the TXP plugin:

Code:
openscenegraph\src\osgPlugins\txp\trpage_pparse.cpp(241): warning C4458: 
declaration of 'imageHelp' hides class member
  openscenegraph\src\osgPlugins\txp\trpage_print.h(136): note: see declaration 
of 'trpgPrintGraphParser::imageHelp'



This last one may actually have consequences which the author did not intend. 
But I am entirely not sure. The author have a protected member variable named 
imageHelp, which is set in the constructor. It also have an access method. But 
the variable is not used anywhere inside of the class, instead the scoped 
variable with the same name is used. 


Regards
Björn

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

robertosfield wrote:
> Hi Bjorn,
> 
> Could you post a log of the warnings that this CMakeLists.txt works
> around?  If there aren't too many we could just fix them.
> 
> Robert.


There are quite many, so IMHO we should just disable this warning for this 
subproject. But I is your call. 

Here are the build log:


Code:
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(178): warning 
C4456: declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(169): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(185): warning 
C4456: declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(169): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(204): warning 
C4456: declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(195): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(222): warning 
C4456: declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_atmosphere.c(213): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_camera.c(149): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_camera.c(134): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_camera.c(155): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_camera.c(134): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(721): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(715): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(728): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(715): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(742): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(715): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(758): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(715): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(776): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(715): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(789): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(715): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(802): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(715): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(850): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(840): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(859): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(840): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(867): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(840): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(909): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_file.c(894): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_light.c(198): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_light.c(191): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_light.c(205): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_light.c(191): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_light.c(211): warning C4456: 
declaration of 'c' hides previous local declaration
  openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_light.c(191): note: see 
declaration of 'c'
openscenegraph\src\osgPlugins\3ds\lib3ds\lib3ds_light.c(218): warning C4456: 
declaration of 'c' hides previous local declaration
  

Re: [osg-users] MSVS2015 3rdparty build

[Björn Blissing]

memory_leak wrote:
> 
> Tryed this evening and I got it work, with some minor problems:
> 
> * Curl does not build. I pulled source from git, and I don't know if it is 
> due to change in Curl or something else, but your cmake file is configured to 
> include some sources which are not found in curl source. They are few 
> curl_ntlm.c, curl_ntlm_msgs.c, curl_sasl_gssapi.c, curl_sasl_ssapi.c and 
> http_negotiate_sspi. Anyway Curl comes with it's own cmake file which works 
> fine "out of the box", so I have opted to comment it out completely from your 
> top level cmake.
> 


Ok, it is rarely a good idea to build against master. In the Readme file there 
are specfied which tagged version which each library is tested against. I have 
just merged a pull request to support the latest stable version of cUrl 
(7.49.1).

Also, there is no need to comment things out in the top level cmake file. If 
you do not want to include a certain library, just leave the corresponding 
*_SOURCE_DIR variable empty and the build script will omit the library from the 
build. 


memory_leak wrote:
> * Giflib failes due to missing strings.h included from "ported" getopt.h. I 
> have included dummy strings.h which just includes standard string.h.


I do not get this problem on Visual Studio 2015 x86. Which platform are you 
building on (compiler)?


memory_leak wrote:
> 
> * Is liFtiff oficially promoted to liff? :-)
> 


Apparently! :-)

I have fixed this spelling error. 

Regards
Björn

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

The included CMakeLists file is for the 3ds plugin.

My suggestion is to disable the variable shadowing warnings for this project, 
since it is basically an external library although included as source files. 
The other option is to fix all the variable name reuse for that project, which 
feels kind of unnecessary as lib3ds is pretty much abandoned as project (no 
activity since 2013). Autodesk has also stopped their development of this 
format years ago.

Regards
Björn


Från: osg-users  för Robert Osfield 

Skickat: den 4 juni 2016 19:42:10
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] Preparing to make 3.5.3 dev release, please test

Hi François,

I have removed the register keyword usage from
Matrix_implementation.cpp and added the "" to the CMakeLists.txt.
These changes are now checked into git mater.

Robert.

On 4 June 2016 at 16:23, François Bérard  wrote:
> Hi Robert,
>
> On 3/6/16 18:46, Robert Osfield wrote:
>>
>> Rather than add this to the root CMakeLists.txt file I have added a
>> Clang specific section to the src/osgPlugins/cfg/CMakeLists.txt thus:
>>
>> # lex/yacc generated files use register that causes warnings with
>> CLang under OSX so disable this warnings.
>> IF(${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
>> SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-deprecated-register)
>> ENDIF()
>>
>> This is now checked into master.  Could remove you your own mds and test
>> this?
>
>
> there is a small pb which breaks the build:
>
> Scanning dependencies of target osgdb_cfg
> [ 79%] Building CXX object
> src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/CameraConfig.cpp.o
> clang: error: no input files
> /bin/sh: -Wno-deprecated-register: command not found
> make[2]: ***
> [src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/CameraConfig.cpp.o] Error 127
> make[1]: *** [src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/all] Error 2
> make: *** [all] Error 2
>
>
> adding double quotes fixes it:
>
>  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-register")
>
> Also, the warning appears in osg/Matrix_implementation.cpp (see attached
> log), you may want to add the definition to the CMakelist of libosg. I tried
> by adding the IF block juste before the SETUP_LIBRARY, it worked. But
> removing the two register keywords in the matrix code may be the best
> approach: they are most probably always ignored by the compilers.
>
> ___
> 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
# List of C files to be compiled as C++ (else CMake sets ".c" to be compiled as 
pure C)
SET(C_FILES
lib3ds/lib3ds_io.c# Modified to support OSG endianness
)

SET(TARGET_SRC
ReaderWriter3DS.cpp
WriterNodeVisitor.cpp
WriterCompareTriangle.cpp

${C_FILES}
lib3ds/lib3ds_atmosphere.c
lib3ds/lib3ds_background.c
lib3ds/lib3ds_camera.c
lib3ds/lib3ds_chunk.c
lib3ds/lib3ds_chunktable.c
lib3ds/lib3ds_file.c
lib3ds/lib3ds_light.c
lib3ds/lib3ds_material.c
lib3ds/lib3ds_math.c
lib3ds/lib3ds_matrix.c
lib3ds/lib3ds_mesh.c
lib3ds/lib3ds_node.c
lib3ds/lib3ds_quat.c
lib3ds/lib3ds_shadow.c
lib3ds/lib3ds_track.c
lib3ds/lib3ds_util.c
lib3ds/lib3ds_vector.c
lib3ds/lib3ds_viewport.c
)
SET(TARGET_H
WriterNodeVisitor.h
WriterCompareTriangle.h
lib3ds/lib3ds.h
lib3ds/lib3ds_impl.h
)

IF (MSVC)
#disable specific warning level 4 warnings:
#C4456 declaration of 'c' hides previous local declaration
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /wd4456")
ENDIF(MSVC)
 
 end var setup  ###
SETUP_PLUGIN(3ds)
ADD_DEFINITIONS( -DLIB3DS_STATIC )# lib3ds is included, so we need the 
flag
SET_SOURCE_FILES_PROPERTIES(${C_FILES} PROPERTIES LANGUAGE "CXX")# 
Force some files to be compiled as C++
___
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:
> 
> When building with your cmakes I have tryed pretty much what you describe. 
> 1st i downloaded all code for every project in their respective folder, than 
> I put your cmake files in the respective folder and top level one in top 
> level directory where all other src folders were. 


No no... You should not move anything. Keep the files from GitHub as they are, 
otherwise the top level script may not find the scripts for each library.


memory_leak wrote:
> 
> Prospect of configuring manually each and every one did occur to me but I 
> have to admiit, not overly appealing :).
> 
> Now from your answer I understand  I should do some extra work to tell your 
> cmake from my batch file where to find things. That is probably reason why I 
> got only project files for "build all" and "install" but not individual 
> project files.


Well, there is no need to if you do not desire. The only thing you need to do, 
is to point to the location of the source for each library you desire to build. 
Heck, you can even skip the CMake GUI and do everything using CMake 
command-line. Just supply the paths with using the -D flag and you are set. 
That way you can integrated my CMake scripts in your automated build scripts. 
Or you could just defined them as environment variables if that is more to you 
liking.

Regards
Björn

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





___
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]

Hi Carl-Gustaf Kung, 

I wrote the CMake scripts to be able to quickly build the dependencies upon 
which I project I was working on was using. Then I added some more libraries by 
request. Are these scripts totally optimized for every platform? No. They 
should be used as a quick way of getting the dependencies built and assembled 
into a directory for easy use with OSG. If you desire total control of every 
tiny setting for each library I recommend that you do a separate build for each 
library with settings that match your platform.

That said, this is how you use the CMake scripts:

1. Download or Clone the CMake script from the GitHub repo.

2. Download the sources for each library you desire to build. You can put these 
anywhere on your filesystem. Download locations for each library can be found 
in the Readme file.

3. Start the CMake GUI:
- In the field "Where is the source code" you enter the directory for the CMake 
scripts. 
- In the field "Where to build the binaries" you enter where you desire the 
Visual Studio project files to end up. I 

4. Press "Configure" in the CMake GUI. This will reveal a couple of directories 
which you need to specify. These all end with _SOURCE_DIR. For these you 
specify the location of the libraries which you downloaded in step 2. 

5. Press "Configure" a couple of more times. Depending on which libraries you 
are building more or less options will be shown in the CMake GUI.

6. When happy, press "Generate". This will construct the solution file and 
project files for Visual Studio in the specified binaries directory.

7. Open the solution file and build the "ALL_BUILD" project.

8. When complete, build the "INSTALL" project. This will create a directory in 
your binary directory named "3rdParty" inside this directory another directory 
will be created which matches your Visual Studio version and selected 
architecture (i.e. 32 or 64 bit build). In this directory there will be the 
lib, include and bin directories. Note that you need to build the "INSTALL" 
project twice, once for Debug build and once for Release. Or else the 3rdParty 
directory will be missing the corresponding files.

Good luck!

Nice username by the way. :)

Regards,
Björn

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

robertosfield wrote:
> Hi Bjorn,
> Unfortunately I don't see these warnings with the compiler I have
> available with the settings that are currently available.  Do you know
> of what to enable these warnings in gcc or Clang?
> 
> The nature of these warnings are such that I really need to be able to
> see the warning first hand and attempt a local fix to see the affect.
> 
> Cheers,
> Robert.
> 


Hi Robert,

I have made a small example which shows the problem with these types of 
constructors:

https://gist.github.com/bjornblissing/1895b168b2e90762ebee065adb3d3c65

It emits compilation warnings in Visual Studio 2015, but I have been unable to 
reproduce the warning in neither GCC nor Clang. Although the output of the 
executable are identical.

Regards
Björn

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

Hi again, 

Forgot to attach the last two files with fixes to the virtual inheritance 
warnings...

I have also attached the fix to the type shadowing problem in 
ConvexPolyhedron.cpp

With this I think that the OSG Core group of projects compiles without warnings 
on Visual Studio 2015.

Regards
Björn

>-Original Message-
>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>Behalf Of Björn Blissing
>Sent: Friday, June 3, 2016 3:35 PM
>To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
>Subject: Re: [osg-users] Preparing to make 3.5.3 dev release, please test
>
>Hi again,
>
>This is the fix for the rest of the virtual inheritance warnings. Same as for
>issues as for the Operation class.
>
>Regards
>Björn
>
>>-Original Message-
>>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>>Behalf Of Björn Blissing
>>Sent: Friday, June 3, 2016 2:39 PM
>>To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
>>Subject: Re: [osg-users] Preparing to make 3.5.3 dev release, please test
>>
>>Hi Robert,
>>
>>The warnings relating the Operation class comes from the two protected
>>constructors. Since the class uses virtual inheritance it is initialized by 
>>the
>most
>>derived class. So the initializer for the virtual base class is ignored.
>>
>>So just removing the base class initializer for Operation will remove this
>>warning. I do not think this will have any negative side effects, since base
>class
>>initializer should be ignored by all compliant compilers anyway.
>>
>>I have attached the changed file.
>>
>>Regards
>>Björn
>>
>>>-Original Message-
>>>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>>>Behalf Of Robert Osfield
>>>Sent: Friday, June 3, 2016 1:46 PM
>>>To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
>>>Subject: Re: [osg-users] Preparing to make 3.5.3 dev release, please test
>>>
>>>Hi Bjorn,
>>>
>>>On 3 June 2016 at 09:48, Björn Blissing <bjorn.bliss...@vti.se> wrote:
>>>>
>>>> I compiled the latest master with Visual Studio 2015.
>>>>
>>>> I got a couple of warnings.  First of all I got a ton of these, which all
>>originates
>>>from the same origin:
>>>>
>>>>
>>>> Code:
>>>>
>>>> ...
>>>> OpenSceneGraph\include\osg/OperationThread(80): warning C4589:
>>>Constructor of abstract class 'osg::Operation' ignores initializer for 
>>>virtual
>>base
>>>class 'osg::Referenced' (compiling source file
>>>D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
>>>>   OpenSceneGraph\include\osg/OperationThread(80): note: virtual base
>>>classes are only initialized by the most-derived type (compiling source file
>>>D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>> And the same warnings for the following classes:
>>>>
>>>>
>>>> Code:
>>>>
>>>> OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning
>C4589:
>>>Constructor of abstract class 'osgGA::CameraManipulator' ignores initializer
>>for
>>>virtual base class 'osg::Callback'
>>>>   OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note: virtual
>>>base classes are only initialized by the most-derived type
>>>> OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): warning
>>C4589:
>>>Constructor of abstract class 'osgGA::StandardManipulator' ignores
>initializer
>>>for virtual base class 'osg::Callback'
>>>>   OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): note:
>virtual
>>>base classes are only initialized by the most-derived type
>>>> OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): warning C4589:
>>>Constructor of abstract class 'osgViewer::ViewerBase' ignores initializer for
>>>virtual base class 'osg::Object'
>>>>   OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): note: virtual
>base
>>>classes are only initialized by the most-derived type
>>>> OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): warning C4589:
>>>Constructor of abstract class 'osgViewer::ViewerBase' ignores initializer for
>>>virtual base class 'osg::Object'
>>>>   OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): note: virtual
>base
>>>classes are only initialized by the most-derived

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

Hi again,

This is the fix for the rest of the virtual inheritance warnings. Same as for 
issues as for the Operation class.

Regards
Björn

>-Original Message-
>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>Behalf Of Björn Blissing
>Sent: Friday, June 3, 2016 2:39 PM
>To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
>Subject: Re: [osg-users] Preparing to make 3.5.3 dev release, please test
>
>Hi Robert,
>
>The warnings relating the Operation class comes from the two protected
>constructors. Since the class uses virtual inheritance it is initialized by 
>the most
>derived class. So the initializer for the virtual base class is ignored.
>
>So just removing the base class initializer for Operation will remove this
>warning. I do not think this will have any negative side effects, since base 
>class
>initializer should be ignored by all compliant compilers anyway.
>
>I have attached the changed file.
>
>Regards
>Björn
>
>>-Original Message-
>>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>>Behalf Of Robert Osfield
>>Sent: Friday, June 3, 2016 1:46 PM
>>To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
>>Subject: Re: [osg-users] Preparing to make 3.5.3 dev release, please test
>>
>>Hi Bjorn,
>>
>>On 3 June 2016 at 09:48, Björn Blissing <bjorn.bliss...@vti.se> wrote:
>>>
>>> I compiled the latest master with Visual Studio 2015.
>>>
>>> I got a couple of warnings.  First of all I got a ton of these, which all
>originates
>>from the same origin:
>>>
>>>
>>> Code:
>>>
>>> ...
>>> OpenSceneGraph\include\osg/OperationThread(80): warning C4589:
>>Constructor of abstract class 'osg::Operation' ignores initializer for virtual
>base
>>class 'osg::Referenced' (compiling source file
>>D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
>>>   OpenSceneGraph\include\osg/OperationThread(80): note: virtual base
>>classes are only initialized by the most-derived type (compiling source file
>>D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
>>> ...
>>>
>>>
>>>
>>>
>>> And the same warnings for the following classes:
>>>
>>>
>>> Code:
>>>
>>> OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning C4589:
>>Constructor of abstract class 'osgGA::CameraManipulator' ignores initializer
>for
>>virtual base class 'osg::Callback'
>>>   OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note: virtual
>>base classes are only initialized by the most-derived type
>>> OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): warning
>C4589:
>>Constructor of abstract class 'osgGA::StandardManipulator' ignores initializer
>>for virtual base class 'osg::Callback'
>>>   OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): note: virtual
>>base classes are only initialized by the most-derived type
>>> OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): warning C4589:
>>Constructor of abstract class 'osgViewer::ViewerBase' ignores initializer for
>>virtual base class 'osg::Object'
>>>   OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): note: virtual base
>>classes are only initialized by the most-derived type
>>> OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): warning C4589:
>>Constructor of abstract class 'osgViewer::ViewerBase' ignores initializer for
>>virtual base class 'osg::Object'
>>>   OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): note: virtual base
>>classes are only initialized by the most-derived type
>>> OpenSceneGraph\src\osgAnimation\AnimationManagerBase.cpp(65):
>>warning C4589: Constructor of abstract class
>>'osgAnimation::AnimationManagerBase' ignores initializer for virtual base
>class
>>'osg::Callback'
>>>   OpenSceneGraph\src\osgAnimation\AnimationManagerBase.cpp(65):
>>note: virtual base classes are only initialized by the most-derived type
>>
>>Unfortunately I don't see these warnings with the compiler I have
>>available with the settings that are currently available.  Do you know
>>of what to enable these warnings in gcc or Clang?
>>
>>The nature of these warnings are such that I really need to be able to
>>see the warning first hand and attempt a local fix to see the affect.
>>
>>Cheers,
>>Robert.
>>___
>>osg-users mailing list
>>osg-users@lists.openscenegraph.org
>>http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

Hi Robert,

The warnings relating the Operation class comes from the two protected 
constructors. Since the class uses virtual inheritance it is initialized by the 
most derived class. So the initializer for the virtual base class is ignored.

So just removing the base class initializer for Operation will remove this 
warning. I do not think this will have any negative side effects, since base 
class initializer should be ignored by all compliant compilers anyway.

I have attached the changed file.

Regards
Björn

>-Original Message-
>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>Behalf Of Robert Osfield
>Sent: Friday, June 3, 2016 1:46 PM
>To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
>Subject: Re: [osg-users] Preparing to make 3.5.3 dev release, please test
>
>Hi Bjorn,
>
>On 3 June 2016 at 09:48, Björn Blissing <bjorn.bliss...@vti.se> wrote:
>>
>> I compiled the latest master with Visual Studio 2015.
>>
>> I got a couple of warnings.  First of all I got a ton of these, which all 
>> originates
>from the same origin:
>>
>>
>> Code:
>>
>> ...
>> OpenSceneGraph\include\osg/OperationThread(80): warning C4589:
>Constructor of abstract class 'osg::Operation' ignores initializer for virtual 
>base
>class 'osg::Referenced' (compiling source file
>D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
>>   OpenSceneGraph\include\osg/OperationThread(80): note: virtual base
>classes are only initialized by the most-derived type (compiling source file
>D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
>> ...
>>
>>
>>
>>
>> And the same warnings for the following classes:
>>
>>
>> Code:
>>
>> OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning C4589:
>Constructor of abstract class 'osgGA::CameraManipulator' ignores initializer 
>for
>virtual base class 'osg::Callback'
>>   OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note: virtual
>base classes are only initialized by the most-derived type
>> OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): warning C4589:
>Constructor of abstract class 'osgGA::StandardManipulator' ignores initializer
>for virtual base class 'osg::Callback'
>>   OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): note: virtual
>base classes are only initialized by the most-derived type
>> OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): warning C4589:
>Constructor of abstract class 'osgViewer::ViewerBase' ignores initializer for
>virtual base class 'osg::Object'
>>   OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): note: virtual base
>classes are only initialized by the most-derived type
>> OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): warning C4589:
>Constructor of abstract class 'osgViewer::ViewerBase' ignores initializer for
>virtual base class 'osg::Object'
>>   OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): note: virtual base
>classes are only initialized by the most-derived type
>> OpenSceneGraph\src\osgAnimation\AnimationManagerBase.cpp(65):
>warning C4589: Constructor of abstract class
>'osgAnimation::AnimationManagerBase' ignores initializer for virtual base class
>'osg::Callback'
>>   OpenSceneGraph\src\osgAnimation\AnimationManagerBase.cpp(65):
>note: virtual base classes are only initialized by the most-derived type
>
>Unfortunately I don't see these warnings with the compiler I have
>available with the settings that are currently available.  Do you know
>of what to enable these warnings in gcc or Clang?
>
>The nature of these warnings are such that I really need to be able to
>see the warning first hand and attempt a local fix to see the affect.
>
>Cheers,
>Robert.
>___
>osg-users mailing list
>osg-users@lists.openscenegraph.org
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

Hi Robert,

Since you introduced the osg::PI_2f value, maybe you should replace the two 
osg::PIf*0.5f found in ShapeDrawable at line 1405 and 1479.

Regards
Björn

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Björn Blissing]

Hi,

I compiled the latest master with Visual Studio 2015.

I got a couple of warnings.  First of all I got a ton of these, which all 
originates from the same origin:


Code:

...
OpenSceneGraph\include\osg/OperationThread(80): warning C4589: Constructor of 
abstract class 'osg::Operation' ignores initializer for virtual base class 
'osg::Referenced' (compiling source file 
D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
  OpenSceneGraph\include\osg/OperationThread(80): note: virtual base classes 
are only initialized by the most-derived type (compiling source file 
D:\github\OpenSceneGraph\src\osg\AnimationPath.cpp)
...




And the same warnings for the following classes:


Code:

OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning C4589: Constructor 
of abstract class 'osgGA::CameraManipulator' ignores initializer for virtual 
base class 'osg::Callback'
  OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note: virtual base 
classes are only initialized by the most-derived type
OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): warning C4589: 
Constructor of abstract class 'osgGA::StandardManipulator' ignores initializer 
for virtual base class 'osg::Callback'
  OpenSceneGraph\src\osgGA\StandardManipulator.cpp(51): note: virtual base 
classes are only initialized by the most-derived type
OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): warning C4589: Constructor of 
abstract class 'osgViewer::ViewerBase' ignores initializer for virtual base 
class 'osg::Object'
  OpenSceneGraph\src\osgViewer\ViewerBase.cpp(44): note: virtual base classes 
are only initialized by the most-derived type
OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): warning C4589: Constructor of 
abstract class 'osgViewer::ViewerBase' ignores initializer for virtual base 
class 'osg::Object'
  OpenSceneGraph\src\osgViewer\ViewerBase.cpp(50): note: virtual base classes 
are only initialized by the most-derived type
OpenSceneGraph\src\osgAnimation\AnimationManagerBase.cpp(65): warning C4589: 
Constructor of abstract class 'osgAnimation::AnimationManagerBase' ignores 
initializer for virtual base class 'osg::Callback'
  OpenSceneGraph\src\osgAnimation\AnimationManagerBase.cpp(65): note: virtual 
base classes are only initialized by the most-derived type




The I get a couple of warnings due to osg::PI being used with floats:


Code:

OpenSceneGraph\src\osg\ShapeDrawable.cpp(311): warning C4305: 'initializing': 
truncation from 'double' to 'float'
OpenSceneGraph\src\osg\ShapeDrawable.cpp(381): warning C4305: 'initializing': 
truncation from 'double' to 'float'
OpenSceneGraph\src\osg\ShapeDrawable.cpp(669): warning C4305: '=': truncation 
from 'double' to 'float'
OpenSceneGraph\src\osg\ShapeDrawable.cpp(776): warning C4305: '=': truncation 
from 'double' to 'float'
OpenSceneGraph\src\osg\ShapeDrawable.cpp(1479): warning C4305: 'initializing': 
truncation from 'double' to 'float'
OpenSceneGraph\src\osg\ShapeDrawable.cpp(1697): warning C4305: '=': truncation 
from 'double' to 'float'
OpenSceneGraph\src\osg\ShapeDrawable.cpp(1783): warning C4305: '=': truncation 
from 'double' to 'float'





Then some warnings about narrowing conversions:


Code:
OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp(1693): warning C4838: 
conversion from 'int' to 'DWORD' requires a narrowing conversion
OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp(1693): warning C4838: 
conversion from 'unsigned int' to 'BYTE' requires a narrowing conversion



And finally some shadowed variable warnings:


Code:
OpenSceneGraph\src\osgShadow\ConvexPolyhedron.cpp(820): warning C4459: 
declaration of 'Points' hides global declaration
  OpenSceneGraph\src\osgShadow\ConvexPolyhedron.cpp(88): note: see declaration 
of '`anonymous-namespace'::Points'
OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp(2739): warning C4457: 
declaration of 'lParam' hides function parameter
  OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp(2511): note: see 
declaration of 'lParam'



There was also a lot of (+100) shadow warnings in the 3ds library. As well as 
one shadow warning each for the fbx and txp library.

Regards

Björn

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





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

Re: [osg-users] Submission/Pull Request problems on github

[Björn Blissing]

robertosfield wrote:
> Hi Björn,
> 
> I just checked, github still isn't giving my an option to reopen the
> pull request. Could you try another push of the request?
> 


I have submitted my pull request again (it was the gitignore patterns for 
Visual Studio). 


robertosfield wrote:
> 
> I'm struggling to get git to work in a way that allows me to do a
> proper review with the ability to graphically comparing sets of
> changes, for instance I have a set one pull request that has 88 files
> modified, alot of files but a small number of relatively minor changes
> such a variable renames.  I've done a quick review online and spotted
> that one instance so far where this renaming actually introduces a
> bug.
> 
> I've experimented with pull in the 3rd party clone of the
> openscenegraph that contains these modfications and successfully
> created a patch and applying this to a local branch on my
> openscenegraph, it applies fine but contains the known error, perhaps
> others that I'll spot once I go through another full review.  This is
> where graphically diff is crucial.  git makes it dead easy to merge
> many file changes with a couple of lines of git on the command line,
> but as yet I'm struggling to find a way to get git to allow me to
> merge one file at a time and presented with a graphics diff that
> allows me to individually accept/discard changes.
> 
> Will I need to write my own script to do this?   To do this I'd need
> to get to spit out a list of all the modified files in a form that I
> can pass into a script.
> 
> As things stand I am not prepared to merge a big patch with an unknown
> number of bugs introduced simply because git makes it convenient to
> merge as is and makes it hard to spot errors and intervene.
> 
> Thoughts, advice how to workaround these problems using git?
> 


I agree that doing merges online using the GitHub platform is a very bad idea, 
except for trivial changes (for example changing a spelling error inside a 
readme file).

For all cases with source code I will fetch the pull request to my local 
machine and do the merge to my workspace. Then I can use my favorite diff tool 
as well as compile and test. If all my tests pass then I commit the merge to 
the master branch and push the changes to the online repo.

(The above workflow is pretty much identical to: applying a patch file -> 
test -> commit to SVN.)

Regards
Björn

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





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

Re: [osg-users] Submission/Pull Request problems on github

[Björn Blissing]

robertosfield wrote:
> 
> Do you know what steps do members of the community need to do to fix
> things?  Perhaps we can pass instructions on via comments of each pull
> request.


Hi Robert,

Since you rewrote the entire history I had to hard reset all my branches in my 
forked repo. So for each branch I was had do:


Code:
git checkout master
git reset --hard upstream/master
git push origin master -f



I also tried to rebase my old pull request to the new master. But that took 
forever. So I resetted that branch as well and recommitted my change. But even 
when I force pushed this branch to my repo, the corresponding pull request did 
not update and is still closed.

Regards
Björn

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





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

Re: [osg-users] Windows 8.1 DPI-aware scaling: Problem and solution

[Björn Blissing]

Hi Paul,

Regarding the error when you are trying to run the script: I suspect that you 
have another name for your build target then TARGET_TARGETNAME. This is only a 
variable name that I use for my build target names. Yours is probably something 
completely different. Check your what the first variable in ADD_EXECUTABLE or 
ADD_LIBRARY in your CMake script and use that variable instead of 
TARGET_TARGETNAME.

Regarding your second question: The script is complete, when you are amending 
manifests to DLL files you need to change the characters #1 to #2 in the 
script. 

I have updated my gist comment to reflect this:
https://gist.github.com/bjornblissing/6fc452fe7ec1fdfe3419#gistcomment-1317136

Hope that solves your issues.

Regards
Björn

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





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

Re: [osg-users] Using multiples texture for a geometry

[Björn Blissing]

Flogo wrote:
> 
> I wanted to have multiples different textures not mixed (or blended) on a 
> same geometry such as doing floor tiles 
> (https://en.wikipedia.org/wiki/Porcelain_tile#/media/File:Chinese_porcelain_tiles,_Cochin_synagogue.jpg).


Hi Florian,

Normally this is done via a texture atlas:
https://en.wikipedia.org/wiki/Texture_atlas

That is a large texture which contains multiple subtextures. These can then be 
applied to the geometry by specifying the corresponding UV-coordinates.

There is even some thing called Mega-textures, where parts of the texture atlas 
get streamed from disk to create gigantic virtual textures:
http://gamedev.stackexchange.com/questions/1157/how-does-megatexture-work

Regards
Björn

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





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

Re: [osg-users] osgViewer::Viewer fullscreen dual monitor issue

[Björn Blissing]

akaisora wrote:
> Hi,
> 
> I am still new around here, I've got the book "OpenSceneGraph 3.0 Beginner's 
> Guide" and learning step by step. But I have dual monitors and running any 
> osg::Viewer example I got fullscreen window on both monitors, and a splitted 
> view as demonstrated in the attached screenshot.
> 
> Bascially it swaps the two monitors, the left render should have been on the 
> right and vice versa. 
> 
> Any idea how to fix it? Except using only one monitor :)
> 
> 
> Thank you!
> 
> Cheers,
> Soulaymen


Hi Soulaymen,

This is because you have your monitors setup in the wrong order in your windows 
settings. Windows enumerates your monitors, which can be seen in the displays 
settings. Make sure that your leftmost monitor have id 1 and the one to the 
right have id 2. (Note that this have nothing to do with which monitor is set 
to be primary or secondary, it is quite possible to make monitor 2 the primary 
monitor.).

I suspect that if you open the display settings you will currently have 
something that looks like this (Note the numbers on the displays and their 
location):
http://i.stack.imgur.com/SQzT8.png

You will need to change this so the numbers are in order left to right.

Regards
Björn

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





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

Re: [osg-users] Dumb Screen Resolution Question

[Björn Blissing]

Hi Paul,

This is the DPI-aware scaling you are seeing. Since Windows 8.1, the operating 
system will scale your application to this DPI-scaling setting, unless you 
explicitly declare the application as “DPI-aware”. Declaring your application 
as “DPI-aware” tells the operating system that you will be handling the scaling 
yourself. 

I have posted about this before:
http://forum.openscenegraph.org/viewtopic.php?t=14318

Regards
Björn

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





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

Re: [osg-users] VR headset integration

[Björn Blissing]

Interions wrote:
> 
> Any updates on your work?  I'm interested in this as well. Looking at various 
> resources and will help out by sharing what I find.  Thanks.


Hi Ruth (or whatever your name is),

The integration for 1.3 is working, but as Christian stated do not handle 
shutdown correctly. Right now I only work on this project on my spare time, 
which is currently very limited due to other project work.

The code is available here:
https://github.com/bjornblissing/osgoculusviewer

Regards
Björn

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





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

Re: [osg-users] Visual Studio 2015 dependencies?

[Björn Blissing]

James Turner wrote:
> 
> I’m trying to use these scripts at the moment, with some additions for 
> FlightGear.
> 
> But I’m hitting the problem that the generated FreeType layout is different 
> to what OSG expects. Is it supposed to work out of the box, with current 
> FreeType version (as recommended on the README) and current OSG?
> 
> Also, if this is not the correct place to ask such questions, please let me 
> know a better one, I can submit bug reports on GitHub.
> 
> Kind regards,
> James
> 

Hi James,

You are completely correct. This must be filed under the category: "How did 
that ever work?"

But I think I have fixed these bugs in the CMake scripts now. At least it 
compiles on my machine. 

Regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

So the first "stable" version of the Oculus SDK have been publicly released. I 
am happy to report that I got the OpenSceneGraph integration up and running. 
Although there is a bit more work to get it completely stable. 

Oculus have now launched what they call Oculus Home, which is their portal for 
pretty much everything. To play nice with this portal you have to handle your 
application with special care, or as Oculus calls it "VR Focus Management". 
This means that your application must handle situations such as the user 
unplugging the HMD, handling application shutdown and restart in a special way, 
etc.. 

This have not been implemented yet, the main part being the application 
shutdown problems. This is mainly due to differences between the way Oculus 
prefer you to handle shutdown and how shutdown is performed from OSG. So 
shutting down the application currently results in a crash on my machine. But 
hopefully this is something we should be able to fix.

As usual have the previous development been branched to:
https://github.com/bjornblissing/osgoculusviewer/tree/sdk-v0.8

Regards,
Björn

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





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

Re: [osg-users] VR headset integration

[Björn Blissing]

Hi Christian,


I have started working with the integration of the Oculus 1.3 SDK, but haven't 
finished quite yet. Mostly because due to lack of time.

Hopefully I will get some spare time and be able to complete the work during 
the week.


Best regards

Björn



Från: osg-users  för Christian 
Buchner 
Skickat: den 30 mars 2016 15:19
Till: OpenSceneGraph Users
Ämne: [osg-users] VR headset integration

Hi,

I just wanted to ask around rather generally, how OSG integration with various 
VR SDKs is coming along.

Can osgoculus be built against the recently released SDK version 1.3 at this 
time?

Is anyone working on a HTC Vive (OpenVR) or OSVR ( 
http://osvr.github.io/compatibility/ ) integration into OpenSceneGraph?

Christian

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

Re: [osg-users] Visual Studio 2015 dependencies?

[Björn Blissing]

Trajce Nikolov NICK wrote:
> Hi Bjorn,
> 
> I am using these CMake scripts, and many others as I follow the user lists .. 
> And you are forced to repeat yourself dosen of times with the same link
> 
> 
> Maybe you talk to Robert to place info about your github project on the web :)
> 


Hi Nick,

I have no problem if a link to the github page gets added to the dependencies 
section of the osg homepage. But someone with edit permissions have to make the 
change.

Regards
Björn

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





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

Re: [osg-users] Visual Studio 2015 dependencies?

[Björn Blissing]

Hi Carsten,


Depending on which dependencies you need you could always compile them yourself 
using the following CMake scripts:

https://github.com/bjornblissing/osg-3rdparty-cmake


Regards

Björn



Från: osg-users  för 
dragon...@versanet.de 
Skickat: den 16 mars 2016 11:53
Till: osg-users@lists.openscenegraph.org
Ämne: [osg-users] Visual Studio 2015 dependencies?

Hi All,

I'd like to compile Osg 3.4.0 with Visual Studio 2015 as 64Bit.
But I could find any precompiled dependencies for VS2015.
Can anybody point me to where to get them please?

Regards and thanks in advance,
Carsten
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Live skybox (video stream)

[Björn Blissing]

Hi Eddie,

What you are looking for is osg::ImageStream, which can be used to have video 
textures. 

I have written a small example using OpenCV to capture live images an display 
them on a texture. It can be found here:

https://github.com/bjornblissing/osgopencv

Cheers,
Björn

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





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

Re: [osg-users] 3rd party binaries VS 2013

[Björn Blissing]

Hi,

For some of the standard dependencies I have made CMake scripts that helps 
building them from source. As of now the scripts supports:

* zlib
* libpng
* libjpeg
* libtiff
* FreeType
* GLUT
* GIFLIB
* MINIZIP

And have been tested with the most recent versions of Visual Studio as well as 
MingGW+GCC.

The build scripts are available here:
https://github.com/bjornblissing/osg-3rdparty-cmake

Cheers,
Björn

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





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

Re: [osg-users] Convertions w.r.t .gitignore

[Björn Blissing]

SMesserschmidt wrote:
> 
> I'm not arguing that using CMake prevents you from doing in-source building, 
> but I guess only a fraction of people is doing this.
> Even if the majority is using it this way, I would still advocate for not 
> adding the VS specific entries to the .gitignore file.
> 


On the other hand, I don't see any clear drawback with having some VS specific 
entries in the .gitignore file.

I have submitted a pull request for a subset of gitignore patterns that I use 
for Visual Studio. I'll let Robert decide if these should be merged or not.

Regards
Björn

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





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

Re: [osg-users] Convertions w.r.t .gitignore

[Björn Blissing]

Hi Robert,

GitHub have a collection of useful gitignore templates:
https://github.com/github/gitignore

It may be a good idea to add the patterns from the C++.gitignore as well as the 
patterns from VisualStudio.gitignore.

Best regards,
Björn

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





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

Re: [osg-users] How to have access to the active OpenGL context?

[Björn Blissing]

Hi Alexandre,

I have the same problem with my Oculus integration. 

See discussion here (and possible solution here):
http://forum.openscenegraph.org/viewtopic.php?t=15186

Regards,
Björn

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





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

Re: [osg-users] Convertions w.r.t .gitignore

[Björn Blissing]

SMesserschmidt wrote:
> Hi Robert,
> 
> With the use of CMake the source and solutions are always separated.
> So there is no need for the VS-ignore stuff.
> 
> Cheers
> Sebastian
> 


Hi Sebastian,

ALWAYS is a strong wording. There is nothing in CMake to prevent you from doing 
an in-source build. The choice of doing in-source or out-of-source build is 
completely up to you.

I usually build OSG in-source because I prefer to have the auto generated 
header files in the same folder as the rest of the osg headers. (If you do an 
out-of-source build your auto generated header files will end up in the build 
directory.)

Regards
Björn

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





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

Re: [osg-users] Anyone Experimenting with OSVR

[Björn Blissing]

Jan Ciger wrote:
> The HDK itself has some interesting features that no other consumer HMD on 
> the market has, though. Display resolution is not the main thing there, even 
> though it should be comparable to Rift DK2.
> 
> For me the key differentiator is the built-in FPGA for image processing. That 
> could do things like the image distortion and colour aberration correction in 
> hardware, without the application needing to be aware of it all. The 
> application feeds it a regular side-by-side or frame sequential signal and 
> the FPGA would do all the work that currently has to be hacked in through 
> shaders or the late image warping used by Rift for reducing the tracking 
> latency. Basically that would make integration of such HMD very trivial, not 
> requiring specific support from Nvidia or a proprietary SDK where you are at 
> the mercy of the driver vendor because everything is done by your PC. 


This is a good idea, provided that you are able to send the HMD an image with 
higher resolution then the native resolution of the display. Otherwise the 
warping inside the FPGA will have too few pixels to work with.

/Björn

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





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

Re: [osg-users] github not synchronized

[Björn Blissing]

Hi Robert,

When I cloned the code from the GitHub source I discovered that the 
OpenSceneGraph-3.4.0 tag is missing. The code is there, but the tag is missing. 
All other tags seem to be present, but for some odd reason this tag has not 
been synced correctly from the SVN repo.

I solved it by manually finding the corresponding SVN commit which corresponds 
to the 3.4.0 tag:
https://github.com/openscenegraph/osg/commit/7d9536b463a41a35ed4a65d6510e220e90721d28

If it is deemed important enough I guess it could be added manually? But I 
guess it falls quite far down on the priority list...

Cheers,
Björn

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





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

Re: [osg-users] github not synchronized

[Björn Blissing]

Hi Robert,


Will this affect the submission protocol? I.e. will pull-requests at GitHub 
replace the osg-submission mailing list?


/Björn


Från: osg-users  för Robert Osfield 

Skickat: den 12 november 2015 10:36
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] github not synchronized

On 12 November 2015 at 02:53, Jason Beverage 
> wrote:

So is Github going to be the new official home of osg?

That's my plan.  Will be updating the website soon, but have client work to get 
done right now so will tackle this once I've got a bit more free time.

Robert.

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

Re: [osg-users] Anyone Experimenting with OSVR

[Björn Blissing]

Hi David,

I looked at it a couple of months back. My hope was to generalize my Oculus 
integration to be able to use OSVR as well. But due to lack of time and lack of 
an OSVR HMD for testing I had to abandon my efforts. 

Regards
Björn

>-Original Message-
>From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>Behalf Of David Glenn
>Sent: Monday, November 09, 2015 11:27 PM
>To: osg-users@lists.openscenegraph.org
>Subject: [osg-users] Anyone Experimenting with OSVR
>
>Greetings All!
>
>Is anyone experimenting with OSVR yet?
>
>I know that there is some Oculus stuff that people have tried with some
>limited success, but just wondering if anyone looked at it from the OSVR
>standpoint!
>
>...
>
>Thank you!
>
>Cheers,
>David
>
>
>David Glenn
>---
>D Glenn 3D Computer Graphics Entertainment.
>www.dglenn.com
>
>--
>Read this topic online here:
>http://forum.openscenegraph.org/viewtopic.php?p=65589#65589
>
>
>
>
>
>___
>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] Oculus+OSG

[Björn Blissing]

Chris Hanson wrote:
> Is the additional performance penalty for OGL apps (versus DX) from context 
> sharing still an issue?


Well, I still see some frame drops in the OpenGL example compared to the 
DirectX version, which is running without any drops at all. But it's much 
better compared to the previous SDK version. Now I am getting a frame drop 
maybe once every 2 minutes compared to getting drops every other second.

Best regards
Björn

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





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

Re: [osg-users] Visual Studio 2015 3rd_party

[Björn Blissing]

Chris Hanson wrote:
> That's similar to what our build system does. Ours has some additional steps 
> to fetch from source and deal with applying localized patches in case there 
> are API disagreements between versions of the 3rdparty code and OSG and such.
> 
> We're hoping to release our build tools once we get them dusted off and fixed 
> up.


In our case we only included the 3rd party dependencies we needed for our 
internal projects. Then I added some more that were easy to integrate. 

Others such as GDAL, CURL etc that use rather complex build processes have been 
left out. But I recently discovered the "ExternalProject_Add" function in 
CMake, which (at least on paper) looks like a way to integrate those as well.

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> NOTE: Oculus SDK and Runtime 0.8.0.0 beta have just been (quietly) released.
> 
> Christian


Hi Christian,

I have already made the (minor) changes needed. And these commits have been 
pushed to the master branch at GitHub.

Best regards
Björn

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





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

Re: [osg-users] Visual Studio 2015 3rd_party

[Björn Blissing]

Chris Hanson wrote:
> We're working towards getting our own in-house build system up to modern 
> compilers shortly.


Hi Chris,

On a related note. I have tried to automate the building of the 3rd party 
dependencies via a toplevel CMake script which builds the desired dependencies 
from source. And then via the install feature collects the relevant headers, 
libraries and DLLs into one directory.

The project can be found here:
https://github.com/bjornblissing/osg-3rdparty-cmake 

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Riccardo Corsi wrote:
> thanks Björn for the MSAA pointer - it was not the cause of the issue but the 
> explanation on the 75Hz helped me solve the problem:
> I had to remove the V-sync setting from the driver configuration. 
> 


Ok, I guess you had your V-sync setting to "Force on". Otherwise this should be 
handled with code inside the osgoculusviewer.


Riccardo Corsi wrote:
> So to keep a smooth experience the osg application must be able to render at 
> 75Hz for both eyes - is that correct?
> This is an important tip to keep in mind...


To cite "VR Design : Best Practices":

"PERFORMANCE, i.e. FRAME RATE, IS KEY
the difference between 75fps and 30fps is night and day…
you MUST deliver 75 fps at a minimum
don’t ship until you hit this bar
this isn’t an average, its a floor : so target 100fps average
this isn’t a luxury, its a requirement."

Source: http://dsky9.com/rift/vr-design-best-practices/

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Ricky,

We have recently added support for MSAA in the OsgOculus integration (credits 
to Chris Denham). Rendering with MSAA enabled will require some extra GPU horse 
power and is probably the reason you see the stuttering in the rendering. If 
you look at the performance HUD (by pressing '2' on the keyboard), you will see 
what frame rate the compositor is working with. Anything under 75fps will cause 
stutter (on the DK2) and the performance HUD will report by incrementing the 
value: "Compositor Missed V-Sync Count".

To disable the MSAA change this line to a zero (or you could try to lower the 
amount to 2 and see if that helps):
https://github.com/bjornblissing/osgoculusviewer/blob/d0c425d3eda01b8134518ef524906e736a6aed9b/src/viewerexample.cpp#L50

This is probably also related to the flickering you are seeing. 

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

I just fixed a performance related bug. 

Due to misuse of an enum I had accidentally disabled all culling. (This bug 
would probably been avoided if strongly typed enum a'la C++11 were used).

This bug only affects users using Oculus SDK 0.6 and 0.7. I urge all users of 
these versions of OsgOculusViewer to update to the head revision on GitHub.

Best regards,
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
> 
> Oh careful there.
> 


Not my words, I was only quoting the author of the videos.


Jan Ciger wrote:
> What he is actually showing is the effect of the asynchronous timewarp - if 
> you can't hit the framerate, you reproject/warp the previous frame. That's a 
> fairly new thing which required the driver support - you need to preempt the 
> current rendering command stream if you aren't going to hit the target and 
> re-project the old frame.
> 
> The original idea of timewarping was to reduce the apparent tracking latency 
> by warping the rendered image to match the tracking data late in the frame. 
> That is what I was referring to - I doubt the latency reduction in the case 
> of positional tracking is worth the effort, because the tracker is running at 
> a comparable/same speed as your application.
> 


In the "Oculus Rift Developer Guide" you will not find a word about 
asynchronous time warp. They are only saying that the compositing framework is 
handling distortion, timewarp, and GPU synchronization, whatever that incurs... 

I don't know if this means that Oculus currently are doing pure "original 
timewarp", pure "asynchronous timewarp" or a combination of the two (since its 
all happening inside the closed source part of the Oculus SDK). But the feature 
shown in the videos is currently available.

/Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
> It is described in this post (that you have mentioned too):
> https://developer.oculus.com/blog/asynchronous-timewarp-examined/
> It was one of the reasons they had to go to Nvidia (the other being
> the direct mode support), because it is not possible to implement it
> without driver support.


I feel that you are misunderstanding what I am trying to say. I will try to 
reformulate myself.

First of all, we have two types of warping that could be performed:

1. Rotational - A pure 2D transformation, we only need a color texture for this.

2. Positional - A 3D re-projection were every pixel has to be transformed with 
its depth taken into account. This requires us to have a color texture, a depth 
texture and the projection matrices used.

Both techniques can be used either in sync with rendering (as was performed 
with rotational timewarp in SDK0.5 and earlier) or in a separate thread. The 
benefit of having it in a separate thread is that we can handle the case of the 
rendering is not done when the HMD requires a new image. But with the drawback 
that it requires low level support in OS/Driver. 

I concur with your conclusion that it is highly likely that Oculus are in fact 
using the asynchronous solution in the SDK0.6 and 0.7, BUT they have not stated 
officially that the are using this. In theory positional re-projection could be 
done in synchronous rendering (although unlikely). 

/Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> 
> did I understand correctly that the time warping feature cannot be disabled, 
> as it is a built-in feature of the Oculus SDK?
> 


My understanding is that time warp is enabled by default. And I have not found 
a simple way of disabling it. I have posed a question on the Oculus forum, but 
have not received any replies, yet.

But when I have read some more about how positional time warp works I 
discovered that to be able to use it the compositing layer must of type 
ovrLayerType_EyeFovDepth. And currently the osgoculusviewer is using the 
simpler ovrLayerType_EyeFov layer type, which only supports rotational time 
warp.

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> let me use this thread to suggest a new feature. I would like the positional 
> tracking of the osgoculusviewer to be optional, possibly by calling a member 
> function oculusDevice->setPositionTracking(false);
> 


Hi Christian,

I have now added the feature to toggle the positional tracking (using the X-key 
on the keyboard). The state is handled inside the event handler which calls the 
following function in OculusDevice:


Code:
void OculusDevice::setPositionalTrackingState(bool state)



Best regards,
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
> 
> Hum, alright. I was searching the documentation and the changelogs for
> this but haven't seen it mentioned anywhere.


Hi Jan,

You will find it on page 22 in the 0.7 developer guide. It is a bit hidden 
inside the ovrLayerType_EyeFov description, the section about DepthTexture:

"Provides depth data for the EyeFovDepth layer type, and is used by positional 
timewarp to try to apply the correct parallax for the layer..." 

Michael Antonov also mentions it in a post on the Oculus blog:
https://developer.oculus.com/blog/asynchronous-timewarp-examined/

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
> That blog post I remember, but the conclusion there seems to be that 
> positional timewarp introduces occlusion artifacts and a lot of extra 
> complexity. I didn't sound like something they are intending to implement at 
> the time.
> 


Hi Jan,

One reddit user made two short videos to display the effect of positional 
timewarp. Both a normal case and one extreme case (pushed to fail).

In the first video the frame rate is artificially dropped. Then he toggles 
between positional timewarp on/off, to show how this trick can alleviate a 
frame rate drop and still do some minor movement without stutter:
http://zippy.gfycat.com/JealousMeagerKestrel.webm

The second video shows what happens if you move to much. Here rendering is 
frozen and the HMD user continues to move until the effect fails miserably:
http://giant.gfycat.com/AgileThatGraysquirrel.webm

The author wrote the following description:
"Timewarp is a way of distorting the image the HMD receives in the event that 
the simulation can't keep up with the target frame rate or refresh rate of the 
device in order to compensate. So, motion-to-photon latency and headtracking 
will appear to remain consistent, even if your framerate is fluctuating. This 
helps to alleviate jitter. This, however, was only previously possible for 
rotational tracking in a prior Oculus SDK. Now the distortion is possible for 
positional tracking as well. Both have their limits of course -- you can only 
move so much before the scene becomes terribly warped. It's meant to cover for 
momentary or tiny dips in frame rate -- not for massive ones that last a while. 
"

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Jan,

Since SDK 0.6 Oculus have implemented both rotational AND positional timewarp. 
The positional time warp require you to submit both a image texture as well as 
a depth texture. This depth texture is then used to calculate the tiny parallax 
effect due to movement between render and presentation. 

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Christian,

Well, the simplest way of disabling the positional tracking is just to 
physically cover the lens of the Oculus Camera. ;) 

I could make an option to disregard the positional information from the Oculus 
SDK. But since the new compositor framework introduced in Oculus SDK 0.6 the 
time-warp feature is enabled by default. So even if we don't use the positional 
information from the SDK, the positional information would be used in warping 
of the image (postional timewarp). So depending on how you overlay your video 
feed you may get strange juddering because of this feature.

Best regards,
Björn

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





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

Re: [osg-users] Open Scene Graph 3.4.0 has bug when using two monitor setup

[Björn Blissing]

Hi Thomas,

I am running Windows 7 64-bit with dual screen setup (2 screens running at 
1280x1024). I have no problems with the osgviewer in 3.4.0 version. I have 
tested with both small and large models. I can display the image spanned over 
both screens or on one screen at the time. No crashes here...

Currently running a nvidia GTX 700 card with the 355.83 beta drivers (The 
reason for the beta drivers is to be able to use the latest Oculus SDK).

Do you get this problem with all models? The simple cow.osg or dumptruck.osg 
for example. 

Or does the crash happen with some specific model?

Best regards,
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> Trying to build the current osgoculus master branch against Oculus SDK 
> 0.7.0.0 using OSG 3.2.1
> 
> 
> the following code from oculusdevice.cpp is making trouble. For OSG 3.2  the 
> variable "ctx" is undefined.
> 
> void OculusTextureBuffer::setRenderSurface(const osg::State& state)
> {
> #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
>     const osg::GLExtensions* fbo_ext = state.get();
> #else
>     const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx, 
> true);
> #endif
> ...
> 
> void OculusDepthBuffer::setRenderSurface(const osg::State& state)
> {
> #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
>     const osg::GLExtensions* fbo_ext = state.get();
> #else
>     const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx, 
> true);
> #endif
> ...
> 



cbuchner1 wrote:
> A followup: inserting the following line into both #else branches fixes it
> 
> const unsigned int ctx = state.getContextID();
> 


Ah, the woes of trying to have support for multiple OSG version at the same 
time. I did some refactoring yesterday and this bug obviously slipped through 
without being tested. Sorry about that. 

Another user already submitted a pull request with a fix, which is merged.

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> Can you make any statements regarding latency improvements upgrading from the 
> 0.6 SDK to 0.7 for osgoculusviewer based applications?


Hi Christian,

I have not had time to do any measurements regarding latency differences 
between 0.6 and 0.7 yet. Sorry.



cbuchner1 wrote:
> Our current use case is currently, attaching an Intel RealSense camera to the 
> front of the Oculus DK2 and streaming a live image into the viewer's eyes. 
> Our latency is currently in the area of about 3-4 video frames @75 Hz, 
> amounting to 40-50 ms. This is a bit too high and causes some motion sickness 
> and slow reactions in our unfortunate test persons. ;)


Are you talking about pure rendering latency (motion to photon) or the camera 
to HMD latency (photon to photon)?

If you are talking about the latter 40-50 is quite good I would say. And as Jan 
says, the camera is probably the limiting factor in that case. Another problem 
can be if you run the camera capture in the same thread as the rest of the 
rendering. Moving the camera capture to an own thread gave me a great 
performance boost, but results in the cameras running asynchronous with the 
rendering. This in turn can gives a larger variance in latency.

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Christian,


Well, I don't know how the OSG-DirectShow plugin works regarding threading and 
latency.


When I did a similar setup I used OpenCV and wrote a plugin that spawn a thread 
for image acquisition. Here is my code:

https://github.com/bjornblissing/osgopencv


Hopefully the new Oculus SDK has cut the latency a bit, BUT this does not 
matter much if the main part of the latency comes originates from the image

acquisition.


Best regards

Björn


Från: osg-users <osg-users-boun...@lists.openscenegraph.org> för Christian 
Buchner <christian.buch...@gmail.com>
Skickat: den 1 september 2015 14:57
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] Oculus+OSG


In this case I am using a slightly modified DirectShow OSG plug-in, running the 
osgviewer in single threaded mode. The plug-in provides an osg::ImageStream and 
updates a texture that is displayed in the OSG scene. The camera is an USB 3.0 
model, and I would expect it to be one of the fastest "web cams" out there.

I am hoping that OpenGL applications also benefit from the low level driver 
support created for the Oculus and similar VR devices.

Christian


2015-09-01 12:48 GMT+02:00 Björn Blissing 
<bjorn.bliss...@vti.se<mailto:bjorn.bliss...@vti.se>>:

cbuchner1 wrote:
> Can you make any statements regarding latency improvements upgrading from the 
> 0.6 SDK to 0.7 for osgoculusviewer based applications?


Hi Christian,

I have not had time to do any measurements regarding latency differences 
between 0.6 and 0.7 yet. Sorry.



cbuchner1 wrote:
> Our current use case is currently, attaching an Intel RealSense camera to the 
> front of the Oculus DK2 and streaming a live image into the viewer's eyes. 
> Our latency is currently in the area of about 3-4 video frames @75 Hz, 
> amounting to 40-50 ms. This is a bit too high and causes some motion sickness 
> and slow reactions in our unfortunate test persons. ;)


Are you talking about pure rendering latency (motion to photon) or the camera 
to HMD latency (photon to photon)?

If you are talking about the latter 40-50 is quite good I would say. And as Jan 
says, the camera is probably the limiting factor in that case. Another problem 
can be if you run the camera capture in the same thread as the rest of the 
rendering. Moving the camera capture to an own thread gave me a great 
performance boost, but results in the cameras running asynchronous with the 
rendering. This in turn can gives a larger variance in latency.

Best regards
Björn

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org<mailto: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] Oculus+OSG

[Björn Blissing]

Hi,

I am happy to report that support for Oculus SDK 0.7.0.0 is added and merged 
into the master branch.

The latest Oculus SDK v0.6 development has been merged back into the 0.6 branch:
https://github.com/bjornblissing/osgoculusviewer/tree/sdk-v0.6

Best regards 
Björn

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





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

[osg-users] Executing code before gl context is closed when viewer is shutdown

[Björn Blissing]

Hi,

More odd questions connected to my Oculus integration.

Is there a simple way to detect when the osg::viewer is ordered to close? I 
need to execute some Oculus related code before the OpenGL context is closed. 
So what I am looking for is some form of opposite of 
viewerBase.setRealizeOperation() function.

My first idea was to subclass the osg::GraphicContext class and run my own 
custom destructor before the default constructor. But that idea is a no go, 
because the OS dependent windowing APIs are already implemented as subclasses 
to osg::GraphicContext.

Best regards
Björn

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





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

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

I am happy to report that support for Oculus SDK 0.6.0.1 is now complete.  This 
has now been merged into the master branch at GitHub.

The Oculus SDK v0.5, which is the last version supporting MacOS and Linux has 
been branched to:
https://github.com/bjornblissing/osgoculusviewer/tree/sdk-v0.5

Best regards
Björn

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





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

Re: [osg-users] Advice on how to best inject behavoir regarding FBOs

[Björn Blissing]

Hi Robert Milharcic,

Thank you for your suggestion. But during my debugging session I discovered 
that the only thing I actually need was to get the FBO handles, once it was 
created. So I used the above sequence to get it from the osg::RenderStage, 
while still letting osg handle the initialization and destruction of the FBO's.

Your solution would let me get the FBO handle directly, but the main drawback 
would be that I have to do FBO initialization, handling and destruction on my 
own. This maybe useful in the future, but for now it is sufficient to just get 
the FBO handle.

Thank you!

Best regards,
Björn

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





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

Re: [osg-users] Advice on how to best inject behavoir regarding FBOs

[Björn Blissing]

Hi Jan,

I read the notice about the upcoming v0.7 release as well. My understanding of 
their text is that the new DirectDriver model would NOT replace the current 
direct mode. Instead the DirectMode would be the fallback option for those with 
graphic cards which do not support the new DirectDriver model (ie. Nvidia Card 
before Kepler and AMD cards before GCN). So instead of extended mode and direct 
mode, we will have direct mode and DirectDriver mode. This is supported by the 
following reddit post by one of Oculus Engineers:
https://www.reddit.com/r/oculus/comments/3g4rk7/pc_sdk_07_coming_august_20/ctv0hka

So I still think it may be a good idea to have v0.6 support up and running 
before the v0.7 release. But maybe that just me being a masochist. 

And I suspect that the FBO solution is something that would be present in the 
v0.7 release as well. So I still think a solution to the problem with 
initializing FBOs outside the osg::RenderStage::CameraSetup function is needed.

Best regards

Björn

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





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

Re: [osg-users] Advice on how to best inject behavoir regarding FBOs

[Björn Blissing]

Hi Robert,

Well, I was hoping to be able to do the integration without modifications to 
OSG. If such modifications proves to be necessary, then I agree with Jan that 
we should wait for v0.7 to see if that integration is easier. It seems 
unnecessary to change OSG for a problem that may disappear in later Oculus SDK 
versions.

But I am happy to report that I have a working, flicker free solution. Although 
I had to make a rather cumbersome call inside my pre draw camera callback to 
get the FBO handle:


Code:

osg::Camera* camera = renderInfo.getCurrentCamera();
osgViewer::Renderer *camRenderer = 
(dynamic_castosgViewer::Renderer*(camera-getRenderer()));
if (camRenderer != NULL) {
  osgUtil::SceneView* sceneView = camRenderer-getSceneView(0);
  if (sceneView != NULL) {
osgUtil::RenderStage* renderStage = sceneView-getRenderStage();
if (renderStage != NULL) {
  osg::FrameBufferObject* fbo = renderStage-getFrameBufferObject();
  GLuint fboHandle = fbo-getHandle(ctx);
}
  }
}




This also forced me to link with osgUtil. I don't know if there is a simpler 
way of getting the FBO handle, which does not involve osgUtil?

Best regards

Björn

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





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