Re: [osg-users] Integrate Qt into OSG - not OSG into Qt osgQt

[Jan Ciger]

Hello,

On 02/10/2019 15:23, Trajce Nikolov NICK wrote:
> Hi community, 
>
> I am struggling with the design of such a task. And I am a bit
> familiar with Qt and other UI frameworks. The task is to embed the
> whole Qt framework into OSG - including the event processing and let
> OSG render ( through RTT ) the widgets content.
>
> Any clue, hints what direction I should take?
>
> Thanks a bunch as always!
> Nick


Ufff, you are in for quite a battle, I am afraid. I have done this few
years ago when we were using Ogre and OSG for our virtual reality
simulators at work and we needed a proper UI framework to display user
interfaces inside the application. 

You have basically two options:

a) Render the Qt widget/window into a texture/image, grab that and
display it as an OSG texture. Input from OSG can be fed into Qt's event
system by artificially creating and injecting events.

This works and it is how we have done it. Qt widgets can render
themselves into an image/texture directly, simply by calling their
render() method with proper arguments. We were able to display most Qt
widgets and render QML using OSG textures. Where things get very hairy
is the state management between OSG and Qt (Qt uses its own OpenGL
backend for rendering and assumes that it is in a certain state!) and
then input. When you aren't rendering Qt the usual way by showing
windows on screen but you only call render() and grab a texture, Qt will
not initialize some internal state relating to issues such as cursor,
keyboard focus, state of some widgets, etc.

The result is that you will have problems with cursor disappearing,
widgets not accepting keyboard input, keyboard shortcuts not working and
myriads of other problems like this. It can be solved to some degree by
digging into the Qt's source code, seeing which flags it is relying on
where and then manually calling the necessary functions to ensure that
they are set correctly. We have managed to get it to such shape that the
UIs were usable but if you need a very complex UI you will likely run
into problems. Also OSG's event system doesn't handle anywhere close to
the gamut of input events that Qt does, so a lot of things will have to
be emulated.

b) Implement a new Qt backend running on top of OSG. 

Qt implements several of these backends, including a basic framebuffer
and OpenGL already, that is how they port Qt to different platforms,
such as phones or embedded hardware. This would be probably cleaner
approach if you really need the entire Qt to work but also a lot more
work than the above, because the API is fairly extensive, not super well
documented (this are really the dirty guts of Qt you aren't supposed to
normally see)  and may not have a completely straightforward mapping to OSG.

Good luck,

Jan







signature.asc
Description: OpenPGP digital signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Advice requested: Is OSG what I need for my project?

[Jan Ciger]

On Thu, 13 Sep 2018 at 14:45, Scott Schultz  wrote:

> ;tldr version:
>
> Given a start point and end point, can OSG give me a list of collisions
> with geometry along the specified line segment?
>
>
 Sure it can do that. There is even an example in the repository for it:
https://github.com/openscenegraph/OpenSceneGraph/blob/master/examples/osgintersection/osgintersection.cpp

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

Re: [osg-users] sign language avatar with osg

[Jan Ciger]

On Sun, Mar 11, 2018 at 9:18 PM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> Hello Community,
>
> I carry this idea with me from my UNI days (which is about 20 years ago)
> and since recent it was just an idea. Over time it was even close to get
> some funding but it did not happen.
>
> The idea is to have virtual 3D avatar that can "speak" the sign language
> based on text or voice input. The recent technology from Google made the
> realization of  the language translation doable.
>
> So I am here to ask you if someone might be interested in actually make
> this happen. I personally work with an artist (friend of mine, decades of
> friendship, also worked together on various projects). And we want to do
> this opensource, based on OSG.
>
> All suggestions, brainstorms, hints, anything, are highly welcome!
>
> Cheers,
> Nick
>
> --
> trajce nikolov nick
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>

Hello,

Before you commit significant time into this, do some state of the art
research. This topic has been done quite a few times before, including
attempts at the automatic translation:
https://www.google.fr/search?q=sign+language+virtual+human

If your goal is to bring a product to the market, there is a lot of
material there to get you started. If it is for research purposes, then you
are going to have tough time bringing some new ideas there.

Regards,

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

[Jan Ciger]

Hello,

On Mon, Oct 23, 2017 at 12:03 PM, Gianluca Natale 
wrote:

> Hi all,
>
> We have the requirement to implement VR in our applicaton, that is
> currently completely based upon OSG 3.0.1 (I do know that it is a bit old,
> yes!).
>
> Specifically, we would need to support HTC VIVE VR displays.
> I do know we have to allocate a quad buffer for that, I mean let OSG
> allocate a quad buffer.
>
> Did anybody already try to develop an OSG based application for VIVE VR
> display?
>
> Is there an example that I can look at, as a good starting point?
>

You will need to integrate the SteamVR SDK. Vive does not use quad buffer
rendering. Roughly speaking, you will need to render a large buffer
containing images for both eyes (side-by-side stereo) pre-distorted to
match the distortion of the optics in the HMD. The SDK provides the tools
for doing this.

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.

Another option is the OSVR toolkit - their Render Manager supposedly
(didn't test it myself) works with Vive and it may be easier to integrate.

Regards,

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

Re: [osg-users] Obj model visualization using osg

[Jan Ciger]

On Tue, Oct 10, 2017 at 11:11 AM, Jai Singla  wrote:

> Hi Chris,
>
> Yeah correct. we have some engine models designed in CREO SW in which all
> parts are explicit modeled. Now , How we can achieve exploded view and
> again parts assembly and experience it using HMD devices?
>
> Any video recording and animation will be add on .
>
>
> Is there any plugin or utility in open source domain to achieve the same?
>
>
I am afraid that there is no "magic plugin" or utility, even less open
source, especially when it concerns CAD models. You will have to program
this, animating procedurally the translations/rotations of the parts as you
need. There will likely be also some interaction needed so that the user
can manipulate the model, etc. This is all very much application specific,
so you likely won't find a generic tool doing this.

And it also depends heavily on what software you are using for driving the
HMDs. And also which HMD - e.g. Vive or Oculus Rift don't have the same API
and while e.g. Unity3D tries to abstract away the differences, you will
still need to deal with them.

Regards,

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

Re: [osg-users] Investigating using OSG as a graphics backend for our real-time physics simulation system

[Jan Ciger]

On Mon, Jun 26, 2017 at 4:07 AM, Chris Hanson  wrote:

> Magnum looks pretty cool. I'd be a little worried about the maturity of
> the codebase, but if it does what you need, try it out and let us know how
> it compares.
>

I have looked at it as well, but it looks very much like a one-man project.
Most of the 18 Github contributors have submitted only a patch or two. It
could be a very nice engine but I would be worried about its longevity -
the moment the principal developer moves on to something else it will
likely die. May not be a concern for a one-off project but I would have to
think very hard before getting invested in it too deeply - one could end up
maintaining that project too or face another migration to a different
engine.

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

Re: [osg-users] Investigating using OSG as a graphics backend for our real-time physics simulation system

[Jan Ciger]

Hello,

I am sure Robert as the project's leader could give better answers, but
here is what I have learned in my use of OSG over the years.

On Fri, Jun 23, 2017 at 12:33 AM, Andy Somogyi 
wrote:

> Hi All,
>
> We're evaluating using OSG as a possible graphics backend for our
> real-time physics simulation project, and I've got a few questions:
>
> * We suport Mac, Windows and Linux, how good is cross-platform support
> with OSG?
>

OSG runs on pretty much anything that has OpenGL implementation and working
C++ compiler. At the very least Mac, Windows, Linux, & Android are
supported.


>
> * It looks like it’s pretty easy is it to hook up Magnum to an existing
> native window, just would like to confirm. Say on Windows, I create a new
> Win32 window, or on Mac I create a Cocoa window, is it possible to hook up
> OSG to that window. I know that I'll have to grab the window events (mouse,
> resize, etc...) in my app and forward them to OSG, that's not a big deal.
> We'll be using the native toolkit on each platform for the gui, i.e. WPF on
> Windows, Cocoa on Mac and GTK on Linux, so it's important that we can hook
> up our rendering code to native windows.
>

AFAIK, yes - there are examples for doing this in the OSG source code.



> * Much of our application will entail displaying highly dynamic deformable
> elastic surfaces and particle systems with programmatically generated
> textures, do you thing OSG is a good fit? Does OSG have mesh node types
> where it’s easy from the CPU side to update vertex positions and add/remove
> vertices?
>


osg::Geometry is what you want. Alternatively you could create your own
shape type and do the rendering exactly as you want.



> * We also plan to do a bit of 2D drawing (objects in a tree structure),
> How easy would it be to also use OSG for 2D trees?
>

It can be done but OSG doesn't have much support for drawing 2D primitives,
like lines, rectangles, text and such. You will want to use some toolkit on
top of OSG for doing this unless your needs are really basic. E.g. the Qt
library has good 2D support, if you want some really custom drawing then
Cairo works fine.


>
> * I think a scene graph approach would be a good fit for us, as I’ve
> worked a lot with open inventor in the past. Part of what we'll be doing
> will be constructive solid geometry, similar to OpenSCAD,
> http://www.openscad.org, and a scene graph we think is a good way to
> represent this kind of geometry. There are however some criticisms of scene
> graphs, namely Tom Forsythe’s blog: http://tomforsyth1000.github.
> io/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D



Tom Forsythe's blog is both old and also coming from a totally different
use case. Namely videogame and game engine development. That is very much a
different environment, there it is common to write your own STL
replacement, memory allocators, not use standard library functions and
write as close to the metal as possible in order to squeeze every last drop
of performance. He is railing not so much against scenegraphs but against
using any graphic frameworks.

That is appropriate if you are writing a new engine for every game or at
least significantly "optimizing" it (as it has been common at that time)
but not so much appropriate when the resource constraints are not as tight
and other factors are more important - such as longterm maintainability of
the codebase. A typical game gets shipped and 6 months later nobody has
heard about it anymore. So nobody cares that the code is full of dirty
hacks and kludges because the team has long moved on to something else by
then.

With something like OpenSceneGraph or (SGI's Performer before it) it is
common to support a project for 10+ years. So longterm maintainability of
the codebase is a must. That doesn't mean that the code has to perform
poorly only that squeezing out every last bit of performance is less
important because 6 months later you buy a much faster graphic card anyway.

In the end, I believe the market has proved him wrong. A lot of AAA titles
today are based either on the Unreal Engine or Unity3D (not in the least
due to the very liberal and cheap licensing which hasn't been available in
2011). And both of those engines use scene graph architecture, at least in
part.

* It would appear that Apple, in their infinite wisdom (sarcasm) is slowly
> deprecating OpenGL in favor of metal. In the future, do you think OSG could
> have different backends (metal, directx)?
>

I believe the standard will be Vulkan, Metal is Mac specific, I don't see
that getting much of a traction outside of Mac community so for a
cross-platform toolkit it is a nonstarter. Microsoft has managed to get
their DirectX out there at the time by both actively sabotaging OpenGL
implementation in Windows and by dominating the market, so vendors didn't
have much choice but to support it. Apple is nowhere near that position.

I don't think OSG will get backends for 

Re: [osg-users] Crash on Windows 10 with a Display Link adapter

[Jan Ciger]

Hello,

On Thu, Apr 27, 2017 at 11:03 AM, Fabien CLaudot  wrote:

> Hi,
>
> We have a crash in OSG in the following setup :
> -   Microsoft Surface Pro 4 with Windows 10.
> -   Application is displayed on a deported screen using a Display link
> adapter (Main screen is off).
>
> 




> We get these error messages : Windows Error #127: [Screen #0]
> ChooseMatchingPixelFormat() - wglChoosePixelFormatARB extension not found,
> trying GDI. Reason: The specified procedure could not be found .
>
> Error: OpenGL version test failed, requires valid graphics context.
>
>
 That looks very much like a driver problem. The application failed to
create a proper OpenGL context that OSG needs, so the application crashes.
The DisplayLink adapters are an external GPU and it may not support OpenGL
properly.

You are not the only one having problems with these adapters and Windows 10:
http://support.displaylink.com/forums/287786-displaylink-feature-suggestions/suggestions/17299984-i-need-full-opengl-support

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

Re: [osg-users] [ A Stack Overflow for OSG? ]

[Jan Ciger]

On Thu, Mar 9, 2017 at 2:56 PM, Johny Canes  wrote:

> Stop attacking me though lol
>

Nobody is attacking you. I suggest that if you want to be taken seriously
then you should stop acting like a petulant, immature child. Insults and
constant profanity whenever something isn't to your liking are not a
substitute for arguments (applies to Valerian as well!). This is not a Call
of Duty where you can just bury someone you don't like in insults and think
it is great fun.

If you want to be treated as a professional then start behaving like one.
Otherwise you are only wasting time of the people who are still trying to
answer your questions (most of which, honestly, could be answered in 10
minutes of googling), despite of your attitude.

Regards,

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

Re: [osg-users] [ A Stack Overflow for OSG? ]

[Jan Ciger]

On Wed, Mar 8, 2017 at 5:05 PM, Johny Canes  wrote:

> Dude shut the fuck up lmao
>


How old are you, Johny?

*facepalm*

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

Re: [osg-users] Up to date tutorials for linux

[Jan Ciger]

On Thu, Mar 2, 2017 at 3:37 PM, Robert Osfield 
wrote:

> It looks like there is an error relating to the osgQt module/cmake's
> Qt4Macros.  Either Cmake or Qt might have changed since we made the
> 3.4.0 (a year and half ago.), or perhaps debian's combination of these
> wasn't tested during the OSG-3.4.0 testing cycle.
>


That looks like a CMake bug, IMO - there is an internal error being
reported by CMake. Debian doesn't have the most recent software, CMake 3.0
is a few years old. If Qt4 support is needed for some reason and cannot be
turned off, I would suggest downloading/building a newer version of CMake
first.

Regards,

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

Re: [osg-users] Up to date tutorials for linux

[Jan Ciger]

Hello Rodrigo,

On Wed, Mar 1, 2017 at 10:57 PM, Rodrigo Dias  wrote:

> Without clear instructions for Linux starters, I first downloaded the
> OpenSceneGraph-3.4.0.zip. Then I unzipped it and tried to compile using
> make/cmake. No success. Then I tried sudo apt-get install
> libopenscenegraph-dev openscenegraph. Not sure if the first is in conflict
> with the second, or where to find the proper libraries, includes, etc.
>
> If you do a FREE, OPEN SOURCE project, I think you should have more
> Tutorials other than Windows and Mac OS. I will post some broken links as
> long as I'm allowed.
>


To send the ball back to your court - without a clear report of what
exactly went wrong it is a bit difficult to help you. "No success" is not
very informative. Neither is demanding more tutorials without saying what
didn't work with the existing documentation.

You didn't say what went wrong (any error messages?), neither whether you
have installed all the dependencies (and disabled the ones you don't
have/want using CMake). You need to give people a bit more information if
you actually want help.

OSG is very easy to build on Linux, especially because most of the
dependencies are available compiled in the distribution repositories.
However, it expects that you know how to compile software using the CMake
build tool.

BTW, don't install libopenscenegraph-dev from the distribution repositories
if you want to compile your own OSG - that package is part of a
prepackaged/precompiled (and likely fairly old) OSG version comping with
your Debian. That will interfere with building your own, because the header
files and libraries will get mixed with the ones you are trying to build.

Regards,

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

Re: [osg-users] [ A Stack Overflow for OSG? ]

[Jan Ciger]

On Thu, Feb 23, 2017 at 12:31 PM, Johny Canes  wrote:

>
> Meh
>
> On first sight this place looks kind of meh. It doesn't seem to facilitate
> anything. Take it from me, I saw this place as an anthill. I wanted to drop
> my shit, get condescended by Robert.


Maybe if you cut down on the ego tripping, rudeness and profanity and
communicate like a normal person and not like a ghetto kid you would have a
different experience. Nobody owes you anything here.


> Why do all these new posters have accents


I hope you like my e-mail accent. I wonder how is my Slovak coming through
on your side? You do realize that probably the majority of the people in
the forum and mailing list are not from English speaking countries?


> and use shitty forum titles that do not lend itself to being searched?
>

Sorry, but the fact that you don't know how to use Google (which indexes
the mailing list archives and thus forums too) or to use the mailing list
archives is not really their fault ...

