Search

[Katazuro]

Hi Shawn,

Now that the importer seems to be running smoothly, I've noticed an issue with the exporter with models NOT decompiled.



Here's the situation: the model doesn't seem to capture light in-game or in-viewer and I'm really stumped because I've tried just about every method to see if this has to do with welding vertices or anything of the sort. I've narrowed this down to actual normals issues as illustrated above.

While exporting, I've tried all three options in the Normals dropdown with no real difference..



and even without bumpmaps applied, I recieve the same result:



Thanks!

[K@rt]

Its a little hard to tell from those pics but it does look like part of the back of the jacket the normals are lying down almost flat on the surface of the jacket. This is probably why those areas are rendering very black. Even the normals on the arm look oddly oriented towards the front of the model. Normals don't always want to be pointing directly out perpendicular to the surface, but as a general guide that is a good starting place.

Here is a polycount thread about resetting normals: http://polycount.com/discussion/133315/how-do-i-reset-surface-normals-in-3ds-max

[wallworm]

It does look like the normals in HLMV are not matching those in Max.

I know that you'll need to set the exporter to use Explicit Normals to get what you want. But if it's still failing, it can either be a problem in the model or a problem in WW. I know that the normals in WW Pro tests I've done lately are all as expected. I'll try to test WW free exporter this week to see if there is an issue. If anything, email me your scene zipped up and I'll test when I get a minute.

[Katazuro]

Thank you K@rt and Shawn, I believe resetting the normals did the trick (Edit Normals modifier), but I think the million dollar question you get, Shawn, is: what happened to the smoothing groups?

[EDIT] False alarm.

[Katazuro]

Here's the 2016 max file: https://dl.dropboxusercontent.com/u/15781683/irons_suit.max

EDIT: So I sort of found the solution, but I want to know how I can tackle this problem later on in the future. The original OBJ imported had 4 options (default 3DS Max importing) for normals, one being "auto". Choosing this normal option over importing the original normals exported fine ONLY if I set WWMT's export to "auto" as well... It seems this was the only combination that completely solved the issues with smoothing and normals. What's going on here?

I apologize for so much confusion. I'm still trying to work around the hoops of Max.

[wallworm]

I will explain how WW works:

Face Normals: This method ONLY accounts for SMOOTHING GROUPS. No modified or explicit normals are considered.
Explicit Normals: This method will account for normals taking into account smoothing groups and explicit normals
Auto: If there is an edit normals modifier on the object, use Explicit Normals; otherwise Face Normals

Generally, setting to Explicit Normals should work in all cases. It's not the default because it's considerably slower unless you have WW Pro installed. It was hard for me to think of what mesh configuration could cause Explicit Normals to fail, but after I downloaded the file I discovered the problem.

The transform of the root mesh was pretty crazy. Normally you want your mesh to have 0 scaling and to be aligned to the world.

A good transform is like this:

Code Select Expand

matrix3 [1,0,0] [0,1,0] [0,0,1] [0,0,0]

but the mesh here is:

Code Select Expand

matrix3 [0,-0.4,0] [0,0,-0.4] [0.4,0,0] [0,-2,0]

