Hi,
From what I remember, the original mail on the list about the ffmpeg
plugin mentioned such a setup. Maybe you can look that message up? Plz
keep us posted about your findings.
hth
Raymond
On 9/26/2013 1:56 AM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:
Has anyone had any
Tony Vasile writes:
Hi, Tried setting the values on the command line and the applications
that are built still refer to the .so.80 version of the dynamic
library. Any other suggestions?
You have to rebuild everything —OSG and your program— from scratch.
Nevertheless, I wonder why you would
Anyone any idea?
The problem is that as soon as PagedLOD nodes get paged in they are in
the scenegraph.
Thus saving the graph will save the _databasePath.
cheers
Sebastian
Hi folks,
I found some problem which I'm not able to solve easily.
I try to pack a large number of files in to an
Hi there
I have a tiled DB that is loaded using the DatabasePager. Everything ok and
fully performant.
Now I generate some custom drawables and attach them to the tiles sub-scene
graph. Suddenly I notice a heavy load problem (stutter) in the moment when the
node is being added to the main
@Robert, would it be possible to call
Code:
if (osgDB::Registry::instance()-getSharedStateManager())
osgDB::Registry::instance()-getSharedStateManager()-share(databaseRequest-_loadedModel.get());
in the db loading thread scope instead of during the scene update?
Hi Daniel,
I'm not the author of SharedStateManager so to answer questions I'd need to
dive into the code like yourself to provide answers. In general moving
operations to background threads make sense, but only if they can be done
in a thread safe way. In the case of the
robertosfield wrote:
Hi Jan,
I just had a quick look over the osgoculusviewer code and first thought is
that it should be possible to convert the code across to the new a
osgViewer::ViewConfig subclass which could sit alongside the new
include/osgViewer/config configurations. The
Hi Bjorn,
The orientation of the view would normally come under the
View::getCamera()'s ViewMatrix, usually it's the job of the
CameraManipulators to do this, so you could implement the local offsets
using a custom CameraManipulator written specifically for the OcculusRift.
Alternatively you
I'm just throwing this out there for those who like to keep abreast of
industry developments.
http://www.anandtech.com/show/7371/understanding-amds-mantle-a-lowlevel-graphics-api-for-gcn
Mantle is basically a VERY thin layer between the graphics core (hence,
mantle) and application. Since it
robertosfield wrote:
Hi Bjorn,
The orientation of the view would normally come under the View::getCamera()'s
ViewMatrix, usually it's the job of the CameraManipulators to do this, so you
could implement the local offsets using a custom CameraManipulator written
specifically for the
Raymond,
I scoured the forum to find something and didn't find anything in particular
that addressed my questions. Do you have a link to the discussion you're
referring to?
Thanks,
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Hi,
I am now running against the same issue.
I checked to see that everything is compiled with /MD.
I'm trying to build osg 3.2.0 x64 with VS2012
- 3rd-Party Binaries from:
www.helleboreconsulting.com/index.php/open-source/openscenegraph
- OSG built by myself
- my project runs into:
Code:
4*
Greetings All!
Well, the hard work is over! I've tossed all remaining remnants of the old SGI
based code and now my project is now a %100 OSG project!!
Yey!!
What I have resisted until now to do was to migrate to the current version of
OSG and move to 64bit mode until I finished development.
Hi folks,
We are building a database using an additional texture layer as a height field.
I'm finding that the image stored in database is coming across with what
appears to be 1bit noise. A constant image of say, 125 / 255 after going
through VPB is coming out with some values of 124 /
HI Brad,
My guess is that it's an artefact of using OpenGL/ST3C compression that the
OSG uses by default to keep the tile sizes. You can disable compression
when doing the VPB build by choosing an RGB output format. Run osgdem
--help to see all the options.
Robert.
On 26 September 2013
Hi Robert,
Maybe I'm using the wrong switch? From my email below the target has
compression disabled using -RGBA.
Does this need to be specified after each -layer # switch?
-B
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Hi folks,
I tried --RGB-16 and I get the same effect. There is some kind of sampling
going on and it's hard to tell what it is. The same pattern is in all color
channels.
Any ideas?
-B
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org]
I've found that RGB-16 solves my issues, but not RGBA
On Thu, Sep 26, 2013 at 6:39 PM, Brad Colbert bcolb...@rscusa.com wrote:
Hi Robert,
Maybe I'm using the wrong switch? From my email below the target has
compression disabled using -RGBA.
Does this need to be specified after each
Hi Florian,
You can get around the fatal error by adding /FORCE: MULTIPLE to your
linker options.
This seems to be some odd VS2010 and beyond conformance problem.
Basically I get this error in almost any application linking to osgDB
and using fstream. It is somehow related to the derived
I had the same problem with VS2010 and there are two ways to get around it.
1. Use /FORCE:multiple
2. Create a typdef:
Code:
#pragma once
// Compatibility layer for VS2010 bug. The compiler tries to link the same
// multiple symbols in for the OSG fstream classes which inherit from the STL
20 matches
Mail list logo