For example, here:
https://www.mail-archive.com/osg-users@lists.openscenegraph.org/

Or simply type in the Google search box:
"I saw this place as an anthill" osg-users

One result:
https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg74117.html

What is not lending itself to being searched?

Regards,

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

Re: [osg-users] [ A Stack Overflow for OSG? ]

[Jan Ciger]

On Mon, Feb 20, 2017 at 9:34 AM, michael kapelko  wrote:

> Hi.
> I would says from my personal experience that stackoverflow is a great
> place to find answers to common questions and, what's more important, to
> see most upvoted answers.
> Mailing list/forum doesn't have that.
>
> I would also say that moving to Stackoverflow from Mailing list/Forum is
> like moving from self-hosted SVN to Github: the idea is the same, but
> implementation is more convenient (e.g., no need to attach complete files
> where you only need a tiny pull request).
>
> Thanks.
>

You are forgetting that the mailing list is not only for supporting
users/answering questions. For that SO is indeed useful. However, SO is
completely useless as a medium for having a discussion - such as this one.
In fact, such topics get routinely locked there as not being constructive.

Also the mailing list is not a bug tracking system (like the issues page on
Github). Ever tried to have a meaningful discussion using the issues system
there? In fact, that is the part of Github that is the most heavily
criticized and hated, because it is neither a proper bugtracker (lacks more
advanced features to track/assign/classify the problem reports) and neither
a proper discussion forum.

Then there is the aspect of convenience. From my experience as a developer
supporting a few projects, I don't have means nor time to check 10
different websites with 10 different systems every day for what is new and
who needs help. I wouldn't be doing anything else. Email may sound archaic
but it is a great timesaver - because the issue comes to me instead of me
having to search for it. On many forums people are whining that their
questions are not being answered - guess why. If the developer doesn't come
there and read the entire forum every day (super time consuming!), they may
never see it.

Setting up notifications is not really a solution - it still requires you
to context switch, load that page, remember what login you had for that
system, answer the issue - in the same time two or three things could have
been handled already if I was able to use email directly - especially when
I am doing it on my own time. This is why e.g. Github allows to reply to
issues by email as well.

I encourage anyone suggesting that the list moves to some new shiny thing
XY, because it is better/nicer/more modern/I don't like e-mail/forum/etc to
consider these issues in the future. You are getting free support, so
making the life easier for the project leads like Robert is probably the
least they can ask for in exchange.


All the best,

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

Re: [osg-users] [ A Stack Overflow for OSG? ]

[Jan Ciger]

Hello,

On 17/02/17 20:23, Johny Canes wrote:
> Hi,
> 
> It's a bit of a ruty archaic combo - a phpbb forum backed by a
> mailing list. Nobody has any respect for this place, meaning
> everybody just posts questions instead of searching for a generic
> problem domain.
> 
> Thank you!

What makes you think that replacing the technical infrastructure
(forum/mailing list) will magically fix what is, by your own admission,
ultimately a human attitude problem?

These questions and suggestions about Stack Overflow come at least once
or twice a year - along with the answers why it is not a good idea. Did
you read them? The mailing list is not only for answering developers'
questions.

Best regards,

Jan




signature.asc
Description: OpenPGP digital signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdParty] OSVR and Steam (with the osg sample)

[Jan Ciger]

On Fri, Feb 10, 2017 at 2:23 PM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> Thanks Jan .. Yes indeed, this become OSVR specific .. I will write you
> off-list
>

OK, no prob.

BTW, Ryan Pavlik, the CTO of Sensics is probably on this list too, he is
the best authority on OSVR :)

However, I suggest using their official support channel first:
https://gitter.im/OSVR/home

Regards,

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

Re: [osg-users] [3rdParty] OSVR and Steam (with the osg sample)

[Jan Ciger]

Hello Trajce,

On Fri, Feb 10, 2017 at 2:08 PM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> Hi community,
>
> me again. I am struggling (really first days with this). I know similar
> topics were discussed here so I hope someone will give some hint
>
> I did my home work, web search for answers but no luck. Anyone with
> steps/hints how to make these working together with the OSG
> OSVR-Tracker-Viewer? Or links?
>
> Thanks a lot
>
> p.s. Jan Ciger? :)
>


What exactly are you fighting with?

I don't know much about the HMD support in OSVR, but integration of
trackers is fairly simple - you open a client and then you poll for new
data. I haven't played with OSVR-Tracker-Viewer but I imagine that the code
is along these lines, perhaps calling OSVR from a callback on a node.

Feel free to contact me off-list if it is something OSVR-specific.

Regards,

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

Re: [osg-users] Strange limitation to 60fps

[Jan Ciger]

Hello,

On Mon, Jan 30, 2017 at 11:31 AM, Valerian Merkling 
wrote:

> Hi,
>
> The StatsHandler shows me that I can never get more than 60.00 fps.
>
> I'm mostly running at 59.96 or somethings like this, event with a small
> windows, basic textured quad and a NVidia quadro K4000.
>
> I made lot's of test and tweaks, and I cannot got more than 60.00fps.
> Even with a loop around the frame() call, my statshandler graph looks like
> OSG is waiting between each frame to keep at 60.00fps.
>


 You have most likely VSYNC on. Check the driver settings - the driver can
override the application preferences


Regards,

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

Re: [osg-users] Replies with "Incident ID"'s returned for every post I sent to this list... Is that normal?

[Jan Ciger]

On Tue, Jan 24, 2017 at 3:31 PM, Robert Osfield 
wrote:

> The question is who subscribed supp...@godaddy.com?  Do godaddy.com
> have some robot that goes around adding itself to public mailing
> lists?  Someone playing games?  Some kind of scheme to break things?
>


It could have well been even a disgruntled former client - GoDaddy is not
exactly known for the quality of their customer support or good reputation
...

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

Re: [osg-users] Replies with "Incident ID"'s returned for every post I sent to this list... Is that normal?

[Jan Ciger]

On Tue, Jan 24, 2017 at 2:53 PM, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

>
> Since the member list of the mailing-list is not public, Robert needs to
> check if there is some account registered matching the description.
>
> Cheers
> Sebastian
>
>

Well, considering for how long this is going on already and that the
message is generated for every single post to the list, I would say that
people from secureserver.net or godaddy.com don't really give a flying ..
something about it. Otherwise it would be a 2 minute job to unsubscribe the
offending address from the list for them.

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

Re: [osg-users] [vpb] Buildings

[Jan Ciger]

On 06/01/17 10:02, Sebastian Messerschmidt wrote:
> Are you by any chance Rambabu's little brother?
> ...
> Cheers
> Sebastian

More like a teammate on a student project.

J.



signature.asc
Description: OpenPGP digital signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgconv.exe textures getting mangled

[Jan Ciger]

On Tue, Jan 3, 2017 at 1:49 PM, Rambabu Repaka 
wrote:

> Hi,Iam using osg 3.5.1 version Textures are not loading to the model it is
> showing  Warning: [ReaderWriterOBJ::convertElementListToGeometry] Some
> faces from geometry '' were reversed by the plugin.I converted the model
> into .osgb format but textures are not adding to the model.
>

Do you have the textures correctly applied to your model? I.e. you need the
.mtl file with your .obj and the texture needs to be in the path specified
in the .mtl

Second, the error message about reversed faces means that your model has
inconsistent winding order (clockwise vs anticlockwise). You should check
that because it could mean that your normals will be wrong and faces get
removed/culled by backface culling, making the model either disappear or
have "holes".

Conversion to .osgb won't help you any, because the converter uses the same
obj loader as the viewer. So if it doesn't work with the viewer, it won't
work after the conversion neither.

Regards,

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

Re: [osg-users] About raining

[Jan Ciger]

On Tue, Jan 3, 2017 at 1:57 PM, Rambabu Repaka 
wrote:

> Hi,How to do Wet on the ground when raining in osg ?
>


Ehm, I am not quite sure what do you mean, but I assume that you want to
render wet ground. A big of googling would find this, for example:
https://www.fxguide.com/featured/game-environments-partc/

That should get you started. You will need to write your shaders to provide
the effect you are after. OSG is a scenegraph and doesn't contain every
possible visual effect - but it will let you implement it relatively easily.

If you don't want/can't write this yourself, I suggest you look at engines
like Unity3D or Unreal for your project instead - both have a lot of
plugins and a marketplace where you can buy pre-made tools for almost
anything you want.

Regards,

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

Re: [osg-users] OpenVR, Oculus or HTC - Vive in OSG? Status as of Nov 2016!

[Jan Ciger]

Hello,

On Tue, Dec 13, 2016 at 4:18 AM, Ran Ling  wrote:

> Hi, Jan, I've used osgopenvrviewer too.
> I have some troubles when I try to get a complete mirror on computer
> screen, not divided by left eye and right eye.Because main camera has been
> overwritten by the swap texture.
> Do you have any ideas about this? or any better choice?
> Thank you!
>

I am not quite sure what you are trying to achieve - the HMD needs the
split left/right image, so if you are mirroring that, that's what you will
get. If you want a non-split image, you may have to add an extra camera.

Otherwise, for Rift there is the
https://github.com/bjornblissing/osgoculusviewer which works quite well.

Regards,

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

Re: [osg-users] OpenVR, Oculus or HTC - Vive in OSG? Status as of Nov 2016!

[Jan Ciger]

On Tue, Nov 29, 2016 at 1:01 AM, Chris Hanson  wrote:

> Hey David. I'm working on a project that has both Oculus and Vive support
> via osgOpenVRViewer.
>
>
Any reason not to use the OSVR middleware instead of going directly to
OpenVR? It would give you much wider HW support, both for controllers &
HMDs.

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

Re: [osg-users] Fwd: Unstable passive stereo on Quadro using Quadbuffer

[Jan Ciger]

On 16/11/16 01:06, ZJ Tian wrote:
> Hi, Voerman, 
> 
> Glad to hear your idea.
> 
> I previously made a mistake to assume that there is an automatic frame
> synchronization between the video card and the monitor. Now it appears not.
> 
> I think it do will work by using the monitor's SDK. 
> Thanks for your reminder.
> 

You may not need the SDK initialization (depends on how the display
handles the stereo signal), but at the very least you need the
synchronization cable. Without that it won't work properly.

J.



signature.asc
Description: OpenPGP digital signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fwd: Unstable passive stereo on Quadro using Quadbuffer

[Jan Ciger]

On Tue, Nov 15, 2016 at 11:45 AM, ZJ Tian  wrote:

> Hi, Jan,
>
> You lightened my way. That's the answer I think.
> I will try to work it out though you guessed correctly the display device
> I am unluckily using.
>


You are welcome.

Sadly, these problems are common. The hardware vendors will claim that
their gizmo is perfect, does everything out of the box and, of course, plug
and play. Only when you actually buy it you will discover that the sales
materials neglected to mention that the function you need requires a very
expensive accessory sold extra and made out of unobtanium (because nobody
stocks it - like the mini-DIN connector brackets for Quadros) or that the
function actually works, but it is severely limited to the point of being
unusable because some fool somewhere decided to save $0.1 by eliminating a
connector or shipping non-working firmware ...

I have had these experiences even on very expensive pieces of hardware.
Especially with VR you do have to always test before buying because the
sales brochures and salesmen are never telling the whole story if not lying
outright.

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

Re: [osg-users] Fwd: Unstable passive stereo on Quadro using Quadbuffer

[Jan Ciger]

On Tue, Nov 15, 2016 at 10:40 AM, ZJ Tian  wrote:

> Hi, guys,
>
> I encountered a trouble with passive stereo using quadbuffer.
>


Duh, I am an idiot, should have read more carefully.