Note that the fourth set of numbers is fine (as the translation doesn't matter much) ... but the first three should always be normalized (where the x,y and z of each set add up to 1.0 or -1.0 exactly) If they don't, it means the object is scaled at the object level.

You can see an object's transform by selecting it and typing $.transform in the little pink MAXScript listener at the bottom left of Max and hitting ENTER.

I was able to fix this mesh by doing this:

• Open the Skin modifier and go to the Advanced Parameters rollout
• Save the Skin Envelopes to disk
• Click Utilities > Reset XForm with mesh selected
• Collapse the Model to Editable Mesh (because base was editable mesh)
• Apply new skin modifier
• Add all the old bones to this skin
• Open the Skin modifier and go to the Advanced Parameters rollout
• Load the Skin Envelopes from disk (that you saved above)
• Re-export with explicit normals

[K@rt]

Yeah, that's how they should be looking!

A Normal is basically a statement of how light hitting the surface will be be bounced off, and this determines how we actually see the surface - because when you "see" any object you are seeing light that has already hit it and is returning to your eye. Normal maps give the impression of increased surface detail by changing the angle that light hitting the surface on a pixel by pixel basis, BUT the normal data is a "child" of the vertex normal data, i.e. the normalmap normals will be added to the vertex normals.

On your model the normals on the back of the jacket were almost lying flat on the surface, maybe some were even going back through it, which meant the light was being reflected almost vertically up or down along (or through) the surface of the jacket itself.

This means when looking at it directly on those areas would appear much darker than they should... the majority of the light is NOT being reflected back towards the observer. You would probably find as you moved around you model in the viewer there would be certain weird angles where those dark areas would suddenly become lighter. Like I said, generally you want your normals to be sticking out perpendicular to the surface as close to 90 degress as possible... this can be a problem on right angle corners which is why lighting can be a problem around edges, is why you will often choose to chamfer edges, and is in those kind of situations where edit normals is useful, and is the reason Shawn came up with the ww normal tools as well.

Here is a really nice little tutorial/explanation about normals on polycount:

http://polycount.com/discussion/154664/a-short-explanation-about-custom-vertex-normals-tutorial

[Katazuro]

K@rt and Shawn, thank you! I very much appreciate you explaining everything. I ended up having to redo the envelope rigging because the envelopes didn't seem to transform along with the new mesh. I understand how the XForm works and its purpose - I can see why you, Shawn, are so adamant about its usage in these scenarios.

Now... I understand how you urge WWMT's use for creating new content, yet it's all I have to do the Source Engine work since Max 2012 and below are too buggy or unavailable. I didn't want to clog up with another thread, but I've been experiencing both importing and exporting errors related to skinning:



For any skinned hand model, the fingers never seem to import with its envelopes correctly, even with models that were never even decompiled e.g https://github.com/robotboy655/gmod-animations/raw/master/c_arms_citizen.smd. Now, decompiling a CS:GO character and importing it seems to retain perfect hand rigging.

Now, 3ds and compiled/exported models don't seem to match. Is this a WWMT bug by design or is it user error?



Note the first image being in-game while max shows smoother skinning on the coat.

Here's the scene as per usual: https://dl.dropboxusercontent.com/u/15781683/irons_suit_NEW.max

Thanks in advance

[wallworm]

There are two issue you show. It's possible there is a bug in WW, but I'd investigate these first:

1) With the hands, it's potentially just the envelopes are too large. Normally the envelopes should not matter if the vertices are weighted explicitly. When this occurs, it often means that either the SMD weights were incomplete or. See #2.

2) Generally, you only want your skin to allow 3 (and some versions of Source 4) bones per vertex. If the skin has this problem, you may need to go to the advanced parameters and bring down the bone per vertex limit. That way you can't accidentally have 20 bones affecting the vertex, for example, when Source will only allow a few bones to affect it. WW will not limit these for you--so if the SMD had more bones per vertex assigned to those vertices than Source is allowing, it can lead to this.

[Katazuro]

That has seemed to fix the issue; so many things I'm learning about the Max's interaction with Source!

As for the hands, I'm a bit confused. Seeing how the raw hands SMD was exported:

//Reference File generated by the Wall Worm SMD Exporter 1.47

and compiles fine without being reimported into Max (correct weighting), I can't see why the SMD would have been imported with incomplete weights. The "Rigid Vertices (All)" tickbox seems to remedy this on some hand models, but not completely.

This seems to be something going on with the importer because in past projects, hands/fingers would be exported flawlessly (this model was imported by OBJ and skinned by me).

[wallworm]

The importer may not be setting something correct in the skin. I'll look into it.

[K@rt]

I haven't tried it for a while but in the past I also would have some skin/weighting problems when importing certain models, tbh it has never worked 100% perfectly for all models. Some models would work fine whilst others wouldn't, and oddly I would sometimes get different results depending on which version of Max I was using.

Historically, the whole Source model decompiling and importing has always been a little bit unreliable, a problem which has only gotten worse with more and more engine versions, game variations, DMX files etc. It seems to effect rigged characters or weapons models more than anything else, but that makes sense as they are generally the most complicated models a game will use, having the most variables/parameters... if just one of these gets mis-translated between the mdl/smd file and Max it is likely to throw everything off.

If you happen to still be running Max2012 you can try using Wunderboys importer instead until Shawn gets a chance to look at it, or try importing with WW in different versions of Max if you have them.

I sympathize though, I have suffered frustration in the past because it has turned out to be completely impossible to get certain game models into Max as a correctly rigged object.

[Katazuro]

Haha, it just strikes me how the SMD format is so well-documented yet Mario and Shawn have been the only ones to work on an importer  :-\

But then again, I appreciate everything.

[wallworm]

Fun Fact: WW's SMD Importer actually started as code donated from MarioKart on Facepunch. I did revamp it over time to suit various aspects for WW. Although I don't expect to leave it untouched, be happy that it's even here as is :) --I never had much motivation to work on importers much. But so many users want the importing tools, I've tried to make the community as happy as is feasible within the restraints of my time and goals.

[Katazuro]

I remember the moment I heard I'd be able to work with Max 2013 again by using WW after Max 2012 officially pooped out on me
That being said, expect a little donation! :D