[FIXED] DMX Subsurf problems and [FIXED] VTA random normals

[Keepon]

I wasn't sure if post this as bug or feature request, make thread for each single one or put them together, but here we go.

I made character in Blender and successfully exported via your's exporter.
But, sometimes, after compiling SMD/VTA and applying all flexes at once(in HLMV or SFM, it doesn't matter), some random vertices rotate their normals. It happened to me twice and only on 2.x (maybe on 1.9.x or 1.10.x too, but I'm not sure) after removing some verts on model glithced all shapekeys redoing them using "Shape Propagate" and snapping verts manually to a working copy. I can't remember if rotating normals is possible in Blender.
EDIT 2015-01-18: 'Trianguate modifier' needs to be set at either 'Fixed' or 'Fixed alternative' quad method to avoid bug.


At some point I wanted to try DMX but exporter produces some errors when I try to export with not applied but active "subsurf" modifier.

1. Exporter throws "x verts on 'mesh_name' have over 3 weight links". On SMD export, that warning/error never shows up, even if non-subdiv mesh never go over that limit.
From what I tested, this is because of how subdivision surface modifier "smooths" weight maps over new vertices. SMD exporter somehow limits max "weight links" to 3, while on DMX it shovels all weight data through.
EDIT 2015-01-18: 'Weight Link Cull Threshold' was added 2.2 to fix this problem

2. I wanted to try the '$subd' QC command at some point, but it needs quad only mesh. Exported DMX with ends up being triangulated. The only way to prevent this(at least for now), is to apply subsurf, which I don't want to.

I am currently using exporter version 2.2.0beta from this thread
here's model with problems http://www.pasteall.org/blend/30828 (qc should be included, in text editor)

...gosh, my Engrish is bad :V
EDIT 2015-01-18: edited to add all solutions found in thread

[Artfunkel]

1. This is a limit enforced by studiomdl which isn't present for SMD. There's no getting around it.

2. The exported DMX isn't triangulated (check by importing it), but studiomdl will do that. Perhaps you have some tris hiding in your model? Seems a bit weird that the mesh has to be 100% quad BTW...

The shape normals thing may be a bug with the engine. If you can reproduce it with a single shape active let me know, otherwise it's probably not my problem. :)

[Keepon]

1. it could be nice to have some kind of limiter/normalizer on it. But, if it's not possible, then okay. The only way left will be to strategically weightpaint the mesh, so 'subsurf' wont smooth vertex groups too far ._.

2. hmmm... strange... now it's working... idk how that happened then... ._.
"quad only" is only required by $subd. it's kinda new discovery from facepunch
It allows to subdivide models within Source.

I have spent about month overall to remove/collapse/kill all tris/ngons, i didn't test it yet :v

