Re: [osg-users] Several clipping planes
Thanks Robert, apologies for the long delay, It's taking me a lot of studying to understand shaders uniforms and attributes, so I'm responding to your question as I go on reading and testing. > Is the clipping always going to base on a horizontal plane? Unfortunately no. While this will be the case in 90% of the models, I need to have a more flexible API, so I'm thinking to have uniforms to store reference planes (which will rarely or never change) and some method (uniform or attribute) to pass the clipping distance for the relevant primitives. Are there benefits in moving the objects that need clipping under a different group? They will always be a minority of the model geometry. Thanks, Claudio On Thursday, 4 February 2021 at 13:40:27 UTC+1 robert@gmail.com wrote: > Hi Claudio, > > Welcome to the OSG community. For your first post you sure are diving into > an advanced topic :-) > > Conventionally one would do clipping using gl_ClipPlane, this is set by > osg::ClipPlane state attribute and osg::ClipNode to place one or more > ClipPlane in a final position in space, I think OpenGL implementations > provide at least 6 clip planes, but It's while since I've head my head deep > in OpenGL as I'm mostly working with Vulkan these days. There is a hard > limit though that is driver/hardware dependent. This type of clipping gets > applied during the traseration step just prior to the fragment shader. It > can be used with fixed function and shader pipelines. > > From your description it sounds like something custom will be best, which > in essence would be to use a fragment shader test to discard/fade out > fragments based on some combination of uniform or vertex attribute settings. > > Is the clipping always going to base on a horizontal plane? If so then > you just need to encode the height to clip at for each object via a uniform > or more efficiently with a vertex attribute bound with BIND_OVERALL. > Uniforms have a higher overhead than vertex attributes in OSG/OpenGL so > general best used for rarely changing values, with values that change with > high frequency i.e. different for each object using vertex attributes will > be more efficient. > > Cheers, > Robert. > -- 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/18d25f40-3a7f-4c24-9115-b140d5fe490dn%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Several clipping planes
Hello all, My first post on the new forum, thanks for accepting my request, and for the amazing work on OSG over the years. I intend to use OSG to display the construction sequence of a building site. Some elements will just appear at a given frame (that's easy), but others I'd like to appear progressively. I don't mean that they will "move" to their destination, but rather, that they will be partially visible in their final position as if being partially clipped, until they are entirely visible: [image: Clipping.svg.png] Since timing will be different for each object, a few clipping planes would not be enough. >From what I read, it should be possible to use the fragment shader to cut elements fairly arbitrarily. I've got a couple of questions: 1) Is it possible to use fragment shaders to cut objects at a custom distance from a shared reference plane (the distance should be independent for each object, see hA and hB in the image above)? 2) What path would you suggest me to attempt? Is gl_ClipDistance the right way to go? Am I completely wrong thinking of something like: gl_ClipDistance[0] = dot(u_plane0,vsPos) + *CustomObjectH*; 3) Is the StateSet of an object the right way to pass (and update) a custom variable for the fragment shader (i.e. the distance from the reference plane)? Many thanks, Claudio -- 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/9173059e-957c-471c-a71b-f0dd52a1afb0n%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] what should I dirty when I change ColorArray on the fly?
Hi Nick, indeed, that works. Thank you, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76833#76833 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] what should I dirty when I change ColorArray on the fly?
Hi again, I think I've solved my issue. I've worked out that BufferObject::dirty() does not yield a result because _glBufferObjects[i].valid() is false. This is probably because I was not using VBOs on those geometries. If I create the geometry with setUseVertexBufferObjects(true) the code works. Otherwise I've found that curGeom.dirtyDisplayList(); updates the geometry if setUseVertexBufferObjects() is not invoked. Just writing it here in case it helps somebody else. Thank you! Cheers, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76830#76830 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] what should I dirty when I change ColorArray on the fly?
Hello All,
I have implemented a colour change visitor along the lines of the class found
at:
http://www.vis-sim.com/osg/code/osgcode_color1.htm
While debugging I note that the following code is executed, including the
colorArrays->dirty(), but the colour in the render is not affected.
Could it depend from the way in which the colorArray is initialliy
instantiated?
Should I mark some state as Dynamic?
Code:
void XbimNodeColorVisitor::apply(osg::Geometry )
{
osg::Vec4Array *colorArrays = dynamic_cast(curGeom.getColorArray());
if (colorArrays) {
for (unsigned int i = 0; i < colorArrays->size(); i++) {
osg::Vec4 *color = >operator [](i);
color->set(m_color._v[0], m_color._v[1], m_color._v[2], m_color._v[3]);
}
colorArrays->dirty();
}
else {
// code never enters this path
}
}
Thank you!
Cheers,
Claudio
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76829#76829
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting LigtModel from viewer
Hello Robert, Your solution works very well, the code I'm using to get the LightModel is Code: osg::LightModel *lightModel = dynamic_cast (viewer->getCamera()->getStateSet()->getAttribute(osg::StateAttribute::LIGHTMODEL)); I've already tested that changing its state does affect the render as expected. It's a good sign that even after years of evolution you have access to nested instances so easily. Keep up the great work. Thank you! Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75793#75793 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Getting LigtModel from viewer
Hello All, I'd like to be able to toggle the setTwoSided() value of the LightModel that gets instantiated with the default osg::viewer class. I've looked at the code a while but I can't find a way to get the instance of LightModel from the instance of the viewer. I suppose it's attached to the global state that gets instantiated in the sceneView class, but I'm not sure how to get to that one either. Any help much appreciated. Thanks, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75791#75791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Temporarily overriding alpha channel
Hi all,
If anyone finds this useful, my current solution, combining help from this
thread and Paul Martz at http://forum.openscenegraph.org/viewtopic.php?t=13877,
looks like the following:
Code:
osg::StateSet* state = _rootGroup->getOrCreateStateSet();
if (op == 1)
{
state->removeAttribute(osg::StateAttribute::BLENDCOLOR);
state->removeAttribute(osg::StateAttribute::BLENDFUNC);
state->setRenderingHint(osg::StateSet::DEFAULT_BIN);
}
else
{
osg::BlendColor* bc = new osg::BlendColor(osg::Vec4(1.0, 1.0, 1.0, op));
osg::BlendFunc *bf = new osg::BlendFunc();
state->setAttributeAndModes(bf, osg::StateAttribute::ON);
state->setAttributeAndModes(bc, osg::StateAttribute::ON);
bf->setSource(osg::BlendFunc::CONSTANT_ALPHA);
bf->setDestination(osg::BlendFunc::ONE_MINUS_CONSTANT_ALPHA);
state->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
}
Next I'll try to see if I can set a material so that the blend settings are
ignored for a part of the sub-tree.
Thanks for all the help that carried me this far!
Claudio
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=75790#75790
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Temporarily overriding alpha channel
Thanks Chris, Apologies for the long delay, I've been moving home from the last post, I will be able to pickup your advice this week. I'll have good look at the fixed pipeline blending functions. Thank you! Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75788#75788 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Temporarily overriding alpha channel
Thanks Chris, that's very helpful. I'll have a look at your code. I've uploaded a video that might give you an idea of what I'm aiming at. In the video, I have a similar functionality in a open source WPF viewer that I've produced. The slider on the bottom left of the UI makes all objects transparent to allow to see the location of the selected walls through the walls of a building. https://youtu.be/7n3K52c1GtU Any selected wall, instead, is kept opaque. I think an uniform could be the solution, but it would need a way to exclude some elements of the scene from its application. Any suggestion is welcome. All the best, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75634#75634 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Temporarily overriding alpha channel
Hi, Is there a way to override the transparency channel of a sub tree in the scene? My application shows buildings and their components and I want to give the user a sort of x-ray vision in some circumstances to help locate items behind walls. I know that ideally this would require to z-sort all the elements in the view, but I'm not much concerned with the correct sorting at the moment. These models are sometimes *very* large, so something that uses an override value that I can then cheaply remove would be ideal. Any ideas? Thanks, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75632#75632 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tiny normals: osgviewer vs osgcompositeviewer
Hi again, last one, I promise. :) Reading Robert's answer at http://forum.openscenegraph.org/viewtopic.php?t=14093 I think that the inverse of the original transform needs to be there to compensate for the scaling (i.e make bigger the normal if the original tranform makes the model smaller). But then the normalisation invoked in the code shoulr only happen depending on the use of GL_NORMALIZE and GL_RESCALE_NORMAL. I think I'm going to sleep over this. Cheers, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75631#75631 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tiny normals: osgviewer vs osgcompositeviewer
Hi, Thinking again about this, I am starting to think that the problem could be somewhere else. Regardless from the correctness of the normal transformation, its normalisation should always return reasonable normal vectors. In the worst case scenario the display should render a shade that is similar to the color of the object (perhaps seen at a weird angle), but the full saturation to white, makes me think something else is operating here, there is no viewing angle that makes that same material appear completely white. Food for thoughts, I guess, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75630#75630 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tiny normals: osgviewer vs osgcompositeviewer
Hello, Julien, thanks for your help. I'm confused from the use of the inverse in the multiplication, I'm not sure I understand the nature of the code here. I'll have to go in and debug the values to understand more. What I'd expect is that only the rotation component of the matrix is applied to the normal vector (scaling and translation ignored). In the init code something like: Code: _rot = osg::Matrix::identity(); rot.makeRotate(_m.getRotate()); and then in the normals loop: Code: (*itr) = (*itr)*_rot; I do not understand at all why the code seems to be using the inverse of the matrix instead. Unfortunately I've isolated the scaling issues out of my current code so that testing this code would be quite difficult form me right now, but I'll try as soon as possible. Am I missing something big? Thanks again, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75629#75629 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tiny normals: osgviewer vs osgcompositeviewer
Hi Per, I'm finding the same problem as I'm trying to build a viewer that integrates a variety of models coming in different units (eg. mm vs. m). Have you had any further look at the code to include a fix? My thinking is that normals should only be rotated by the transform matrix, but I've not invested time yet to understand where this should happen in the code. Thanks, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75606#75606 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to abort rendering
Thanks Robert, I've investigated further and by creating a smarter scenegraph I've realised that I won't need to do this; I've achieved good frame rate on a few large models. For reference of anybody else reading in the future I'll add that the flag that Robert mentions works as advertised, however it only stops the Draw call, so if you have a time-consuming cull() operation the frame will still take some time before it ends. Thanks again, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72682#72682 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to abort rendering
Hello everybody, I'm new on the forum, hopefully I'll be able to contribute a bit in the future. I'm reviving this old thread to ask if the approach suggested is still the best way to manage the interruption of the frame rendering. The approach I'm considering is to stop the rendering from the RenderBin class if the frame is taking too long to render and the camera has moved. This would make some elements disappear in some frames, but if the sorting is adequately controlled it might not not disrupt the view much. I guess I'm trying to implement sort a guaranteed minimum frame rate during manipulation events by dropping elements; is anything like this already implemented? Thanks, Claudio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72668#72668 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
