Tim Moore wrote:
>You can't set the render bin, but you can set any other attribute or
>mode in the StateSet. If that causes the StateSet to change its opacity,
>well, that's a problem.
>
>
>
There is no reason to dynamicaly change the renderbin, if the object can
be transparent then it will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mathias Fröhlich wrote:
> Tim,
>
> On Tuesday 08 May 2007, Tim Moore wrote:
There is also a second assumption in the animation system: The textures
for the liveries are expected not to be in the osg::Drawables. That is
not always true a
Tim,
On Tuesday 08 May 2007, Tim Moore wrote:
> >> There is also a second assumption in the animation system: The textures
> >> for the liveries are expected not to be in the osg::Drawables. That is
> >> not always true and is especially no longer true with the ac loader
> >> update in osg svn si
On Tuesday 08 May 2007, Harald JOHNSEN wrote:
> Yes by states I was thinking of statesets. Anyway I looked again the
> geode and drawable definitions and now
> I'm confused, I thought the states were tied to the geodes but they are
> tied to the drawable. I really don't
> understand how we can have
Hi Harald,
On Tuesday 08 May 2007, Harald JOHNSEN wrote:
> To recap we have (or should have in the future) :
> - one drawable per model / part of model
Not sure what this means, the Drawable's are the leaf nodes in osg. They can
have StateSet's attached to it. With one Drawable there is one disp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harald JOHNSEN wrote:
> Tim Moore wrote:
>
>>
>>
>>> To recap we have (or should have in the future) :
>>> - one drawable per model / part of model
>>> - one texture per texture loaded
>>> - one state per static / animation material
>>> - adding a '
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harald JOHNSEN wrote:
> Tim Moore wrote:
>
>>
>>
>>> To recap we have (or should have in the future) :
>>> - one drawable per model / part of model
>>> - one texture per texture loaded
>>> - one state per static / animation material
>>> - adding a 'mod
Melchior FRANZ wrote:
>* Tim Moore -- Tuesday 08 May 2007:
>
>
>>I think it's reasonable to require that all the
>>colors in a material animation be specified; modelers might disagree :)
>>
>>
>
>It's unacceptable. An typical emission animation looks now like this:
>
>
> material
>
Tim Moore wrote:
>
>
>>To recap we have (or should have in the future) :
>>- one drawable per model / part of model
>>- one texture per texture loaded
>>- one state per static / animation material
>>- adding a 'model' will add a geode with a new state pointing to a
>>cached texture and to a cac
* Tim Moore -- Tuesday 08 May 2007:
> I think it's reasonable to require that all the
> colors in a material animation be specified; modelers might disagree :)
It's unacceptable. An typical emission animation looks now like this:
material
instrument-face
controls/l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harald JOHNSEN wrote:
> Mathias Fröhlich wrote:
>
>> Tim,
>>
>> On Saturday 05 May 2007, Tim Moore wrote:
>>
>>
>>> The attached patch fixes material animations (color in particular) in
>>> osg. I also notice a big frame rate increase with aircraft
Mathias Fröhlich wrote:
>Tim,
>
>On Saturday 05 May 2007, Tim Moore wrote:
>
>
>>The attached patch fixes material animations (color in particular) in
>>osg. I also notice a big frame rate increase with aircraft that use
>>material animations.
>>
>>
>Applied thanks!
>
>Comments to that:
>Thi
Tim,
On Saturday 05 May 2007, Tim Moore wrote:
> The attached patch fixes material animations (color in particular) in
> osg. I also notice a big frame rate increase with aircraft that use
> material animations.
Applied thanks!
Comments to that:
This one will only work like expected for the curr
13 matches
Mail list logo
