Hi Christoph,
On Mon, 2005-07-18 at 17:07 +0200, Christoph Anthes wrote:
> Hello,
>
> I have a problem runing OpenSG 1.4 on our Onyx system. I was trying to
> measure the performance of the system using different texture sizes.
> Somehow textures seam to slow down the system immensely.
Hi,
On Fri, 2005-07-15 at 20:00 +0200, Johan Grafstrom wrote:
> Hi Dirk and Gerrit!
>
> I have some questions and a possible feature request regarding
> osg::ChangeList.
>
>
> Disabled ChangList::applyTo(int aspect)
>
> In the source code there are a disabled method "applyTo" that
> takes
OpenSG Commit Digest for 2005/07/18
===
=== Since the last digest [EMAIL PROTECTED] committed
in . Source/Contrib:
added terrain contrib option.
in Source/System/Action:
fixed wrong action->getActNode() return value
Hi!
On Fri, 2005-07-15 at 20:00 +0200, Johan Grafstrom wrote:
Disabled ChangList::applyTo(int aspect)
Gerrit Voss wrote:
there is one trick which would explain the problem and this is that the
changed calls are done for the aspect of the thread doing the sync and
not the receiving
Hello Christoph,
I just loaded the model into VRED and got approx 2 fps on an octane with
v10 graphics. BUT after optimizing away redundant materials the
framerate increased to OVER 40fps in fullscreen mode (1280x1024). This
optimization is done automatic when using performer. So if you simply
Hello,
I have a problem runing OpenSG 1.4 on our Onyx system. I was trying to
measure the performance of the system using different texture sizes.
Somehow textures seam to slow down the system immensely. With models
without textures we produce framerates of 20 frames with 200.000
triangles. W
Hi!
I've generated an OSGDVRVolume with a dataset consisting of only 1
slice. This produces a segmentation fault in
osg::BrickSet::sortBricks3D. If I generate 2 slices the problem does not
arise.
In order to find a solution for this I was wondering whether there's a
bug in OSGBrick or if
