Extending the XSI collada export plugin

Hi,
I’m just beginning the process of moving our toolchain to collada and its all looking rather promising. Unfortunately heowever the material data specified by the current collada specification is far too simple for our needs.

To overcome this I intent to create a new effect profile which exports much more of the shade tree used in the DCC applications, prefeably in as abstract a way as possible. This should allow much better interoperability as well as giving our engine the data it needs to correctly interpret materials.

My question here is about extending the data exported by the various exporters. Obbiously ColladaMaya and ColladaMax are both open source so i can add the code to create my profile to those directly. As far as i can tell however the latest version of the softimage XSI support no longer comes with source. Is there any way for me to extend this plugin directly or am i going to have to fall back to a clunky solution where i export 2 collada files (one from the XSI exporter and one just containing materials from my exporter) and stitch them together…?

Any help gratefully appreciated - i’m keen to get this properly planned up front to make the implementation as painless as possible…

Cheers

Sean

To overcome this I intent to create a new effect profile
Don’t forgot about profile_GLSL, profile_CG, and profile_GLES. They should be capable of describing pretty much any material configuration you might use.

As far as i can tell however the latest version of the softimage XSI support no longer comes with source.
Maybe someone will have a better answer, but you might want to ask XSI about this directly, or post on one of their forums… I don’t believe any of their engineers visit this forum anymore.

I’m afraid i think this falls into the category of “True but not useful”. Which sounds a bit combative, so i will try to explain myself. profile_CG and their like do obviously allow me to specify my shading model directly, and allow any concrete effect i might imagine. This howevers seems to me to be at entirely the wrong abstraction level. By describing the material directly using the pixel and vertex shader I lose the nice abstract shade tree description which allows me (amongst other things) to:

  • Perform automatic shader LOD
  • Generate materials for platforms without shader hardware (over 50% of my target platforms at this point)
  • Support artist generated materials directly and efficiently without involving a specific shader programmer

This is IMHO too much power to lose for the percieved gain.

Back to the original question though, I will contact softimage tech support to see what their suggested solution is, although i’m rapidly becoming less hostile to creating a second collada file containing the material library and think that might form an acceptable solution to the issue.

Cheers

Sean

Hello,
What kind of materials do you want to export : Softimage Mental Ray materials (Phong, Lambert, Blinn…) or RealTime Materials (OpenGL pass nodes) ?
If you want to export OpenGL pass (that seems appropriate for realtime 3D engines workflow), you can maybe use .material files generated with Ogre3D exporter that describe the materials attributes.
Regards,
Benoit

Hi,

You could also look into using the XSI CGFx realtime shader instead. We export it as embeded in the profile_CG or as a reference to an external file thru the nVidia NV_import extra.

LB

Also,

You can extend the COLLADA file exported by the Crosswalk SDK if you want.

The first way would be to add Custom Properties Sets that would be exported as <extra> automatically.

The second way would be to use the Crosswalk SDK I/O layer where templates that can be retrieved from a semantic layer object is a COLLADATemplate which corresponds to each COLLADA xml elements and each of those have attributes. So, you can navigate the COLLADA elements, by going thru their child and parents, you can modify them, add new ones, remove some, etc. To do this, you have the XSI COLLADA plugin code in the Crosswalk setup. This plugins takes care of filling the Crosswalk SDK semantic layer so, in this plugin, you have the opportunity to add your code that perform your required modification right before the final write to file call is performed.

Let me know if you need more info on the second way to extend the XSI COLLADA export.

here’s an example that shows how to change the unit meter and name attribute in the XSI COLLADA plugin - source available in the Crosswalk setup:

// first, get the COLLADA Scene
CSLCOLLADAScene* l_pCOLLADAScene = ((CSLCOLLADAScene*)(in_pContext->ftkscene()));

// get the associated collada template <scene>
CCOLLADATemplate* l_pCOLLADASceneTemplate = l_pCOLLADAScene->GetInstanciatedSceneTemplate();

// get it's parent, the <COLLADA> template
CCOLLADATemplate* l_pCOLLADATemplate = (CCOLLADATemplate*)l_pCOLLADASceneTemplate->Parent();

// look for <asset> childs of the <COLLADA> template
CdotXSITemplates* l_pCOLLADAAssetArray = l_pCOLLADATemplate->ChildrenOfType(CSIBCString("asset"));

if (l_pCOLLADAAssetArray->GetCount() > 0)
{
   CdotXSITemplate* l_pAssetTemplate;
   l_pCOLLADAAssetArray->Item(0, &l_pAssetTemplate);

   // look for <unit> child of the <asset> template
   CdotXSITemplates* l_pCOLLADAUnitArray = l_pAssetTemplate->ChildrenOfType(CSIBCString("unit"));

   if (l_pCOLLADAUnitArray->GetCount() > 0)
   {
      CCOLLADATemplate* l_pCOLLADAUnitTemplate;
      l_pCOLLADAUnitArray->Item(0, (CdotXSITemplate**)(&l_pCOLLADAUnitTemplate));

      // get the <unit> attributes
      CdotXSIParams &l_pAttibuteArray = l_pCOLLADAUnitTemplate->Attributes();

      // look for the meter= and name= attributes and modift their values.
      LONG loop;

      for (loop = 0; loop < l_pAttibuteArray.GetCount(); loop++)
      {
         CdotXSIParam* l_pAttribute;
         l_pAttibuteArray.Item(loop, &l_pAttribute);

         if (l_pAttribute->Name() == "meter")
         {
            char l_NewUnitString[4];
            strcpy(l_NewUnitString, "1.0");
            SI_TinyVariant l_NewUnit;
            l_NewUnit.p_cVal = l_NewUnitString;
            l_NewUnit.variantType = SI_VT_PCHAR;

            l_pAttribute->SetValue(l_NewUnit);
         }
         else if (l_pAttribute->Name() == "name")
         {
            char l_NewUnitString[6];
            strcpy(l_NewUnitString, "meter");
            SI_TinyVariant l_NewUnit;
            l_NewUnit.p_cVal = l_NewUnitString;
            l_NewUnit.variantType = SI_VT_PCHAR;

            l_pAttribute->SetValue(l_NewUnit);
         }
      }
   }

LB