The osgmanipulators example is very clear. I should have checked the examples
first!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73606#73606
___
osg-users mailing list
Hi, I think this issue was commented somewhere else, but I couldn't find
it again: there is something broken with the cloning of osgDB::Options.
This minimal working example works fine with 3.4.x, but SIGSEVs with
3.6.1-rc3 and current master:
#include
int main(){
auto globalopts = new
Hi Robert and Glenn,
I struggle against this problem too for a will now..
Wouldn't it be a good design to make FBO a Camera property and RenderStage take
this one if exist for its stuff?
Cheers
robertosfield wrote:
> Hi Glenn,
>
> If there is a way to share FBO's between osg::Camera I don't
Hi,
AFAIK there is also a https://developer.nvidia.com/nvapi library.
Unfortunately I have no personal experience with this but I believe it can
be used to prgramatically override the setings usually set with NVidia
Control Panel.
Cheers,
Wojtek
2018-05-10 20:18 GMT+02:00 Daniel Emminizer,
Hi Chris,
Not sure if this is what you’re looking for, but you can give a hint to the
drivers by exporting variables in your code. In my main.cpp I do something
like:
#ifdef WIN32
extern "C" {
/// Declare this variable in public to enable the NVidia side of Optimus -
As you are aware, drivers like the NVidia Windows driver have a variety
of tuneable settings accessible through the vendor-specific setting
application. Many times these accomplish things that can't be accessed
through the standard OpenGL APIs or extensions.
Is there any way to force settings
On 10 May 2018 at 18:38, Bolstad, Mark wrote:
> It looks like you hypothesis was correct, I must have fat-fingered a build
> in-source as a clean checkout of the code fixed the issue.
I was able to recreate this on my system : I built OSG-3.4 in source
then 3.6 out of
It looks like you hypothesis was correct, I must have fat-fingered a build
in-source as a clean checkout of the code fixed the issue.
Thanks
Mark
> On May 10, 2018, at 1:30 PM, Bolstad, Mark wrote:
>
> I’m doing an out-of-source build. I’ll try and prune all the
I’m doing an out-of-source build. I’ll try and prune all the directories and
re-git the source.
Mark
> On May 10, 2018, at 12:18 PM, Robert Osfield wrote:
>
> Hi Mark,
>
> I am trying to work out why you have the build problem. Is there a
> chance you've done an in
Hi Robert,
I got my build on Linux done. I test both GLCORE configuration and non-GLCORE
configuration on OpenSceneGraph-3.6.
I am seeing the error in all 3 configurations:
1) Linux Ubuntu 14.04; default OSG 3.6 branch build (GL compatibility mode);
NVidia Quadro K1000M GL 4.5, 384.11
Hi Mark,
I am trying to work out why you have the build problem. Is there a
chance you've done an in source build previously that set the
include/osg/GL prior the OSG_GL_CONTEXT was added, then you're out of
source build is not overriding this as the out of date in source
version of
Hi Robert,
Thanks for trying the example. I'm perplexed why it's OK for you but not me.
In case you're curious, I'm attaching the screenshots of the output.
I should note again that I am running with OPENGL_PROFILE="GLCORE" / GL3 mode.
Would that make a difference?
I will rebuild
Hi Mark,
Are you building out of source?
Robert.
On 10 May 2018 at 16:27, Bolstad, Mark wrote:
> Mostly it’s just configuring cmake followed by make. Turn on build examples,
> delete the paths for inventor and sdl/sdl2 as I don’t need them and they
> typically cause
Hi Dan,
I finally had a chance to look at the your example. It works the same
under 3.6 branch and 3.4 branch for me, I don't ever see any issues
with the texture become skewed regardless of the size of the window.
Robert.
On 7 May 2018 at 12:15, Daniel Emminizer, Code 5773
Hi Mark,
Could you let me know the build steps you took to see this eror i.e.
the command line steps. I want to see if I can recreate the build
issue under Linux.
Robert.
On 10 May 2018 at 16:05, Bolstad, Mark wrote:
> I’m getting a compile failure on OS X 10.12
I’m getting a compile failure on OS X 10.12 with the latest version:
DisplaySettings.cpp:243:25: error:
use of undeclared identifier 'OSG_GL_CONTEXT_VERSION'
_glContextVersion = OSG_GL_CONTEXT_VERSION;
^
1 error generated.
I’ve traced this down to an order of
Hi Glenn,
If there is a way to share FBO's between osg::Camera I don't know of
it off the top of my head. You'd need to look at the
src/osgUtil/RenderStage.cpp so see how it sets up the FBO's. It's
able to ruse it's own FBO on subsequent frames so there may be a way
for forcing it to use an
On 10 May 2018 at 13:48, Rowley, Marlin R wrote:
> Robert,
>
>
>
> Could you do me a favor and see if the example in the OpenSceneGraph 3
> Cookbook, page 242 works on your computer?
>
I don't have the Cookbook. And I'm really busy right now so now time to go
chasing
Hi Robert,
I have a scenario that uses multiple RTT cameras. (The approach is similar
in concept to CSM - Cascading Shadow Maps - where you compose a texture
using multiple frustums). Each RTT camera renders to a different layer of a
Texture2DArray. This works great! However, it uses a lot more
Robert,
Could you do me a favor and see if the example in the OpenSceneGraph 3
Cookbook, page 242 works on your computer? I was originally wanting to test
with that but when I get totally white on the left side of the screen (when it
should have been showing the depth buffer), I went to
On 9 May 2018 at 23:57, Andrew Cunningham wrote:
> Clearly I **am** barking up the wrong tree and should be looking at
> osgManipulators :)
Woof Woof :-)
Are you happy with trying out osgManipulator? The osgmanipulators
example is the best place to start when learning about
Hi Marlin,
On 9 May 2018 at 18:46, Rowley, Marlin R wrote:
> Hello,
>
>
>
> I get the following error when running the example:
> osgpackeddepthstencil.cpp
>
>
>
> *RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd*
>
>
>
> I have a AMD Radeon RX580.
22 matches
Mail list logo