OK I figured it out after digging further into SceneView. In case anyone else
ever runs into this, here is what's going on and how to fix it.
When a new View is created (e.g. osgViewer), it defaults to HEADLIGHT mode and
internally creates the master Camera, along with a Renderer and SceneView
mp3butcher wrote:
> Hi all
> I made my first step with conan and for that i made a recipe for osg3.4.0
> https://github.com/mp3butcher/osg_conan_recipe
> I also upload this bintray but it require approval to be public
>
> I doubt to understood everything but it could be a great multiplatform
Hi Nick,
There isn't anyone else other than you can debug this one - you are
the only one with your data and with your application code, you are
the only one seeing this issue, we'd have to be omnipresent to be able
to pinpoint what is wrong.
As I said the best thing you can do is run your
Hi Maxim,
We just add #define as required rather than attempting to import all
features. As new GL features are added we may find temporarily a
#define is missed, when this occurs we add it as soon as we know about
it.
Not all GL headers are up to date so we generally have to backport
those
Hi,
Has this been resolved, or are there any news on keeping GL extensions updated?
I just ran into a problem where
Code:
#define GL_READ_ONLY 0x88B8
was missing from GL_VERSION_1_5 section. If GLEW was
included it of course worked.
So having extensions updated to 4.6 would be very
I just checked a recent osg::Drawable header file and it seems
dirtyDisplayList() is deprecated
and has been replaced with dirtyGLObjects(). Relevant snippet follows:
#ifdef OSG_USE_DEPRECATED_API
/** Deprecated, use dirtyGLObjects() instead. */
inline void dirtyDisplayList()
{
dirtyGLObjects();
Are display lists active in your scene? if so, maybe a dirtyDisplayList()
call might be required
on the affected drawables.
drawable->dirtyDisplayList()
As far as I know display lists are still the default in OSG, unless you
explicitly disable them on
geometry objects (and possibly enable vertex
Hi all,
I'm loading 3ds scenes as subnodes into my scene. The 3ds coordinates
are in a different scale than my scene.
Usually I would solve this by a transform. But because of internal
reasons I need the vertices being
in MY coordinate measure.
So I wrote a scaling visitor, that multiplies al
Thanks Robert,
no circular reference since I am displaying that database in the viewer
nicely. Here is the struct (a bit odd but it is as is):
Group
|
PagedLOD PagedLOD PagedLOD dozen of these
|
Quadtree (similar to VPB generated subtiles)
I was thinking the visitor is reading all of these
Hi Nick,
This is really something you'd want to use a debug for - just run it
and break the app before anything untoward happens.
The code itself looks quite benign on a first reading, the only thing
I can think of that might cause a memory issue would be if your scene
graph had a circular
hi Robert, Community,
I have the following code in a loop against very large quadtree based
database. And this code is eating all the memory, progressively and then
the system kills it . Any clue?
Thanks a lot
osg::ref_ptr picker;
osg::ref_ptr iv;
osg::Vec3d getHOT(const osg::Vec3d& position,
"Kazim Kamilov" writes:
> Hi, OSG community!
>
> In OSG is not have free camera manipulator. Need to fix it!
> Robert, can you add this in the osgGA?
> Sources in attachment.
>
> Thank you!
>
Dear Kazim,
by just attaching your files in a post in the general channel you risk
that your submission
Hi.
Here's a step-by-step guide to get you started with OSG & MinGW:
https://github.com/OGStudio/openscenegraph-cross-platform-guide/tree/master/1.3.InstallUnderWindows
On 8 January 2018 at 12:43, Christian Schulte
wrote:
> Hi Stephan,
>
> in my honest opinion it
13 matches
Mail list logo