On Thu, Apr 11, 2019 at 5:46 PM Rowley, Marlin R
wrote:
> Sebastian,
>
> I have written the shaders for GL 3.3 so that’s done. When RenderDoc
> runs, I’m assuming it’s only checking that window context. I am NOT
> assuming that it can comb through my code and determine that I’ve used a
>
Robert:
Thanks for the reply. The first method you mentioned should do the trick.
Since we don't know the models that the user will load and the DOFTransform
names or switch names are what is displayed in the menu we can not pre-build
the menus.
Another thing I was thinking about is to keep
Hello,
The Apple VR/AR philosophy seems to officially focus on DAE files. Unofficially
it seems that other 3-D model files types are OK.
So, this solution strategy is very welcome. Thanks to the OSG community.
John
-Original Message-
From: osg-users
Hi Bruce,
On Thu, 11 Apr 2019 at 00:37, Bruce Clay wrote:
> Is there a way to programmatically determine the index when a slave camera is
> added to insure the correct one is removed?
I just looked t include/osg/View header and found :
unsigned int
Sebastian,
I have written the shaders for GL 3.3 so that’s done. When RenderDoc runs, I’m
assuming it’s only checking that window context. I am NOT assuming that it can
comb through my code and determine that I’ve used a fixed-function GL call
somewhere and therefore spits out the message.
Merlin,
As Chris already mentioned the complete application needs to run on
core-profile. That means there is no fixed function pipeline and no
backward-compatibility features.
In order to get your application running in core-profile you need to write
shaders for everything and IIRC
Core profile has none of the backward compatibility features:
https://www.khronos.org/opengl/wiki/OpenGL_Context#OpenGL_3.2_and_Profiles
I'm guessing you won't have much luck getting your application to work in
that limited situation.
___
osg-users
Sebastian,
What does “core OpenGL profile” mean with regards to the graphics context? I’m
still not getting it to work.
Here is my code structure:
…
osg::ref_ptr traits = new
osg::GraphicsContext::Traits;
traits->x = aXPosition;
traits->y = aYPosition;
Hi Marlin,
In order for RenderDoc (and most tools I’m aware of) you’re application needs
to run on core OpenGL profile.
You might want to look here for some debugging options:
https://www.khronos.org/opengl/wiki/Debugging_Tools
I personally used Nvidia Nsight for quite a while, as it at
This is correct.
If your application is GL3 context compatible, you can create a GL3 context
and then RenderDoc should be happier.
On Thu, Apr 11, 2019 at 3:08 PM Lionel Lagarde
wrote:
> Hi,
>
> Win32 is the name for all the Windows windowing systems. It is used on all
> Windows (XP, 7, 10...)
Hi,
Win32 is the name for all the Windows windowing systems. It is used on
all Windows (XP, 7, 10...) and on all targets (32, 64). So the
function is used.
If I remember correctly, the function is used only for >= GL3 contexts.
On 11/04/2019 14:51, Rowley, Marlin R wrote:
We are using
We are using Win10-x64.
We are trying to get RenderDoc to be able to see our application so we can do
some graphics debugging. It’s shouting back that the current device context
wasn’t created using CreateContextAttrib, so I started looking. So since we are
using Win64, doesn’t look like osg
Hi Marlin,
A great for CreateContextttribs in the OSG shows:
$ grep -r CreateContextAttribs .
Binary file ./lib/libosgViewer.so.3.6.4 matches
Binary file
./src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowX11.cpp.o matches
./src/osgViewer/GraphicsWindowX11.cpp:typedef GLXContext
"Bruce Clay" writes:
> When I walk through the nodes in the
> DOFTransform list I can see that each node has an osg::Transform but
> calling asPositionAttitudeTransform returns NULL as do many of the
> other possible converters.
That is right, because they are not PositionAttitudeTransforms, but
14 matches
Mail list logo