3. verts rotates slighty on every single flex, but it is most visible on all of flexes active
http://imgur.com/yP0qdEp http://imgur.com/LrCWhIE
it only happens on smd - no matter if subdivided or not, dmx is not affected by that(at least on non-subdivided mesh, i can't compile higher one, because of bones per vert limit)
I can send you smd/vta or compiled model if you need it

[Revzin]

Hey Artfunkel

1. studiomdl just silently discards extra weight data with SMD and I've been bitten into the ass back in the times ("why wouldn't this bone work?!")
With DMX it gets angry.

The problem here is that we usually have a mesh with a subdiv modifier and subdiv doesn't care for weight limits, and when BST bakes this into a DMX studiomdl gets angry.

The workaround is apllying subdiv on the mesh and then doing Limit Total in Weight Paint but doing this every time the mesh is changed means we have reduplicate and and re-apply and limit vertex groups and re-export yadda-yadda-yadda and this is painfu or really painful, cause we can't apply modifiers on meshes with shape keys

So, the feature request is to do Limit Total when baking a mesh

2. True about $subd, it wants all-quads and also gets angry at some polys:
http://screenshot.su/show.php?img=02e85a116cb989a5dd5446b16319afdd.jpg

[Artfunkel]

I've added a new scene option that enables culling of weight links below a given strength. I didn't use Limit Total itself because it only works on weightmapped meshes (the Tools also support subsurf, text, envelopes etc.) and because it deletes all excess weight links regardless of their strength.

[Revzin]

Thanks a lot, this is great!

[Artfunkel]

Incidentally, the limit in Source 2 is four weights per vertex. The new model compiler will truncate anything over that automatically (and actually tell you that it's done so!).

[Keepon]

Sorry for bumping the thread, but that "random vertices' normals rotating on flexes" bug has appeared again, in slightly different form than last time.


Last time it rotated normals of fixed amount of vertices in same random places of every flex. It happened randomly at exporting, so it wasn't that annoying (and catchable i guess).

Now, quite recently it started to rotate normals of those vertices, which are moved by flex. It happens on every export I made, independently of what model I try to export.
example: http://imgur.com/6vtXjqI (slighty nsfw i think).

It happens only on .smd/.vta

I've tried to:
- export model on another computer with same .blend file - same result on compiled model.
- export model on another computer imported from .dmx and .fbx file - same result
(both on clean version of Blender 2.72b with addon version 2.3.0 and 2.3.1)
- recreate model vert by vert, face by face plus all shapekeys (thanks to Snap function and F2 addon) - it still rotates normals, but in different directions than on original model

I'm not sure anymore, if there's some 'hidden' transformations going on before addon touches the model, or if it's studiomdl doing some magic, or addon fails to do something... or my pc is haunted and tells me to drop .smd format and forces me to use .dmx :/


I can send .smd/.vta, compiled model or .blend file if needed.

EDIT: I've tried to dig in exporter's code myself, but the only line of code that somehow affected flexes was

export_smd.py
1060.            calc_norms(shape) 

After commenting that line, when activating one flex, normals rotates on nearly every vertex possible giving quite nice looking pattern(example: http://i.imgur.com/mLEYTUw.png )

Also, after importing .smd/.vta back to Blender (can't find any other program allowing importing .vta), I get "Warning: 317 VTA vertices (0%) were not matched to a mesh vertex! An object with a vertex group has been created to show where the VTA file's vertices are."
Those "Unmatched vertices" seems to be in correct places when comparing against mesh...

[Artfunkel]

I've discovered that the order of vertex loops can differ between the original mesh and the baked copy of the shape. Try this download[steamreview.org] and see if it fixes anything.

Your two findings above are expected. Not calculating the normals leads to them all being (0,0,0), and the mismatched verts are common with VTA. Use DMX!

[Keepon]

well, looks like normals are fixed, but now some vertices' position got a bit scrambled
video: http://www.youtube.com/watch?v=_gzddkesozY
picture with activated flex: http://i.imgur.com/V4Dxelj.png

and yes, after little over 2 years of stable .SMD usage, it's time to switch to unknown (at least to me) waters of .DMX format ...
... after that one vta bug will be squashed, ofc

EDIT: I've updated thread's topic to mark what's fixed

[Artfunkel]

This isn't going to be an easy fix at all. The issue appears to be that the triangulation operator gives one result when two faces are connected in a convex manner and another when the connection is concave. That is exactly the change that the shape you're trying to export makes.

This also explains why DMX is unaffected: it supports ngons, so no triangulation is performed.

So yeah, use DMX! :)

[Keepon]

Okay, time for DMX then :V
I got an idea for workaround, but 'till I'll learn Blender's Python stuff, let's just leave it as is

For now, I'm marking vta as "unfixable" (you can change it later to whatever you want I guess).
But thanks for all help so far :D

ps. I'll miss ya .VTA

[Artfunkel]

There are two fixes that I can think of.

The first is to triangulate before splitting shapes into separate objects, but that's a bad idea as it can lead to drastic changes to the output (e.g. per-face dupligroups).

The other is to recombine all of the shape objects to one mesh after triangulation, then split them off into separate objects again. That should work, but would make exports considerably slower. Given that this is an edge case in a legacy export format, I'm not happy about that prospect. I may experiment with it and see how bad the slowdown is though...

[Artfunkel]

Have you tried using the Trianguate modifier? There might be a setting in there that fixes this problem.

[Keepon]

tbh no, but I'll try it tommorow.

[Keepon]

Well, just to think the easiest solution was the hardest to find :V

Default setting for Trianguate modifier's 'quad method' is 'Shortest Diagonal' that works exactly as you described few posts ago. 'Beauty' method gives nearly same result.
On either 'Fixed' or 'Fixed alternative' method those bugs went away.
Tested on both 2.3.1 and 2.3.2b1 you have posted.

I made some googling and find out that, according to Blender's API Documentation[www.blender.org] 'quads_convert_to_tris' operator (which is essentially 'Trianguate modifier' and is used when no active 'Trianguate modifier' is found on model) defaults to 'Beauty' quad method and gives errors on model's .vta.

tl;dr: Looks like Trianguate modifier on right settings fixed problem for good

As you already suggested, I've switched to .dmx, so let's just hope that bug will not show up on .dmx too :)
Thanks for help.