Hi Robert,
Thank you for your reply.
> I have outlined why mixing scene graph state with the rendering back-end is a
> bad idea.
Could you tell me where I can read it?
By the way,I don't mix scene graph state with the rendering back-end,but make
it possible,since I only add an extension layer a
Hi Jannik,
I forgot to mention it, I don't realize originally that it'd work for
your usage case just calling drawable-->dirtyGLObjects() should be
sufficient addition to get the arrays to update automiatcally without
needing to set DataVaraince to DYNAMIC.
I'm now considering adding a STREAM var
HI Jannik,
On 18 August 2016 at 13:50, Jannik Heller wrote:
> Have you done benchmarking to see if avoiding these if checks makes a
> difference?
Yes. It helps just doing one check.
> Have you considered checking the individual arrays could be advantageous if
> not all arrays have changed?
T
One more thing: Rendering to a pbuffer does not automatically give you the
option to access your rendered content as a texture.
The technique to render to texture with pbuffers is called pbuffer-rtt and
implemented in several OSG samples with the "
*--pbuffer-rtt" command line option.*
*This may
On Windows, create a graphics context with the pbuffer flag set to true
and windowDecoration set to false.
osg::ref_ptr traits = new
osg::GraphicsContext::Traits;
traits->x = 0;
traits->y = 0;
traits->width = 640;
traits->height = 480;
traits->red =
Hi,
OK, I based my initial integration into my app on osgteapot.cpp. As with all
the other examples, it os run via
viewer.run();
And this creates an output window in OSX (and I am assuming any other OS its
run on). And thats the issue I have, I need OSG to run "headless", that is to
say, prod
Hi,
>
> I have
> done this to avoid the extra checks required against the individual
> arrays to see if they are dirty or not - I have done it for
> performance reasons as I want to keep the CPU overhead for draw
> dispatch as low as possible.
>
Have you done benchmarking to see if avoidi
Hi,
https://github.com/xarray/osgRecipes
Chapter 6 - it's all what you need.
Cheers,
Nickolai
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68418#68418
___
osg-users mailing list
osg-users@lists.
Hi Chris,
Take a look at the osgprerender example. It shows you how to render to
a framebuffer object.
The bound texture can be used to be displayed later on.
Cheers
Sebastian
Hi,
I have an existing app I am developing, which itself is based on OpenGL. It
uses an API that provides a 3D win
have a look at the osgprerender example. That one renders to texture first,
and then uses the contents of this texture for rendering to screen.
The osgscreencapture and osgposter examples also have options to render
off-screen to FBO or pbuffers.
2016-08-18 13:19 GMT+02:00 Chris Thomas :
> Hi,
Hi,
I have an existing app I am developing, which itself is based on OpenGL. It
uses an API that provides a 3D windowing system, with different media being
displayed on planes, within this 3D space. All good...
Except, its API does not offer anything near the flexibility, and ease of use
of OS
Hi,
OSG version is 3.4.0
Cheers,
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68414#68414
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listin
Hi Wang,
I have outlined why mixing scene graph state with the rendering back-end is
a bad idea. It's a dead end so I see little point in hashing over it.
The VAO implementation now in the vertex_array_branch is pretty close to
being fully realised, from here on out is a case of testibg and tweak
13 matches
Mail list logo
