Khronos Public Bugzilla
Bug 33 - Shared surface support
Shared surface support
Status: NEW
Product: COLLADA
Classification: Unclassified
Component: Schema
1.4.1
PC Windows
: P3 enhancement
: ---
Assigned To: Fabrice Robinet
COLLADA Work Group email alias
: collada-fx
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-27 12:58 PST by Brandon Ehle
Modified: 2014-01-07 10:23 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brandon Ehle 2007-02-27 12:58:09 PST
There does not appear to be a way to share surfaces between effects in the specification.  It seems like something like this would be needed to share a global cubemap (or something similar) across many effects at once.

A <library_surfaces> tag with surface definitions referred to by the effects seems like it might solve the problem.

See this post:

https://collada.org/public_forum/viewtopic.php?t=714&sid=891961baa609ec3769d073d01d77fc2a
Comment 1 Mark Barnes 2007-02-27 13:39:04 PST
Daniel do you think this is a bug or an enhancement request?
Comment 2 Brandon Ehle 2007-02-27 14:09:11 PST
Somewhere in between.

You can definitely use the surface in the spec currently and be able to create something for testing purposes.  But if you want to scale up to a really large amount of content, I believe copy and pasting surface tags all over the place will be extremely difficult to maintain.

I guess what I am saying is the specification is useful for testing, but not necessary applicable for a production pipeline.  If the purpose of the Collada FX specification is for prototyping and not production, I would label it as an enhancement.  Otherwise I would label it as a bug.

Comment 3 Daniel Horowitz 2007-02-27 15:08:52 PST
Actually it is either a non-issue or an enhancement request...

For the sharing cube-maps example it is a little more of a non-issue because surfaces can sharing the same <image> and swapping out the contents like the references to a cubemap DDS.  And then the hashcode of the surface setup can be used to cache the runtime object.

But an example that really requires this functionality is RenderToTexture.  Where you might want to render a texture in one effect and then consume that texture in another effect.  In FXComposer2 we added an <extra> to identify shared surface primarily for this purpose.

Because surfaces do not have IDs and material <setparam>s do not have annotations, we added the extra directly to the surface itself.  This provides an ID for sharing.  Each surface that is written out appears as a useful surface with all of the initialization information.  Because of this, the first surface of that ID that is location becomes the initializer.  All others can validate themselves for inconsistancies and warn the user.

That was probably a bit long-winded but I we definitely need to consider an approach like <library_surfaces> which we have talked about before or the semantic style I mentioned above.
Comment 4 Brandon Ehle 2007-02-27 15:51:11 PST
Unless I am mistaken, you also need the surface to be shared in order to be able to calculate processing options when preparing the surface for the runtime.

Because you specify the flags <format>, <format_hint>, <mipmap_generate>, <mip_levels>, <size>, etc... in the surface, you need to have the surface if you want to process your textures offline to the correct binary format.  Right now you have to copy those flags to each and every <material> that contains a <setparam> with that surface.

In order to find out what the correct binary format for a texture is, you have to scan your entire tree of Collada materials looking for each and every <setparam> that references a texture to be able to apply the correct processing options.  And even then it's not clear what the correct decision is when you run across the same texture referenced with different options.  Do you duplicate it and waste memory?  Throw an error?  Randomly pick a set of options?

Given a shared set of <surface> objects that are referenced by <setparam> calls, the domain of the problem is significantly reduced.  You merely have to walk the the list of <surface> objects in the <library_surfaces> node and build a runtime ready surface for each object in the list.
Comment 5 Mark Barnes 2008-05-10 18:59:18 PDT
Daniel what is the status of this?
Comment 6 Mark Barnes 2010-05-17 04:36:45 PDT
Since 1.5 effect schema is different, this bug is not relevant to that branch.
The work group thinks this problem is resolved in 1.5 as well.