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.):
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
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
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
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
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
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
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
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
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
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,
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
12 matches
Mail list logo