If your system uses passive glasses (the non shuttering type) then the
problem is most likely in the setup of your display. If the display is
using sequential ("active") stereo from the Quadro (that's what I assume
since you are using quadbuffer) and converting that to passive, do check
for the presence of the synchronization signal. If you aren't using HDMI
1.4 (or newer) connection, you may have to connect an extra mini-DIN or a
USB cable somewhere. Some Quadro cards require buying of an extra bracket
with a connector for this (like this one:
https://www.bhphotovideo.com/c/product/838382-REG/PNY_Technologies_930_50764__000_Full_Height_Bracket_Stereo.html
)

If it is this display:
http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=c04784690=quickspecs=EN_US==us=en

Then you may be actually out of luck. The DVI-D and DP 1.2 ports don't
support the synchronization signals required, AFAIK. You may want to
contact HP support about it and verify with them.

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

Re: [osg-users] Fwd: Unstable passive stereo on Quadro using Quadbuffer

[Jan Ciger]

Hello,

On Tue, Nov 15, 2016 at 10:40 AM, ZJ Tian  wrote:

> Hi, guys,
>
> I encountered a trouble with passive stereo using quadbuffer.
>

That sounds like your display and glasses are not being correctly
synchronized to the graphic card. For stereo to work in a stable manner the
glasses must know which frame is being rendered by the GPU at any given
moment. That is usually achieved either by the old school 3 pin mini-DIN
cable from the Quadro, synchronization signal being sent using a USB dongle
(like Nvidia 3DVision) or the signal being digitally "tagged" with the
left/right frame tags (recent HDMI/Display Port interfaces versions).

Some systems are "dumb" and don't use this sync signal - typically cheap
DLPLink projectors - and rely only on the stability of the input signal to
not swap the left/right frames while in use. The glasses are only told to
switch between left/right but don't really know which image is being
actually displayed by the GPU, so you have to manually "invert" the stereo
at the start, typically by pushing a button somewhere. That is good enough
for something like Bluray video but not for interactive application where
the framerate is never 100% stable.

I am not familiar with the display and glasses you are using so you will
need to check the manual for your hardware how to set it up correctly.
However, in general, simply enabling quad buffer stereo *is not* sufficient
in itself to obtain a reliable stereo without these glitches. The
synchronization between the GPU and the display/glasses must be in place as
well. Be careful that synchronizing the glasses to the display alone (using
radio, infrared signal, display flashes ...) may not be sufficient if the
display is not actually synchronized with the GPU - that's the case of the
common DLPLink systems, but may exist elsewhere too. If the glasses are not
connected to the GPU directly and are driven from the display (common with
3D TVs and projectors), I would expect that this could well be the case.

Regards,

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

Re: [osg-users] [build] Proper CMAKE settings for ZLIB, bogus "optimized.lib" in link

[Jan Ciger]

Hello,

On 02/11/16 22:05, Andrew Cunningham wrote:
> Hi,
> I am trying to build OSG 3.4.0 on Windows/Visual Studio 2015 using CMake to 
> generate the projects.
> 
>  Everything works pretty well except the confusing settings for ZLIB_LIBRARY, 
> ZLIB_LIBRARY_DEBUG,ZLIB_LIBRARY_RELEASE. Why 3 settings ?
> 
> I included paths to Debug and Release builds of ZLib,  in the 
> ZLIB_LIBRARY_DEBUG and ZLIB_LIBRARY_RELEASE respectively and left 
> ZLIB_LIBRARY blank. 
> 
> Although the DEBUG build is ok , my RELEASE builds ended up with library 
> references to non-existent "optimized.lib" and "debug.lib"  as well as 
> duplicating the debug and release versions of the zlib libraries.
> 
> For example, this is pasted from the VS linker settings for and OSG project.
> -
> optimized.lib
> D:\OSG\3rdParty\build\lib\Release\zlib.lib
> debug.lib
> D:\OSG\3rdParty\build\lib\Debug\zlibd.lib
> 
> 
> Andrew

That is completely normal. Visual Studio uses different C/C++ runtimes
for Debug and Release configurations and if you mix libraries compiled
against different C/C++ runtimes you will get memory corruption and
weird crashes at runtime. So it is an extremely bad idea to mix them
unless you know what you are doing (and probably even then).

Why there are 3 variables - I don't remember exactly the OSG's setup,
but typically:

* ZLIB_LIBRARY_DEBUG and ZLIB_LIBRARY_RELEASE would be internal use
CMake variables ("advanced" in CMake parlance)

* ZLIB_LIBRARY would contain something a value calculated by the script
from the two variables above like this:
"optimized;c:/foo/bar/baz/zlib.lib;debug;c:/foo/bar/baz/zlibd.lib"

The "debug" and "optimized" keywords denote which runtime is the library
meant for. This is the variable you would then normally use when
configuring linking for the target (exe or library) in the CMake script.

This is Window/Visual Studio specific pain in the backside, no other
platform that I know of has this problem with requiring separate
libraries for debugging/optimized build configurations.

Regards,

J.



signature.asc
Description: OpenPGP digital signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Trouble Drawing Text in Arabic

[Jan Ciger]

On Wed, Nov 2, 2016 at 3:35 PM, Chris Hanson  wrote:

> Is this something osgCairo ( https://github.com/cubicool/osgcairo ) might
> solve for you?​
>


Love that TODO in the README!

However, be aware that when I have played with Pango/Cairo for OSG some
years ago for one of our projects, these libraries had major issues with
multithreading in OSG, resulting in randomly corrupted text/textures. I
haven't tried osgCairo, though, perhaps it fixes that problem.

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

Re: [osg-users] Trouble Drawing Text in Arabic

[Jan Ciger]

On Tue, Nov 1, 2016 at 9:35 PM, Erik Hensens  wrote:

> Hello!
>
> I am having some trouble drawing text correctly in Arabic. I can get the
> Arabic letters themselves to show up correctly, but the letters do not
> connect together as they should.
>
> I am not an Arabic speaker, but my understanding is that when letters in
> Arabic are adjacent to each other within a word, the letters take different
> shapes and connect to each other, similar to cursive English.
>
> As a sanity check, I used the exact same TTF font and showed the same
> Arabic string on a 2D drawing area using Gtk. This 2D drawing area window
> shows the text correctly rendered with the letters connected properly.
>


Uff, I think you are pushing the poor old osgText far beyond its design
limits. This sort of thing requires some special treatment in the code,
which GTK does but osgText doesn't. osgText only takes the glyphs rendered
by FreeType, one by one. So if there are alternative glyphs to use in
certain situations (like ligatures) or something else, FreeType needs to
handle it and I believe it doesn't currently (or at least not
automatically). GTK uses Pango/Cairo combination, not raw FreeType for font
rendering, I believe.

So you could be out of luck here and may have to write your own text
rendering module - e..g use Pango/Cairo to render into a texture and
display it on a quad.

Regards,

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

Re: [osg-users] [forum] Graph Help Please!!

[Jan Ciger]

On Tue, Sep 6, 2016 at 7:45 PM, Megan Mason  wrote:

> Hi ya'll!!
>
> I have experience in quite a few things, but graphs are new to me :O. I
> work in a call center and was asked to graph the following:
>
>
>
I think you want to look at something like Excel instead of OpenSceneGraph
:)

http://blog.hubspot.com/marketing/how-to-build-excel-graph

Good luck,

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

Re: [osg-users] OSG & RTOS software architecture

[Jan Ciger]

On Wed, Sep 28, 2016 at 7:21 AM, Jan Cools  wrote:

> Hi,
>
> This is a more high level software architecture question considering a
> combination of OSG with a RTOS. My application considers 3D visualization
> and navigation for automatic machine control. The machine control loop will
> be implemented on a RTOS. In this control loop also some functions of OSG
> will perform some 3D calculations. For the RTOS I'm looking into the
> Xenomai patches for Linux. However this API is written in C while the OSG
> API is written in C++. I'm familiar with both languages however never
> attempted to combine 2 API's of different programming languages. Is it even
> possible what I'm trying to attempt? Any good advice?
>
> Thank you!
>


Hello,

You may also want to consider a different architecture - instead of forcing
everything to run on the RTOS, with all the complications that brings (RTOS
+ OpenGL is likely a non starter if you need hard real time, also driver
availability/compatibility is an issue), use the RTOS only for time
sensitive matters - i.e. the control loop.

Visualization is unlikely to be time sensitive, so a good solution could be
a second computer to run that and have the realtime system share its data
with it somehow (networking or even custom hardware if really necessary).

This sort of setup lets you use smaller real time system where you really
need it and run the parts that don't need to be real time (like the
visualization) on commodity hardware. Both resulting in a cheaper and most
likely more reliable setup as well.

Regards,

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

Re: [osg-users] [build] Building OSG for Android on Windows

[Jan Ciger]

On Thu, Jul 21, 2016 at 7:04 AM, Zach Cregan  wrote:

> Hi,
> ...
>


> Do I actually need to get this NVIDIA Nsight Tegra Visual Studio Edition?
> I haven't seen that dependency mentioned anywhere on the OSG website,
> forum, or through any Googling so I thought I must be doing something
> wrong. I appreciate any help. I have some experience setting up builds for
> iOS with Xcode, but this NDK stuff is beyond me.
>
> Thank you!
> Zach
>
>
I haven't built OSG for Android in a while, but a quick check of the
current code doesn't show the above line in the build system. I recall the
Tegra stuff was not really necessary and I believe it is not even avaliable
anymore. 3.4 is quite old, try to update to the latest 3.5 branch or even
master and that should get rid of that issue.

Apropos, if you want to save yourself a lot of trouble, don't use the
official NDK from Google but the repackages Crystax variant:
https://www.crystax.net/en/android/ndk

It should be a drop-in replacement but with a ton of bugs fixed. (NDK is a
serious pain in the backside ...)

Regards,

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

Re: [osg-users] Compilation error with MSVC 2015

[Jan Ciger]

Hello again,

On Mon, Jul 4, 2016 at 4:29 PM, Robert Osfield 
wrote:

> Weird.  I have just had a look t the source file the compiler is
> complaining about and it looks pretty standard.
>
> The gles plugin on Linux is not particularly large either. I can't see
> any obvious reasons why there would be any need for some special
> options.
>
>
This is what the doc says about /bigobj:
https://msdn.microsoft.com/en-us/library/ms173499.aspx

My suspicion is that as that optimizer code works over all possible OSG
nodes, it is possible it is trying to instantiate ton of templates (e.g.
osg::ref_ptr<>), pushing the number of sections over 64k in my particular
case, with my set of self-compiled dependencies.

It seems that adding /bigobj should be safe, only compilers older than MSVC
2005 wouldn't be able to deal with such object files - which is a
non-issue, because one cannot really mix C++ object files/libs between MSVC
versions safely anyway.

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

Re: [osg-users] Compilation error with MSVC 2015

[Jan Ciger]

Hello,

On Mon, Jul 4, 2016 at 4:29 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Jan,
>
> On 4 July 2016 at 14:12, Jan Ciger <jan.ci...@gmail.com> wrote:
> > It was a fresh checkout from Github master from a few minutes ago. I have
> > modified the main CMakeLists.txt and added /bigobj, as mentioned in the
> > error message, to CMAKE_CXX_FLAGS for MSVC and now the same code seems to
> > build fine,so that doesn't look like a corrupted file. I was building a
> > debug build when I have got that error, not sure whether it has any
> > relevance.
>
> Weird.  I have just had a look t the source file the compiler is
> complaining about and it looks pretty standard.
>
> The gles plugin on Linux is not particularly large either. I can't see
> any obvious reasons why there would be any need for some special
> options.
>
> What size are the object files and resulting osgdb_gles.dll?
>


The OpenGLESGeometryOptimizer.obj is 4.84MB in Release and 28.81MB in
Debug, the remaining files are few hundred kB (Release), few megs (in
Debug).

The DLL is 770kB in release and 3.84MB in debug.

I have noticed that the incremental linking was off in the CMakeLists.txt
for MSVC, that could perhaps have an impact.

Can the option just been added to the gles pugin if absolutely required?
>

Yes, possibly. However, it may be that the build would break elsewhere too
- I didn't have time to rebuild the whole mess several times today, so I
have put it only globally. I don't think that the GLES code is somehow
special.


>
> Right now, it seems pretty odd that the gles plugin would break some
> compiler limits that we've never hit before in any other module or
> plugins, so I'm inclined to think there is something specific going
> on, perhaps a bug with the compiler that is throwing things off.
>

Yes, I wouldn't be surprised. Or it could be triggering generation of ton
of code in 2015 that exceeds the limits. MSVC 2015 broke a lot of code that
was compiling before, because it is both stricter and updated for newer C++
standard. So when rebuilding older C++ code I am now often troubleshooting
compilation failures about code referencing deleted functions, template
problems, you name it.

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

Re: [osg-users] Compilation error with MSVC 2015

[Jan Ciger]

Hello,

On Mon, Jul 4, 2016 at 2:29 PM, Robert Osfield 
wrote:

> Hi Jan,
>
> The gles plugin is a tool to aid conversion of fixed function pipeline
> scene graphs across to shader based ones compatible with GLES2, it's
> not specifically tied to GLES though and should happily compile and
> work with a normal OpenGL build.
>

OK.


>
> The error you report looks like a compiler bug/error rather than a
> code error.  The only other thing I can think of that for some reason
> your OpenGLESGeometryOptimizer.cpp file has got corrupted.
>
> You don't specify which version of the OSG you are using so can't
> check to see if the file is actually OK.
>


It was a fresh checkout from Github master from a few minutes ago. I have
modified the main CMakeLists.txt and added /bigobj, as mentioned in the
error message, to CMAKE_CXX_FLAGS for MSVC and now the same code seems to
build fine,so that doesn't look like a corrupted file. I was building a
debug build when I have got that error, not sure whether it has any
relevance.

I have yet to see whether the extra flag will have any runtime consequences.

Regards,

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

[osg-users] Compilation error with MSVC 2015

