Re: [osg-users] Explicitly requesting default state for attribute
I figured out a solution: * Subclass the attribute in question. Make the subclass' apply do nothing. * Apply the subclassed attribute to the root of the scene graph's stateset - this protects against the State instance encountering the unmodified attribute first, so cloneType-ing that, making the global default attribute not get applied repeatedly, and not have any OpenGL calls if it does. * Apply the subclassed attribute anywhere that doesn't care. * Apply the regular attribute anywhere that *does* care, including places that needed the regular default state. Hopefully, this relatively simple solution shows up for anyone searching for this in the future. Cheers, Chris On Friday, 11 December 2020 at 19:38:26 UTC Chris Djali / AnyOldName3 wrote: > Hi, > > I'm working on a node visitor that converts FFP state to shaders and am > extending it so it can handle more than it used to. To avoid unnecessary > state switches for things now handled by my shaders, I'm attempting to > remove fixed-function-related state from the nodes which have had shaders > set up. > > With modes, this works well - I can just set them off and protected, and > the glEnable/glDisable calls go away. However, it's proving difficult to > achieve the same behaviour with StateAttributes. The obvious solution would > be removing the attribute from the StateSet it's attached to, but it might > be higher in the scenegraph so also affect nodes which aren't having > shaders attached, so it's only really safe to modify the stateset the > shader program gets attached to. > > So far, the best thing I've got is default-constructing the particular > StateAttribute I'm interested in and attaching that to the stateset. This > means the default state is set when the draw call happens, but I can see a > lot of apply calls (resulting in a lot of GL calls) toggling between this > copy of the default attribute and the copy in the state's attribute stack > (via applyGlobalDefaultAttribute). I don't think it's wildly different from > the number of unnecessary GL calls I was getting before I tried this. > > A solution that I think would work would be > calling getGlobalDefaultAttribute on the State object as then the pointers > would compare equal and the apply call would get skipped, but I don't have > any clean way of getting the State instance to my visitor. > > Ideally, there'd be some neat trick I've missed that lets me say "any > subgraph of this node doesn't care about this attribute type, so set the > default/leave whatever's there from the last draw call" that would work > with the normal state composition mechanisms so I could override it from a > parent stateset or make it protected so it couldn't be overridden by parent > statesets. Maybe a custom StateAttribute could do that, but maybe someone > on this mailing list knows something I don't already. > > Cheers, > > Chris > -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/f2289386-d074-4a23-a41b-e858e990a5c8n%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to access material properties from a GLSL shader?
Hi, osg::Material pretty much encapsulates OpenGL's fixed-function material state, so things like glMaterialfv (that controls material settings for whole draw calls) and glColorMaterial (that controls what vertex colours actually affect). If you're using a suitably old GLSL version, you can access this state through the built-in uniforms. These aren't featured prominently in lots of the modern OpenGL documentation like the wiki as they're removed in modern OpenGL, but I have this bookmarked and it at least says what's there: http://mew.cx/glsl_quickref.pdf. Once you know an actual uniform name, relevant stuff should show up in a search engine. The one problem you'll hit is that there's no built-in uniform to say whether glColorMaterial is enabled or what mode it's in, so you'll have to set that up yourself with a uniform or shader define. I *think* that with the right combination of settings, OSG exposes similar uniforms in newer OpenGL/GLSL versions where the fixed function pipeline has been removed, so that's something to look into. I've never needed this, though, so don't know if it just happens when OSG is compiled with GL3 support, or whether there's more that you need to do. Hope this helps, Chris On Wednesday, 8 January 2020 22:53:28 UTC, Armin Samii wrote: > > Does openscenegraph provide easy access to osg::Material values in the > shaders? If so, in which Uniforms are the various properties set? If not, > is the best path forward to set my own Uniforms based on osg::Material? > > For context: I had an OBJ/MTL that loaded and rendered fine by default, > but when I turn on `setUseVertexAttributeAliasing`, the texture coordinates > seem to break. I am trying to replace the default rendering with my own > shader instead, but can't reproduce the original look and feel. While > texture coordinates and texture loading does work with shaders, I cannot > seem to find how to access the colors specified in the MTL files. > > (A google search shows several results for "openscenegraph material > shaders" which looks helpful, but they are all in the forum, which is now > inaccessible. Apologies if this question has been asked and answered > elsewhere.) > -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/5b4d4380-6d02-4726-a13f-2068c47d70d6%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
> > I can't investigate either issue without being able to recreate the > crash/GL errors myself. If either of these issues occur on an existing OSG > example then I can take it from there. Short of being able to recreate the issue and investigate it myself the > only thing I can do is suggest ways of investigating the issue that might > reveal the cause of the issues. Your suggestions are the kinds of thing I'd be looking at if I had more time, but unfortunately, I don't. However, it might actually be reasonable for you to take a look yourself. I'd put money on OpenMW being the most widely-installed OSG application, and it's open-source, so it would be a good candidate for part of your own regression testing. Sorry to just pile on work when I'm unable to help myself. We just don't have anyone who's both got time and familiarity with OSG. Thanks, Chris On Wednesday, 18 December 2019 10:56:39 UTC, Robert Osfield wrote: > > > > On Tuesday, 17 December 2019 21:40:37 UTC, Chris Djali / AnyOldName3 wrote: >> >> Hi Robert, >> >> OpenMW still experiences some regressions when built with OSG 3.6.x >> instead of 3.4.1. It's completely possible they're because we're trying to >> coerce OSG systems to do things they weren't intended to as it's a big >> project created without much interaction with the OSG community. >> >> The two issues we're tracking are: >> >>- https://gitlab.com/OpenMW/openmw/issues/5205 the builds provided by >>Arch Linux crash. The Arch packagers think they're not doing anything >>abnormally, so I don't have a clue where the issue actually lies. >> >> My best guess is there is some threading issue where a slightly different > build resulting slightly different data alignment in a race condition > becoming critical. That's just a guess though, there isn't any evidence in > the thread above that can pin point any specific problem. > > Given the fickle nature of threading problems, just because it occurs in > 3.6.x but not 3.4.x doesn't mean that there has been a bug introduced after > 3.4, it just needs some condition to slightly change that cause some of the > data in the application to be aligned different and over the application > goes. > > The best I can recommend is to run the application with valgrind > --tool=helgrind to see if it picks up any race conditions. > >> >>- >>- https://gitlab.com/OpenMW/openmw/issues/4773 OpenGL errors we >>didn't use to get. This hasn't been very thoroughly investigated at all. >> >> There are potentially other issues, too. I had a collection of stack >> traces of crashes and OpenGL errors that I was working through, and not all >> of them ended up on our tracker. As the issues I'd already brought up on >> the forums were taking a while to flush through due to your focus on VSG, >> tracking down OSG regressions had been put on the back burner, and I don't >> have a huge amount of time right now. That means the best I can do if you >> want things narrowing down is to try and get people to replicate the issues >> with the tip of the 3.6 branch and potentially get stack traces. >> >> > Does this happen with all hardware/OS/driver combinations or just > particular ones? > > From the glTextStorage2D documentation at > https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glTexStorage2D.xhtml > > Errors > > GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to > target. > > GL_INVALID_OPERATION is generated by glTextureStorage2D if texture is not > the name of an existing texture object. > > GL_INVALID_ENUM is generated if internalformat is not a valid sized > internal format. > > GL_INVALID_ENUM is generated if target or the effective target of texture > is not one of the accepted targets described above. > > GL_INVALID_VALUE is generated if width, height or levels are less than 1. > > GL_INVALID_OPERATION is generated if target is GL_TEXTURE_1D_ARRAY or > GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(width)⌋+1 > > GL_INVALID_OPERATION is generated if target is not GL_TEXTURE_1D_ARRAY or > GL_PROXY_TEXTURE_1D_ARRAY and levels is greater than ⌊log2(max(width, > height))⌋+1 > > Given the glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGB8, 320, 320) looks valid > on it's own we are left with: > > GL_INVALID_OPERATION is generated by glTexStorage2D if zero is bound to > target. > > The next step would be to put into some test code that Texture2D.cpp to > track what is happening right before the call. There is a > textureObject->bind() before each call to glTexStorage2D,
Re: [osg-users] Please test OpenScenGraph-3.6 branch in prep for the up commign 3.6.5 maintainance release
Hi Robert, OpenMW still experiences some regressions when built with OSG 3.6.x instead of 3.4.1. It's completely possible they're because we're trying to coerce OSG systems to do things they weren't intended to as it's a big project created without much interaction with the OSG community. The two issues we're tracking are: - https://gitlab.com/OpenMW/openmw/issues/5205 the builds provided by Arch Linux crash. The Arch packagers think they're not doing anything abnormally, so I don't have a clue where the issue actually lies. - https://gitlab.com/OpenMW/openmw/issues/4773 OpenGL errors we didn't use to get. This hasn't been very thoroughly investigated at all. There are potentially other issues, too. I had a collection of stack traces of crashes and OpenGL errors that I was working through, and not all of them ended up on our tracker. As the issues I'd already brought up on the forums were taking a while to flush through due to your focus on VSG, tracking down OSG regressions had been put on the back burner, and I don't have a huge amount of time right now. That means the best I can do if you want things narrowing down is to try and get people to replicate the issues with the tip of the 3.6 branch and potentially get stack traces. Sorry I can't be more specific, Chris On Monday, 16 December 2019 17:16:01 UTC, Robert Osfield wrote: > > Hi All, > > I have merged the outstanding pull requests and made a couple of bug fixes > that are now checked into the OpenSceneGraph-3.6 branch: > > > https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6 > > Could everyone test out this branch to see how well it's working on your > build platforms and against your hardware/OS/application combinations. If > everything looks solid I make a 3.6.5 release candidate with the aim to > make a 3.6.5 in January. > > Thanks in advance with your help in testing. > Robert. > > *-- ChangeLog since the 3.6.4 release on 26th of July 2019:* > > Mon, 16 Dec 2019 16:51:16 + > Author : Robert Osfield > Added automatically removal from the OjbectCache when a object or it's > subgraph contain Texture that no longer have an osg::Image. > > Mon, 16 Dec 2019 11:54:12 + > Author : OpenSceneGraph git repository > Merge pull request #871 from LaurensVoerman/commit_tgaFixfix debug compile > error for ReaderWriterTGA > > Mon, 16 Dec 2019 11:02:41 +0100 > Author : Laurens Voerman > fix debug compile error for ReaderWriterTGA > > Mon, 16 Dec 2019 09:40:30 + > Author : OpenSceneGraph git repository > Merge pull request #870 from > eligovision/OpenSceneGraph-3.6_glext_fixGLExtensions's isPBOSupported and > isVAOSupported flags fixed > > Mon, 16 Dec 2019 09:40:00 + > Author : OpenSceneGraph git repository > Merge pull request #869 from eligovision/OpenSceneGraph-3.6_glextAdded FBO > GL extensions (useful for mobile VR etc.) > > Fri, 13 Dec 2019 19:40:11 +0300 > Author : konstantin.matveyev > GLExtensions's isPBOSupported and isVAOSupported flags fixed for > GLES2+GLES3 configuration > > Fri, 13 Dec 2019 19:42:30 +0300 > Author : konstantin.matveyev > GLExtensions's isInvalidateFramebufferSupported flag improved > > Tue, 26 Nov 2019 17:17:38 +0800 > Author : PntAndCnt > Fontconfig should be external library.Add Fontconfig to TARGET_LIBRARIES > cause osg3::osgText target looking for > openscegraph-Fontconfig-import-targets.cmake, which doesn't exists. > > > Sun, 13 Oct 2019 20:24:36 +0800 > Author : PntAndCnt > Fix a typo and invisible 3dtext in examples/osgtext.Second text alignment > is wrong when "--alignment" specified. > > 3D text radius is too small, only SCREEN_COORDS can be seen. > > Text position should multiply radius. > > > Tue, 3 Sep 2019 16:11:14 +0800 > Author : Kent > Mered fix for internalFormat > > Thu, 12 Dec 2019 18:41:23 +0300 > Author : valid-ptr > glInvalidateFramebuffer added to GLExtensions > > Thu, 31 Oct 2019 18:59:04 +0300 > Author : konstantin.matveyev > glFramebufferTexture2DMultisample added to GLExtensions > > Tue, 10 Dec 2019 15:08:25 +0300 > Author : Dmitry Marakasov > Add FreeBSD-specific code bits for pthread_setaffinity_np support > > Thu, 12 Dec 2019 13:25:44 + > Author : Robert Osfield > Fix linking with Xinerama > > Thu, 12 Dec 2019 13:09:33 + > Author : OpenSceneGraph git repository > Merge pull request #861 from aluaces/default-ffmpegSet ffmpeg as the > default plugin for video files. > > Fri, 22 Nov 2019 21:07:36 +0100 > Author : elsid > Fix clang 8 & libc++ build errorsReplace operators for implicit type > conversion by explicit data() method to > access implementation pointer and subscript operator to access element by > index just like in std::vector. > > src/osgPlugins/tga/ReaderWriterTGA.cpp:455:22: error: use of overloaded > operator '==' is ambiguous (with operand types 'SafeArray' > and 'long') > if (colormap == NULL) > ^ > src/osgPlugins/tga/ReaderWriterTGA.cpp:525:16:
Re: [osg-users] Clipping osgText::Text
Hi, It might not necessarily be fast, as you'd be changing state that would normally stay the same between consecutive draw calls, but you could also change the scissor rectangle to the region you want to keep, or you could draw a rectangle with the same depth as the text, then set the depth test to equal, then draw the text. Other options include adding discards to the fragment shader when the fragment is outside the rectangle (which can sometimes make all draw calls that frame slower, not just the current one, especially on tiled renderers like mobile GPUs and post-Maxwell Nvidia cards, so you'll want to avoid this, too). Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76859#76859 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DEEP_COPY_USERDATA isn't that deep
Hi,
It's been pointed out to me that the DefaultUserDataContainer object list can
be a little bit more deeply copied with this change:
Code:
--- a/src/osg/UserDataContainer.cpp
+++ b/src/osg/UserDataContainer.cpp
@@ -56,7 +56,10 @@ DefaultUserDataContainer::DefaultUserDataContainer(const
DefaultUserDataContaine
itr != udc._objectList.end();
++itr)
{
-_objectList.push_back(copyop(itr->get()));
+if (copyop.getCopyFlags()::CopyOp::DEEP_COPY_USERDATA)
+_objectList.push_back(osg::clone(itr->get(), copyop));
+else
+_objectList.push_back(copyop(itr->get()));
}
}
This will make _objectList at least point to copies of the objects instead of
literally the same objects, which is a step in the right direction, but those
copies will still be shallow copies.
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76837#76837
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image from shader
Hi, The name texUnit0 comes from the shader, which you're providing. The texture unit index (which my example snippet sets to 0) comes from your scene graph, which you said came from osgOcean, and will almost certainly be 0 for a diffuse map. If I was trying to check that, I'd run the application through APITrace and see which units have textures bound to them during the draw calls for the meshes I'm interested in, but that might not be the simplest approach. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76795#76795 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image from shader
Hi,
OSGOcean is probably setting up the necessary fixed-function stuff to put its
texture in texture unit zero, but you'll need to tell the fragment shader that
its texUnit0 uniform refers to that texture unit. It should be enough just to
add a uniform to the same stateset as you're adding your shader that sets
texUnit0 to 0 e.g.
Code:
stateSet->addUniform(new osg::Uniform("texUnit0", 0));
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76791#76791
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image from shader
Hi,
If you're not seeing any errors in the console, I don't think you've added your
shader to the scene properly. You have to assign something to gl_Position
otherwise the rasteriser has no idea where your vertex is, so doesn't know
which pixels any triangles cover, and nothing will get drawn.
Also, I reckon two things that you've got wrong that stop you from getting
image2 are:
image2 looks like it has some basic lighting, hence why the cylinder's
colour varies from left to right. You're not doing any lighting, just
forwarding the vertex colour.
image2 looks like it has a texture, at least on the brown bit. You're
not sampling from a texture anywhere.
I'd start with these shaders generated by 3DLabs GLSL ShaderGen and comment out
things or add things until you get the result you're after:
Vertex:
Code:
/***
* Fixed.vert Fixed Function Equivalent Vertex Shader *
*Automatically Generated by GLSL ShaderGen *
* https://github.com/mojocorp/ShaderGen *
***/
vec4 Ambient;
vec4 Diffuse;
vec4 Specular;
void pointLight(in int i, in vec3 normal, in vec3 eye, in vec3 ecPosition3)
{
float nDotVP; // normal . light direction
float nDotHV; // normal . light half vector
float pf; // power factor
float attenuation; // computed attenuation factor
float d;// distance from surface to light source
vec3 VP; // direction from surface to light position
vec3 halfVector; // direction of maximum highlights
// Compute vector from surface to light position
VP = vec3 (gl_LightSource[i].position) - ecPosition3;
// Compute distance between surface and light position
d = length(VP);
// Normalize the vector from surface to light position
VP = normalize(VP);
// Compute attenuation
attenuation = 1.0 / (gl_LightSource[i].constantAttenuation +
gl_LightSource[i].linearAttenuation * d +
gl_LightSource[i].quadraticAttenuation * d * d);
halfVector = normalize(VP + eye);
nDotVP = max(0.0, dot(normal, VP));
nDotHV = max(0.0, dot(normal, halfVector));
if (nDotVP == 0.0)
{
pf = 0.0;
}
else
{
pf = pow(nDotHV, gl_FrontMaterial.shininess);
}
Ambient += gl_LightSource[i].ambient * attenuation;
Diffuse += gl_LightSource[i].diffuse * nDotVP * attenuation;
Specular += gl_LightSource[i].specular * pf * attenuation;
}
vec3 fnormal(void)
{
//Compute the normal
vec3 normal = gl_NormalMatrix * gl_Normal;
normal = normalize(normal);
return normal;
}
void ftexgen(in vec3 normal, in vec4 ecPosition)
{
gl_TexCoord[0] = gl_MultiTexCoord0;
}
void flight(in vec3 normal, in vec4 ecPosition, float alphaFade)
{
vec4 color;
vec3 ecPosition3;
vec3 eye;
ecPosition3 = (vec3 (ecPosition)) / ecPosition.w;
eye = vec3 (0.0, 0.0, 1.0);
// Clear the light intensity accumulators
Ambient = vec4 (0.0);
Diffuse = vec4 (0.0);
Specular = vec4 (0.0);
pointLight(0, normal, eye, ecPosition3);
color = gl_FrontLightModelProduct.sceneColor +
Ambient * gl_FrontMaterial.ambient +
Diffuse * gl_FrontMaterial.diffuse;
color += Specular * gl_FrontMaterial.specular;
color = clamp( color, 0.0, 1.0 );
gl_FrontColor = color;
gl_FrontColor.a *= alphaFade;
}
void main (void)
{
vec3 transformedNormal;
float alphaFade = 1.0;
// Eye-coordinate position of vertex, needed in various calculations
vec4 ecPosition = gl_ModelViewMatrix * gl_Vertex;
// Do fixed functionality vertex transform
gl_Position = gl_ProjectionMatrix * gl_ModelViewMatrix * gl_Vertex;
transformedNormal = fnormal();
flight(transformedNormal, ecPosition, alphaFade);
ftexgen(transformedNormal, ecPosition);
}
Fragment:
Code:
/***
* Fixed.frag Fixed Function Equivalent Fragment Shader *
*Automatically Generated by GLSL ShaderGen *
* https://github.com/mojocorp/ShaderGen *
***/
uniform sampler2D texUnit0;
void main (void)
{
vec4 color;
color = gl_Color;
color *= texture2D(texUnit0, gl_TexCoord[0].xy);
gl_FragColor = color;
}
Cheers,
Chris[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76787#76787
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image from shader
Hi, I'm pretty sure you're not using your shaders at all. You're not setting gl_Position in the vertex shader, so it's not going to compile, and OSG will fall back to either its basic shader or fixed-function mode depending on how you've set it up. You should be seeing errors printed to the console when you run your application. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76782#76782 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DEEP_COPY_USERDATA isn't that deep
Hi, I'm not seeing a particularly easy way to deep-copy the rest of the stuff in osg::DefaultUserDataContainer, either. The description list is a vector of strings, which are deep-copied, so that's fine, but the object list is harder as I'd need to cast the const off the CopyOp if I were to deep-copy those objects (which is undesirable) or copy the CopyOp to get a non-const version, which I can't do, as there's no way to determine if it's actually a user-provided derived class. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76755#76755 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DEEP_COPY_USERDATA isn't that deep
Hi, Is there a way to copy something if all I have is a ref_ptr to Referenced? I see that Object has a clone method, but Referenced doesn't. This poses a potential problem with deep-copying user data, as osg::DefaultUserDataContainer::_userData is a ref_ptr. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76753#76753 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glClampColor with GL CORE profile
Hi, Yeah, they're pretty obviously deprecated as they control fixed-function stuff, and the whole FFP was deprecated ages ago. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76737#76737 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DEEP_COPY_USERDATA isn't that deep
Hi, Good, but would the new enum entry be for the current behaviour or the new behaviour? If the current behaviour is a bug, then it makes sense to only keep the old behaviour as the new enum value so everyone gets the fix, but conceivably there could be applications that rely on the current behaviour not changing, so would want the same name and value to keep the same behaviour. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76733#76733 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DEEP_COPY_USERDATA isn't that deep
Hi, How do you want backwards compatibility to be handled? The current behaviour could just be dropped, or it could be available under a new flag name like SHALLOW_COPY_USERDATA (potentially with the same value as the current deep copy one), or the new behaviour could be under a new flag name like DEEP_COPY_USERDATA_AND_CONTENTS. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76727#76727 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DEEP_COPY_USERDATA isn't that deep
Hi, Is it intentional that using osg::CopyOp::DEEP_COPY_USERDATA copies the UserDataContainer, but doesn't deep-copy the actual things in it unless osg::CopyOp::DEEP_COPY_OBJECTS is also enabled? This means that things can be added or removed, but changes to existing things are shared. We have a situation where we only want to deep-copy the userdata and not anything else, so can't set the deep-copy objects flag. This could be supported either by ORing objects into the copy op in the userdata container copy constructor, or by adding another copy op for copying userdata even more deeply, otherwise we're going to have to manually implement a less pretty workaround. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76725#76725 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glClampColor with GL CORE profile
Hi, Somehow I missed the several parts about you intentionally using a core profile. I guess the most reasonable thing to do is submit an issue report that https://github.com/openscenegraph/OpenSceneGraph/blob/OpenSceneGraph-3.6/src/osg/ClampColor.cpp#L52-L53 should be fenced off so they don't get called when a core profile is in use. I'm not 100% sure whether there's any way built into OSG to do this at runtime based on the context version, but OSG_GL3_AVAILABLE does exist to do it at compile time as you've noticed. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76716#76716 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glClampColor with GL CORE profile
Hi, Are you definitely creating an OpenGL context with either a version less than or equal to 3.0, or as a compatibility profile? This sounds to me like you've got a core profile, so don't have access to old deprecated stuff, but are trying to use it anyway. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76714#76714 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Shininess and Color Array
Hi, Have you tried playing with osg::Material::setColorMode? It controls glColorMaterial settings, which is used to switch between having the material colour be determined by the global colour or vertex colours. You probably had the Material set to use its own colour, but if you re-add it and set the mode to GL_DIFFUSE or GL_AMBIENT_AND_DIFFUSE, your vertex colours set in the colour array should still work. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76681#76681 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Implement.
Hi, You need to use shadow2D instead of texture2D to sample a sampler2DShadow in older GLSL versions. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76668#76668 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow Implement.
Hi, As someone who's added shadows to an OSG application, I can confidently say you're going to have a bad time if you try and use anything in osgShadow. I was told this before I'd really got started, and I didn't believe it, so continued anyway, and while I did end up with impressive final results, it would have been much simpler and faster if I'd started from scratch. The methods you need to use vary significantly based on the type of scene you're working with. If you just have a few objects that the camera orbits, you'll be able to get away with a much simpler system than if you have a whole world with huge viewing distances and tiny objects in the foreground. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76657#76657 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, It's been a week, so I'm just checking this hasn't been forgotten. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76638#76638 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions on optimizing my scene graph
Hi, > Statusswitches are always costly. How does OSG identify if a texture or a > program is identical when > checking for status changes? Is it by comparing the pointers? If yes, it > is necessary to manage a pool > and use the same pointers everywhere? StateSet::compare takes an optional bool argument that determines whether it compares the contents or just pointers. By default, it's false, so just compares pointers, and the StateSet comparison operators leave it false, and I thinkl they're what actually gets used. That means you should try and use the same StateAttribute instances rather than copies. You might also find that the priority for choosing which state to sort by doesn't necessarily reflect how expensive a particular change would be on modern GPUs. I don't know if there's a way of changing it, though. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76633#76633 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi,
The reason I couldn't add or remove views during the event traversal was that
it was invalidating iterators that iterated over the views. Instead, I'm adding
an update operation to add or remove the viewer.
I now have a fairly minimal example that replicates my use case and bug:
Code:
#include
#include
#include
#include
#include
class AddViewOperation : public osg::Operation
{
public:
AddViewOperation(osg::ref_ptr view)
: osg::Operation("AddView", false)
, _view(view)
{}
void operator() (osg::Object * compositeViewer) override
{
OSG_NOTICE << "AddView operator()" << std::endl;
osgViewer::CompositeViewer * viewer =
dynamic_cast(compositeViewer);
viewer->stopThreading();
viewer->addView(_view);
viewer->startThreading();
}
protected:
osg::ref_ptr _view;
};
class RemoveViewOperation : public osg::Operation
{
public:
RemoveViewOperation(osg::ref_ptr view)
: osg::Operation("RemoveView", false)
, _view(view)
{}
void operator() (osg::Object * compositeViewer) override
{
OSG_NOTICE << "RemoveView operator()" << std::endl;
osgViewer::CompositeViewer * viewer =
dynamic_cast(compositeViewer);
viewer->stopThreading();
viewer->removeView(_view);
viewer->startThreading();
}
protected:
osg::ref_ptr _view;
};
class ViewAdder : public osgGA::GUIEventHandler
{
public:
ViewAdder(osgViewer::CompositeViewer * viewer)
: _viewer(viewer)
, _view(nullptr)
{}
bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa)
{
if (ea.getEventType() == osgGA::GUIEventAdapter::KEYUP && (ea.getKey()
== 'v' || ea.getKey() == 'V'))
{
if (_view)
{
OSG_NOTICE << "Existing view, remove it" << std::endl;
// parts of the scene get removed before the view gets
destroyed.
// normally this is fine as things get handled by destructors.
// however, things that are still cached require the cache to
be released
_view->setSceneData(nullptr);
// We need to remove the view after the event traversal is done
to avoid invalidating iterators
_viewer->addUpdateOperation(new RemoveViewOperation(_view));
_view = nullptr;
}
else
{
OSG_NOTICE << "No existing view, create one" << std::endl;
_view = new osgViewer::View;
_view->setName("View two");
_view->setUpViewOnSingleScreen(1);
osg::ref_ptr text2 = new osgText::Text();
text2->setText("Here's some other text. It appears in the
dynamically-added view. It ensures the default font gets used with a context
that goes away, and that lives in the cache.");
osg::ref_ptr autoTransform2 = new
osg::AutoTransform();
autoTransform2->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
autoTransform2->addChild(text2);
osg::ref_ptr scene2 = autoTransform2;
_view->setSceneData(scene2.get());
_view->setCameraManipulator(new osgGA::TrackballManipulator);
_viewer->addUpdateOperation(new AddViewOperation(_view));
}
return true;
}
return false;
}
protected:
// raw pointer because it's stack-allocated
osgViewer::CompositeViewer * _viewer;
osg::ref_ptr _view;
};
int main(int argc, char **argv)
{
// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(, argv);
osg::ref_ptr text = new osgText::Text();
text->setText("Here's some text. It doesn't have to be text, and in fact we
don't need anything in the main view as it just exists to keep the application
alive.");
osg::ref_ptr autoTransform = new osg::AutoTransform();
autoTransform->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
autoTransform->addChild(text);
osg::ref_ptr scene = autoTransform;
if (!scene)
{
OSG_NOTICE << argv[0] << ": requires filename argument." << std::endl;
return 1;
}
// construct the viewer.
osgViewer::CompositeViewer viewer(arguments);
// single-threaded to prove a threading bug isn't responsible for the
symptoms
viewer.setThreadingModel(osgViewer::CompositeViewer::SingleThreaded);
// view one
{
osg::ref_ptr view = new osgViewer::View;
view->setName("View one");
viewer.addView(view);
view->setUpViewOnSingleScreen(0);
view->setSceneData(scene.get());
view->setCameraManipulator(new osgGA::TrackballManipulator);
view->addEventHandler(new ViewAdder());
}
// run the viewer's main frame loop
return viewer.run();
}
This started life as the Composite
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, I'm trying to build a stripped-down version of the same behaviour as my application, but it's got extra issues because things that are handled by what I'm stripping out aren't being handled when they're gone. What's the correct process for adding and removing views to and from an osgViewer::CompositeViewer while it's running? I was under the impression I just needed osgViewer::CompositeViewer::stopThreading and osgViewer::CompositeViewer::startThreading either side of it being added and removed, but that's not working (access violation) when doing it with an osgGA::GUIEventHandler attached to one of the views. There's pretty much nothing else at all in the demo application, just a text node added to all of the views. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76610#76610 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi,
As we've discussed, that only occasionally helps. In the boring single-viewer,
single-view case, it works, but no one would notice there was a problem there
anyway as nothing would actually render incorrectly.
My application just uses the camera created for it by OSG when an
osgViewer::View is created, and I think it's reasonable to expect OSG to clear
up things it's created itself. I'm under the impression that you do, too.
I've been having a poke around, and it seems to me that one possible option
would be to call releaseGLObjects on a camera being removed from an
osg::GraphicsContext when it's the only one attached. In such a situation, we
already call it on the camera's non-shared child nodes (which is all of them)
and its rendering cache, so this only adds the renderer and callbacks as extra
things being released. It's my belief that this could only cause unwanted
releasing in the case where all the cameras were removed from a context and
then new ones were added. I think such a situation is probably unlikely (but
you'd know better) and not much would be different to how things are now, as
any attached nodes are already being released. There's also an added bonus that
the function can return early as there'd be no need to work out which child
nodes may or may not be shared.
The diff that fixes my use case is
Code:
diff --git a/src/osg/GraphicsContext.cpp b/src/osg/GraphicsContext.cpp
index 1a35497d0..e6113eb9a 100644
--- a/src/osg/GraphicsContext.cpp
+++ b/src/osg/GraphicsContext.cpp
@@ -741,6 +741,12 @@ void GraphicsContext::addCamera(osg::Camera* camera)
void GraphicsContext::removeCamera(osg::Camera* camera)
{
+if (_cameras.size() == 1 && camera == _cameras.front())
+{
+_cameras.clear();
+camera->releaseGLObjects(_state.get());
+return;
+}
Cameras::iterator itr = std::find(_cameras.begin(), _cameras.end(),
camera);
if (itr != _cameras.end())
{
How does this look to you?
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76605#76605
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, Is the plan still to have OSG itself release GL objects in the object cache when the contexts they're associated with are destroyed, and if so, have you had any further thoughts about how this might be accomplished? The problem is still that there's nothing in osgViewer that has the same lifetime as an osg::GraphicsContext, and osg isn't supposed to be aware of osgDB, so it has to be osgViewer that releases things, right? Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76601#76601 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Here it is again: AnyOldName3 wrote: > Hi, > > Hopefully, after that two-week hiatus, we can get this sorted. > > > > You can always subclass from Camera and override the destruct if you want > > to add this "fix" if it suits your usage case. > > > I'm already going to have to include a separate fix for older OSG versions > (and I have a good idea of how I'll implement it), as we're supposed to > support as far back as 3.4.x, so if we're abandoning the idea of actually > fixing the issue in OSG itself, I've already got a workaround figured out. > > I imagine, though, that until everyone who writes applications knows how to > use Vulkan and all devices have Vulkan support, removing the footgun from OSG > is still your preferred option. > > > > The approach I have taken with the VSG is for the GPU objects to hold a > > ref_ptr<> to the VkInstance wrapper preventing it being deleted when the > > objects are still in use. It's thread safe, robust for a lots of different > > usage cases and straight forward. Alas OpenGL can't be managed like this, > > or at least I don't think you can keep a graphics context around after a > > window has been deleted. If I was to writing an OpenGL scene graph from > > scratch I'd probably try to resolve this topic in a more flexible way than > > the OSG which has evolve from narrower usage cases to more and more general > > usage cases as users have pushed and pulled it in various directions. > > > That does sound like a much nicer way of doing things. The only thing similar > I can think of with OpenGL is to have a sharing context with access to the > same objects as the main window, and to only destroy this extra context once > everything has been released, but then I'm still discovering surprising new > OpenGL features that can do new things. > > Cheers, > Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76598#76598 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, Did my last message disappear because of the forum issues? It's been a while and there's no reply yet... Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76596#76596 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed pipeline lighting to shaders
Hi, ShaderGen from 3D Labs is an old tool that can generate equivalent GLSL 1.2 shaders for a fairly large subset of FFP state. I've used it a fair amount to sanity-check things. If you just want a basic shader as a start point to drop into an FFP application, it's pretty good, but there are definitely things it doesn't cover. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76576#76576 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shininess without Material
Hi, Fixed-function materials can track either the material colour or the vertex colour depending on if glColorMaterial is used, so you can probably get the behaviour you want by setting a material on the stateset as before, but changing its mode so that (for example) the diffuse and ambient colours track the vertex colour. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76575#76575 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi,
> So... would change the destructor to:
>
>
> Camera::~Camera()
> {
> setCameraThread(0);
>
> if (_graphicsContext.valid())
>
> {
>releaseGLObjects(_graphicsContext->getState());
>
>
> _graphicsContext->removeCamera(this);
> }
> else
> {
> releaseGLObjects();
>
> }
>
>
> }
This does solve the problem. Is it definitely safe it do this, though? What if
the camera references stuff still shared by another context (e.g. RTT cameras
that get added to and removed from an existing context)? I don't imagine you
want to add a regression while fixing this.
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76507#76507
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, I have more information. The GraphicsContext is only referenced by the camera when the camera is destroyed. The camera detaches itself from the graphics context in its destructor, then the camera's ref_ptr to the graphics context is destroyed, triggering the destruction of the graphics context. The graphics context calls its own close in its destructor, but by then the camera has already detached itself, so it's not helpful. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76497#76497 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, > Are the Camera's being removed from the Window before it gets closed? I have > just checked the GraphicsContext::close() method and it calls all the > Camera::releaseGLObjects(), which in turn will call the > Renderer::releaseGLObjects(), which will now call the > ObjectCache::releaseGLObjects(). After calling all the releaseGLObjects() > the GraphicsContext::close() then calls the > osg::deleteAllGLObjects(_state->getContextID()) of the context isn't shared. There aren't any cameras in the GraphicsContext's list when its closeImplementation is called. The camera is removed from that list by its destructor, and its destructor is called when the ref_ptr is set to zero in the osg::View destructor. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76496#76496 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, Annoyingly, while that branch fixes the issue in my examples, it isn't fixing it in my actual application. The cache gets cleared when the application exits (potentially after all OpenGL contexts have been closed), but not when views are added to and removed from the composite viewer, so I'm still getting the same Warning: detected OpenGL error 'invalid value' at after RenderBin::draw(..) message. I'm not seeing Renderer::releaseGLObjects get called ever, but I can't tell whether it would be called if there was a view active when the application was closed, as I'm also battling a Qt bug that causes a crash in that situation. There might be something weird that needs fixing at my end. I can see with tracepoints that a pair of Renderers gets constructed when the application constructs a View and StatsHandler and they get destroyed when the last ref_ptr to the view is destroyed, so the Renderers aren't sticking around forever. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76493#76493 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] An entity that could build OSG?
Hi, Try using the GUI version of CMake - if you select the compiler you want to use as the generator, it'll try looking for that compiler instead of defaulting to NMake makefiles, which usually use Visual C++. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76484#76484 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android: Survive Context Loss without complete reinitialization
Hi, You can't release objects that belong to a destroyed context, so you definitely need to call all the releaseGLObjects methods before the context is destroyed. You shouldn't need to call it on the root node provided the root node is still attached to the viewer when the viewer and context are destroyed, as the normal viewer does this for you. You need to give the state associated with the context that's being destroyed if you just want to clear GL objects for that context. If you're fine deleting things from every context (e.g. because you've only got one context or destroy them all at once) you can just pass a null pointer, and it'll do it for all contexts. flushAllDeletedGLObjects gets called automatically unless you're using a weird viewer (which is possible given that you're using Android, but I'd guess it isn't happening). If I were in your situation, if you're loading fonts from files, I'd try calling releaseGLObjects on the object cache (osgDB::Registry::instance()->getObjectCache()->releaseGLObjects();) right before the context is closed, and if you're letting OSG use its default font, I'd do the default font instead (osgText::Font::getDefaultFont()->releaseGLObjects();). If either of these helps, then the problem is what I think it is. I've not looked at the Android examples, so I don't know where you'd put the call, though. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76475#76475 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android: Survive Context Loss without complete reinitialization
Hi, This is almost certainly due to one of the issues I've outlined here: http://forum.openscenegraph.org/viewtopic.php?p=76471#76471 The standard viewer definitely doesn't clean everything up that it's supposed to, as demonstrated by the examples I gave in that thread. Specifically, this example shows that the static default font isn't released: http://forum.openscenegraph.org/viewtopic.php?p=76365#76365, and this example shows that loaded fonts living in the object cache aren't released: http://forum.openscenegraph.org/viewtopic.php?p=76345#76345. You'll need to run these examples through an OpenGL debugger like CodeXL that tells you when things aren't released. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76472#76472 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, Now Robert seems to be back from his break, I'm just going to mention the potential footguns I found here in case they need sorting out. I've got a reasonable solution for the issue I was having, so that doesn't really need discussing any more, but it seems sensible to me that OSG might want to avoid letting people get into such a situation in the first place. When a context is destroyed, the object cache can still have things in it that need releasing. It might be a good idea to automatically release things in the object cache when a context is destroyed. Even in the single-view case, it's not best practice to rely on the GPU driver to clean up everything when a context is closed, so this might be helpful for anything that loads stuff from files. If a composite viewer has a cleanup operation, it's only called when the composite viewer is destroyed, and not when associated contexts are destroyed. This should maybe be changed so that it happens when a view is removed, too, or maybe it should be possible to set a cleanup operation on the context objects themselves. The static default font doesn't get released when a context is destroyed. I don't know everything about OSG, so maybe there's a list of static OSG objects that it should be added to, or maybe having static OSG objects is just a bad idea. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76471#76471 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, Now Robert seems to be back from his break, I'm just going to mention the potential footguns I found here in case they need sorting out. I've got a reasonable solution for the issue I was having, so that doesn't really need discussing any more, but it seems sensible to me that OSG might want to avoid letting people get into such a situation in the first place. When a context is destroyed, the object cache can still have things in it that need releasing. It might be a good idea to automatically release things in the object cache when a context is destroyed. Even in the single-view case, it's not best practice to rely on the GPU driver to clean up everything when a context is closed, so this might be helpful for anything that loads stuff from files. If a composite viewer has a cleanup operation, it's only called when the composite viewer is destroyed, and not when associated contexts are destroyed. This should maybe be changed so that it happens when a view is removed, too, or maybe it should be possible to set a cleanup operation on the context objects themselves. The static default font doesn't get released when a context is destroyed. I don't know everything about OSG, so maybe there's a list of static OSG objects that it should be added to, or maybe having static OSG objects is just a bad idea. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76470#76470 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgposter through Task Scheduler
Hi, I don't want to be the guy that says "Go away and Google your problem", but I was curious and searched for OpenGL on headless Windows and saw a few results where people had managed to do it. Even if you don't find something compatible with your situation, you're likely to find more and better answers on a less-specific mailing list. Sorry I couldn't give an actual answer, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76366#76366 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi,
Turns out that it's not a font in the object cache that's causing me grief
after all, but instead the static default font here:
https://github.com/openscenegraph/OpenSceneGraph/blob/OpenSceneGraph-3.6/src/osgText/Font.cpp#L40.
This is initialised from a GLubyte array instead of a file, so never ends up
in the object cache.
I can manually call releaseGLObjects on it when a graphics context is
destroyed, which solves the problem for my application, but I can provide an
example of an OSG application that CodeXL says leaks stuff to prove that
there's still a footgun.
Code:
int main()
{
osgViewer::Viewer viewer;
// Use an auto transform so the text actually faces the screen
osg::ref_ptr scene = new osg::AutoTransform();
scene->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
viewer.setSceneData(scene);
osg::ref_ptr text1 = new osgText::Text();
text1->setText("text1");
scene->addChild(text1);
// Display one or more frames
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
for (int i = 0; i < 100; ++i)
viewer.frame();
// Remove a text node
scene->removeChild(text1);
// Pick which path depending on whether or not we trust all references to
things to go away
if (false)
{
text1->releaseGLObjects();
}
else
{
}
text1 = nullptr;
// osgText::Font::getDefaultFont::s_defaultFont still exists, so the
default font isn't released
return viewer.run();
}
As before, CodeXL is still reporting the following error:
[Image:
https://cdn.discordapp.com/attachments/502999428798480387/596112745104146487/unknown.png
]
Maybe it would be a good idea for static OSG objects to all be held together in
a global vector somewhere so that their GL objects can be released whenever a
context is destroyed. Maybe something like that exists already and the default
font just got forgotten.
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76365#76365
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, Apparently, that approach won't work here - in my actual application, the multiple views are managed with a composite viewer, and that only calls its cleanup operation in its destructor and not when views are removed. I'll still be able to make something work, but it would have been nice to just set a callback that gets called right before a context is destroyed. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76362#76362 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, This surprises me, but apparently clearing the object cache is enough to stop anything from leaking (otherwise, in the case where the second text node was removed, too, without releasing its GL objects, CodeXL was reporting two leaked shaders and three leaked program pipelines). I was expecting some things not to be released by their destructors, but apparently everything is. I'm now in a situation where I think I can solve the issue that's bothering me sufficiently tidily that it won't be a maintanance nightmare, so the OpenMW Construction Set might be about to get its first non-nasty piece of code, which is nice. I've seen that the object cache also has a releaseGLObjects function, which I imagine should have roughly the same effect except with the option to do it for just one context instead of all of them. I'm planning on calling that as part of a viewer cleanup operation. Might it be an idea to make this happen automatically in OSG without applications having to set it up themselves? Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76361#76361 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, When the text node's releaseGLObjects is called, it calls the same method of: The GlyphQuads The Font (which is potentially problematic when it doesn't get skipped). The vertex attributes ( _coords, _normals, _colorCoords, _texcoords) The primitives in _decorationPrimitives The base Drawable. The Text destructor releases none of these, neither does the TextBase destructor, and the Drawable destructor doesn't release everything that its releaseGLObjects does, but that might be inconsequential. The GlyphQuads should be fine as it's just its primitives that get released, and all the primitive sets seem to release their own stuff in their destructors. It should be similar for _decorationPrimitives. The vertex attributes might be fine with the handling in their destructors, too. As I've been saying, the font might be shared with other text nodes, so may or may not be released later depending on what happens with other text nodes. That means that it's possible that within all the nested releasing of GL objects for a text node, only the font actually owns anything that needs releasing, so in the case where only one text node is removed, we get away without calling releaseGLObjects. If that's the case, though, it seems like relying on it for correctness isn't a good strategy - surely all these release calls exist because there's some chance an implementation detail might change at some point and make them necessary. It also isn't a great strategy to apply generally - if we removed all the text nodes, and didn't release the last one, the texture and program(s) the font owns would definitely leak. In the case of an application where for whatever reason it's difficult to keep track of which text node is the last, and so a consistent strategy is required, you're back with the release-or-leak choice. Surely the best solution is an osgText::Text::releaseGLObjects implementation that's always safe to call for text nodes that won't get used again? Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76357#76357 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, I've only tested that example against the 3.6 branch (as of commit 4b6d9287, which was the latest yesterday), and while it doesn't actually crash or show errors, putting tracepoints in shows that the shader program is recompiled and the glyph texture is added to the orphaned list once the text node is removed after a hundred frames. It should break more visibly if you add something to flush the orphaned texture list. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76350#76350 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi,
Hopefully this example illustrates the underlying problem with
osgText::Text::releaseGLObjects without the multiple viewer schenanigans in my
previous example:
Code:
#include
#include
#include
#include
int main()
{
osgViewer::Viewer viewer;
// Single-threaded mode so we don't need to worry about things still being
used by the draw traversal
viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);
// Use an auto transform so the text actually faces the screen
osg::ref_ptr scene = new osg::AutoTransform();
scene->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
viewer.setSceneData(scene);
// Add two text nodes sharing the same font
osg::ref_ptr font = osgText::readRefFontFile("trebuc.ttf");
osg::ref_ptr text1 = new osgText::Text();
text1->setFont(font);
text1->setText("text1");
scene->addChild(text1);
osg::ref_ptr text2 = new osgText::Text();
text2->setFont(font);
text2->setText("text2");
scene->addChild(text2);
// Display one or more frames
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
for (int i = 0; i < 100; ++i)
viewer.frame();
// Remove a text node
scene->removeChild(text1);
// Pick which path depending on whether we prefer leaks or rebuilding
things we're still using and potential errors
if (true)
{
text1->releaseGLObjects();
// text2 must now compile its program again -
osg::Program::compileGLObjects is called the next frame.
// Also, the glyph texture (which text2 still needs) is added to the
pending orphaned texture list.
// I'm not sure how OSG would normally delete orphaned textures, so I
can't trigger that, but I imagine OSG doesn't keep them all around forever.
}
else
{
// text2 can still use its program and the glyph texture, but text1's
objects leak.
}
text1 = nullptr;
return viewer.run();
}
All that happens here is we create a viewer, add two text nodes with the same
font, and 100 frames later, remove one of them again. The text node that
remains has to recompile its shader program (a very minor but unnecessary
performance hit) and its glyph texture ends up in the orphaned texture list
(which I'm pretty sure means it could be deleted at any time).
If I knew how OSG typically cleans up orphaned textures, I could add extra
steps to this and make it actually produce OpenGL errors when the texture is
deleted, but as-is it just hangs around in the orphaned list indefinitely.
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76345#76345
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, I still think you're completely missing my point because of a criticism of my example code. For now, ignore the symptoms that brought me here. Just consider your bog-standard single-viewer situation. If a text node is added to the scene graph and stays attached for the whole lifetime of the viewer, everything is fine. If two text nodes are added to the scene graph and stay attached for the whole lifetime of the viewer, everything is fine. If a text node is added to the scene graph and is removed before the viewer is destroyed, you can either not release GL objects, and have a bunch of things leak, or release them, and have everything be fine. If you have two text nodes in the scene graph, and one is removed before the viewer is destroyed, you can either not release GL objects, and have some things leak (and some get cleaned up), or release them, and break the still-attached node. Are you seriously telling me that OpenSceneGraph provides no mechanism to safely remove nodes that at one point were attached to the scene graph and this is intentional? If so, it's misleading to even have functions like osg::Group::removeChild as they're providing unsupported behaviour. I'd be very surprised if this is actually what you're saying. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76343#76343 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, I've been putting off responding to the last post as I wanted to be sure I wasn't misunderstanding you, but after several rereadings, I still think you've missed my point. I'll try explaining the issue again, but I'm not sure which part isn't clear, so I don't know how much it'll help. In the application I'm working with, many viewers (and their OpenGL contexts) can come and go over the lifetime of the program, but the scenegraph doesn't get replaced, so can be used with multiple viewers, potentially at the same time. OSG has mechanisms that make this work, such as how osg::Program has PerContextProgram. Most of the time, this works just fine - provided you release a node's GL objects when you remove it from the scene, and let a viewer release the GL objects it has in the scene when you destroy it, everything is managed correctly. However, osgText::Text doesn't work well with this approach. It uses one osg::Program for all instances in the scene that have the same font, so it's not safe to release a text node's GL objects when you remove it, as they may still be being used by another text node. Unless you've got a hacky workaround in place (a few of which I've outlined above), the shared program will leak when the viewer is destroyed (which is bad) and then, if another viewer is assigned the same context ID (which it will be), it's mistaken for the old one, and the invalid PerContextProgram (which refers to the leaked GL program) gets used, causing OpenGL errors. This might have wider-reaching consequences than just the issue I'm having in the lots-of-viewers case - if two text nodes with the same font are used and one gets deleted, regardless of whether more contexts are created later: calling osgText::Text::releaseGLObjects calls osgText::TextBase::releaseGLObjects, which calls osgText::Font::releaseGLObjects, releasing GL objects still in use by the other text node. Not calling osgText::Text::releaseGLObjects means that the other GL objects the node owns, such as its vertex buffers, get leaked, even though the shared font might get cleaned up later with the other text node. Maybe the right thing to do is to only release the font's GL objects when all its users request it, rather than just one. I've not thought of a nice way of implementing this yet. I'll address specific parts of the previous post now: > there is no mechanism for deleting > this global prior to the viewer cleans up so in essence it's prevent > that scene graph from being deleted and cleaned up. After the exit of > the main frame loop you could explicitly delete this object. There's not supposed to be any mechanism for deleting it prior to the viewer cleaning up as it's going to be used by another viewer later. Pretend it's not just a few ShapeDrawables with labels, but instead something really complicated that takes a long time to regenerate. > Another > approach would be to make this World object a custom Group node in the > scene graph that adds the high level behaviors you want and with it > ensure that you can override any releaseGLObjects() etc on any locally > cached objects that would otherwise be hidden from the OSG's attempts > at cleaning things up. The high-level behaviour is all fine as-is. The specific problem is that it's not safe to call osgText::Text::releaseGLObjects when removing a text object as that releases GL objects for the font, too, and that can still be in use by other text nodes. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76341#76341 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text dissapears when reparent container window on qt
When the widget is popped out, it causes the creation of a new OpenGL context. I see that you've told Qt to share things between the old and new context, which means you'll still be able to use some things in the new one, but I'd look into what can and can't be shared as it isn't everything. I'd guess that something that the text node is using can't be shared. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76321#76321 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Layered rendering with a geometry shader
Hi, Most of my testing was with a ShapeDrawable with a sphere, and that uses quad strips. However, I've also tried it with some of OSG's test models, such as spaceship.osgt, and that specific example only uses triangles and is broken, too. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76135#76135 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Layered rendering with a geometry shader
Hi, I've been playing around with this, and have an annoying issue. On my machine, which runs Windows and has a Radeon Vega 56, using three viewports with geometry shader instancing makes some triangles go missing in the second and third viewports. This happens in my own application and in a slightly modified version of the example. It works fine if I do everything in a single invocation, or run it on another machine, though, so I'm guessing it's a driver bug. I'd report it, but I've not found a place where AMD accepts issue reports in the form of a minimal executable reproducing the issue rather than a description of the bug and the name of the software it happens with. Does anyone have a link or contact at AMD so I can report this properly? Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76119#76119 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, It looks like this has fallen off the radar again as it's been a month. I'd still rather fix this in a robust way rather than making a guess as to the most sensible approach and creating maintenance problems down the line. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76109#76109 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Layered rendering with a geometry shader
Thanks Voerman. I'd looked through the examples for other things, but not for multiple viewports, so missed that. It seems to be a good starting point once I switched the GLSL extension from the NV variant to the ARB one. Despite not being core until OpenGL 4.1, it looks like multiple viewports are available on nearly all hardware supporting geometry shaders, so I don't think I'm even going to have to worry about not supporting as much hardware as I wanted to. Regarding more conventional batching, we have to deal with stupid assets, such as crates implemented as six individual faces each with their own texture. We don't have the rights to fix and redistribute these assets, so any possible solution is going to need stuff like texture atlassing on load. We've got a high-level outline for something that should work, but there are a lot of moving parts to meddle with, so it's beign put off for now. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76108#76108 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Layered rendering with a geometry shader
Hi, I'm investigating using a geometry shader to render multiple shadow map cascades in one pass in OpenMW. While I've heard conflicting (but mostly negative) accounts of how much additional performance this can bring, I reckon it's likely to help, as OpenMW uses a ridiculous quantity of tiny drawables, causing a ridiculous number of draw calls when RTT passes are used, and there's no easy batching implementation as user/game scripts can add, remove, replace and relocate object with no notice. There are solutions in the works for this, but layered rendering may be low-hanging fruit that can be done in the meantime. Anyway, onto the problem at hand... In order to do this, I need to bind a layered depth texture as a render target. When I looked into doing this in OSG, the two threads I found claimed it wasn't possible yet, but as they were from a long time ago, it's possible support has been implemented since them. Can this be done yet? I'd rather not have to spend a long time investigating only to determine that it's still impossible. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76104#76104 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert .earth file to .osg format
Hi, I think they're talking about the C preprocessor definition, FLT_MAX rather than anything specific to anything used here: https://www.tutorialspoint.com/c_standard_library/float_h.htm It's the maximum value of an IEEE 32-bit float. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75948#75948 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Different views hide/show different nodes shared scene graph
Hi, You should be able to dynamic_cast or asCullVisitor the arguments to a regular node callback to get a cull visitor pointer, and then from that, you can access the camera. You don't need to have a version with a boolean return value, either. Just don't traverse the node's children from the cull callback when you want the node to be skipped. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75872#75872 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi,
The following basically simulates the use case that's causing problems.
Code:
#include
#include
#include
#include
#include
#include
#include
/** A representation of something that gets edited.
* Pretend it's actually more complicated than this so that reference counting
the number of attached text nodes is a nuisance. */
class World
{
public:
World() : mScene(new osg::Group)
{
// add things so the viewer doesn't automatically zoom too far in to
see the 'objects'
auto worldCorners = { osg::Vec3(-11, -11, -11), osg::Vec3(-11, -11, 11),
osg::Vec3(-11, 11, -11), osg::Vec3(-11, 11, 11),
osg::Vec3(11, -11, -11), osg::Vec3(11, -11, 11),
osg::Vec3(11, 11, -11), osg::Vec3(11, 11, 11) };
for (auto corner : worldCorners)
{
osg::ref_ptr pat = new
osg::PositionAttitudeTransform();
pat->setPosition(corner);
pat->addChild(new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0,
0, 0), 0.1)));
mScene->addChild(pat);
}
}
osg::ref_ptr getScene() { return mScene; }
/** Adds an object with a label to the scene based on something the user
has done. */
void addObject(std::string name)
{
osg::ref_ptr object = new
osg::PositionAttitudeTransform();
object->setName(name);
static std::random_device r;
static std::default_random_engine randEngine(r());
static std::uniform_real_distribution<> dist(-10, 10);
object->setPosition(osg::Vec3(dist(randEngine), dist(randEngine),
dist(randEngine)));
osg::ref_ptr objectLabel = new osgText::Text();
osg::ref_ptr autoTransform = new
osg::AutoTransform();
autoTransform->addChild(objectLabel);
autoTransform->setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
object->addChild(autoTransform);
autoTransform->getOrCreateStateSet()->setMode(GL_DEPTH_TEST,
osg::StateAttribute::OFF);
objectLabel->setText(name);
objectLabel->setCharacterSize(1);
osg::ref_ptr shape = new osg::Sphere(osg::Vec3(0, 0, 0), 1);
object->addChild(new osg::ShapeDrawable(shape));
mScene->addChild(object);
}
/** Removes an object from the scene based on something the user has done.
*/
void removeObject(std::string name)
{
osg::ref_ptr child;
for (unsigned int i = 0; i < mScene->getNumChildren(); ++i)
{
if (mScene->getChild(i)->getName() == name)
{
child = mScene->getChild(i);
mScene->removeChild(i);
break;
}
}
// If we call child->releaseGLObjects() here, the text program will be
released, too, even though it could still be being used by other labels.
// If we don't, we may be detaching the last text node from the scene
graph, and so the text program may never get released.
}
private:
osg::ref_ptr mScene;
};
World world;
bool useNewViewer = true;
class EventHandler : public osgGA::GUIEventHandler
{
public:
bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa)
{
if (ea.getEventType() != osgGA::GUIEventAdapter::KEYDOWN)
return false;
// The user may wish to close the 3D view to work on something else and
then reopen it later.
// That would be a pain to implement directly, so instead, we simulate
it by reopening the 3D view when it's closed if Return was pressed while it was
open.
if (ea.getKey() == osgGA::GUIEventAdapter::KEY_Return)
{
useNewViewer = true;
return true;
}
// Press a letter key without shift to add an object.
else if (ea.getKey() >= 'a' && ea.getKey() <= 'z')
{
std::string name(1, ea.getKey());
world.addObject(name);
return true;
}
// Press a letter key with shift to remove an object.
else if (ea.getKey() >= 'A' && ea.getKey() <= 'Z')
{
std::string name(1, ea.getKey() - ('Z' - 'z'));
world.removeObject(name);
return true;
}
return false;
}
};
int main()
{
osg::ref_ptr currentViewer;
int returnCode = 0;
while (useNewViewer)
{
currentViewer = new osgViewer::Viewer;
currentViewer->setSceneData(world.getScene());
currentViewer->addEventHandler(new EventHandler);
useNewViewer = false;
returnCode = currentViewer->run();
}
return returnCode;
}
Imagine this is part of a world editor for a game or CAD software or one of any
number of types of software packages where you edit something and might want a
3D view of it, but wouldn't necessarily always want that 3D view taking up
space in the window, so you'd possibly close it and then reopen it
Re: [osg-users] EditorConfig file?
Hi all, kornerr wrote: > Hi, Chris. > > I would guess it might be not exactly appropriate to update > OpenSceneGraph sources just to have the order in spaces and tabs. > However, I think VulkanSceneGraph would definitely benefit > EditorConfig rules. So once VSG has its place at GitHub, I would > recommend re-raising this issue and creating a pull request. > > Regards, > Michael. > > On Fri, 12 Apr 2019 at 21:27, Chris Djali <> wrote: > > > > > Hi, > > > > Here's a list by file extension of which indentation styles are used. > > Annoyingly, a lot of the file extensions that always have tabs somewhere > > often have spaces, too, so it's not quite as simple as declaring all .java > > files use tabs (although I'm assuming they all used tabs when they were > > added and then were edited later to have tabs in places). > > > > I'm going to use my best judgement based on how things look and what > > directory they're in etc. but I'm just posting this to illustrate that it's > > become a mess and that's why I've not just jumped in with a pull request. > > Hopefully, when it's done for OSG, it'll be convincing enough that > > VulkanSceneGraph has a .editorconfig file from early on in the project, and > > whitespace problems will never come up. > > > > > > > > > .1: unindented > > > .README: unindented > > > .bat: unindented > > > .c: mixed, spacey, tabby > > > .cfg: spacey > > > .cmake: mixed, spacey, unindented > > > .cpp: mixed, spacey, tabby, unindented > > > .css: tabby > > > .h: mixed, spacey, tabby, unindented > > > .hpp: spacey, unindented > > > .html: mixed, tabby, unindented > > > .in: spacey, unindented > > > .inst: tabby > > > .java: mixed, tabby > > > .js: spacey > > > .l: mixed > > > .m: mixed, spacey > > > .md: spacey, unindented > > > .mk: tabby > > > .mm: mixed, spacey > > > .nib: spacey, tabby > > > .osgt: spacey > > > .plist: spacey > > > .properties: unindented > > > .rc2: unindented > > > .rc: spacey, unindented > > > .strings: unindented > > > .txt: mixed, spacey, unindented > > > .xml: mixed, spacey, tabby > > > .y: spacey > > > .yml: spacey > > > : mixed, spacey, tabby, unindented > > > > > > > > > > > > Cheers, > > Chris > > > > -- > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=75831#75831 > > > > > > > > > > > > ___ > > osg-users mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum An .editorconfig file wouldn't actually edit anything immeditately, but in supported editors, any new changes would have the correct indentation applied (and if someone applied their editor's autoformat tool, that would also apply the correct indentation, just like how if they did that now, it would apply whatever their editor preferences were set to). robertosfield wrote: > Hi Chris, Michael et. al, > > On Sun, 14 Apr 2019 at 15:50, michael kapelko <> wrote: > > > I would guess it might be not exactly appropriate to update > > OpenSceneGraph sources just to have the order in spaces and tabs. > > However, I think VulkanSceneGraph would definitely benefit > > EditorConfig rules. So once VSG has its place at GitHub, I would > > recommend re-raising this issue and creating a pull request. > > > > For the VSG I've adopted clang-format to enforce standard formatting, > I run this periodically to make sure we don't deviate for too long. > > The .clang-format file is: > https://github.com/vsg-dev/VulkanSceneGraphPrototype/blob/master/.clang-format > > I am not familiar with EditorConfig, for the VSG it won't be critical > for enforcing format. I'm open to suggestons but don't want to liter > the code base with things that aren't critical to the use of the code > base. > > Robert. > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum It seems that clang-format has a lot of s
Re: [osg-users] EditorConfig file?
Hi, Here's a list by file extension of which indentation styles are used. Annoyingly, a lot of the file extensions that always have tabs somewhere often have spaces, too, so it's not quite as simple as declaring all .java files use tabs (although I'm assuming they all used tabs when they were added and then were edited later to have tabs in places). I'm going to use my best judgement based on how things look and what directory they're in etc. but I'm just posting this to illustrate that it's become a mess and that's why I've not just jumped in with a pull request. Hopefully, when it's done for OSG, it'll be convincing enough that VulkanSceneGraph has a .editorconfig file from early on in the project, and whitespace problems will never come up. > .1: unindented > .README: unindented > .bat: unindented > .c: mixed, spacey, tabby > .cfg: spacey > .cmake: mixed, spacey, unindented > .cpp: mixed, spacey, tabby, unindented > .css: tabby > .h: mixed, spacey, tabby, unindented > .hpp: spacey, unindented > .html: mixed, tabby, unindented > .in: spacey, unindented > .inst: tabby > .java: mixed, tabby > .js: spacey > .l: mixed > .m: mixed, spacey > .md: spacey, unindented > .mk: tabby > .mm: mixed, spacey > .nib: spacey, tabby > .osgt: spacey > .plist: spacey > .properties: unindented > .rc2: unindented > .rc: spacey, unindented > .strings: unindented > .txt: mixed, spacey, unindented > .xml: mixed, spacey, tabby > .y: spacey > .yml: spacey > : mixed, spacey, tabby, unindented > Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75831#75831 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, It's been a couple of weeks since the last reply to this. I'm guessing this has fallen off the radar, but I still need to fix the issue, so would appreciate if another look could be taken at this. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75828#75828 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] EditorConfig file?
kornerr wrote: > Hi, Chris, > > just create EditorConfig and share it. Those who are interested will > follow you.Don't wait for us to want your thing. Just do the thing, > show it and explain its benefits. > You're not alone, we're here, but you lead EditorConfig initiative, not us. > > Regards > > That's the approach I've taken with other projects, but they've tended to follow their own whitespace rules. As an EditorConfig file is a formalisation of whitespace rules, it makes sense to know I'm enforcing the rules the project wants rather than some random ones which I guessed. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75769#75769 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] EditorConfig file?
Hi, It's been a couple of weeks, and I've not had any response about any official policy on indentation in the case of existing files that already break the global rule. Should I just go for the stance of "it's supposed to be spaces for everything except for files that are already entirely tabs"? Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75761#75761 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
All out of the 3.6 branch, 3.4.1 and OpenMW's 3.4.1 fork (which doesn't make any changes to osgText, and we're trying to abandon, but it's much faster than the official 3.4.1 release). If everything's working as we think it does, OpenMW should work with any OSG release after 3.4. The issue of the text program not being released when the context is torn down happens with all the versions listed above. Also, an answer to the question in the general case would probably be helpful for all of the versions. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75753#75753 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
The problem is specifically because it's static. Unless I'm manually keeping track of when the last text object is removed from the scene, I can't release the program without it potentially still being in use. If I never release it, references to it can persist beyond the lifetime of the context it was created for. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75747#75747 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Removing objects with shared GL state from scene graph
Hi, I know that when an OpenGL context is destroyed, the associated viewer can only call releaseGLObjects(osg::State *) for nodes still attached to the scene graph, so if you're removing things before that, you're manually supposed to call releaseGLObjects on the subgraph. However, as I see it, there's a potential problem here. If the subgraph contains nodes that share GL objects with things still attached to the main scenegraph, you'll end up releasing those, too. This can mostly be worked around by not sharing GL objects between nodes with different lifetimes, but sometimes that's not possible. For example, osgText::Text seems to have a global osg::Program used for all instances (or, at least, all instances with the same settings). If I always call releaseGLObjects when removing subgraphs containing an osgText::Text, it's going to kill the per-context programs and they'll need rebuilding for any other text nodes, which isn't desirable. If I never call releaseGLObjects, then that's even worse (for obvious reasons). It seems like the only good ways of handling this would be to either keep track of when the last text node was removed so the objects could be released when their last user was removed, or move 'removed' objects to another part of the scene graph (e.g. as a disabled osg::Switch child) so they're actually kept around without being drawn, but still get their GL objects released when the context is destroyed. There's also the hacky option of attaching another text node somewhere else in the scenegraph so it always gets released, which works in the specific ca se of osgText::Text, but won't work in the general case, and doesn't seem desirable. Is there a better way of handling this than I've suggested here? If there's something intended for this built into OSG that I just don't know about, that would be great, but I'm not going to shy away from writing something custom if that's what's necessary. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75726#75726 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt doesn't set a context ID
The problem was definitely user error - parts of the scene graph were being removed before OSG had had a chance to clean up. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75723#75723 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt doesn't set a context ID
I've been informed that I was wrong about this. While I am seeing issues with my application, the context ID is actually being set, just it's being set to the same value as the previous context as OSG reuses IDs for dead contexts. What I know about the issue so far is that the per-context program isn't being deleted properly. It looks like the OSG object is never actually cleared when releaseGLObjects is called, but it's hard to pin down exactly what's going on when debugging an optimised build, so I'm trying to replicate the issue on an unoptimised one instead, but have stumbled across other problems while doing so. I'll be back once I know more, as I don't know enough to determine if this is an OSG problem or user error right now. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75721#75721 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] EditorConfig file?
I just grepped the repo for tabs just in case, and found that that's not entirely accurate. There are a few files where tabs have snuck into otherwise space-indented files (which is fine - adding an editorconfig file won't meddle with existing stuff until someone edits that line), but it looks like there are a few cases where asking more questions would be a good idea: osgAndroidExampleGLES1 and GLES2 use tabs exclusively for their java, xml and mk files, and I don't know whether that's something we want to override, whether we want specific settings for those projects, or whether we want to prefer tabs globally for java, xml and mk files. There are some files in places like osghangglide, osgviewerFOX and many of the plugins that use either nothing but tabs, or mainly tabs, and it might be more pragmatic to have exceptions made for those files. There's probably some threshold where it makes sense to make a distinction between accidental tabs and intentional tabs, and it might be the whole file uses tabs or it might not, but if so, knowing where it is would be good. There are a lot of tabs in src/osg/glu/libtess/ and I'm assuming that's because it originally came from somewhere else (which I also suspect is the source of the tabs in several of the plugins). If so, excluding it from OSG's indentation rules might be prudent. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75713#75713 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] EditorConfig file?
I'm fine making the pull request. I'd just like confirmation of exactly what the whitespace conventions are - I wouldn't want to set it to use four spaces for indentation for everything and then find out later that the CMake files use tabs or anything like that. The main rules are listed here: https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#current-universal-properties Beyond knowing if the preferred indentation size and style is the same for all file types (and if not, which differ), I'd like to know if there's any policy for stuff like whether trailing whitespace at the ends of lines should be removed, whether having a blank line at the end of files should be enforced, and whether there's a preferred character encoding (or whether we're going to assume everyone's going to stick to the characters in common between UTF-8 and ASCII). Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75709#75709 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] EditorConfig file?
Hi, I just noticed (when looking at a local modification and realising my IDE had added tabs to a file using spaces) that the OSG repo doesn't contain an EditorConfig file. This is basically a file that instructs IDEs and editors of a project's whitespace style, overriding the user's settings when they don't match, reducing the chances that someone accidentally messes things up. I reckon it would be a pretty good idea for OSG to include one. A few other projects I've worked on have done so, and it's been a great help not having to change my indentation settings when changing from project to project. To be clear, I'm not suggesting something only supported by a couple of editors - it's pretty widely adopted, with many tools coming with native support, and yet more with a plugin available. The list is available here: https://editorconfig.org/ Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75707#75707 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgQt doesn't set a context ID
Hi, For context, this discussion is about the OpenMW CS tool, the source of which is available here: https://gitlab.com/OpenMW/openmw/tree/master/apps/opencs. I've kind of inherited maintenance responsibilities for the graphical parts of this without necessarily knowing much of how it works. It might well do dumb things, but in cases where it's significantly more work to remove the dumb things than work around them, a workaround is preferable. Anyhow... The OpenMW CS uses osgQt to render an OSG scene onto a QWidget. The widget can be closed and reopened without closing the whole application, and when this happens, the widget and its OpenGL context both are destroyed. When something else needs rendering, a new widget and new OpenGL context are created, but the same OSG scene graph is reused. For the most part, everything's fine with this. However, as I've mentioned in this GitHub issue (https://github.com/openscenegraph/osgQt/issues/24) osgQt isn't ever setting up a context ID, so things like per-context programs think it's the same OpenGL context and this causes OpenGL errors as they try to use objects that don't exist in the new context. To quote the important part of what I said in the issue report: > When an OpenGL context is created with regular OSG, the window implementation > calls osg::GraphicsContext::createNewContextID() to generate a unique ID for > that context and passes it to osg::State::setContextID(), allowing things > like per-context programs and vertex buffers to work. When a new context is > created with osgQt, however, the state's context ID is never set, so if an > application uses multiple contexts with the same OSG objects, things break. I can avoid the symptoms by setting the context ID from within my application, but this seems to me like something osgQt should be handling itself. I could take a stab at working out where exactly a new context is created in osgQt and in which cases it actually shares objects with an existing one to try and resolve this myself, but hopefully, someone with better knowledge of the codebase is around and can do a better job. The issue report I made doesn't seem to have garnered any attention, so I'm hoping that a forum post gets more visibility. Many thanks, Chris[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75702#75702 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shadow Shenanigans (Implementing shadows in OpenMW and associated experiments)
Hi, I'm currently in the process of trying to make shadows work in OpenMW and am therefore trying to learn about osgShadow and also convince it to do a bunch of things. I have several questions, so I'll try and organise them nicely with bullet points and subheadings etc. In case it affects any of this, I'll also include some system details here: OS: Windows 10, post-'Creators Update' GPU: Radeon RX Vega 56 GPU Driver: 17.9.1 All testing described here occurs with Scrawl's OSG-On-Steroids fork (github com/OpenMW/osg dot replaced by a space so I can actually post this), which is preferred for OpenMW, and if it turns out that any of my issues are magically fixed in 3.5.x, it means the fix will have to be backported, as there are good reasons why OpenMW uses the fork. Examples osgshadow As described in another user's thread (forum openscenegraph org/viewtopic.php?t=16521 dots replaced by spaces so I can actually post this), there are issues with the shadow example. I am no longer wholly convinced that I need any scenes other than number four to actually work, so this isn't the end of the world for me. Even when using scene four, there are several shadow techniques which appear to do nothing or do something very wrong. I guess I can provide further information if critical, but I've found that LispSM mostly works, so I'm using that. LispSM specifically There's something wrong with how backfaces are culled when rendering the shadow map for LispSM. The island scene uses a lot of non-manifold meshes, so the backfaces absolutely have to be considered for the shadow map to be correct. There was also some other weirdness I noticed with this (I can't remember the specifics right now), but I think having manifold meshes or disabling backface culling would fix that, too. I went hunting through the source code and figured out how to disable the culling in StandardShadowMap, and that fixes scene four. The cast and receive shadow node masks are completely ignored. I'm not sure if this is a technical problem or just an oversight, but it has the potential to make bad things happen. I've started using LispSM with OpenMW now, as everything else either provides unusably poor results, breaks stuff, or does nothing. OpenMW & LispSM Some shadows seem to end up rendered on the skybox. I'm pretty sure the skybox is rendered really close to the camera in an early render bin, and then the depth buffer is cleared before the rest of the scene gets rendered. If I can't make nodemasks work with LispSM, the scene graph could need some serious rearranging. Some shadows seem to disappear when they fall on something close to the camera. This is probably just a constant that needs changing. I can replicate this in the shadow example, but for that, I have to zoom in ridiculously far. Some shadows have holes or bits missing. I think this is the same backface culling issue as in the island scene as Bethesda's meshes are often crappy. The shadow on a specific door looks like it might be the wrong colour at a very specific time of day. That's probably just Bethesda's fault for setting up a material weirdly, and I can probably tweak this more easily when using OpenMW in shader mode. Many thanks for any answers, AnyOldName3 -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72019#72019 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::Viewer fullscreen dual monitor issue
I'm having a similar issue but under slightly different circumstances. Unlike the original author of this thread, my leftmost monitor shows as having the lower index. Is there anything I can do about this? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71678#71678 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
