Hi Cong,
On Thu, 16 Aug 2018 at 06:32, Cong Ye wrote:
> I agree this is a problem. But i don't think it causes the shadow not
> displays in embedded window problem. Could I ask where can I specific the
> graphicscontext to shadow camera? That may be the problem? Didn't find any
> methods in sh
Hi Julien,
On Thu, 16 Aug 2018 at 02:30, Julien Valentin
wrote:
> Immutable Storage mandatory for lot of GL4 features:
> TextureImage synchronization,TextureView, persistance mapping, virtual
> texture and surely other stuff I didn't used yet
Thanks, this is what I was missing. I had been sea
Hi Julien,
On Wed, 15 Aug 2018 at 23:44, Julien Valentin
wrote:
> if I read all that correctly it seams assumeSizedInternallFormat is only used
> to create Texture from Image...I think an improvment would be to move
> assumeSizedInternallFormat from Texture to Image and change its name
> (getS
robertosfield wrote:
> Hi Cong,
>
> On Thu, 16 Aug 2018 at 06:32, Cong Ye <> wrote:
>
> > I agree this is a problem. But i don't think it causes the shadow not
> > displays in embedded window problem. Could I ask where can I specific the
> > graphicscontext to shadow camera? That may be the p
On Thu, 16 Aug 2018 at 09:29, Cong Ye wrote:
> I am currently using the osgShadow NodeKist. It only works when I use
> osgViewer as default graphics context. Now the case is, I have to assign a
> third party graphics context to the main camera as we are using a Qt Gui for
> buttons etc. After I
Ho I haven't realized the root of existence of this function was the previous
contribution to the implementation of glTexStorage.
So Now I can see where the contributor (sure it's Pawel Ksiezopolski) wanted to
do.
I don't know why there's so many comments and misses in sizedInternalFormats
but
glTexStorage is much faster then glTexImage because it allocates the whole
memory buffer in one shot, glTeximage take quite a bit longer to allocate
the memory, not sure if it's 1.x or even longer than that due to
reallocing and moving the memory if needed. I'm running off 3.4 and made a
number
Hi julien,
On Thu, 16 Aug 2018 at 17:45, Julien Valentin
wrote:
> Ho I haven't realized the root of existence of this function was the previous
> contribution to the implementation of glTexStorage.
> So Now I can see where the contributor (sure it's Pawel Ksiezopolski) wanted
> to do.
>
> I don
Hi Dan et al.
A quick update. I am now looking into this issue, sill too early to
provide a solution, it shouldn't take too much longer though.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listin
Hi Robert, thanks for the update. I'm happy to test my side against whatever
you decide, once I'm in the office.
Thanks,
- Dan
> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Thursday, August 16, 2018 1:
testing enum as bool is sure bad practice but the first error was to set 0 as
default for _sourceFormat...
robertosfield wrote:
> Hi julien,
>
> On Thu, 16 Aug 2018 at 17:45, Julien Valentin
> <> wrote:
>
> > Ho I haven't realized the root of existence of this function was the
> > previous co
..But my question was
If I'd make a pr with this fix for all Textures
Code:
if( useTexStorrage)
{
//ensure _internalFormat is sized
GLenum sized_internalFormat = _internalFormat;
if(!isSizedInternalFormat( sized_internalFormat))
siz
Forgot to mention:
The code posing problem with ImageLess Texture is not in Texture.cpp but it's
in derivated TextureXXX.cpp
mp3butcher wrote:
> ..But my question was
> If I'd make a pr with this fix for all Textures
>
> Code:
> if( useTexStorrage)
> {
> //ensure _internal
I have checked in a fix for the leaking of the VAS objects:
https://github.com/openscenegraph/OpenSceneGraph/commit/eee5d5482e41290e7c210273f8c6bae489cedb76
The solution was to call the releaseGLObjects(), but done in a way to
avoid a the Drawable destructor calling the
Geometry::releaseGLOb
Hi Jordi
I admit I haven't read the question but the topic title remind me of a pr i
haven't made...
Should'nt it be default obj plugin behavior not to strip instead of an option
one have to set?
Is this pr valid to you?
https://github.com/openscenegraph/OpenSceneGraph/pull/597
Cheers
Jordi Tor
Oups made mistake in given pr good one is
I should have also remove the comment talking about perf enancement (so 90's)
Tristrip is good for HW but Optimizer generate multiple patch so duplicate one
prim set into several (Draw Overhead)
Indexed Triangles nowadays have realy good perf
https://gith
16 matches
Mail list logo