[Jan Ciger]

Hello,

I am updating my OSG at work and when building with the MSVC 2015, I am
getting this:

72>C:\R\Dependencies-x64-2015\OpenSceneGraph\src\osgPlugins\gles\OpenGLESGeometryOptimizer.cpp
: fatal error C1128: number of sections exceeded object file format limit:
compile with /bigobj

And the build fails.

What is strange is that why is it even trying to build that file - I have
all GLES options off. Has anyone seen this error before?

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

Re: [osg-users] osgQt Coverity Scan reported issue, Qt experts please chip in.

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 24/06/16 20:32, Robert Osfield wrote:
> If you have a github account you should be able to login in with
> this account.  Alternatively you can create your own account for
> Coverity.

I have logged in with my Github account, but unless someone adds me to
the OpenSceneGraph project, I don't have access to the reports.

> 
> Attach is a screen snaptshot of the source browser.  The source I
> also included in my previous post.

> 
> I've looked at the relevant code, copy and pasted below for
> reference. The issue looks to be related to mixing an int key value
> with the enum's defined in osgGA::GUIEventAdapter.  I presume the
> key value is coming in from a Qt event, though I'm not 100% clear
> on this as I'm not the author of this code, no have Qt expertise.

Yes, the problem is that the key is being passed into the function as
an instead of enum. It is coming from QEvent (line 136 of the same
file). The code is taking the Qt events and passing them to the OSG
event handling system using custom Qt events (a kludge necessary to
work around some Qt issues).

To fix the problem the comparison should be done using the Qt key
codes instead:

Change:
osgGA::GUIEventAdapter::KEY_Shift_L  to  Qt::Key_Shift
osgGA::GUIEventAdapter::KEY_Shift_R to Qt::Key_Shift as well

osgGA::GUIEventAdapter::KEY_Control_L to Qt::Key_Control
osgGA::GUIEventAdapter::KEY_Control_R to Qt::Key_Control

osgGA::GUIEventAdapter::KEY_Alt_L to Qt::Key_Alt
osgGA::GUIEventAdapter::KEY_Alt_R to Qt::Key_AltGr

osgGA::GUIEventAdapter::KEY_Meta_L to Qt::Key_Meta
osgGA::GUIEventAdapter::KEY_Meta_R to Qt::Key_Meta


I don't think Qt makes distinction between left/right shift, control
and meta (windows) keys unless you use the native scan code, which is
platform-specific.

You can find the full list here:
http://doc.qt.io/qt-5/qt.html#Key-enum

Best regards,

Jan

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFXbY4sn11XseNj94gRAsTqAJ9mZ7BWmhrfNKNPSbjlw97UPMVb8QCfVuzK
3exJN3eTbdmqx1pwgwPHeYw=
=Hs+F
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt Coverity Scan reported issue, Qt experts please chip in.

[Jan Ciger]

Hello Robert,


On Fri, Jun 24, 2016 at 12:13 PM, Robert Osfield 
wrote:

> Hi All,
>
> The Coverity Scan has picked up what it thinks is a defect in
> QGraphicsViewAdapter:
>
>
> https://scan9.coverity.com/reports.htm#v25753/p12834/fileInstanceId=5614557=1105702=124679
>
> I've looked at the relevant code, copy and pasted below for reference.
> The issue looks to be related to mixing an int key value with the
> enum's defined in osgGA::GUIEventAdapter.  I presume the key value is
> coming in from a Qt event, though I'm not 100% clear on this as I'm
> not the author of this code, no have Qt expertise.
>
> It would really helpful for those with some Qt expertise to dive in
> and review the code and the Coverity Scan defect to see what the
> resolution should be.
>


Could you, please, post the report from Coverity? The link above demands
login from me. I have done quite a bit of Qt development, so I can check
what the deal is.

Regards,

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

Re: [osg-users] Creating a annex/attic repository for old and no longer used parts of the OSG

[Jan Ciger]

On Mon, Jun 20, 2016 at 2:13 PM, Alberto Luaces  wrote:

> Robert Osfield writes:
>
> > Thoughts?
>
> In my opinion, a new repo implies extra maintenance duties (even they
> are likely low), but cannot guarantee that it is synced or working with
> the latest OSG version, so it has a little added value.
>


Wasn't the entire point of having the dead code in a separate repo that it
won't need to be maintained? If someone still wants to use it, it will be
available, just not necessarily compiling with the current OSG and they
would have to put some elbow grease in it to make it work again.

Personally I don't have an issue with it. There is little point in spending
resources on things that are not being used but still have to be maintained
only because someone could find the code potentially useful in the future.

I would adopt a 2 step process for it, though - mark the bits to be removed
as deprecated in version N first, including warning messages being printed,
etc. and only remove it to a separate "attic" repo in release N+x, where x
is to be defined. Not everyone that uses OSG follows the list or updates to
the current version as soon as it is released, so that should give them an
ample warning.

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

Re: [osg-users] Arcball Camera without unexpecting 'roll' of the camera

[Jan Ciger]

On Tue, May 17, 2016 at 2:35 PM, Daniel Neos  wrote:

> Unfortunalety there is no feature "throw" feature. My class inherits from
> osgGA::GUIEventHandler and there is no setAllowThrow implemented, as far as
> I know.
>
>
And if I am zooming in, sometimes the effect gets worse and the camera is
> hardly to control. Maybe there is an error in my rotation setup?
>


That sounds like a classic case of gimbal lock to me. You are rotating
using 2 Euler angles rotations, so it is easy to align the axes in exactly
"the wrong way" and trigger the singularity when approaching +- 90 degrees.

You may want to look at this code:
https://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenGL_Tutorial_Arcball

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

Re: [osg-users] about the state of the BVH plug-in, when used with CMU MoCap files

[Jan Ciger]

On Fri, Apr 1, 2016 at 4:45 PM, Christian Buchner
 wrote:
>
>
> I've tried the OSG 3.2 branch and this version exhibited the same problem.
>
> Then I had a closer look at the BVH files supplied by that web site. I am 
> finding that it defines
> rotational parameters always in the order Z, Y,  X.  That is different from 
> the sequence I expect
> from various online sources that use Z, X, Y.
>
> ...
> I will have to do some more online research to understand whether the BVH 
> spec actually allows
> to specify rotation in an arbitrary order and what the definitive answer 
> about the sequence of applying
> the Euler angles is.
>

Actually, the order is not defined by the spec
(http://www.character-studio.net/bvh_file_specification.htm). Usually
it is assumed to be YXZ, but that's not always the case, the same as
there is no way to tell which way is "up" for the character :(

The only thing you can use to guess the order is the CHANNELS keyword
in the joint definition in the hierarchy part.

CHANNELS 3 Zrotation Xrotation Yrotation

This one defines the ZXY parsing order.  The problem is that some
software understands this as only the specification in which order are
the data written into the file, but not the order in which to compose
the transforms. So this, along with the z-up/y-up, which way is
forward, etc. must not be hardwired, because every mocap
system/animation software exports these files with different
conventions :(

Regards,

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

Re: [osg-users] Whether is Wince support OSG to use?

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/03/16 03:08, 韩志平 wrote:
> HI:
> 
> When I use osg, It cannot open include file’GL/gl.h’;NO such file 
> or directory.
> 
> System:Wince
> 

You need to build OSG with OpenGL ES, not desktop OpenGL. Also,
Windows CE supports OpenGL ES only in the version 7.0 and up and even
then it may depend on the vendor of your hardware whether or not there
are drivers/libraries for it.

If you google around, there are some examples how to use OpenGL ES on
Windows CE, e.g. here:
http://developer.toradex.com/knowledge-base/open-gl-es

I am not sure whether OSG is explicitly supported on Windows CE (it is
an extremely obscure platform today), so you may have to do some
porting too.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFW+RnRn11XseNj94gRAiDwAJ9PxGOvned5caLxWbkuKbBK4ATAZwCgrzVB
jwus0bJsaPeJMBUX83u5yZc=
=6wBn
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ArUco (AR) with OSG

[Jan Ciger]

On Wed, Feb 17, 2016 at 10:48 AM, Robert Osfield 
wrote:

> Hi Igor,
>
> The description is useful. In general the OSG just passes along projection
> and view matrices directly to OpenGL.  However, by default the OSG computes
> the near and far in the cull traversal on each frame and uses this to clamp
> the projection matrices so that depth precision is maximized.  The problem
> can arise if you are trying to match two render passes, if they have a
> different depth range then z buffer test will be erroneous so you'll get
> fragment clipped or not clipped.  Could this be the issue?
>
> To disable the compute near far simple do:
>
>
> viewer.getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
>
> You can find all the settings in the include/osg/CullSettings.
>
>

I have found it useful to force the projection matrix using the
osg::Projection node.  That avoids any issues with OSG modifying the
projection matrices.

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

Re: [osg-users] Augmented reality with OSG

[Jan Ciger]

On Tue, Feb 16, 2016 at 6:29 PM, Robert Osfield 
wrote:

> Hi Igor,
>
> The original thread dates back to 2011, FIVE years ago, it's about as
> stale thread as one can get, the orignal poster may well not even work at
> the same place or still use the OSG, so expecting a reply from them is
> rather optimisitc.  The original poster never replied to my suggestions and
> never added further to it - the old thread is DEAD.
>
> If you want to fire up a new discussion please do so, but you'll need to
> write about what you are trying to do, what you've tried so far, what
> problems you see.  If you can't be bothered telling us these basic details
> then there is pretty nothing we can do to help you.
>
> Robert.
>
>

Amen to that.

I will only add that there are probably hundreds of things that could be
wrong, both with Aruco (it was completely unusable when I have tried it
last time, but perhaps they have fixed it since) and the integration with
OSG.

Things like camera calibration, forgetting to load the calibration data
into Aruco, coordinate system mismatches between what Aruco and what OSG
assume, perhaps Aruco/OSG clobbering the OpenGL context to each other (no
idea how you have integrated it), etc.

So without elaborating *what exactly are you attempting to do* and *how*
(i.e. your code) it is completely impossible to help you. Nobody can see
over your shoulder and/or read your mind.

I have successfully integrated both ARToolkit, Qualcomm Vuforia and my own
homegrown AR solution with OSG, so it certainly is possible.

Best regards,

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

Re: [osg-users] Augmented reality with OSG

[Jan Ciger]

Hello Igor,

On Tue, Feb 16, 2016 at 12:51 AM, Igor Jurík  wrote:

> Hi,
> I am solving very similar problem, I am rewriting opengl commands to OSG
> as you stated. Have you been successfull and solve problem with OSG
> matrices??
> ...
>
>
What sort of problem do you have?

Most of the discussion is happening on a mailing list that is only
gatewayed to a forum, so if you are replying to a 5 year old discussion,
you would get help faster if you quote the relevant context.

Regards,

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

Re: [osg-users] osg Android viewer

[Jan Ciger]

On Mon, Feb 8, 2016 at 10:22 AM, Joe Kindle  wrote:

> Hey guys
> So I'm looking for a good free 3d viewer for Android that can run osgb
> files
> Anyone has something to suggest ?
>

OSG is free, AFAIK. Just compile the Android version, then you should be
able to open your osgb files (that's. OSG binary format).

J.
___
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

[Jan Ciger]

On Fri, Nov 20, 2015 at 9:37 AM, Björn Blissing  wrote:

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

Well, that is no different than what we do now with the Rifts - you
also render in higher resolution so that the shaders have a margin for
the warping. I don't know which version of HDMI does the HDK use, but
there should be ample bandwidth to do this. If they are using Display
Port instead, it is even easier, because that supports higher
resolutions.

J.
___
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

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 19/11/15 19:50, David Glenn wrote:
> Greetings All!
> 
> I've been messing with Rift at work for some time now but mostly on
> Unity, so I wanted to get a feel of how others are out there and I
> did get a taste of OSVR at the razor booth at GDC. So when it came
> to getting one for my own experimentation, I decided to try the HDK
> out! I Figure that it might not be at the level of Crescent Bay,
> but it can't be any worse than DK1.
> 
> That's about the level that I've been able to study at in given
> that I'm not a AAA game developer.
> 
> FYI: My lone game credit in my resume was WWII-online!
> 

Please be aware that OSVR is not really the HMD (HDK) - the much
larger part is the software framework to manage the VR hardware for
you application (even if you are not using the HDK).

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. You
could  even connect the thing to your Bluray player or a Playstation
and play 3D movies on it directly, without any special software
support. Good luck trying to do something like that with the Rift ...


The FPGA firmware for this isn't available yet, but the hardware is in
place and is documented - they are a bit hoping that some 3rdparty
hacker will sit down and write the necessary Verilog for this, based
on the recent blog post.

Regards,

J.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFWTicOn11XseNj94gRArwUAJ9HSl++uOtmubLBYMVhGO9Zz00gswCfbSfB
btHzOod/VpnNDNVznUKNXvo=
=bSYi
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Intercepting Windows messages

[Jan Ciger]

Hello,

On Wed, Nov 18, 2015 at 12:41 PM, Anders Backman  wrote:
> No one experienced that OSG consumes 3DConnexion messages until you move the
> window with the mouse, then auddenly messages related to the 3DConnexion
> Space Navigator starts coming in...?

If you don't want to battle Windows-specific issues like this, you can
use VRPN to feed you the SpaceNavigator data. VRPN talks to the device
directly using HID so you don't have any of these issues.

J.
___
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

[Jan Ciger]

Hi,

On Tue, Nov 10, 2015 at 11:28 AM, Björn Blissing  wrote:
> 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.

You don't really need an OSVR HDK to test this. It should work even
with Oculus Rift DK1 and DK2, Vrvana's Totem and, of course, the
Sensics HMDs (dSight and such). They ship example descriptors for
these.

Basically what OSVR manages for you is mainly the display
configuration - things like what are the distortion parameters, IPD,
focal distance, resolution, etc.

I am not sure whether or not there are plugins written to initialize
the individual HMDs and handle their built-in trackers - I am sure
there is one for the OSVR HDK, but I haven't seen ones for the other
HMDs. If there isn't one already (I didn't really look), it wouldn't
be too hard to write one, though, using the official Rift SDK.

Correction: Of course that there is one:
https://github.com/OSVR/OSVR-Oculus-Rift (haven't tried it)

Regards,

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

[Jan Ciger]

On Mon, Nov 9, 2015 at 11:26 PM, David Glenn  wrote:
> 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!

I am doing quite a bit of OSVR integration work at my current job,
mostly because we use GearVR quite a bit and getting VRPN working on
Android and in Unity3D is a pain. It can be done, but OSVR had
supposedly supported Android port and more features, so we have tried
that instead.

In short, the framework parts related to device management and
tracking work, even though you need to expect some rough edges. It is
basically a layer on top of VRPN (the VRPN maintainer now works for
Sensics, the company behind OSVR), with the protocol mostly being
compatible. For example, you can use VRPN clients to receive data from
an OSVR server for devices like trackers or buttons, of course without
the extra metadata.

I have also written a few plugins for OSVR to expose data from other
sources (Kinect, Natural Point's Optitrack, etc.) or to
process/transform tracking data using scripts - the APIs required are
there and it basically works, even though a few things are still a bit
rough. It is usable, though.

Where things could go south is if you try to do things the OSVR
developers didn't anticipate - I think I am one of the leading
external bug reporters on their issue tracker because we are always
finding use cases they didn't expect or that nobody has attempted
before.

For example, right now it is impossible to use an external OSVR server
(i.e. not running on the same machine as your client - probably the
most common VRPN setup) with the official code, unless you use kludges
like defining an environment variable or a local OSVR server to point
to the remote one. The code to allow this is there and works, but I
was told that the clients are not supposed to use the sw in this way
so it is not exposed in the API. I have a patch submitted for this,
but it wasn't accepted yet.

I cannot comment on the parts related to HMDs (management of
distortion and such) - never used it and Oculus Rift and GearVR that
we use pretty much require the use of their native SDKs so unless you
have the OSVR HDK helmet, it is probably not going to be all that
useful, because the Rift-proprietary features will not be supported
(at least with the current code - could change in the future).

>From what I can see from the source, the HMD support is right now
mostly about publishing the HMD parameters (like the distortion
parameters, focal length, etc.) in the metadata tree and then there
are some utilities and examples provided that can use that information
and calculate the correct matrices for your client application (it
uses Eigen everywhere, so it is API agnostic), making it independent
from the exact model of the HMD you use. At least that's the idea, the
practical implementation (and performance) of this remains to be seen.
There may be some other tools available which are outside of the main
OSVR-Core tree, but I haven't looked at this part of OSVR in any
depth, so take this with a grain of salt.

Also keep in mind that OSVR is still under a heavy development - if
you need unconditional API/protocol stability, it is probably safer to
use VRPN, which is a known quantity and pretty much an industry
standard. In addition, there is likely a lot of OSVR development
happening out of public view - they (Sensics) are certainly at least
in talks with major hw/sw players if not in collaborations already,
judging from the list of partners, so things will most likely change
quite a bit.

On the other hand, VRPN is very limited compared to what OSVR can do,
especially when it comes to publishing of the metadata - publishing
things like names of the tracked rigid bodies, marker - rigid body
associations, orphan markers in the scene, quality of tracking per
joint, etc. VRPN cannot deal with any of that without major
nonstandard kludges. OSVR is also designed for runtime reconfiguration
without restarting the server, so you can have plugins publish changes
(e.g. when a new device is connected) on the fly and the client will
pick that up and re-establish the data routing correctly. Again not
something typical VRPN setups can do.

I suggest you test the software and see whether it fits your needs.

Regards,

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

Re: [osg-users] Joystick support in OSG

[Jan Ciger]

Hello,


On Mon, Nov 2, 2015 at 9:35 AM, Elias Tarasov  wrote:
> Hi!
>
> Which is the best way of supporting joystick's input in modern OSG?
> OSG Cookbook says it's a Directinput 3rdParty lib, but looking into OSG trunk 
> code it seems that last update was done 5 years ago. SDL was updated 5 month 
> ago, but that comment in the last commit
>
>
>>
>> OpenSceneGraph\src\osgPlugins\sdl\JoystickDevice.cpp(42): error C2664: 
>> 'const char *SDL_JoystickName(SDL_Joystick *)' : cannot convert argument 1 
>> from 'int' to 'SDL_Joystick *'
>> due to changes in the SDL api.
>>
>> Tested with Visual Studio Express 2013; SDL 2.0.1"
>>
>
>
> makes me uncertain about that choice.
>
> Could anybody please provide more consistent info?

That code looks like it was written for the older pre 2.x SDL and
nobody has updated it yet.

You can either try to update that one (the SDL 1.x -> 2.x transition
is fairly simple) or simply use SDL 2.0 and handle the input outside
of OSG. The plugin doesn't do much anyway - just reads the device and
sends OSG events.

Alternatively, depending on what do you need the joystick for, you can
use also VRPN/OSVR - that will get you device independence (e.g. you
could emulate a joystick with something else or swap the devices at
runtime). Overkill for a simple application, but if you are building
some sort of virtual reality system then VRPN/OSVR are likely the
tools to go for.

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

Re: [osg-users] the new glTF format by the Kronos Group

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 20/10/15 13:51, Christian Buchner wrote:
> Hi all,
> 
> The Khronos group has published a specification for a data exchange
> and transmission format for 3D objects and scenes, it appears
> 
> https://github.com/KhronosGroup/glTF
> 
> I think the OpenScenegraph community might be a interesting in 
> implementing a a file format plugin, or even come up with a
> standaloner viewer for this format.
> 
> So far it is hard to tell if this format will be widely adopted.
> But having support in OSG from an early point in time could either
> make OSG more popular, or glTF...  ;)

Interesting, I wasn't aware of something like this being in the works.
It could be useful to support, indeed. If someone is building a new
application, this could potentially save them some work, especially if
there will be tooling available.

On the other hand, I don't see much potential for this as an
interoperability format because I don't see major game/3D engine
vendors abandoning their proprietary "baked" asset for this. There is
 too much investment in their existing tooling already and a vendor
lock-in is a major factor in their interest too. E.g. Unity wouldn't
want to make it easier for their paying customers to jump ship to
Unreal (or vice versa). The same for the various asset stores these
companies are running - vendor lock-in is a major advantage there,
because they get to be the gatekeeper and collect toll.

J.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFWJom6n11XseNj94gRAob+AKC4Eln1nSCdMHpke3Xfru7j16Q8fwCfa4fw
EZ7Kjzlr5DiW6M6QODDGzs4=
=gXAU
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] the new glTF format by the Kronos Group

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/10/15 20:56, Chris Hanson wrote:
> I could probably crank out a glTF loader in short work if anybody
> was interested. I haven't had any clients come forth demanding one
> yet, but it may happen. We'll see. Can't be any more complicated
> than COLLADA! ;)

Well, considering it is a part binary format, I wouldn't underestimate
it :) It could be easily a similarly complex mess, only in a different
way.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFWJrk2n11XseNj94gRArJLAJ9F85H5NayajscCXBdkzGg//A1cwgCg268J
CsXoNZLQwWo7rfJ7vxw6WcI=
=ucym
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] How to use osg to record screen

