Hi Rômulo,
I didn't spot any code you posted that handles resizing, did I miss it?
Robert.
On Tue, 2 Oct 2018 at 08:10, Rômulo Cerqueira
wrote:
>
> Hi,
>
> I have rendered a FBO camera to image by using a callback (as seen in the
> code below), however some OpenGL warnings/erros are raised
Hi Nick & Per,
On Tue, 2 Oct 2018 at 06:12, Per Nordqvist wrote:
> I and Nick are working to utilize as much of the GPUs as possible, either on
> single machine or cluster.
> So hardware is not yet decided, but let's assume ubuntu 16+, multiple modern
> Nvidia gaming cards, but still single
Hi Andrew,
On Tue, 2 Oct 2018 at 03:45, Andrew Cunningham wrote:
> I upgraded from 3.4.1 to 3.5.7 and my code that uses "hardware instancing"
> (to render a large number of simple geometry) renders nothing now.
3.5.7 is a developer release and is unsupported, I wouldn't recommend
using an old
Hi David,
It's not possible to know specifically what is wrong without having
your hardware, software and data available to test, even with these
one might well need inisght from NVidia to unravel what is going on.
>From your description it sounds like you are running three separate
slave
On Fri, 28 Sep 2018 at 14:48, Rowley, Marlin R
wrote:
> LOL @ mis-reading my question.
>
My best excuses is speed reading and trying to do too many things at once
:-)
> How would you check the values of vertices? I just need to see the
> transformed values of a vertex.
>
One way would be
On Fri, 28 Sep 2018 at 12:13, michael kapelko wrote:
> But so far I've seen no problem with `this` approach.
Well it compiles... and technically it's valid C++.
I don't believe it's a good practice though, you can do lots of crazy
things in C++ and still have it compile. The 6 extra characters
Hi Marlin,
On Fri, 28 Sep 2018 at 07:40, Robert Osfield wrote:
> To pass data into shaders you have use a combination of uniforms
> (osg::Unfiorm), textures (osg::Textre*) and vertex attributes. With recent
> 3.4.x onwards you also have the option of passing in constants via
>
Hi Rômulo,
Without the the line numbers on the source we can't match up the stack
trace crash point to lines of code.
Robert.
On Thu, 27 Sep 2018 at 20:45, Rômulo Cerqueira
wrote:
>
> Hi,
>
> I have tried to read image from RTT (where the image is "not attached", but
> available on buffer)
Hi Marlin,
On Thu, 27 Sep 2018 at 19:30, Rowley, Marlin R
wrote:
> Is there a way to examine variable values in shader code? I can’t figure
> out this problem that we are having unless I can see the values in the
> shaders.
>
To pass data into shaders you have use a combination of uniforms
Hi Lonni,
Laurens suggested fix is what I would have suggested too so I'd
recommend you just apply these locally.
For updating to the latest version, given that you are jumping from
3.01 to 3.6.x would be a big jump. Both are still part of 3.x series
so broadly similar w.r.t public API, so for
Hi Michael,
On Wed, 26 Sep 2018 at 09:16, michael kapelko wrote:
> I started to use explicit `this` to simplify reading and increase
> "shareability" of code:
Doing something that very few other developers do is likely to reduce
"shareability", I'm experienced engineer and read lots of third
Hi Michael,
Thanks for creating the new tutorial.
I had a quick look at the examples repository and am curious why do
you use "this->" every time you access a member variable or method?
Personally, as a style of coding I find it a bit odd to see it used so
pervasively, it's unusually enough
; To: OpenSceneGraph Users
> Subject: RE: [osg-users] context IDs
>
> Thanks, I'll take a look. I am hoping this will be more remove than replace,
> not needing multiple levels of caching.
>
> thanks
> andy
>
> -Original Message-
> From: osg-users On Behalf
then we need a way to clear out what is stored, possibly
> when the context ID usage count goes to 0, or maybe explicitly.
>
> thanks
>
> andy
>
> -Original Message-
> From: osg-users On Behalf Of
> Robert Osfield
> Sent: Wednesday, September 19, 2018 4:20
Hi Andy,
It's quite a while since I worked specifically on the osg::State,
ContextID, osg::GLExtensions management. In principle it should be
possible to reuse ContextID's, the sticky issue of whether the
GLExtensions object is recreated for each new graphics context is
something I haven't
Hi François,
On Sat, 15 Sep 2018 at 18:31, François Cami wrote:
> Fedora uses HyperKitty:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/
>
> ( https://hyperkitty.readthedocs.io/en/latest/ )
>
> It's quite cool. Users can interact with the ML directly with the web
Hi Werner,
On Tue, 11 Sep 2018 at 12:02, Werner Modenbach
wrote:
> My integration is dated April 2013 and I didn't need any changes since then.
It might not have any issues with the usage case you have, but it
doesn't necessarily mean that it will work with all usage cases.
One area that broke
ribute Texture2DArray.
>
>
> Again, these may just be glTexStorage strictly enforcing things that
> glTexImage was lenient about.
>
> Glenn
>
>
> On Fri, Sep 14, 2018 at 8:56 AM Robert Osfield
> wrote:
>>
>> On Fri, 14 Sep 2018 at 13:08, Glenn Waldron
&g
Hi Herman,
On Fri, 14 Sep 2018 at 15:00, Herman Varma wrote:
> Thanks to your input I have Ben Discoe's software up and running with
> OSG-3.6.2. He does not appear to be supporting VTP since 2015.
Good to hear that you've completed the port.
OpenSceneGraph-3.6.3 is out now so you'll have to
On Fri, 14 Sep 2018 at 13:08, Glenn Waldron wrote:
> False alarm on the transparency report -- sorry!
That's a relief, didn't want to break the record of hearing of the
first bug right after tagging a first release.
Thanks for the testing,
Robert.
___
Hi All,
I would like feedback on the community about possible forum/mailing
list tools that we could adopt for the OSG and VSG projects. I don't
have any significant experience with Gitter but have just started
looking into it - I see that osgjs has a presence.
Would love to hear what others
and bug fixings,
Robert.
-- ChangeLog since 3.6.2
Fri, 14 Sep 2018 10:41:24 +0100
Author : Robert Osfield
Updated version number and date for 3.6.3 stable release
Thu, 13 Sep 2018 08:52:21 +0100
Author : Robert Osfield
Updated ChangeLog for 3.6.3-rc3
Thu, 13 Sep 2018 08:47:17 +0100
Author : Robert
Hi All,
I'm ready to tag the 3.6.3 release. All the issues I'm aware of are
resolved, so if there is some issue with 3.6.3-rc3 please let me know,
otherwise it'll have to wait till after 3.6.3.
Cheers,
Robert.
___
osg-users mailing list
GL_BLEND if the image was translucent and tested it with
OpenSceneGrpaph-Data/Images/trree0.rgba and it worked fine. The
modified file is attached.
#include
#include
#include
#include
#include
#include
const char* vert =
"#version 330 compatibility\n"
"out vec4 coord;\n"
"void main() {\n"
Hi Glenn,
On Thu, 13 Sep 2018 at 21:25, Glenn Waldron wrote:
> Did you test it using a texture with alpha channel? We are now seeing some
> problems now transparency.
Do you see these problems with 3.6.3-rc3? Do they occur with test
program Laurens posted? Do they occur with any alpha'd
HI Laurens,
Fun image demonstration of mipmapping :-)
Works fine for me with 3.6.3-rc3.
Cheers,
Robert
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Hi Harman
On Thu, 13 Sep 2018 at 13:55, Herman Varma wrote:
> Just to clarify I should replace in the class CSimpleInterimShadowTechnique
>
>
> CSimpleInterimShadowTechnique();
> CSimpleInterimShadowTechnique(const CSimpleInterimShadowTechnique&
> es, const osg::CopyOp&
since 3.6.3-rc2
Thu, 13 Sep 2018 08:47:17 +0100
Author : Robert Osfield
Updated for 3.6.3-rc3
Wed, 12 Sep 2018 17:45:49 +0100
Author : Robert Osfield
Standardized the glTexStorage*() calls to use
osg::maximum(_numMipmapLevels,1) of rnumber of mipmaps to keep the
usage consistent. Fixed
Hi Herman,
To make sure that shadow techniques properly handling applications
opening new windows and properly handle clean up they need to
implement the resizeGLObjectBuffers(..) and releaseGLObjects(..)
methods. In 3.6.x to ensure this is done these methods are pure
virtual forcing the
Hi Glenn etl al,
Using Laurens PR as inspiration I have applied a fix for glTexStorage
mipmap allocation issue as part of wider standatization of how the
number of mipmap levels is selected for glTexStorage,
The commit to OpenSceneGraph-3.6 is:
gist.github.com/gwaldron/9d65c35a5d940965429f401331b72420
>
> Windows 10, NVIDIA 760GTX, OSG 3.6.x branch tip 9/11/18.
>
> Glenn Waldron
>
>
> On Tue, Sep 11, 2018 at 7:36 AM Robert Osfield
> wrote:
>>
>> Hi All,
>>
>> I have just tagged the 3.
Hi Nick,
There are plenty of ways mutlti-thread setting of Text labels could
cause problems if the threads reading from the Text are running in
parallel to the ones setting it. A mutex "might" help but it could
easily be done in the wrong way. If you are modifying text
dynamically then you
Hi Steven,
osgViewer was never designed to be used in the way you want to use it,
there are almost certainly better ways of doing what you want to do
functionally and a simpler way that trying play games with who invokes
frame. It's just a bad approach so trying to help do something that
isn't
Hi Steven,
I haven't heard of anyone trying to call frame from multiple threads
before, and personally wouldn't recommend doing it. I have said why
you are wanting to do this so can't judge how sensible or daft it is.
If you want an application that has multiple threads that modifying
something
Hi All,
I recently updated my OS to Kubuntu 18.04 and when I build the OSG I
now getting warnings that I hadn't seen before, I'm working through
these and will be checking in fixes for them, but one I haven't worked
out how to resolve:
since 3.6.3-rc1
Tue, 11 Sep 2018 11:56:04 +0100
Author : Robert Osfield
Updated rc number 2 for 3.6.3-rc2
Tue, 11 Sep 2018 11:29:36 +0100
Author : OpenSceneGraph git repository
Merge pull request #620 from LaurensVoerman/txt_SCREEN_COORDSfix scale
problem for osgText with characterSizeMode
HI Eric,
The change in behaviour is actually a fix for a regressions that
happened when the Linux window managers changed. It's just the
default behavior that has changed for setUpViewAcrossAllScreens(), so
it now behaves as it should. You can adjust what happens by default
using the Producer
Hi Riccardo,
On Thu, 6 Sep 2018 at 16:43, Riccardo Corsi wrote:
> I tried adding the setShaderHint() line but things get a bit worse - alpha
> issue still there and not text at all, see attached screenshot.
>
> I get display errors also in my other HUD contents where I actually use gl_
>
icanmapping/OpenSceneGraph/commit/c8b5a925459aa624a1d779192d3b8b0d7c4fa767
>
> I made this change against the 3.6.x branch. It's a small patch, but if you
> need a proper PR let me know and I'll spend some time putting it together.
>
> Glenn Waldron
>
>
> On Thu, Sep 6, 2018 at 7:38 AM Robert Osfield
>
Hi All,
I have tagged the first release candidate for the upcoming 3.6.3 stable release:
https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.3-rc1
To make sure that this stable release is a rock solid as we can make
it I need the community to help out with build and
Hi Ricardo,
On Thu, 6 Sep 2018 at 10:49, Riccardo Corsi wrote:
> good guess! I've enabled the aliasing and my shaders works now with osg
> default build!
> With this configuration there is still a side effect though: something is
> wrong with alpha settings for HUD cameras.
> See attached
Hi Ale,
Thanks for the updating test program, this illustrates a separate bug
in the KdTree copy constructor. I have added missing copying of the
indices:
~/OpenSceneGraph/src/osg$ git diff
diff --git a/src/osg/KdTree.cpp b/src/osg/KdTree.cpp
index 709c12f99..3f7a4a34a 100644
---
HI Brian,
I am not aware of any issues with textured point sprites in 3.6.
If the rendering flickers between states as you move the eye point
then this is an indication that some state hasn't been consistently
set up in your scene graph so that subgraph that is flickering is
inheriting state
Hi Omar,
On Wed, 5 Sep 2018 at 17:07, Omar Álvarez wrote:
> Thank you very much for your time. If nobody else feels like doing it, I can
> help with updating osg::GraphicsContext::WindowingSystemInterface.
This hasn't looked like an OSG bug too me, just a usage issue. What
specifically do you
Hi Riccardo,
On Wed, 5 Sep 2018 at 15:56, Riccardo Corsi wrote:
> I've rebuilt osg as suggested by Robert and still getting no GL errors but
> nothing shows up.
> To sum it up, running a test app which only uses libA (which addresses only
> GL3 functions and shaders version 150)
> under
I missed changing one of the getScreen() calls in main, so please use
the attached version.
#include
#include
int main(int argc, char** argv)
{
osg::ArgumentParser arguments(, argv);
osgViewer::Viewer viewer(arguments);
osg::GraphicsContext::WindowingSystemInterface* wsi =
On Wed, 5 Sep 2018 at 15:22, Julien Valentin wrote:
> for your code you should replace
> wsi->getNumScreens()
> with
> wsi->getNumScreens(osg::GraphicsContext::ScreenIdentifier(1))
> to work on DISPLAY=:1.0
Sounds like we are getting to the bottom of things now :-)
FYI,
HI Julian,
On Wed, 5 Sep 2018 at 15:10, Julien Valentin wrote:
> WindowingSystemInterface is an interface implemented in system dependant
> osgViewer::XXXWindowingSystemInterface
> What may be done is to add a system agnotistic windowInterface in osgviewer
>
> #ifdef SYS
> typedef
Hi Omar,
What happens when you run osgviewer? Do you get errors output to the console?
Do any of the OSG examples fail?
If we can't see the error in standard OSG examples then it may be
worth creating a small test program so that others can run it on their
own systems to see if we can
Hi Riccardo,
On Wed, 5 Sep 2018 at 10:23, Riccardo Corsi wrote:
> Now what I'd like to do (on Win only) is to use libA and libB together.
> To do so I expected it was enough to add the OSG_GL3_AVAILABLE flag to build
> OSG and to request a Compatibility GL context.
> What happens instead is
Hi Riccardo,
The OSG_GL*_AVAILABLE flags are the lower level switches, if you want
a core profile with none of the fixed funcion pipeline then the
OSG_GL1 + GL2_AVAILABLE will need to be OFF. There are other controls
as well.
The best way to get everything set correct is to run CMake with
since 3.6.2
Tue, 4 Sep 2018 15:26:30 +0100
Author : Robert Osfield
Changed the ShapeDrawable::build() methpd so that it does run when the
ShadpwDrawabe is a KdTree.
Tue, 4 Sep 2018 14:13:32 +0100
Author : Robert Osfield
Updated SO version as XmlNode::Input changes change the ABI
Tue, 4 Sep 2018 12
On Fri, 31 Aug 2018 at 08:06, Trajce Nikolov NICK
wrote:
> can you fix this too when you get back to OSG dev please?
This morning I have checked in UTF8 handling in XmlNode/Input to
master and the 3.6 branch.
Hi Ale,
I have invested the issue further, focusing on why the sphere appears
fine when the KdTree isn't build, but disappears when it is. I
tracked this issue down to the ShapeDrawable::setShape() being invoked
by the KdTreeBuilder that creates a KdTree for a ShapeDrawable then
assigns this
Hi Ale,
I built with release.
I will try with a debug build. A change in behaviour between release
a debug would suggest an unintialized variable.
Could you provide the stack trace.
A binary for Windows isn't required at this point.
Cheers,
Robert.
On Mon, 3 Sep 2018 at 15:00, Ale Maro
Hi All,
Thanks to John to organizing the SIggraph BOF once again.
My BOF presentation given in my absence (I was hear in Scotland at the
time :-) was written in Google Slides, and you can access it with the
following link:
Hi Jilien,
On Tue, 28 Aug 2018 at 22:55, Julien Achard wrote:
> I have reduced the involved code to the minimum.
> I put in attachement the sample.
>
> It's a really simple application, and you will see that attemp to call run()
> (or frame() in a loop) in the run() of the thread will fail.
>
>
Hi Guy,
I have looked into the revision that Konstantin made back in January
and it looks to me like the intent was to prevent the viewer from
starting threads before you've called realize:
Hi Ale,
I have now built and run your test and it works fine for me.
I have run with the --relative-camera-scene command line option and I
don't see any cube or sphere, but I do see reports of hits.
This is testing with the 3.6 branch under Kubuntu 18.04.
At this point I don't have anything
H Glenn,
I don't have a test for the issue you've seen so have to implement
what I think could resolve the issue and get this checked into OSG
master, 3.6 and 3.6-TexStorage:
https://github.com/openscenegraph/OpenSceneGraph/commit/bcba3928e6be5d284b1611a0472fe5e24d184f67
I simply added a
Hi Glenn,
A, Fix one problem create another...
The Drawable::releaseGLObjects() was added to the destrcutor fix a bug
with VertexArrayState not being cleaned up. Calling the
StateSet::releaseGLObjects() should be safe if it's not shared, but it
would be inappropriate to call it when
Hi Cong,
Whether it's safe to do or not will depend the threading you are using
in your viewer. If you viewer is running single threaded then it
should be fine to use cull callbacks. However, if you have multiple
cull traversals threads happening in parallel then you'll end up with
a potential
On Wed, 29 Aug 2018 at 09:17, Ale Maro wrote:
> sorry for asking again. Did you have time to take a look to my example?
Not yet. Still busy wrapping up the last week of the Exploration Phase
of the VSG project. Next week I'll spend time on the OSG side and
will have a look.
Robert.
In my testing here on my Kubuntu 18.04 I've found the
glGetProcAddressARB and getGetProcAddress functions were returning non
NULL values for invalid function names. This looks like a driver bug
to me, one that has potentially for affect far more than just the
glGetTextureHandle usage. dlsym works
We are entering a bit of twilight zone to
osg::getGLExtensionFuncPtr() I added the follow debug output to the
linux code path:
static GetProcAddressARBProc s_glXGetProcAddressARB =
convertPointerType(dlsym(0,
"glXGetProcAddressARB"));
if (s_glXGetProcAddressARB)
{
On Tue, 28 Aug 2018 at 08:24, Voerman, L. wrote:
> HI Julien,
> I cannot find a specification for the function with the name
> "glGetTextureHandle", and I think that might explain why you get unexpected
> results on linux. The windows driver does not provide this function, so osg
> falls back
Hi Julien.
On Sun, 26 Aug 2018 at 16:29, Julien Valentin
wrote:
> My plateform is Ubuntu LTS with Nvidia proprietary driver
> I noticed the bug come and go when update my system (Lately, it comes back
> when updating to 18.04 with nvidia-390)
I have Kubuntu 18.04 + Nvidia 390.48 on my system
Hi GuiYe,
You can change the render to texture Camera's NodeMask to 0x0 to
switch it off. To render switch it back to 0x.
Robert.
On Sun, 26 Aug 2018 at 08:29, GuiYe wrote:
>
>
> Hi,
> I want to render a ploygon to texture,I won't change this polygon unless the
> polygon data changes.
Hi Juilen,
This sounds like a driver bug. What OS/hardware/drivers are you using?
It would be worth printing out the address returned for each the
"glGetTextureHandle", "glGetTextureHandleARB","glGetTextureHandleNV"
variants to see what is being returned, this might gives some clues
that could
On Fri, 24 Aug 2018 at 13:59, Daniel Emminizer, Code 5773
wrote:
> So good so far on 3.6-TexStorage branch, running on win64 VC-14 (Visual
> Studio 2015). No issues seen yet.
Thanks for the testing. Good to hear things are working fine. If
there no reports of issues I'll merge 3.6-TexStorage
On Wed, 22 Aug 2018 at 12:54, Daniel Emminizer, Code 5773
wrote:
> It's on my list to swap over to 3.6-TexStorage to make sure it doesn't break
> anything. I'll do that in the next couple of days and test this out.
Thanks.
> The change looked good from a quick review on 3.6 branch. But on
On Wed, 22 Aug 2018 at 11:19, michael kapelko wrote:
> Hi. Who's the audience of the change? (i.e. should I care?)
With my focus on new feature dev to the VSG project for the next year
the next major OSG release (4.0) is pushed a bit further out, so
availability of new features that are in
Hi Dan et. al,
To resolve this issue I have added a mode validity setting to
State::nitializeExtensionProcs(), this resolves the GL warning
generated by the checkvalidity_bug test program. The fix is checked
into master, 3.6 branch and 3.6-TexStorage.
Cheers,
Robert.
Hi Chenyanlin,
OpenGL lights are a form of positional state, positional state uses
the current modelview matrix to compute the values in eye space that
are passed to the graphics card to do the maths required within the
shaders.
If you just place the Light into the scene graph as you'd do with
Hi Dan,
On Tue, 21 Aug 2018 at 23:15, Daniel Emminizer, Code 5773
wrote:
> Still a low priority because I am able to work around in my own code. But
> wanted to make sure this doesn't get lost in the traffic about texture modes
> in other threads. The original message had an example .cpp
On Tue, 21 Aug 2018 at 20:43, Paul Levy wrote:
> Seems to be working now. Yesterday I submitted a PR to change GL_RGBA16F and
> GL_RGBA32F to GL_RGBA16F_ARB and GL_RGBA32F_ARB, but you only changed
> GL_RGBA32F. Both are undefined on Windows so I re-submitted a PR to get the
> Windows build
HI All,
I have created a OpenSceneGraph-3.6-TexStorage branch to allow
glTexStorage support that was just in the master branch to be ported
back onto 3.6. There isn't any public API changes so it should drop
in OK compile wise, runtime wise it's a different matter though.
We need testing across
Hi Glenn,
We have had a bash at resolve this issue. Could you please try out
OSG master or the OpenSceneGraph-3.6-TexStorage branch to see if this
issue still exists.
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi Sid,
The OSG's osgjs plugin exists to convert to .osgjs not to read from
.osgjs. At worst this plugin isn't reporting this lack of support, so
if there is bug it's unhelpful error report.
As a general comment, when reporting issues it's best to specify which
version of the OSG that you are
Hi Julian,
These changes are all in support of the shader_pipeline work, to
enable automatic mapping of fixed function pipeline to shaders. This
functionality isn't tied to just mapping fixed function across, it can
be used for custom shader composition as well. It's bleeding edge
work though,
I am just heading offline for the evening so a quick update. I have
rolled out the use of GLenum Texture::selectSizedInternalFormat(const
osg::Image* image) to the other glTexStorage cases in the OSG and also
when doing this spotted a bug in the allocation/reuse of GL texture
objects - to fix
Hi Julien et. al,
I have so far just focused on the 3.6 branch as this has quite well
constrained use of glTexStorage, so not so many code paths to look at.
To help clean up the sized internal format code up I have created a
GLenum Texture::selectSizedInternalFormat(const osg::Image* image)
const
Hi Julien,
On Fri, 17 Aug 2018 at 03:19, Julien Valentin
wrote:
>
> ..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;
>
Hi Dan,
On Fri, 17 Aug 2018 at 07:04, Daniel Emminizer, Code 5773
wrote:
> Hi Robert, thanks for the update. I'm happy to test my side against whatever
> you decide, once I'm in the office.
I'm happy with what I've checked in, so now it's just a matter of wider testing.
Cheers,
Robert.
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
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
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
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
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
>
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
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
Hi Julien,
On Wed, 15 Aug 2018 at 16:35, Julien Valentin
wrote:
> I'll do the pr you want from me
> (with this ugly patch code:
>
> Code:
>
> ex for Texture2D:
> if( useTexStorrage)
> extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels
> >0)?_numMipmapLevels:1,
>
Hi Julien,
I wanting to know what problems the glTexStorage solves that aren't
addressed by original non glTexImage code. I want know the
justification for the extra complexity and the pain that it has caused
other users with regressions.
The OSG is not a clean room OpenGL scene graph
Hi Julian,
I have been looking through the glTexStorage changes and the
background to this GL feature.
It doesn't look like to me that glTexStorage* has any functionality
benefit over just using the original glTexImage* code. Yes
glTexStorage is the "modern" way to do things in recent GL
HI Cong,
In your code snippet you don't set Camera::setRead.WriteBuffer()
settings. For a double buffer this will need to be GL_BACK.
Robert
On Wed, 15 Aug 2018 at 08:20, Cong Ye wrote:
>
> Hi,
>
> I am recently encountered an interesting problem. I am trying to add shadow
> to a scene
On Wed, 15 Aug 2018 at 01:10, Julien Valentin
wrote:
> @Robert:
> Please, don't rush in rejection, take your time to understand my point.
> (I think I have enough developped it...to be understable)
> and please explain me at last what do you mean by "not setting
> internalFormat". It doesn't
HI Julien,
On Tue, 14 Aug 2018 at 17:24, Julien Valentin
wrote:
> So if noone have a better idea, my proposal is to simply to ban usage unsized
> _internalFormats. I think it would sanitize osg
I have already rejected that idea.
Your changes to use glTextureStorage in master have broken the
Hi Dan,
I've just reached a mini milestone in my VSG Exploration work and
finished up my BOF presentation so I'm now kicking back a bit.
Tomorrow my plan is to dive back into the OSG maintenance side for a
day or two. In theory I have an hour left of work today, but feel
like relaxing more than
Hi All,
Thanks to John Richardson for organizing the BOF in my absence (I'll
here at my base in Scotland right now). I've finished up my
presentation, and hoping that it'll work fine tomorrow.
Time and place:
Wednesday 15th August 2018, 10am-11am
East Building, Room 12, Vancouver
Hi Jilien,
My priority for the OpenSceneGraph is stability and backwards compatibility.
So if you are suggesting that is something the breaks backwards
compatibility/change behaviour then it's a problem.
OpenSceneGraph and OpenGL have evolved together over nearly two
decades, both are now in
301 - 400 of 12708 matches
Mail list logo
