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

[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

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

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

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

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

[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

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) {

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:

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

[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

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).

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

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

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

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,

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