[Jan Ciger]

See the FAQ:

http://www.openscenegraph.com/index.php/support/faq#HowdoIcaptureascreengrab

If you want to record a video, just record the individual frames into
files and then use ffmpeg utilities to combine these into a video.

If you don't want to do that, use Google - there are plenty of screen
capture tools around (Fraps, BandiCam ...).

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

Re: [osg-users] Oculus+OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 29/09/15 12:22, Antoine Galluet wrote:
> Hi,
> 
> Please tell me if you prefer me to post my issue in another thread
> to keep this one clean.
> 

Please, don't hijack threads with unrelated issues. Make a new
thread/topic.

> I'm starting with openscenegraph and the oculus. I compiled the
> viewer and I can load the basic example (cow, plane). But I have an
> error when I try to load one of my own .osgb. The viewer returns me
> "InputStream::readObject<>: Unsupported wrapper class"
> 
> Do you have any clue of what's going wrong?


Your problem is likely because you are trying to load an .osgb file
that was exported by an incompatible OSG version. That has nothing to
do with Oculus Rift whatsoever.

Try to use osgconv on the file and convert it to .osg for example. If
you set OSG_NOTIFY_LEVEL env. variable to DEBUG, it might give you
idea why it has failed.


Regards,

Jan


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFWCuWLn11XseNj94gRAqcnAJwJL/z9wZbD8nfGq6Ckc+AjBSzGZgCdGv0l
ETZWZaJidAldsagsFMCikDI=
=/Hf3
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Jan Ciger]

On Sun, Sep 27, 2015 at 9:28 PM, Garth D
 wrote:
> As a side note, I have to say that I am really liking the ability to hang
> Uniforms off arbitrary parts of the scene graph- generally on Geometry or
> Groups depending on the scope that I need the Uniform to cover. It's really
> a very nice design.


Uniforms are parts of the OpenGL state, same as e.g. bound textures,
shaders or lighting settings. If I grossly simplify things, the "only"
thing that OSG does is to manage this state for you - adds and removes
bits from the state depending on which part of the scene graph is
being drawn, all the while to make sure to minimize the amount of
these state changes (changing state of the driver is relative
expensive operation). It is one of the basic purposes of a scene
graph.

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

Re: [osg-users] Modern GLSL and OSG

[Jan Ciger]

Hello,

On Sat, Sep 26, 2015 at 5:02 AM, Garth D
 wrote:
>
> My original motivation was to move to using "modern" OpenGL (ie. avoiding
> anything deprecated) because I didn't want to be in the situation where I
> started relying on something that was likely to be removed in the future.

Well, I don't think you need to worry about that too much. Yes, the
"old school" OpenGL is marked as deprecated and removed from the Core
profiles (and OpenGL ES 2.0 doesn't support it at all). However, at
least Nvidia (AMD/Ati probably as well) has declared that they are
going to support the legacy profiles for indefinite future.

The reason is that the code is already in the driver and costs them
essentially nothing (the old APIs don't change) and also the ton of
old code that uses it. That's also why the OpenGL 3 was felt to be
such a letdown and not a radical departure in a new direction - there
are simply too many CAD and visualization companies with decades old
codebases that would stop working overnight with a new driver and
there is no business willpower to rewrite that because it works well
enough. Moreover, I am pretty sure that even today you will find major
CAD systems doing atrocities such as using direct mode (glBegin/glEnd)
somewhere in their code ...

> Additionally, I have a need that I know is not going to be handled very well
> in the fixed-function pipeline. From experience I know that whilst the FFP
> is neat for simpler tasks, it feels like a massive burden as the needs get
> more complex.
>
> A last goal was as a learning exercise. The aim was to rely on shader
> functionality a bit more strictly than minimally necessary, as a means of
> taking care of the glaring (and increasingly hard-to-explain professionally)
> hole in my 3D knowledge.

By all means, that is a good reason. Also if you decide to develop on
mobile, you won't have much choice there.

Regards,

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

Re: [osg-users] Modern GLSL and OSG

[Jan Ciger]

On Fri, Sep 25, 2015 at 2:01 AM, Garth D
 wrote:
> Thankyou for the suggestion. :)
>
> I have to admit being unsure how to set the specific context at present.
>
> From what I've read, there'd need to be a glXCreateContextAttribsARB call
> somewhere to create the GL3 context under Linux- and there doesn't seem to
> be one. Skimming the source (I'm presently using OSG 3.2.1, but had a peek
> at 3.4.0) suggests that perhaps this support is only available on a Windows
> build. On the cmake side, OSG_GL3_AVAILABLE in my build is off. However,
> glVersion=4.4 appears in my log during a build.

The cmake variables are meant to be set by the developer, see the
instructions here:

http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/72253

It is possible that GL3 support is still available on Windows only,
but even if that is the case, it shouldn't be terribly difficult to
make it work in Linux too. The drivers and OpenGL implementations
certainly support it now.

> I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might not be
> the best thing for me to concentrate at the moment. I might be better off
> just using it where it helps and leaving a jump to "pure" modern GL until a
> later date.

Well, it depends on what you want to do. Moving to the "modern" OpenGL
without the fixed pipeline functionality is a big jump, because
basically you don't have anything pre-defined by the library anymore.
No matrix stack (glPush/glPop), everything needs to be managed using
shaders, etc. The older functionality is easier to make display
something on the screen quickly, because there are fewer things to set
up. The newer stuff gives you much more flexibility, though. Using OSG
helps to hide this complexity, because OSG abstracts and manages many
of these things for you, regardless of which OpenGL profile are you
using.

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

Re: [osg-users] Modern GLSL and OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/15 00:19, Garth D wrote:
> 
> Hi Christian,
> 
> Many thanks for the interesting suggestion. :)
> 
> My main development environment is Linux-based, with a secondary 
> virtualised Windows development environment. Due to the
> visualization (VirtualBox) I don't believe I can do much in the way
> of development with ANGLE due to its DX backend, at least with my
> current setup.

Um, wouldn't it be far easier to simply ask OSG to create an OpenGL
3.x/4.x core context instead? Then you don't have the legacy stuff
available and don't need to bother with hacks like Angle.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFWBFOUn11XseNj94gRArP1AKDneqprlIWSFje9RJ6gGmgJuBCGFQCeN0hL
I2nYYPPFemO/2jo40R7PH14=
=V73u
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] performance mystery with an osg::TerrainTile on nVidia. Intel wins.

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/09/15 17:03, Christian Buchner wrote:

> What I do not understand is why the command "glxinfo" kept showing 
> NVIDIA Corporation as vendor for OpenGL in this case.

Don't look only at the vendor string - that is the OpenGL library
shared library indication only. You would see Mesa there only if you
switch the libGL.so to point the libMesaGL implementation.

