id Tech Forums

Yeah at a guess something else is being done with the switch to 2017 that's not being properly declared. If there wasn't a specific reason for upgrading to 2017 I'd agree on using 13 or 15, at least that way you know there isn't necessarily a core source issue..

The error refers to it as a "class" so it'll likely be declared in a file rather than being one. The "io" part looks to be input/output. Can't say much beyond that unfortunately as I'm not running the same specs as you so likely not seeing exactly the same data (a quick source search didn't ping anything up for me).

Don't know if this helps but if you look at _iobuf at line 3644(?) does it list _file as a property or function? If it does, that error appears to point to an undeclared association somewhere, so you'll likely need to add "_file" to something or remove it.

If you figure it out remember to write up what you did this time! lol

What's the full error "C2039: Class is not a member of Namespace" or similar? Most resources suggest something is missing or there's a circular logic going on - file A refs file B, file B refs file A.

Yeah that's the one, you need the two elements in the material/shader which is why it won't work on it's own. Only ever noticed it on LWO but good to know it does work for ASE also.

Don't quote me on this as it's been a long time since I looked at that particular command but IIRC it only works with LWO models because it's tied to the Maya 'bake' commands often still seen in the *.mtl files - its original purpose was to smooth tangents across mirrored models (again IIRC).

@OP: If terrain models are causing particular problems with collision/AI the way to work around the problem is to block out your expected path using brush volumes manipulated into shapes the AI can use and then export this for work in a 3D app - the 'path' is minimally edited or changed, the terrain built up around it. Once imported back into the editor the model will sit exactly over the top of the previously prepared brush 'path' the AI should be able to follow.

Ah right.. mesh splits create physical breaks or holes in the mesh, forcing light/shading to adhere to what such splits define, hard/soft edges. Normal map images over-ride or utilise these splits depending on their being uniquely baked or tiled textures - unique normal maps over-ride because they're high-res versions of the same object, tiled don't because their purpose is to represent 'surface' detailing not an 'object' relative data.

(note: baked normal maps don't actually over-ride, it's more correct to say such mesh objects don't need forced splitting if the object uses uniquely baked normals - if splits exist they tend to adversely affect the appearance of the object because they supersede smoothing based on normals)

A wooden table for example can be mapped with a unique normal map baked from a high-res version of the object. In such instances the normal map defines smoothing/shading (and optionally surface detailing). Mapping the same object with a tiled 'wood' texture however, doesn't work as all that provides is surface detailing, i.e., wood grain. Left in it's raw state this latter approach makes the object appear mushy because the normal map is not providing *object* relative smoothing information (normal orientation as you mention), the mesh is. In such instances it (the mesh) would need to be manually split to define edges and break the uniform surface continuity.

The upshot is that splits tend to be required when models are covered with tiling textures, but not if they are using unique baked data. And yes, the split is caused by a surface break and duplication of vertices along the break - which is what's shown exactly with the pics you've attached... that's the expected behaviour from that arrangement.

You mean this? Briefly... smoothing is about surface continuity, the way light and shadow/shading is distributed across a mesh. Managing smoothing is essentially about breaking this continuity into manageable sections to give the impression of hard edges. This can be done using 'splits' (ASE) or UV map sections (MD5).

@kordex: if it helps I can send the mesh/blend file. Just ping me on info[at]katsbits[dot]com

In case this is still outstanding (and for the archive) the model viewer is indicating a split in the mesh, either as a result of a UV split or mesh (smoothing) split.

Yes I saw that... lol 

@kordex: See attached (the UV are shifted to one side to reveal the underlying texture in the B/W shot).

@motosep: just using the script kordex posted in OP (suits what I'm doing).

What's the status on this exporter? Just trying to get something to export in 2.77a and whilst mesh and anim export, the objects UV's are all over the place and nothing I've tried has fixed it (deleted, rebuilt, flipped, split etc.). There is still interest in a simpler export script like this BTW even though there are a number of other more complex ones available (the only thing it could do with is selectable export rather than exporting the contents of the Scene, other than that, there is demand/interest in it).

Yes, tiz I.