Exporting UV2 mapping for lightmaps

#1 The DTS exporters don't support 2nd UV channel, nor vertex colors. You must use Collada.

If you have a model setup with the proper hierarchy to export correctly as DTS, it should export to Collada without hitch.

#2 Cheers Manoel, I'll be looking into this over the next few days, great to get a headstart from someone in the know 8)

#3 No problems :)

BTW, Collada are much better to work when you have tons of nodes (mounts, hubs, etc) to work with, since they just export everything without need for .CFG files like DTS.

#4 Cool ! I didn't know that either !! ...Right, no .CFG needed.... 8)

#5 While the exporters might not support a second UV channel, the DTS format itself does. So the cached DTS the engine would create from such a Collada will then have 2 UV channels.

Pretty weird that none of the exporters support it.

#6 @Konrad: that's because the feature was added for the new DTS format used only for T3D, or you mean TGE-compatible DTS files?

T3D actually only loads DTS files, being merely capable of converting DAE to DTS by itself. However, this makes it much easier to extend and/or modify the DTS format: in the past adding a new feature would require all different exporters being updated to support it.

As example, someone willing enough could store IK constraints in DTS files if they wanted to.

#7 @Manoel: Yes, I meant the new DTS format, version 26. Thanks for the info though! I didn't know that DTS can be so easily expanded. That's very interesting.

#8 Hey All,

Okay so I've managed to get a wheeled vehicle exported using UV2 with a lightmap on there etc. Looks cool but the art process was pretty time intensive, mapping the second channel etc. and I've got very many mdels to try and get this extra polish into...You mentioned vertex colours being supported using the collada exporters. Is there anything special I have to do to export the vert colours or make them visible in the engine? ... I've coloured a few verts as a test, exported using opencollada and they're not showing up on the model..

Cheers

Harv

#9 @Harvey: Vertex colors are supported by the Forest Editor. Each color stands for a different parameter when the system animates a tree. See this thread for more information about that.

The engine itself does not display vertex colors - but the collada importer stores them. You might have to write your own shader feature to do what you want. It'd be another pretty cool way to lightmap an object.

Also, the defaulttree.dae model included in Torque 3D is a model exported with OpenCollada from 3DS Max by Russell Fincher. This is a good example for a model with vertex colors as I just learned myself. (Only on the highest lod meshes have colored vertices in the file.)

#10 Cheers Konrad!

Right, so I have to find out what to do with the shader then? I'll look at the tree stuff and see what I can find out...I'm no coder though so it'll have to be simple!

Call me crazy but if Torque3D can display vertex colours, and the exporters support them too, I think it would be really cool if it was really easy for us to use them. Maybe it is once I start digging a little deeper. It'll make all the difference though...

I don't suppose anyone knows if there are any areas of performance this could hit? I'd assume a vertex coloured model would be just fine, but just to make sure it doesn;t turn a 5,000 vert model into a 20,000 vert one or something?

Thanks for the very speedy reply !

#11 No problem.

I am not an expert at this, but I don't at all believe having colored vertices on all your models in your scene would cause a noticeable difference in performance. It should be just a little more data pumped into your gfx card. All the coloring would take place in the generated pixel shader code that uses your shader feature. As far as extra vertices go, it shouldn't increase your vertex count, no.

On one hand, it's a good idea to start looking at the Forest code and see how those parameters are sent to the shader. But you might also want to look at shader features (GameClay has a great tutorial on how to add your own) because if you'd want this to work with all kinds of objects and materials, then you'll need to create this as a new shader feature instead of just a shader.

Good luck, and let me know how that goes!

#12 @Konrad: T3D can display the vertex colors. There's a shaderFeature for them. You enable them by setting vertLit[0] to true in your Materials (it's just not exposed in the material editor). It works the same as adding a lightmap to your models, but using the vertex colors instead of a lightmap.

If you want to use vertex colors for something else other than self-illumination, then you need to write a custom shader feature. In the project I'm working on we added a feature to use vertex colors as ambient occlusion.

#13 @Manoel: Oh! Really? That's awesome!! Thanks so much for letting us know. I've been aching to see vertex colors all this week - been procedurally coloring my trees - blindfolded. How neat! Thanks again! :)

#14 Wow! That sounds cool...so in my material.cs should something like this work?

singleton Material(condortest_Con_Sail1_material)
{
mapTo = "Con_Sail1-material";

diffuseMap[0] = "scripts/data/condortest/images/Con_Sail1";
normalMap[0] = "";
specularMap[0] = "";

diffuseColor[0] = "1 1 1 1";
specular[0] = "0.9 0.9 0.9 1";
specularPower[0] = 10;
vertLit[0] = true;

doubleSided = false;
translucent = false;
translucentBlendOp = "None";
};

#15 aaahrgh! I just read your post again Manoel.

Yes, that's exactly what I'm trying to do, use vert colours as ambient occlusion instead of a lightmap...Does this mean writing my own shader then? As I say, I'm no coder and have no experience writing shaders...

#16 Manoel, would you feel like packaging up all of your fantastic shaders(all non-default T3D) and selling them as a package to people like Harvey and I ?

#17 I can confirm...Although this sounds dead easy, I've not managed to get anything to work just yet....Still trying....

#18 My vertex AO code only works in BL (since our game doesn't use AL), but this should be enough to get started:

In materialFeatureTypes.h, add:

DeclareFeatureType( MFT_VertexAO );

In materialFeaturesType.cpp, add:

ImplementFeatureType( MFT_VertexAO, U32(-1), -1, true );

In the function ProcessedShaderMaterial::_determineFeatures(), add this after the code block that deals with vertLit:

if ( !mMaterial->mVertLit[stageNum] && mVertexFormat && mVertexFormat->hasColor() )      
      fd.features.addFeature( MFT_VertexAO );

(It will only enable vertex AO if mVertLit is false, so you can toggle between both features)

I didn't actually write the new shader feature class: I just check if the feature exists to change the code generated in RTLightingFeatHLSL::processPix() and RTLightingFeatHLSL::processVert() (which is the shader feature for BL lighting):

In RTLightingFeatHLSL::processVert() before:

addOutWsPosition( componentList, meta );

I added this:

Var *inColor = (Var*) LangElement::find( "diffuse" );  
   if (inColor && fd.features[MFT_VertexAO])
   {
      ShaderConnector *connectComp = dynamic_cast<ShaderConnector *>( componentList[C_CONNECTOR] );
      Var *outColor = connectComp->getElement( RT_COLOR );
      outColor->setName( "vertColor" );
      outColor->setStructName( "OUT" );
      outColor->setType( "float4" );
      meta->addStatement( new GenOp( "   @ = @;rn", outColor, inColor ) );
   }

And in RTLightingFeatHLSL::processPix(), replace this:

LangElement *lighting = new GenOp( "float4( @.rgb + ambient.rgb, 1 )", rtShading );

By this:

LangElement *lighting;
   Var *vertColor = connectComp->getElement( RT_COLOR );
   if (vertColor && fd.features[MFT_VertexAO])
   {
      vertColor->setName( "vertColor" );
      vertColor->setStructName( "IN" );
      vertColor->setType( "float4" );
      
      lighting = new GenOp( "float4( (@.rgb + ambient.rgb * @.rgb), 1 )", rtShading, vertColor );      
   }
   else
      lighting = new GenOp( "float4( @.rgb + ambient.rgb, 1 )", rtShading );

To make this work in AL I think you'd need a proper ShaderFeature. I'd copy the VertLit feature and instead of overwriting the values in the light buffer you multiply.