You need to check whether the "Direct Rendering: Yes" is present in
the output - that is what indicates that the GLX module is actually
working.

J.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFV+vjfn11XseNj94gRAt19AKDx8k4G7E/Fe2LYlA0n9NsHOB+m+gCglnMy
5Y2Ks61WRHZS4fJXT/lr/aw=
=Cwrj
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Mon, Sep 7, 2015 at 9:37 PM, Björn Blissing <bjorn.bliss...@vti.se> wrote:
>
> 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. "

Oh careful there.

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.

 I have recently spent some crazy amount of time debugging framerate
problems when the application (both OSG/OpenGL & Unity/D3D) are locked
to VSYNC but you get horrible framerate jitter every once in a while
for no apparent reason. This produces horrid artifacts when doing
frame-sequential stereo, because suddenly the stereo flips (I am
trying to do stereo on a GeForce with my own synchronisation hw). My
hypothesis is that the Nvidia's driver is silently dropping frames
from the pre-rendered frame queue if you are rendering too quickly
(the scene was really simple, rendering in thousands of fps without
vsync) instead of blocking or something. And it happens only on
GeForce hardware, not on our old Quadro, so it seems to be driver
"optimization". If the same thing happens with the Rift connected too,
then these timewarping kludges are going to have a hard time keeping
up. Or maybe they switch to a different code path in the driver when
the Rift is detected ...

I can't say I am a big fan of this - it is a kludge depending on the
GPU vendor's good will and your good relationship with them (the SDK
is NDA-ed, for ex.). Basically we are getting to the point where it is
going to be impossible to deliver a properly working 3D application
without working with the GPU vendor (good luck if you are a small
indie guy).

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

Re: [osg-users] Oculus+OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/09/15 19:48, Björn Blissing wrote:
> 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).

Positional reprojection could certainly be done synchronously (modulo
artifacts, etc), but the Reddit video you have posted explictly shows
framerate "smoothing".

That wouldn't happen if you do the warping at the end of each frame
(as before), regardless whether only rotational warp is done or both
positional and rotational. The framerate will be the same or even a
bit worse than before because more calculation has to be done per
frame. However, the tracking latency will be perceived as lower,
because the time between the movement and the change making it to the
screen will be shorter.

That's why I have concluded that the video is showing the new
asynchronous timewarping technique - that one actually permits to
fill-in for the missing frames and allows to smooth over framerate
jitter and occasional missed vsync deadline. The "old style"
timewarping doesn't do that (and was not advertised as a tool for that
neither).

J.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFV709In11XseNj94gRAjXnAKCJHP+0FeNrcRr42q/GtTxRrU1T+QCg0WTy
3LeldC81cWSvU5YFT1OPF3k=
=lrOB
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Tue, Sep 8, 2015 at 4:26 PM, Björn Blissing  wrote:

> 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...

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 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.

Yes, that is the asynchronous timewarping in the new SDK. The
"original timewarp" does not have any effect on framerate (you still
need to render every frame + you are rendering the warping at the
end), only on perceived tracking latency. The difference is explained
in that blog article by their chief software architect. The original
timewarping by J. Carmack is described here:
https://web.archive.org/web/20140719085135/http://www.altdev.co/2013/02/22/latency-mitigation-strategies/


Regards,

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

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Sun, Sep 6, 2015 at 7:34 PM, Björn Blissing  wrote:
> 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.

Hum, alright. I was searching the documentation and the changelogs for
this but haven't seen it mentioned anywhere. I do wonder whether it
actually has any perceptible impact, considering the added complexity
and the relative slowness of the position tracking.

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

Re: [osg-users] Oculus+OSG

[Jan Ciger]

Hi,

On Mon, Sep 7, 2015 at 2:52 PM, Björn Blissing  wrote:
> 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..."
>

Good catch, I didn't think to dig in there that deep. Well, they have
been really silent about a fairly major change like that. I would have
expected it mentioned in the changelog and/or some blog post ...

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

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.

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

Re: [osg-users] Oculus+OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 05/09/15 21:59, Björn Blissing wrote:
> 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.
> 

AFAIK, the timewarp uses only the current orientation from the
high-speed IMU that is on board. I have never heard about "positional
timewarp" being used (or even being developed). It probably wouldn't
make much sense, because the position tracker is much slower - around
60-120fps - compared to the IMU. So you wouldn't be likely to get a
"new" information towards the end of the frame warranting a
reprojection/warping.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFV7B1Wn11XseNj94gRAosaAJ99Ady2i7IhJ9tcGN1tgKWCudSznQCeOufU
EaLvtVkeXlf1YcX5hIwB0YA=
=hpuj
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Tue, Sep 1, 2015 at 11:15 AM, Christian Buchner
 wrote:
>
> Can you make any statements regarding latency improvements upgrading from
> the 0.6 SDK to 0.7 for osgoculusviewer based applications?
>
> 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. ;)
>
> Christian

I haven't tried the latest Oculus SDK, but the problem you are
describing is most likely due to your implementation of the video
streaming than the Oculus SDK. I doubt they would release code that is
THAT broken, especially when they go to the trouble of having custom
functionality built into the Nvidia driver to squeeze down the latency
even more.

How much latency has the RealSense camera itself?

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

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Tue, Sep 1, 2015 at 2:57 PM, Christian Buchner
 wrote:
>
> 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.

The DirectShow filter chain alone will add you several frames of
latency easily. DirectShow is far from a real time, low latency API.

The fact that the camera is an USB 3.0 model is a red herring - that
only affects how fast it could *theoretically* transfer data but has
no impact on the various buffering and processing done once the data
are in your machine.

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

Even if they didn't, even the plain old Rift DK1 has a sub 20ms
latency. So that is certainly not the source of your problem.

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

Re: [osg-users] Android osgPlugins

[Jan Ciger]

On Sun, Aug 23, 2015 at 7:22 PM, Christian Kehl christian-k...@web.de wrote:
 Thanks for the explanation - never digged so much into the linker behaviour 
 because usually libraries generate shared or static libraries consitently. 
 This way into the Java sandbox and how to link dependency code for it was new 
 to me. Still, in this case it was the only way I could make it work.

This isn't really an Android or Java specific issue, it is an
idiosyncracy of the GNU linker.

I think the problem happens only when you are taking a static library
(.a) and trying to convert it to a shared library (.so).

This is possible in Linux (and Android), however, it involves
relinking - and that is where things go wrong. If you don't tell the
linker to include the whole archive (.a) file, it will optimize the
unused code away. In extreme cases it will happily create a shared
library that has no code inside ...

Trying to link the OSG plugins (shared libraries) using static
dependencies is similar use case - the linker included only symbols
that were used by the rest of the plugin, but had no idea that it
should include also symbols that are only needed by other modules
after the shared library was loaded in memory.

That is, IMO, a compilation bug - each module should be linked with
everything it needs and not rely on the presence of a(nother) shared
library at runtime to bring in those 3rd-party dependencies (I think
it was zlib in your case). E.g. DLL compilation in Windows will fail
for such unresolved symbols. In Linux it passes, because the linker
allows late binding by default, assuming that the undefined symbols
will be resolved at runtime by the dynamic linker.

J.
___
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

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/08/15 10:30, Björn Blissing wrote:
 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_augus
t_20/ctv0hka

Hum,
 
that is not how I have read the notice, but you are right, they
aren't saying they are replacing the existing direct mode now that I
have re-read it.

The dropping of the extended mode is more problematic, because the
direct mode doesn't work on a lot of hardware, even desktop machines
with standalone Nvidia cards.

 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.

That's possible, but difficult to know until the new version is out. I
do find it unfortunate that they are resorting to these types of hacks
that make the integration a complicated mess.

J.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFVx0gTn11XseNj94gRAqVWAJ9Kcekh8yo//6wzCIcoQjl1PhZrTwCcCHcr
M3Rh51XIW0PXJ1JI+kPVcMI=
=w3eK
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Android osgPlugins

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/08/15 23:50, Christian Kehl wrote:
 What I deduct from that: something went wrong when compiling OSG
 3.3.8 for Android with the plugins, as the static libraries
 (osgdb_jpeg, osgdb_gif, osgdb_curl) do not properly link to their
 pre-compiled library counterparts (libjpeg, libgif, libcurl, etc.)
 
 Jan, Rafa - the community: a) Did you try out to build osgAndroid
 with plugins ? Did you get the same problems ? b) Any idea how to
 circumvent the problem ?

I suspect that the:

LOCAL_STATIC_LIBRARIES := -ljpeg -lgif -lpng -lcurl -ltiff

doesn't actually work like this. The arguments should be prebuilt
modules, not linker arguments. Yay for the abomination that is the NDK
build system. I have also wasted time on this.

See here:

http://stackoverflow.com/questions/5463518/android-ndk-link-using-a-pre-
compiled-static-library

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD4DBQFVxd0On11XseNj94gRAiK5AKCxafeRG7/wt6xqMjnH8WGJSkE/xgCYkYi/
PETHomFvHndaRSsILEpipw==
=6Xmv
-END PGP SIGNATURE-
___
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

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 08/08/15 18:33, Björn Blissing wrote:
 Hi,
 
 I am (as some of you already know) working with the integration of 
 the Oculus Rift and OpenSceneGraph. Usually I have been able to
 get the new SDK working within days of a new release. But since
 v0.6 of the Oculus SDK I have been struggling.
 
 This has mainly been due to the fact that this SDK version is
 pretty much a completely new SDK compared to the previous version.
 Most of the setup is now handled inside the Rift SDK and runtime.

Björn, I suggest that you stop with 0.6 and look at the 0.7 version
(or wait until it is out if it isn't yet). They have redone the direct
mode completely, now it is part way in the actual graphic driver. I am
afraid that what you are fighting with now could be a wasted effort
because they have changed the API yet another time.

Oh and they promise to break compatibility until 1.0 is released in
November ...

J.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFVxp8cn11XseNj94gRAgqGAKCNuqbiOVSG3ZQbCq/DJUKGWlnOiQCeK2BH
84OsjqvCVlDfd2wPqfPAFmg=
=d7VB
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] Cannot load WRL files

[Jan Ciger]

On Wed, Jul 22, 2015 at 9:27 AM, Felix Goldberg
felix.goldb...@gmail.com wrote:
 Hi,

 I am trying to render models using the MATLAB 3D Model Renderer which wraps 
 OpenSceneGraph. It works well for .osg files but gives me error on every 
 other kind of of file, in particular .wrl which I need to be able to work 
 with textures.

 I initially thought  that a plugin was missing but I am able to view the .wrl 
 files using the osgviewer.exe - so maybe that is not the problem.

 Seeking enlightenment

It would help if you posted the error message you are actually getting.

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

Re: [osg-users] force vsync to false (sofware not hardware) on NVidia

[Jan Ciger]

Hello,

I am prototyping some OpenGL stuff in Python using Pyglet and have
encountered the same vsync problem, both in Linux  Windows. I think
it is Nvidia's driver that is (again - Nvidia had various vsync issues
in the past) trying to be smart and is breaking vsync in OpenGL. It
has most likely nothing to do with OSG.

For me if the vsync setting in the driver is set to application
controlled, it is always on, no matter what the application specifies
(vsync=False or vsync=True in the gl.Config setup in Pyglet makes no
difference). The only way to turn vsync off is to disable it in the
driver's control panel.

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

Re: [osg-users] force vsync to false (sofware not hardware) on NVidia

[Jan Ciger]

On Wed, Jul 22, 2015 at 11:05 AM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
 Hi,

 Have you tried the nvapi-library? [1]
 As far as I know you can set anything you can via the control-panel here at
 least for windows platforms.

Yes, but for most things you need a D3D handle ... And it seems that
they have locked up most of the API under NDA: Requires NDA Edition
for full control of this feature. This isn't really a solution for
most cases.

Gee thanks ...

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

Re: [osg-users] Android - corrupt block passed to dlfree

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/07/15 19:02, Steven A. White ARA/SED wrote:
 The symptom seems to be a block of uninitialized memory being
 passed to a dlfree call .  The back trace can start from numerous
 sources based on the example code, but the failure is always based
 in std::allocatorchar ::~basic_string().   I would normally
 blame STL incompatibilities, but with the osgAndroidExampleGLES2 I
 can confirm that both the APK and the OSG libs were compiled
 against gnustl_static so I wouldn’t expect this to be the core
 conflict.
 

Ouch, I have just spent a week chasing this exact bug, but not with
OSG but OSVR on Android.

The problem is most likely that you are linking with gnustl_static, in
fact. Rebuild everything with gnustl_dynamic and the crash in the
string destructor will most likely disappear.

My suspicion is that the app is not entirely statically linked and
when another copy of libc gets loaded into it at runtime by the
dynamic linker on Android, it is slightly different. And the code
crashes.

That the OSG example works doesn't mean much - for me the OSVR code
was working just fine when called from a normal app but the same code
crashing horribly when used from Unity - most likely because of
different memory layout or different shared libraries being linked at
runtime.

Yay for joys of the Android development ...

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFVmtQpn11XseNj94gRAlwpAJ4o4QFuV50ydnp/YAYX46fa5J8A3gCgwl0B
Kk7XjyBS+5yHQbB1Y+ySjoA=
=hbMZ
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] QT + OSG Performance Issues

[Jan Ciger]

On Fri, Jul 3, 2015 at 12:55 AM, sam brko...@gmail.com wrote:
 When running the example osgViewerQt there is some serious lag /
 performance issues. Is there something I have to tweak or change in order to
 get a smooth QT + OSG integration? I'm running QT 5.4.1 and OSG 3.2.1.
 Thanks.

Are you running the Angle version of Qt, by chance? That's the default
download, I believe. If so, try to download the OpenGL enabled version
instead (the installer has the -opengl suffix).

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

Re: [osg-users] .3ds to .osgb file conversion using OSG Exporter

[Jan Ciger]

Hello,

