4 réponses à ce sujet

[DarthParametric]

I gather this might be something a dev will need to answer, but does anyone have any idea how to generate "meta data" for custom models? When using custom models in the level editor, I get the following when trying to render light maps: "Could not find meta data for [model name]" and "No render targets found - no job submitted".

I haven't seen anything obvious in example MMH.XML files for a vanilla game floor model besides CastRuntimeShadow="1" CastBakedShadow="1" ReceiveBakedShadow="1", which I added to my model's MMH.XML before compiling. There was no change though. I also changed the MAO to replicate one of the game's tileset pieces as follows:

<Material Name="Static.mat"></Material>
<DefaultSemantic Name="Default"></DefaultSemantic>
<Texture Name="mml_tDiffuse" ResName="texname_0d.dds"></Texture>
<Texture Name="mml_tNormalMap" ResName="texname_0n.dds"></Texture>
<Texture Name="mml_tLightmap" ResName="LM.dds" RequiresID="true"></Texture>
<SoundType Name="mml_iSoundMaterialType" value="13"></SoundType>

But again, there was no change. The level editor still complained about a lack of meta data. I also get the same thing when I edit one of the vanilla model's MMH and PHY to use a different model name, so I assume that there must be a database somewhere that uses file names. Linked to the RequiresID="true" line above maybe? I looked through the 2DAs and some of the XMLs, but I couldn't see anything obvious.

Modifié par DarthParametric, 01 janvier 2010 - 08:48 .

[ChewyGumball]

The reason why it won't change is because there isn't a second set of texture coordinates in the msh file. That second set is required for the static material for the lightmap to work. I don't think the meta data is a significant problem atm, it might later when more complicated models are needed, but the render targets is a definite problem.

I have been looking up more on lightmaps, and it looks like they used a render to texture to create the second set of texture coords used for them. This requires a light though, so my additional question is where was this light placed, and what were its properties? I would think that custom lighting every model would require too much work to be worth it, and so there was a standard lighting setup. I would think a single skylight would be sufficient, but if something more complicated was used it would be nice to know what that setup was.

[CyrNoodles]

I also have this meta data problem with custom models/textures. Lightmapper works but spreads horrible shadows, making the map ugly.

Anyone knows how to solve this issue ?

[BioSpirit]

I just ran into this problem.  About what meta data it's whining about ? Is it the MMH or something else ?

The problem is: Without meta data Lightmaps won't render for a custom models.

ChewyGumball wrote...
The reason why it won't change is because there isn't a second set of texture coordinates in the msh file. That second set is required for the static material for the lightmap to work.

A second set of texture coordinates for a lightmaps would make sence. But how does it identify which one because both sets are labelled the same way. I would understand it much better if the second set would be labelled like "LMCOORD" instead of having two sets of "TEXCOORD"s.

ChewyGumball wrote...
.....This requires a light though, so my additional question is where was this light placed, and what were its properties? I would think that custom lighting every model would require too much work to be worth it.

Are you talking about unwraping the UVs for lightmaps or something else ?

If the second set of TEXCOORDs are used for lightmaps, then the triangles shouldn't overlap eachother. And in that case the second set would be invalid in my model. I just took a copy from the first set.

Modifié par BioSpirit, 23 janvier 2010 - 11:53 .

[tmp7704]

BioSpirit wrote...

A second set of texture coordinates for a lightmaps would make sence. But how does it identify which one because both sets are labelled the same way. I would understand it much better if the second set would be labelled like "LMCOORD" instead of having two sets of "TEXCOORD"s.

Each stream of data in the binary .msh file has a field GFF_MESH_VERTEXDECLARATOR_USAGEINDEX. The value of this field is typically 0, but if there's more than one stream with the same type of data --like 2 sets of UV coordinates-- then this field is set to 0 for the first stream, 1 for the second and so on.