[osg-users] Make node transparent on the fly - osg::Depth state leakage?
Hi! Before removing some nodes, I want them to fade out. So I want them to be rendered transparently for a short time, after they have been opaque most of their lifetime. I achieve this by setting the node's state as follows when the fadeout starts (omitting blend func constant details etc.): state_set-setAttribute(new osg::BlendFunc(GL_CONSTANT_ALPHA, GL_ONE_MINUS_CONSTANT_ALPHA)); state_set-setRenderBinDetails(BN_TRANSPARENT, DepthSortedBin); state_set-setMode(GL_BLEND, osg::StateAttribute::ON); state_set-setAttribute(new osg::Depth(osg::Depth::LESS, 0,1,false)); The problem is that the osg::Depth state seems to leak out and affect every rendered node while the fade-out is in effect. After the node is removed from the scenegraph, everything is back to normal. If I set the osg::Depth state right from the start when creating the node (and before rendering for the first time), I get the expected results, without state leakage (but obviously z-buffering doesn't work for the node). Is there something general I'm doing wrong, or is it rather something specific to the way I build my scene graph? Perhaps some information has to be rebuilt after changing state attributes, which doesn't happen automatically? At the moment I'm clueless where to start. I'm using OSG 2.2. thx for advice christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Make node transparent on the fly - osg::Depth state leakage?
Hi! Thanks for the quick response :-) You could help yourself if you just add the correct depth attribute to the parent of your node which should be faded out. For example: A is to fade out. P is parent of A, then you do: A-stateattribute-(new osg::Depth(0,1,false)) // or whatever you had before P-addChild(A) P-stateattribute(new osg::Depth()) // or whatever are correct values for proper depth handling. Unfortunately, I already tried that (sorry I didn't mention it in my original posting...) I tried adding osg::Depth() to the immediate parent and to the top node of my scene graph, but it doesn't make any difference. regards christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Zero Ballistics - open beta
Hi! Any ETA on the Linux client? :) Should be up during the next 1-2 days. Don't expect it to work on ATI cards, though, last time we tried it crashed horribly when compiling the GLSL shaders... regards christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMapping on recent ATI - repost
Hi! I didn't look at your images, but I recently posted an issue that seems to be similar to yours... (title issues with latest ATI driver, please confirm) I'll quote the relevant part here: In my program, I use perspective shadow maps, rendering to a depth texture using setRenderTargetImplementation(FRAME_BUFFER_OBJECT). This works perfectly with driver version 7.9. In 8.1 however, it appears that the frame buffer image is flipped upside down for some reason. If I invert the y-coordinate for shadow texture lookup, everything works fine again for this driver version. Can anybody confirm these issues? I'm afraid now I'll have to implement a test of whether the frame buffer is flipped to maintain compatibility with the screwed-up ATI driver... I hope this is not the case... Nobody replied to this post yet, in the meantime I have implemented the workaround which tests the orientation of the image which is rendered to the FBO. Perhaps this is of any help regards chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] issues with latest ATI driver, please confirm
Hi! There seem to be numerous issues regarding the latest ATI driver (8.1, tested on Windows XP): The osgshadow sample complains about the vertex shader missing. If I recompile the sample with a dummy shader, the sample displays the geometry, but all in black. I didn't investigate further yet. In my program, I use perspective shadow maps, rendering to a depth texture using setRenderTargetImplementation(FRAME_BUFFER_OBJECT). This works perfectly with driver version 7.9. In 8.1 however, it appears that the frame buffer image is flipped upside down for some reason. If I invert the y-coordinate for shadow texture lookup, everything works fine again for this driver version. Can anybody confirm these issues? I'm afraid now I'll have to implement a test of whether the frame buffer is flipped to maintain compatibility with the screwed-up ATI driver... I hope this is not the case... regards cm ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ATI GLSL bug regarding uniform arrays?
Mike Weiblen wrote: Hi, Agreed this is not for OSG to workaround. But rather than do without arrays, couldn't your app conditionally append the [0]? Not clear why this is a showstopper. Just curious. You are right about this - anyway, my usage of arrays was triggering a software fallback on some cards, so I implemented it differently and didn't pursue this further. regards chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions about Geometry implementation details
Robert Osfield wrote: Hi Ralf, Thanks for the clarification, I'm afraid my trip meant not following threads too closely. I've reviewed the code and the if (!array-getVertex..()) line is wrong, and Ulrich pointed to the correct implementation. I've fixed the relevant code and checked it into SVN. Sorry to bother you again, but did you take a look at the other lines of code I pointed out? I think the same problem exists there. line 1123: if (!array-getVertexBufferObject()) vbo = array-getVertexBufferObject(); line 1170: if (!array-getVertexBufferObject()) array-setVertexBufferObject(0); line 1178: if (!elements-getElementBufferObject()) elements-setElementBufferObject(0); The ! should be removed in all three cases. thx cm ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Questions about Geometry implementation details
Robert Osfield wrote: Hi Christian, On 10/19/07, Christian Muschick [EMAIL PROTECTED] wrote: Sorry to bother you again, but did you take a look at the other lines of code I pointed out? I think the same problem exists there. line 1123: if (!array-getVertexBufferObject()) vbo = array-getVertexBufferObject(); line 1170: if (!array-getVertexBufferObject()) array-setVertexBufferObject(0); line 1178: if (!elements-getElementBufferObject()) elements-setElementBufferObject(0); No I didn't, I assumed it was just the line illustrated. With problems like this its best to be explict, or ideally fix the code to what you think it shoudl be and then post a complete file for review, I then can do an graphical diff and spot exactly whats changed, what problems they address and any pattern involved. I'll remember that for the next time. Your latest changes seem to fix the problems that I spotted, thanks. regards cm ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Questions about Geometry implementation details
Hello!
My last request concerning this question didn't get any reply, so let me
try this reformulated version:
In Geometry.cpp, there are several lines of code that don't make sense
to me. More precisely, the conditions in a few if-statements seem to be
incorrect.
As an example, in Geometry::getOrCreateVertexBuffer, it says
{
ArrayList arrayList;
getArrayList(arrayList);
osg::VertexBufferObject* vbo = 0;
ArrayList::iterator vitr;
for(vitr = arrayList.begin();
vitr != arrayList.end() !vbo;
++vitr)
{
osg::Array* array = *vitr;
if (!array-getVertexBufferObject()) vbo =
array-getVertexBufferObject(); /// This will only set vbo to NULL!?
}
if (!vbo) vbo = new osg::VertexBufferObject;
}
In the loop, vbo will never get a value different from the null-pointer.
Is this on purpose? Did I miss something entirely?
Variations of this issue can be seen at lines 1123, 1170 and 1178.
Please have a look at this and correct me if I'm wrong.
regards
cm
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry::getOrCreateVertexBufferObject() - bug?
Hello! While browsing the source I noticed this line in Geometry.cpp (line 1060, rev 7375): if (!array-getVertexBufferObject()) vbo = array-getVertexBufferObject(); As far as I can see, there never is anything assigned to vbo but the NULL pointer, so a new vertex buffer object is always created later in the function. The same thing happens in getOrCreateElementBufferObject. Could somebody familiar with what should happen take a look at this? regards cm ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Linux Impostor sample issues
Hello! Running the osgimpostor sample under linux first works fine. After some moving around, however, patches of houses start to disappear or flicker, and finally the application crashes. Numerous errors are written to the console, see the end of the message. After killing the program, direct rendering doesn't work anymore until I restart gdm. OSG 2.1.8 dev release Ubuntu 7.04 NVIDIA Geforce 8800 GTS with latest driver (*100.14.11)* regards chris - Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadAlloc (insufficient resources for operation) Major opcode: 142 Minor opcode: 27 Error code: 11 Request serial: 1149 Current serial: 1150 ResourceID: 50331651 Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadWindow (invalid Window parameter) Major opcode: 143 Minor opcode: 4 Error code: 3 Request serial: 1150 Current serial: 1150 ResourceID: 50331651 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadAlloc (insufficient resources for operation) Major opcode: 142 Minor opcode: 27 Error code: 11 Request serial: 1151 Current serial: 1152 ResourceID: 50331651 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadWindow (invalid Window parameter) Major opcode: 143 Minor opcode: 4 Error code: 3 Request serial: 1152 Current serial: 1152 ResourceID: 50331651 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'invalid framebuffer operation' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'invalid framebuffer operation' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'invalid framebuffer operation' after RenderBin::draw(,) Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadAlloc (insufficient resources for operation) Major opcode: 8e Minor opcode: 1b Error code: b Request serial: 620 Current serial: 621 ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadWindow (invalid Window parameter) Major opcode: 8f Minor opcode: 4 Error code: 3 Request serial: 621 Current serial: 621 ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadAlloc (insufficient resources for operation) Major opcode: 8e Minor opcode: 1b Error code: b Request serial: 622 Current serial: 623 ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadWindow (invalid Window parameter) Major opcode: 8f Minor opcode: 4 Error code: 3 Request serial: 623 Current serial: 623 ResourceID: 303 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'invalid framebuffer operation' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadAlloc (insufficient resources for operation) Major opcode: 8e Minor opcode: 1b Error code: b Request serial: 6c9 Current serial: 6ca ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadWindow (invalid Window parameter) Major opcode: 8f Minor opcode: 4 Error code: 3 Request serial: 6ca Current serial: 6ca ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadAlloc (insufficient resources for operation) Major opcode: 8e Minor opcode: 1b Error code: b Request serial: 6cb Current serial: 6cc ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadWindow (invalid Window parameter) Major opcode: 8f Minor opcode: 4 Error code: 3 Request serial: 6cc Current serial: 6cc ResourceID: 303 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadAlloc (insufficient resources for operation) Major opcode: 8e Minor opcode: 1b Error code: b Request serial: 6f1 Current serial: 6f2 ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadWindow (invalid Window parameter) Major opcode: 8f Minor opcode: 4 Error code: 3 Request serial: 6f2 Current serial: 6f2 ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadAlloc (insufficient resources for operation) Major opcode: 8e Minor opcode: 1b Error code: b Request serial: 6f3 Current serial: 6f4 ResourceID: 303 Got an X11ErrorHandling call display=0x982f720 event=0xb6a259f4 BadWindow (invalid Window parameter) Major opcode: 8f Minor opcode: 4 Error code: 3 Request serial: 6f4 Current serial: 6f4 ResourceID: 303 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Got an X11ErrorHandling call display=0x982f720 event=0xb6a258a4 BadAlloc (insufficient
Re: [osg-users] Linux Impostor sample issues
I'm afraid this is osgimpostor running out of memory due to too many impostors being used all at once. The current impostor implementation doesn't try to provide an overall memory management scheme so is prone to consume too much resources. Impostors don't really have that much potential given the raw throughput speeds of modern hardware - its better just to send all the geometry rather than be clever with impostor techniques. For this reason I wouldn't recommend use of impostors. Thx for the quick response, I won't bother with Imposters anymore then... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