On Thu, Jul 2, 2015 at 11:14 AM, HITESH Singhal ug201211...@iitj.ac.in wrote:
 Hi,

 I have a .3ds and a .fbx file with me and when I'm converting these in .osgb
 format using osgexporter in powershell, it is not loading any data. The
 message which is coming is:
 Warning: Could not find plugin to read objects from file
 C:\Users\Hiteshsinghal\Desktop\My Vizard Tuts\Chair\Chair\Chair.3ds
 Warning: Could not find plugin to read objects from file
 C:\Users\Hiteshsinghal\Desktop\My Vizard..
 Error no Data loaded.

 Please tell me any solution to this.

This is something you may have to ask to WorldViz support. The error
message you are seeing typically happens when OSG is unable to find
plugins for the source format you are trying to import/convert. I have
no idea how WorldViz ships OSG compiled with their Vizard, whether the
3ds plugin (or any plugins at all) are installed.

In the worst case you can always install regular OSG separately from
Vizard and use the osgconv tool from there - I think that the 3DS
plugin is available in the precompiled Windows binaries. If it is not,
then you can always compile OSG and the plugin yourself.

Regards,

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

Re: [osg-users] Vizard 3D Model

[Jan Ciger]

Hello,

On Wed, Jul 1, 2015 at 5:19 PM, HITESH Singhal ug201211...@iitj.ac.in wrote:
 Hi,

 Currently I'm working on a 3D Environment, I need 3D model of a Theater
 Chair (Picture Hall Chairs). Where can I get the same in osg file.

I think that you have got several answers regarding file exporters,
3DS Max and even marketplaces to this question already.

 And how can we create lights in our 3D environment, i.e. to turn on and off
 a light or making a light?

That very much depends on what exactly are you after because there are
several techniques.

OSG supports the OpenGL lights out of the box. You need to create
them by calling the appropriate functions in your code (search the
documentation for Light). I am not sure whether any OSG exporters
support lights. These lights are good for dynamic lighting, but are
fairly computationally expensive and there is only a limited amount of
them (~8 or so) available.

Another option is that you go for baked lighting and create
lightmaps in your 3D modelling software (Blender, 3DS Max, Maya, etc.)
Then you export those and use them as textures on your objects. This
is used for static parts of the scene and to give you a photorealistic
look without having to do a lot of computation.

Then there are things like screen space ambient occlusion or image
based lighting and such, but I don't think OSG supports any of that
out of the box - you would have to implement that yourself.

However, to me it seems that you have very little experience with 3D
graphics - I strongly suggest that you get one of the OSG books
(http://www.openscenegraph.com/index.php/documentation/books ). All
these basic questions are answered there.

Regards,

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

Re: [osg-users] Trouble with transitioning to OSG

[Jan Ciger]

On Thu, Jun 25, 2015 at 12:29 AM, sam brko...@gmail.com wrote:
 I thought that would be taken care of when I do:

 auto pos = osg::Vec3(relPos[0], relPos[2], relPos[1]);

 That should swap the Z accordingly? Or am I missing the boat on this one.

Your matrices you using to assemble the bones need to be converted too.

The simplest way to deal with this is to put a rotation transform at
the root of the scenegraph and attach your nodes to it instead of the
root. That will effectively change the coordinate system from the OSG
z-up to your y-up and you keep working in your y-up coordinates. If
you start converting the coordinate systems vector by vector then you
will have to change all the matrices too - fairly error prone if you
have a larger codebase.

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

Re: [osg-users] Trouble with transitioning to OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/06/15 22:50, sam wrote:
 Hi All,
 
 I have a snippet of code that I am trying to reproduce using OSG,
 it was originally written in pretty raw gl with glm. You can view
 it here: http://pastebin.com/PYphHLYE
 
 I currently have the following snippet and the geometry references
 are all over the place. If somebody could take a quick look and see
 if I'm missing something fundamental, that would be great:
 
 http://pastebin.com/nhSzZGdu

If nothing else, be careful that OSG uses row major matrices and
premultiplies - if v is a vertex, then its transformation is usually
expressed as v' = M * v but in OSG you will have it as v' = v * M (and
the matrices are transposed).

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFViyWFn11XseNj94gRAtTeAKCWh8pvzgVV/NKtNEBXpo0G2Ug0nwCeK2C+
3y37pxcENvMBY2614Z4DvSA=
=/ff0
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Trouble with transitioning to OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25/06/15 00:13, sam wrote:
 Ah, I see. Throwing the parent matrix at the end of the
 multiplication puts the debug data in the correct place! Thanks,
 Jan. Only other issue is the model is coming in on its side
 compared to the basic viewer camera.
 

OSG uses z-up convention, likely your model is exported y-up. You may
want to rotate it by 90 degrees around the x axis.

Regards,

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFViy5nn11XseNj94gRApweAKDIAGNUw4sUIb/OxJg5yB9fK3GB3gCfeUxN
B75nRtPoU+Eibxo0W+tvnwY=
=HlPi
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Regarding Converting 3ds Max file in OSG format

[Jan Ciger]

On Tue, Jun 23, 2015 at 2:20 PM, HITESH Singhal ug201211...@iitj.ac.in wrote:
 I was asking all that because I'm working on a software named VIZARD and it
 supports only OSG files. I have no option using any file other then OSG. So
 where can I find 3d Shopping Mall model in osg files directly. Any
 suggestion?


You won't find one. OSG is format specific to OpenSceneGraph, no
graphic software can export that directly. AFAIK, Vizard is
OpenSceneGraph + some Python, so you should be able to use any formats
that OSG can handle. However, as I said, you will need to
convert/rework/adapt any models you download, there is no way around
it.

At least OSG can load quite a few different file formats - Unreal
Engine I was working with as well can deal with only .obj and .fbx and
even then it loads only the mesh - no materials whatsoever (i.e. no
textures or even vertex colors). The material import/export from any
modelling tool you may want to use is completely up to you. And that
is a big commercial engine ...

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

Re: [osg-users] Regarding Converting 3ds Max file in OSG format

[Jan Ciger]

On Tue, Jun 23, 2015 at 1:32 PM, HITESH Singhal ug201211...@iitj.ac.in wrote:
 Hi,
 Thanks for your help. I've converted my model in .osgb but it is missing
 various textures and materials, It is not in the same form. How can I get
 the model exact in osgb, without any loss.


Generally speaking, you can't. 3DS Max (or Maya or Blender ...) uses a
very different shading and lighting model than OSG (or any 3D engine).
This must be converted by the exporter plugin and even then the
conversion is never 1:1 because some things simply don't have an
equivalent representation, e.g. various normal mapping, composition
effects, shaders, etc.

This is a common and non OSG-specific problem. The asset creation
pipeline is a huge issue for any 3D engine and generally the asset
tools are written from scratch for each, to support their needs. It is
a large industry and the market for these tools is where a lot of
money is being made - good tools are rare and expensive. Then your 3D
designer needs to be aware of the limitations of both the 3D engine
they are targetting and the exporters and create their model
accordingly.

If you are hoping to download a random model somewhere and use it with
OSG/Unreal/Unity/etc. without any changes/rework, that is bound to
fail, unfortunately. At best you get the mesh and some materials
(vertex colors and some textures), at worst not even the mesh.

Good luck,

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

Re: [osg-users] Regarding Converting 3ds Max file in OSG format

[Jan Ciger]

Actually that wouldn't work - Powershell doesn't find binaries in the
current directory (intentional security feature copied from Unix). You
need to type:

.\osgconv C:\MyPathToTheModel\model.3ds C:\MyPathToTheModel\model.osgb

J.


On Tue, Jun 23, 2015 at 9:06 AM, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com wrote:
 For this I would look up on web, how to update PATH environment variable in
 Windows. For temporary use it might be something like

 set PATH =
 %PATH%;C:\Users\Hiteshsinghal\Desktop\OpenSceneGraph-3.0.1-VS9.0.30729-x86-release-12741\bin;

 or

 go to that bin folder and run it from there, but you have to provide full
 path to your file like:

 osgconv C:\MyPathToTheModel\model.3ds C:\MyPathToTheModel\model.osgb

 model.osgb is your output from the conversion

 On Tue, Jun 23, 2015 at 8:59 AM, HITESH Singhal ug201211...@iitj.ac.in
 wrote:

 Ya i have that but how to get this folder in my PATH environment??

 --
 Regards
 Hitesh Singhal
 Electrical Engineering
 +91-8386837430


 On Tue, Jun 23, 2015 at 12:26 PM, Trajce Nikolov NICK
 trajce.nikolov.n...@gmail.com wrote:

 do you have
 C:\Users\Hiteshsinghal\Desktop\OpenSceneGraph-3.0.1-VS9.0.30729-x86-release-12741\bin
 folder? Can you see if that utility osgconv.exe is located in that bin
 folder? If so, I think best you should set this folder in your PATH
 environmental variable and restart your command prompt

 On Tue, Jun 23, 2015 at 8:50 AM, HITESH Singhal ug201211...@iitj.ac.in
 wrote:

 I have got the OSG binaries. But when I'm typing 'osgconv --help' in my
 Powershell window it is showing error that osgconv term is not recognised
 as the name of cmdlet.
 My OSG binaries are saved at the location:

 C:\Users\Hiteshsinghal\Desktop\OpenSceneGraph-3.0.1-VS9.0.30729-x86-release-12741

 Now tell me what to do?

 --
 Regards
 Hitesh Singhal
 Electrical Engineering
 +91-8386837430


 On Tue, Jun 23, 2015 at 12:13 PM, Trajce Nikolov NICK
 trajce.nikolov.n...@gmail.com wrote:

 This is sample application that comes with OSG distribution/source. You
 only need to build osg yourself (or get from somewhere the binaries). Once
 you have done that, simply type:

 osgconv --help

 for all the options

 On Tue, Jun 23, 2015 at 8:30 AM, HITESH Singhal
 ug201211...@iitj.ac.in wrote:

 Can you please explain me in details what is this and how to do it?

 --
 Regards
 Hitesh Singhal
 Electrical Engineering
 +91-8386837430


 On Tue, Jun 23, 2015 at 11:51 AM, Trajce Nikolov NICK
 trajce.nikolov.n...@gmail.com wrote:

 Hi HITESH,

 if you have 3ds model you can use the osgconv utility (from OSG). You
 do osgconv mymodel.3ds mymodel.osgb

 Nick

 On Tue, Jun 23, 2015 at 6:04 AM, HITESH Singhal
 ug201211...@iitj.ac.in wrote:

 I have 3ds file too of that model, so in that condition will I be
 able to get my model fully without any loss in environment?
 And one thing more here I'm unable to use that OSG exporter, what If
 I send you the .3ds file and you convert it at your place and send it 
 back
 to me on Google Drive.
 So can you help me with that?


 --
 Regards
 Hitesh Singhal
 Electrical Engineering
 +91-8386837430


 On Tue, Jun 23, 2015 at 1:11 AM, Chris Hanson xe...@alphapixel.com
 wrote:

 The .max format is proprietary and cannot be read by OSG.

 On Mon, Jun 22, 2015 at 1:40 PM, HITESH Singhal
 ug201211...@iitj.ac.in wrote:

 No it's in .Max format

 On 23 Jun 2015 00:29, Farshid Lashkari fla...@gmail.com wrote:

 The exporter works as a plugin to 3ds max, so you will need to
 have 3ds max installed in order to use it. What exact format is the 
 file in
 (.3ds or .max)? OSG comes with a .3ds file loader, so that should 
 work if
 the file is in .3ds format.

 On Mon, Jun 22, 2015 at 10:23 AM, HITESH Singhal
 ug201211...@iitj.ac.in wrote:

 Hi,

 Thanks for reply. I'm not having any 3ds max software because I'
 unable to download it in my laptop. So can you suggest me any way 
 to
 download it or is there any other way to convert 3ds file in OSG 
 format.

 --
 Regards
 Hitesh Singhal
 Electrical Engineering
 +91-8386837430


 On Mon, Jun 22, 2015 at 10:49 PM, Farshid Lashkari
 fla...@gmail.com wrote:

 Hi,

 Once you have installed the exporter, you should see a
 OpenSceneGraph Exporter option in the 3ds max export dialog. 
 What version
 of 3ds max do you have installed?

 Cheers,
 Farshid


 On Mon, Jun 22, 2015 at 12:02 AM, HITESH Singhal
 ug201211...@iitj.ac.in wrote:

 Hi,

 I have a 3d model in 3ds max format, I want to change it in
 OSG format. I have also downloaded that OSG Exporter.But I don't 
 know how to
 use it, because I'm not seeing any software after downloading 
 this exporter.
 So can any one please help me out with this problem. Its
 urgent for my project work.

 Please reply at your earliest!!
 --
 Regards
 Hitesh Singhal
 Electrical Engineering
 +91-8386837430


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org

 

Re: [osg-users] Regarding Converting 3ds Max file in OSG format

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/06/15 21:40, HITESH Singhal wrote:
 No it's in .Max format
 
 

Then you need 3DS Max, unfortunately. Nothing else will read that,
AFAIK. The format is proprietary and undocumented.

Regards,

J.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFViJ4Yn11XseNj94gRAvoBAJ9xY6JPZlm/VnpIj38O6zsLHslpvACcCuvr
JVLkHIeu3pbX5OF9qdX5WTU=
=lv7A
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Jan Ciger]

On Fri, Jun 19, 2015 at 10:10 AM, Florian Weidner osgfo...@tevs.eu wrote:
 FYI:
 Right now, it looks like I'll use a) Unreal Engine, b) Unity Engine or c) an 
 in-house pbr graphics engine focused. The first and second have a nice 
 feature set, but aren't open source. the last is open source but lacks 
 necessary features (yay. coding ahead ^^). However, I like the idea and 
 concepts of open scene graph and will try to integrate my solutions (which 
 are targeted to new user interfaces) with osg in my free time. So be prepared 
 to hear more from me :)


Unreal is open source - the source code is on Github, freely (as in
beer) available. It isn't  open in the sense of Free software - there
are licensing restrictions you need to obey, mainly concerning
royalties if you make some sort of commercial project with it.

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

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

