KatsBits Community

[UDK] Blender UV problems

ward · 45 · 40209

0 Members and 3 Guests are viewing this topic.

Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
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


Offline ward

  • Newbie
    • Posts: 33
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.


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
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.


Offline ward

  • Newbie
    • Posts: 33
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"?


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
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).


Offline ward

  • Newbie
    • Posts: 33
They will always be used together though, never for backgrounds etc.


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
If the textures/material don't have any special effects applied then leave them as a unit in that case, because yes, although you do have meshes that use a few materials, you're essentially reusing both the texture and 3D assets, it's not like each building has it's own set of textures - that's really where this over-rendering causes problems. In other words so long as you 'instance' them in some way you're off-setting the render load.


Offline ward

  • Newbie
    • Posts: 33
... it's not like each building has it's own set of textures - that's really where this over-rendering causes problems.
Well these are temporary testmaterials, eventually there will be per house textures, however only about 5-10 sets that will be re-used randomly, so the houses will look unique.


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
In that case your use of temp textures now should reflect what you intend to do later so all you need do is swap them over thus avoiding any reworking/building of the assets and/or reduce the possibility of unforeseen problems.


Offline ward

  • Newbie
    • Posts: 33
How is this best done by the way? Unique materials for multiple instances, almost finished with unwrapping the models.


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
You just use temp textures of the same number and proportion (size doesn't matter as such) as your finals. The pictures on the previous page are simple checkers for example, you can use several of those - they have the same file name as your final assets, so "wall.tga", "beams.tga" and so on. All you then do save over those when you're done and/or re-import them into UDK.


Offline ward

  • Newbie
    • Posts: 33
Yeah i know that part, but do i need to copy the mesh a bunch of times and assign diffrent materials, or is there a better way? (Since, ideally the geometry only needs to be loaded once.)

By the way I didn't mention yet that the models come from sketchup 8 (exported as collada), material slots get exported too. So I just assign a diffrent color for a diffrent material in sketchup, blender imports this, and in UDK I assign the proper materials. This works pretty good for tiling materials, and when I need it for aligning I just add an image in blender. Of course I also unwrap them in blender, and further distort them to make them look older. I'll post a decent screenshot with testmaterials sometime.


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
Thought they might be SketchUp models  ;)

Anywho, to answer your question.. if I'm understanding you correctly it depends on what you're going to do with the models. The screenie you posted previously shows 5 different versions of the same type of house so what you could do is have several sets of all five houses, one set is 'red', another 'blue', yet another 'green' and so on, that way you're at least minimising the texture over heads by using each asset repeatedly.

You could go one step further and break the models up as per what was discussed above as that would reduce overheads even more by only changing the outer texture set, so even though you had 20 or so houses in a map for each 'set', the innards would all be the same (relative to their being a set).

The alternative is to mess around with UDK's shader settings, iirc you can edit specific instances of meshes in the editor so although you could have the same model loaded a few times each one would be slightly different because of the additional node work applied to it. Ah here it is...

http://udn.epicgames.com/Three/MeshPaintReference.html - Mesh Painting (essential reading)
Also bookmark this forum on Polycount, a lot of the guys posting there are professionals using UDK/Unreal tech


Offline ward

  • Newbie
    • Posts: 33
Do you mean I could make one set of materials, but paintable, so I don't need to copy the models? Just to make sure I understood correctly. I already knew about vertex painting, one of my materials already is paintable :).


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
Depending on how complex that vertex painting can get, yes you might potentially only need one set of houses and one set of textures, you then use vertex painting to make each model look unique even though they're not. I'd do some tests first, make *one* model and fully texture material it then spam it around a test map and see how unique you can make that one item. If the results look OK then you know you're going to be OK doing that to all of them.