Hi Terry,

I haven't used SharedStateManager personally (it was developed by a
member of the community), so am not in a strong position to dive in a
guide proceedings.

You suggest about breaking the enum out into
DYANMIC/STATIC/UNSPECIFIED variants looks like something that might be
required.  Or perhaps this could be placed in a separate options.  In
general I'd suggest that STATIC and UNSPECIFIED are ones that you
could merge by default but not DYNAMIC state.   So SHARE_TEXTURES
would be equal to SHARE_STAITC_TEXTURES | SHARE_UNSPECIFIED_TEXTURES,
and the same for SHARE_STATESET.

Robert.

On Tue, Jul 1, 2008 at 9:12 PM, Terry Welsh <[EMAIL PROTECTED]> wrote:
> It looks like SharedStateManager is appropriate for what I'm doing,
> but it doesn't seem to be quite as flexible as I'd like.  With the
> wide variety of modelers, exporters, and loaders, I can't always be
> assured that the DataVariance on StateSets and Textures will be
> static.  This is currently a requirement for sharing, though.
>
> The current share modes are
>
>        enum ShareMode
>        {
>            SHARE_NONE      = 0x00,
>            SHARE_TEXTURES  = 0x01,
>            SHARE_STATESETS = 0x02,
>            SHARE_ALL       = SHARE_TEXTURES |
>                              SHARE_STATESETS
>        };
>
>
> Would it be too weird to append these modes like so?
>
>        enum ShareMode
>        {
>            SHARE_NONE      = 0x00,
>            SHARE_TEXTURES  = 0x01,
>            SHARE_STATESETS = 0x02,
>            SHARE_ALL       = SHARE_TEXTURES |
>                              SHARE_STATESETS,
>            SHARE_TEXTURES_DYNAMIC = 0x04,
>            SHARE_TEXTURES_UNSPECIFIED = 0x08,
>            SHARE_STATESETS_DYNAMIC = 0x10,
>            SHARE_STATESETS_UNSPECIFIED = 0x20
>        };
>
> I've already tried it with textures and it helps out a lot when you
> can't easily control what's in your model files; I can submit it if
> this looks good.
>
> The only problem I see is that SHARE_ALL no longer makes much sense,
> but changing it would break backward compatibility.  And it would look
> weird to have SHARE_ALL_NO_REALLY_SHARE_ALL.
> - Terry
>
>>
>> Message: 11
>> Date: Fri, 27 Jun 2008 09:32:15 +0100
>> From: "Robert Osfield" <[EMAIL PROTECTED]>
>> Subject: Re: [osg-users] multiple models, single texture
>> To: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org>
>> Message-ID:
>>        <[EMAIL PROTECTED]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi Terry,
>>
>> On Fri, Jun 27, 2008 at 5:01 AM, Terry Welsh <[EMAIL PROTECTED]> wrote:
>>> Is it possible to load multiple model files that use the same texture
>>> but only have the texture get loaded once?  It seems like a good way
>>> to save memory and reduce state changes.
>>
>> The loaders don't cache images and textures, but it is possible to
>> combine duplicate state once the data is loaded.  The
>> osgUtil::Optimize::RemoveDuplicateState can be used on a whole scene
>> graph, and the osgDB::SharedStateManager can be used when you are
>> incrementally loading subgraphs.
>>
>> Robert.
>>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to