[Jan Ciger]

On Fri, Jun 19, 2015 at 3:51 PM, Florian Weidner osgfo...@tevs.eu wrote:
 Hi Jan,
 afaik it is available freely but you aren't allowed to share source code or 
 applications you developed via arbitrary channels. You have to use the unreal 
 marketplace or the github repository.

That's not what I know. I would love to see a reference to the EULA
part saying this.



 https://www.unrealengine.com/faq wrote:

 however the UE4 Editor (including modified versions) and code may only be 
 distributed through official Epic channels (e.g. the UE4 launcher for 
 binaries, and GitHub for source), to users who have accepted the EULA.

Well, ok, but normally you don't ship the Editor to your
clients/users. That's not needed to run applications based on Unreal
Engine.


 https://www.unrealengine.com/faq wrote:

 You can’t combine the Unreal Engine code with code covered by a “Copyleft” 
 license agreement



 :( :(

 That is, in general not a big issue but I don't like it. Imho publicly funded 
 research should be available freely and without any restrictions. So, I 
 consider the UDK, but would prefer another solution ^^[/quote]


You can use free (LGPL and such) libraries no problem in your plugins.
What you cannot do is to use such libraries with the core code where
it could infect it and force Epic to release the source under a more
permissive license. So this usually isn't a big problem in practice
but it depends a lot on what exactly you want to do. Building a
simulator typically doesn't require much hacking in the Unreal Engine
code itself.

I agree with the idea that publicaly funded research should be
available freely and without restrictions, however here you are going
to hit the wall of market realities. There is no fully free/open
source game engine that comes close to the features you are looking
for and that these commercial engines have - hobbyists and volunteers
can do a lot, but it is hard to compete with a well paid and qualified
team of developers working on something like this full time.

There are few free/OSS engines around - Irrlicht, Crystal Space,
Delta3D, Blender Game Engine, Panda3D. Then you have some frameworks
you can use to build a game engine out of - such as OSG, Bullet, ODE,
etc. but that's pretty much it. It will take a lot of time and work to
make a reasonable engine and tools (e.g. editor) out of those
libraries. It certainly is possible, with a lot of effort, though.


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

Re: [osg-users] osgQt versioning problem

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/12/2015 10:02 PM, Robert Osfield wrote:

 Perhaps one would just need to avoid using the whole MOC stuff and 
 linking directly the callbacks in normal C++.

That isn't really reasonably possible without going into
undocumented/internal API territory. MOC doesn't really pose problems
in general, as long as you don't try to be too clever with your headers.

The idea of moving the implementation to headers is, honestly, a hack
to work around another problem, so it is hard to blame MOC for not
supporting/breaking on something like that. For example, Unreal Engine
doesn't even use a custom preprocessor and use C++11 for the part. And
good luck trying something like that there - their C# build tool acts
as a code generator too and will blow up spilling its guts all over
with much less prodding than MOC ever did.

If you want to actually solve the problem, then the cleanest solution
would be to split osgQt into a subproject with its own CMake build.
That would avoid having Qt CMake variables clobbered between Qt versions
.

Then run the osgQt build as many times as many Qt versions were
checked/activated by the user in the master/top level build,
generating libraries with different names - e.g. osgQt4, osgQt5, etc.
Those can be installed side-by-side no problem.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFVfBO6n11XseNj94gRAlG/AKCXtqPEKbjqmwm08ZBXHnrRu1DPkQCgpmqI
QcJ6mbbnGC2V5qSUyS/ykWA=
=KbOs
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgviewerQt integration required

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/13/2015 09:06 AM, manish Choudhary wrote:
 Hi,
 
 Problem resolved  once I downloaded  version of Qt with the native
 OpenGL support. Now osgviewerQt example  is working fine.
 
...
 Thanks you all for your support

You are welcome!

All the best,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFVfBP5n11XseNj94gRAs/sAKDvalHIrO7gxJHO1O9iJa8KBHZQyACghLCj
cToDf5buGZCg0Z4ldUPdNT0=
=ABHF
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt versioning problem

[Jan Ciger]

On Fri, Jun 12, 2015 at 1:00 AM, Jannik Heller scr...@baseoftrash.de wrote:
 Hi Jan,


 The only way you could have problems is if you rely on the OSG
 libraries shipped by the distro, where you don't have control over how
 it was compiled.


 That is precisely what's going to happen. My application is likely to become 
 available in distro repositories (FWIW, an older version of my application 
 that isn't using the OSG *is* already in distro repositories). Packaging 
 guidelines typically require a package to use the established library stack. 
 A package isn't likely to get accepted if it ships its own forks of already 
 packaged software. That would be a maintenance and security nightmare.

Then it cannot be a problem, because all distros recompile the
applications they package for their repositories using their
libraries. You can specify in the spec file (if you are building for
RPM-based distro) or the manifest for .dpkg (for Debian/Ubuntu/...)
which library version your application needs. Then the package will
not build for the repository maintainer until the requirements are
met.

The only exception are binary-only, proprietary software packages -
but there you are on your own and shipping everything needed is your
problem.

 Sounds easy in principle, but will cause a waterfall of problems for package 
 repositories.

I don't see how - if you set up your package requirements properly,
then there is no way the repository maintainer could build your
package requiring one version of Qt and build OSG using another one.


 - Not all application developers are willing or able to upgrade to Qt5 yet.
 - *if* there is a mismatch, we just get a crash, instead of the mismatch 
 being detected at the build system stage. The packager or tester is left to 
 dig into the crash to find out what's wrong. There is no way for the 
 application to detect what version of Qt the osgQt was built with, so the 
 application can't provide a sensible error message either. Ultimately, the 
 developer will be left to deal with lots of support requests by frustrated 
 users.
 - If one package requires osgQt5, but a different one requires osgQt4, we get 
 a conflict. The user wouldn't be able to install those two packages at the 
 same time.

Well, there isn't really a way around that - you must have two
versions of OSG installed side by side for this to work. That's the
responsibility of the distro packager, IMHO, not yours. If they build
the packages inconsistently, despite your specified requirements,
well, things won't work, but only they are to blame in such case.

OSG is no way special there - this is a common issue with software
requiring e.g. specific version of Python, wxWindows toolkit,
KDE/Gnome ...

 In addition, if you are trying to distribute a binary-only package

 I don't. I just distribute source-code and let others worry about the rest ;)

OK. I would say that the only thing you could do is to document this
requirement. It is the packagers' job to deal with this.

 My suggestion is:

 - Provide separate libosgQt4/5 libraries.
 - Provide a libosgQt library that points to the default, either 4 or 5, for 
 backwards compatibility.
 - Add an OSGQT_DESIRED_QT_VERSION switch for the FindosgQt.cmake script, 
 allowing applications to opt for a specific version.

You just have to build OSG twice using each version of Qt in turn. OSG
respects the DESIRED_QT_VERSION already.

cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x
cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series

Regards,

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

Re: [osg-users] osgQt versioning problem

[Jan Ciger]

On Fri, Jun 12, 2015 at 2:51 PM, Jannik Heller scr...@baseoftrash.de wrote:
 Hi,



 You just have to build OSG twice using each version of Qt in turn. OSG
 respects the DESIRED_QT_VERSION already.

 cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x
 cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series


 Yes, but then you won't be able to install those two OSG versions at the same 
 time.
 Unless you renamed libraries or used a completely separate prefix for each 
 OSG build, but there isn't an established pattern to do so, so what we'd end 
 up with is each distribution inventing its own ways to cope with the 
 versioning problem. That is what should be avoided at all cost.

Yes, correct. However, there are few applications that *need* OSG that
are commonly packaged by Linux distros and that don't ship their own
OSG. So you build the package against whatever OSG/Qt combo is on the
machine. If someone then force installs the wrong version of Qt,
breaking dependencies, that's not really something you can do much
about.


 Speaking for some popular distro's that I've seen, there is a way to request 
 a version of the OSG, but no way to request a Qt version of osgQt. No one 
 bothered to add separate versioning for it, probably because the OSG itself 
 doesn't provide one either so doesn't set a precedent on how it should be 
 done. See my earlier comment w.r.t each distribution being forced to invent 
 their own solutions.

OSG does provide an option to choose the Qt version already.

This problem is hardly unique and is commonly encountered - have a
look at e.g. apps using OpenCV, wxWindows, or Gnome libraries.

Typically these additional requirements are documented in the
README/INSTALL file, so the packagers (or whoever is compiling the
application) should pay attention to it. Again, that not something
you, as the app developer, should be dealing with.


 Yes, it can work, if you jump through some hoops and are careful in what you 
 do. My point is: it *should* work out of the box. A framework is supposed to 
 make the developer's job easier, not harder, after all.

 In my experience with packaged repositories, whatever can go wrong, *will* go 
 wrong eventually. Thus having proper safeguards in place can safe you a lot 
 of time.

Agreed. However, there isn't all that much that OSG can (or even
should) do here. What are you going to do if the distro packagers
decide to build OSG with no Qt support at all to reduce dependencies
(completely legitimate thing from a packager's point of view)? It is
an optional component, finally.


 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5


 That sounds good. It wouldn't have to be a separately maintained source tree, 
 just building the same tree twice with different build parameters.

That could be an option, but probably you won't be able to build it
from the same build folder by re-running cmake with different options
-  the CMake Qt variables conflict (not OSG specific, that's a CMake
thing). So you would need to build in separate folders (or wipe the
CMakeCache.txt, but that is equivalent - causes a full rebuild).

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

Re: [osg-users] osgviewerQt integration required

[Jan Ciger]

On Fri, Jun 12, 2015 at 1:36 PM, Alistair Baxter alist...@mve.com wrote:
 Actually the default version Qt 5.4 dynamically selects what it thinks is the 
 most appropriate version of OpenGL to use.

 You can force it to use desktop OpenGL by calling 
 QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL) on your app instance 
 before you call exec on it.

Ah interesting to know. That wasn't the case before.

Thanks for the tip.

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

Re: [osg-users] osgQt versioning problem

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/11/2015 10:19 PM, Jannik Heller wrote:
 Hi,
 
 Recently I have had my application tested on a wide range of linux 
 distributions. Some users are running into a problem with Qt
 version mismatch. My application gets built with Qt4, but osgQt
 might be built with Qt4 or Qt5. If you load Qt4 and Qt5 libraries
 in the same executable, a crash ensues.

This means you have built your application incorrectly. It is normally
not possible to start an application built with Qt4 using Qt5
libraries and vice versa - the APIs and ABIs are not compatible, the
library version numbers are different and the application will not start
.

 
 This forces users to rebuild the OSG with a particular version of
 Qt, just to run a certain application, which is bad.

It is unfortunately inevitable, because Qt4 and Qt5 are not
compatible. There were huge API changes, some libraries were removed
and many more added between Qt4 and 5.

 
 For a proper solution, the OSG could provide libosgQt4 and
 libosgQt5 libraries, along with find scripts that allow the
 application to request a particular osgQt version to be used. What
 do you think about the idea?
 

I don't think that is necessary - you need to ensure in your
application that it is built against the correct version of Qt which
is the *same as the version you use for osgQt*. Then you ship both OSG
libraries and your application.

The CMake scripts for Qt and OSG allow specifying the Qt version
already. And most Linux distributions ship both the older Qt4 and the
new Qt5 series, so if you build for one of them, it should work.

The only way you could have problems is if you rely on the OSG
libraries shipped by the distro, where you don't have control over how
it was compiled. However, that is a terrible idea, because that OSG
tends to be outdated and many distributions don't ship OSG at all.

In addition, if you are trying to distribute a binary-only package,
you are going to have major problems with library version and C++ ABI
incompatibilities between distributions. Qt will be the least of your
problems. You should always ship your shared libraries with the
application or recompile/package the software for the particular
distribution.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFVefgYn11XseNj94gRAjQ+AKCk66wnwYe6LPfM35sJCxMsCwNCyACfcjCU
BQs5Q4TgtHM5+vB8zQdI054=
=hWe4
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgviewerQt integration required

[Jan Ciger]

On Thu, Jun 11, 2015 at 4:43 PM, manish Choudhary osgfo...@tevs.eu wrote:
 Hi,

 I'm using Qt 5.4.2 for Windows 32-bit (VS 2013) and  OpenSceneGraph-3.2.2 
 stable release  on Window 8.1 platform.
 osgviewerQt example is not working without any modification.
 It is aborts and in the command prompt it showing
 Warning: detected OpenGL error 'invalid operation' at Before 
 Renderer::compile
 Error: In Texture::Extensions::setupGLExtensions(..) OpenGL version test 
 failed, requires valid graphics context. 

...

 Why osgviewerQt example not working that seem strange to me.?

Those errors are Qt/OpenGL problems, not OSG issues.

Did you install the Qt version using the Angle emulation, by chance? I
believe that is the default download. Angle supports only OpenGL ES
2.x and translates that to Direct3D calls, so any code requiring
true OpenGL will not work with that. The Angle backend is mainly
there to accelerate the Qt scenegraph and is not really a full OpenGL
implementation. Make sure to download the version of Qt with the
native OpenGL support

The versions with OpenGL in the name are the correct ones:
http://www.qt.io/download-open-source/#section-2

If that is OK, then make sure you have the vendor OpenGL drivers for
your graphic card installed (from AMD or Nvidia) - Windows used to
ship with an ancient version of OpenGL, that will not work with OSG.

Regards,

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

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

[Jan Ciger]

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

 how are you? At first, thanks for the effort put in the development of 
 OpenSceneGraph.

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

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


OSG would certainly work, however OSG is only a scene graph. It
doesn't have a pipeline for producing assets, no scenario/scene
editor, no concept of a map, no scripting/triggers, etc. You would
have to implement/intergrate all that yourself - OSG is basically
only OpenGL with a lot of convenience functions.

What you are likely looking for is a complete game engine instead. If
you want to use OSG, there is Delta3D which is OSG based and
integrates some of the above already.

Regards,

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