Email Discussion
by Derek Bronson · in Collada Test · 01/06/2009 (10:51 am) · 11 replies
Russel -
I'm using Max 2008 w/ColladaMax exporter and Max 2009 with native Collada exporter. The meshes I'm exporting are using vertex coloring and two UV sets. So far everything's working great. Just a note, I probably won't be working with characters before this importer is released, so I won't be able to test skinned meshes or animations any time soon.
Matt Ostgard -
I'll be using Maya 2008's native exporter and possibly Modo's native exporter for static objects.
James Barnette -
As far as a model format to use in engine I find that to be completely inpractical far all but the simplest of games. Aside from the reasons that you mention like the load times it leave all of the art assets open to manipulation.
the only practical course I see as collada is concerned is as you alluded to a stand alone converter. Ideally with source released with the engine.
A conversion tool that has selectable input profiles for the differnt originating applications these ideally would be scripts that explain to the exporter how to read the collada fromt he different application so that the output is consistent.
This also has the added benifit that it could still be run via script from the originating application so that the process is transperant to the artist.
Another benefit to this is that new versions are not required every time and application like MAX or Maya comes out with a new version.
this is my opinion anyway,
James Brad Barnette
Matt Ostgard -
Russell: I thought Maya came with it, but it may have been a separate install.. I'm using Autodesk's "FBX 2009.3 Plug-in for Maya 2008" (which also supports DAE). I've used a skinned mesh with it and it seems to export alright, but usually doesn't import very well.
Russell -
One thing I found in Max when using Collada as opposed to dts is that now the materials.cs file is asking for the material name, not the texture name. I haven't checked those files, but if they are set up to work as dts, this might be the problem.
Before, if my diffuse texture was named "tallgrass_diffuse.png", and it was in a material setup in Max that I left at the default name (usually something like "standard01"), then the materials.cs file would be set to ask for "tallgrass_diffuse". Now, since the materials.cs file is asking for the material name and not the texture name, I have to make sure and change the default material name in Max to something distinct, or to the name that the materials.cs file is asking for. In my case "tallgrass_diffuse".
Hope that makes sense.
James -
so does anyone know the material name or have a material cs for the example files?
Russell -
I'm just saying that you'll need to make sure the material in XSI is named correctly, and corresponds to your materials.cs file. If it's not, you'll need to re-name the material in XSI.
Jentzen -
I will be using XSI 7.0 and the Mod Tool(6.5) release and Collada via Crosswalk 3.11
I'm using Max 2008 w/ColladaMax exporter and Max 2009 with native Collada exporter. The meshes I'm exporting are using vertex coloring and two UV sets. So far everything's working great. Just a note, I probably won't be working with characters before this importer is released, so I won't be able to test skinned meshes or animations any time soon.
Matt Ostgard -
I'll be using Maya 2008's native exporter and possibly Modo's native exporter for static objects.
James Barnette -
As far as a model format to use in engine I find that to be completely inpractical far all but the simplest of games. Aside from the reasons that you mention like the load times it leave all of the art assets open to manipulation.
the only practical course I see as collada is concerned is as you alluded to a stand alone converter. Ideally with source released with the engine.
A conversion tool that has selectable input profiles for the differnt originating applications these ideally would be scripts that explain to the exporter how to read the collada fromt he different application so that the output is consistent.
This also has the added benifit that it could still be run via script from the originating application so that the process is transperant to the artist.
Another benefit to this is that new versions are not required every time and application like MAX or Maya comes out with a new version.
this is my opinion anyway,
James Brad Barnette
Matt Ostgard -
Russell: I thought Maya came with it, but it may have been a separate install.. I'm using Autodesk's "FBX 2009.3 Plug-in for Maya 2008" (which also supports DAE). I've used a skinned mesh with it and it seems to export alright, but usually doesn't import very well.
Russell -
One thing I found in Max when using Collada as opposed to dts is that now the materials.cs file is asking for the material name, not the texture name. I haven't checked those files, but if they are set up to work as dts, this might be the problem.
Before, if my diffuse texture was named "tallgrass_diffuse.png", and it was in a material setup in Max that I left at the default name (usually something like "standard01"), then the materials.cs file would be set to ask for "tallgrass_diffuse". Now, since the materials.cs file is asking for the material name and not the texture name, I have to make sure and change the default material name in Max to something distinct, or to the name that the materials.cs file is asking for. In my case "tallgrass_diffuse".
Hope that makes sense.
James -
so does anyone know the material name or have a material cs for the example files?
Russell -
I'm just saying that you'll need to make sure the material in XSI is named correctly, and corresponds to your materials.cs file. If it's not, you'll need to re-name the material in XSI.
Jentzen -
I will be using XSI 7.0 and the Mod Tool(6.5) release and Collada via Crosswalk 3.11
About the author
#2
same here.
01/06/2009 (11:36 am)
Xsi 7.0.1x64 with Crosswalk (3.1.1)Quote:
At a first try, the model is not exported with the right SRT (rotated 90) and the materials.cs edit is not clear yet, as Russel pointed out.
same here.
#3
A solution for people forgetting that they have to name a material could be a simple script that would have a check box for "Material Name = Diffuse" which would rename all used materials and export.
As for collada being directly supported by the engine, I am in favor of it for a couple of reasons:
1) Eventual support for shaders embedded in the model and possibly other future features.
2) Allowing for easier access to information that coders or artists might want and may not be available in a dts viewer. Since I would be putting collada files in the game directory I can be sure that anyone on the dev team can reference it if they need to and have more of a chance of tracking down possible model related problems.
3) More fluid work flow. Being able to drop in a collada file and it creates the materials from it is definitely a big plus imo.
I do not think that a game should ship with collada though.. it should be used for development, and then ship with the DTS models/materials the engine generates. In favor of a flexible workflow though, I think it would be good if we had a separate DAE to DTS executable.. but if it is a choice of one or the other, I would rather just have engine support.
01/06/2009 (12:13 pm)
I think that a torque material should be applied via material instead of texture name because it's current implementation has caused some irritating workflow problems in the past. Let's say I have 1 diffuse texture shared by 2 objects, but on one object I want the material to animate scroll and the other I want to animate rotate (or even something simple like a different specular power on both). That means I have to create a duplicate dummy texture for the application to reference and then have my material.cs mapTo the dummy texture but actually use the same texture the other object is using.A solution for people forgetting that they have to name a material could be a simple script that would have a check box for "Material Name = Diffuse" which would rename all used materials and export.
As for collada being directly supported by the engine, I am in favor of it for a couple of reasons:
1) Eventual support for shaders embedded in the model and possibly other future features.
2) Allowing for easier access to information that coders or artists might want and may not be available in a dts viewer. Since I would be putting collada files in the game directory I can be sure that anyone on the dev team can reference it if they need to and have more of a chance of tracking down possible model related problems.
3) More fluid work flow. Being able to drop in a collada file and it creates the materials from it is definitely a big plus imo.
I do not think that a game should ship with collada though.. it should be used for development, and then ship with the DTS models/materials the engine generates. In favor of a flexible workflow though, I think it would be good if we had a separate DAE to DTS executable.. but if it is a choice of one or the other, I would rather just have engine support.
#4
Are you able to provide this model in the samples forum? Collada has a tag indicating the model's native coordinate system (eg. X_UP, Y_UP or Z_UP), and the loader uses this to convert to Torque's coordinate system (Z_UP).
However, I have seen several models that do not specify the correct value in this tag, and thus end up incorrectly oriented when loaded into Torque.
01/06/2009 (12:41 pm)
Quote:At a first try, the model is not exported with the right SRT (rotated 90)
Are you able to provide this model in the samples forum? Collada has a tag indicating the model's native coordinate system (eg. X_UP, Y_UP or Z_UP), and the loader uses this to convert to Torque's coordinate system (Z_UP).
However, I have seen several models that do not specify the correct value in this tag, and thus end up incorrectly oriented when loaded into Torque.
#5
I think that this is unlikly as the format that torque uses and collada standard shaders are completly different.
not to mention that it would mean you would have to change the order in which things initialized in order to extract the shader from all of the model then compile them, then go on about loading everything else. to be quite honest that is a lot of work and not a very practical use of man hours especially give you later statment about not wanting to ship with this. Which is why I have said from the beginning that a stand alone tool is much more preferable. There is not point in adding something to the engine that is not going to be used in the shipping version. Plus a standalone app can have profiles for mapping all parameters to the correct places since it seems that just about every app writes collada differently.
Possibly but the same can still be done with a standalone command line utility, But a cmd line utility has other advantages that I will get to.
Again, there is no reason to involve the engine in this. Besides I don't know how big your team is but we are small and will be using outsouring from india. I don't want to give anyone I don't have to anything that I don't need to give them. Wow 3 Don'ts in one sentence. I dont want to give outside artist access to my game code and engine. and I dont want to give and outside programmer or even another artist access to assets in an unpretected form. I'm telling you if you go sending art assets out in collada you are gonna see them on turbo squid before you know it . Or they will get modified and used in another project. Collada is great for a common format for import. But that is where I think it should End.
In my Opinion:
1: the Collada should be pulled out of the engine itself.
2: the code should be used to generate a standalone cmd line app that would
a: command line flags for all of its paramerters.
b: have a text base profile that can be speced from a flag
example: exporter.exe -app maya scenefile.dae
c: the exporter would then take and make a roughed in .cs file for the object
d: the exporter would then export the dts files
e: the exporter would rough in a materials.cs file
3: then make the new changes to the DTS part of the common code base. So that the new DTS files that the new converter makes and the engine are compatible.
The benefit of what I outlined is far more flexible in that, it could be run from script from inside ANY of application. this make it transparent to the artist. And as a artist that is what is important to me.
Make a button in my app that runs a gui. pick my options and click go. It saves a collada file and then launches the utility in the background using the options i slected in the gui and and feeds it the collada file and out comes the .dts .dsq and .cs files.
this is a system that also is not going to break every time Autodesk decides to update. like a plugin exporter. As a matter of fact it is something that, outside of it's scripts would almost never have to be updated.
anyway thats my 2 cents.
01/06/2009 (6:47 pm)
Quote:
As for collada being directly supported by the engine, I am in favor of it for a couple of reasons:
1) Eventual support for shaders embedded in the model and possibly other future features.
I think that this is unlikly as the format that torque uses and collada standard shaders are completly different.
not to mention that it would mean you would have to change the order in which things initialized in order to extract the shader from all of the model then compile them, then go on about loading everything else. to be quite honest that is a lot of work and not a very practical use of man hours especially give you later statment about not wanting to ship with this. Which is why I have said from the beginning that a stand alone tool is much more preferable. There is not point in adding something to the engine that is not going to be used in the shipping version. Plus a standalone app can have profiles for mapping all parameters to the correct places since it seems that just about every app writes collada differently.
Quote:
2) Allowing for easier access to information that coders or artists might want and may not be available in a dts viewer. Since I would be putting collada files in the game directory I can be sure that anyone on the dev team can reference it if they need to and have more of a chance of tracking down possible model related problems.
Possibly but the same can still be done with a standalone command line utility, But a cmd line utility has other advantages that I will get to.
Quote:
3) More fluid work flow. Being able to drop in a collada file and it creates the materials from it is definitely a big plus imo.
Again, there is no reason to involve the engine in this. Besides I don't know how big your team is but we are small and will be using outsouring from india. I don't want to give anyone I don't have to anything that I don't need to give them. Wow 3 Don'ts in one sentence. I dont want to give outside artist access to my game code and engine. and I dont want to give and outside programmer or even another artist access to assets in an unpretected form. I'm telling you if you go sending art assets out in collada you are gonna see them on turbo squid before you know it . Or they will get modified and used in another project. Collada is great for a common format for import. But that is where I think it should End.
In my Opinion:
1: the Collada should be pulled out of the engine itself.
2: the code should be used to generate a standalone cmd line app that would
a: command line flags for all of its paramerters.
b: have a text base profile that can be speced from a flag
example: exporter.exe -app maya scenefile.dae
c: the exporter would then take and make a roughed in .cs file for the object
d: the exporter would then export the dts files
e: the exporter would rough in a materials.cs file
3: then make the new changes to the DTS part of the common code base. So that the new DTS files that the new converter makes and the engine are compatible.
Quote:
In favor of a flexible workflow though, I think it would be good if we had a separate DAE to DTS executable.. but if it is a choice of one or the other, I would rather just have engine support.
The benefit of what I outlined is far more flexible in that, it could be run from script from inside ANY of application. this make it transparent to the artist. And as a artist that is what is important to me.
Make a button in my app that runs a gui. pick my options and click go. It saves a collada file and then launches the utility in the background using the options i slected in the gui and and feeds it the collada file and out comes the .dts .dsq and .cs files.
this is a system that also is not going to break every time Autodesk decides to update. like a plugin exporter. As a matter of fact it is something that, outside of it's scripts would almost never have to be updated.
anyway thats my 2 cents.
#6
1. Run Torque 3D.
2. Export a DAE file from 3dsmax.
3. Look in the Torque inspector creator for the DAE file to create a TSStatic.
4. Return to 3dsmax... make changes to the model and resave the DAE.
5. Alt-tab back to Torque 3D to see the model update in real-time.
6. Goto 4.
This process is 1000% better than the old DTS exporters and extremely transparent to the artist. If there was another step... a conversion EXE... it would make things less transparent.
Of course when we ship our demo EXE we'll rebuild without the Collada loader and ship the cached DTS files. This process is no different that .cs/.dso files.
I do want to add a command line function to rebuild all the DTS cache files from the DAEs for automated builds... but that should be fairly easy to script.
01/06/2009 (8:14 pm)
Quote:1: the Collada should be pulled out of the engine itself.The Collada support was put in there as a separate module so that someone could do that.
Quote:2: the code should be used to generate a standalone cmd line app that wouldI don't see that happening for Torque 3D... but you have all the code to do that if one would want.
Quote:3: then make the new changes to the DTS part of the common code base.Already works... the modified DTS generated from the Collada loader works with the engine... because its all based on the same code base.
Quote:this make it transparent to the artist. And as a artist that is what is important to me.We've been using and improving the current Collada loader as part of Torque 3D game EXE for months. It works like so...
1. Run Torque 3D.
2. Export a DAE file from 3dsmax.
3. Look in the Torque inspector creator for the DAE file to create a TSStatic.
4. Return to 3dsmax... make changes to the model and resave the DAE.
5. Alt-tab back to Torque 3D to see the model update in real-time.
6. Goto 4.
This process is 1000% better than the old DTS exporters and extremely transparent to the artist. If there was another step... a conversion EXE... it would make things less transparent.
Of course when we ship our demo EXE we'll rebuild without the Collada loader and ship the cached DTS files. This process is no different that .cs/.dso files.
I do want to add a command line function to rebuild all the DTS cache files from the DAEs for automated builds... but that should be fairly easy to script.
#7
what I meant was make the modifications that have been made to DTS itself part of the common code "1.8.x" what everyone else in the community is using. Am I mistaken here about this? I was under the impression that these changes we only present in the version of the T3D demo that we are currently using. Is this already rolled into 1.8?
01/06/2009 (8:30 pm)
That sounds good but I still am obviously not understanding then about the animation. From what I have read thus far it sounds like the animation would stay in .dae form and therefor alterable.Quote:
Already works... the modified DTS generated from the Collada loader works with the engine... because its all based on the same code base.
what I meant was make the modifications that have been made to DTS itself part of the common code "1.8.x" what everyone else in the community is using. Am I mistaken here about this? I was under the impression that these changes we only present in the version of the T3D demo that we are currently using. Is this already rolled into 1.8?
#8
As far as the Collada support its going to be part of Torque 3D... it isn't part of TGEA 1.8. So this won't be released to the community at large for a while longer... your getting an early preview so we can get your feedback.
I'm not sure what EXE you were given... it may be some early version of Torque 3D.
01/06/2009 (8:39 pm)
@James - I'll let Chris address the DAE to DSQ issue... i suppose it works the same as DAE and gets cached out.As far as the Collada support its going to be part of Torque 3D... it isn't part of TGEA 1.8. So this won't be released to the community at large for a while longer... your getting an early preview so we can get your feedback.
I'm not sure what EXE you were given... it may be some early version of Torque 3D.
#9
01/06/2009 (9:02 pm)
The one from the GGbetas site it says "Torque Game Engine Advanced (1.8.0) - T3D " on the title bar of the window when I run it.
#10
01/06/2009 (9:07 pm)
Honestly that doesn't mean anything other than the script which sets the title bar didn't get updated after the last 1.8 merge into Torque 3D. ;) 
Torque 3D Owner Apparatus
I am using xsi 7.0.1 with the latest Crosswalk (3.1.1) installed;
At a first try, the model is not exported with the right SRT (rotated 90) and the materials.cs edit is not clear yet, as Russel pointed out.