Game Editing > General Content Creation

[UDK] Blender UV problems

<< < (7/9) > >>

kat:
Good to see you're finally getting the results you're after, it's often a case of just playing with what you're doing to find the best solution, so if *.fbx are working ok then stick with that as UDK is supposed to have better support for that format. And yes, the ASE script to 2.57 is still WIP so it'll cause problems whilst it's being finalised (and yep, that's me over there as well ;) ).

With regards the materials, it's sort of correct. If you imagine what UDK is doing when its rendering a mesh it's basically pulling in the entire asset (everything associated with the model - mesh, materials, shader effects etc.) and rendering it in 'layers' or 'passes'. First you have the mesh (the wall object, or fountain and so on) and then the materials, then the shaders and effects and so on. Each 'layer' of data requires the renderer to 'parse' it, so yes, if you have seven materials on a mesh the rendering engine is pretty much looking at that object several times, reading each individual material with a view to render them based on where they are on the mesh. If each material has a shader that's a further seven passes being made.

This is why UDK makes more extensive use of 'unique' textures where everything on an object is mapped to the one image, it's only doing a single pass to render those types of objects. Tiled or reused objects differ because although it means the renderer is loading in more assets, those assets can be reused and kept in memory.

Incidentally, this is why polycount isn't always the cause of bad performance

ward:
So is it best to make a component for each material, and export it that way? These are models that will be used a bunch of times (so I ticked "Used For Instancing" in the static mesh editor). Everything so far uses tiling materials in UDK.

kat:
It depends really. Ideally what you should be looking to do is making sure that each house is a compact unit in of itself so that as a group they're all using the same materials, that then offsets the repeat parsing to process the multimaterial assigned to each model - even though you have several *objects* instanced around a level, they all use the same two ot three materials. So no, you don't really need to break the models up into per-material segments, certainly not for those types of objects.

ward:
Well outside and inside have diffrent material slots, so in total most have 6 or 7 materials, i could for instance split them up once, so i got the outside and inside so each has 3 to 4 materials, and then it would remain more or less manageable/pratical in UDK. (Although most practical is to not split them at all.) Maybe this would be a good "middleway"?

kat:
Ah yes, that's what I'd do, separate them into 'inside' and 'outside' units, that way you can spam each element without necessarily having the overheads associated with rendering everything when not necessary (background scene objects for example, players can see but can't interact).

Navigation

[0] Message Index

[#] Next page

[*] Previous page