collapse

Author [EN] [PL] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Mesh normals and active faces, texturing issues.  (Read 274 times)

Offline Norrwin

  • Neonate
  • **
  • Posts: 85
  • Reputation: +1/-0
Mesh normals and active faces, texturing issues.
« on: May 18, 2020, 05:23:54 PM »
Disclaimers, as I am sort of new to modeling all this is new (and exciting) stuff to me so forgive me if this is common knowledge. Also because of my relative ignorance on the subject, some of this will be incorrect/incomplete.

Some of the VTMB models (MDLs) have textures that face inward instead of outward so when you look at the model the textures appear to be missing. However, if you noclip into the model and look out you can see these "missing" textures.

Not knowing too much about modeling I looked it up on the internet and the common answer was that flipping the normals would flip the texture, and it did... but only in Blender. When the model was exported nothing is changed even though I exported the normals. Which was really confusing for me.

Digging further into this I found on the Valve Developer Community Wiki Studiomdl Data page, (after lots and lots of mucking about):

Quote
Triangles
A triangle in a model is defined by three vertices. Included in each triangle is its UV co-ordinates and envelope weights.
Note:
Source's triangles are one-sided. The active face is the one around which the vertices can be traced clockwise.

So the vertex order defines the active face, not the face normal. Since kHED edits SMDs maybe it knows about this? Well yes it does! The option is under "Edit > Reverse Vertex Order" and indeed it flips the texture both inside kHED and in the SMD. The problem is I don't know how to compile from the SMD to a MDL, unless it is a static model (no animations).





What does reversing the vertex order mean? Comparing the two SMDs from above it seems that it means swapping the last two lines and recalculating the vertex normals after the swap.





The normals that get exported with the Blender tool are the vertex normals which don't help with our problem:

Quote
A vertex normal defines the "front" of that vertex, determining among other things how much lighting it receives from a given angle.

So is it possible to reverse the order of the vertices in Blender like in kHED? Well yes, no, maybe... I don't know any builtin menu functions to do it but maybe it is possible to write an Python addon to implement one.

To that end I opened the Python console in Blender and started hacking away. And yes I can get the data but the data I got was read only so I couldn't change it. I'm sure there is a way to change it but this is where my journey ended as I decided I should move on to things I actually know how to do. Maybe an addon to do this already exists, or maybe one that is close could be adapted to do this, I never got  that far either.

For the Python script I selected two adjacent faces, meaning I should get two shared vertices, then looped over all the faces until I found the ones that were selected and printed out the vertex info for them. The triangle number is just the index of my search loop, the first set of vertex data is the vertex x,y,z position, the second the vertex normal vector/position, and the last integer is the Blender index to the face (I think).

Code: [Select]
Triangle: 430
vertex data 0:  [MVert (0.011890 -4.993988 68.900497) (0.000000 0.999969 -0.001648) 2952]
vertex data 1:  [MVert (0.011890 -5.027689 68.634201) (0.000000 0.992065 -0.125523) 2951]
vertex data 2:  [MVert (-0.339110 -4.899389 68.589401) (0.130528 0.990112 0.050935) 2947]
Triangle: 431
vertex data 0:  [MVert (-0.371010 -4.924189 68.847603) (-0.007508 0.992035 0.125584) 2946]
vertex data 1:  [MVert (0.011890 -4.993988 68.900497) (0.000000 0.999969 -0.001648) 2952]
vertex data 2:  [MVert (-0.339110 -4.899389 68.589401) (0.130528 0.990112 0.050935) 2947]
done

Offline Wesp5

  • Administratrix
  • Antediluvian
  • *****
  • Posts: 6670
  • Reputation: +885/-28
  • Unofficial Patcher
Re: Mesh normals and active faces, texturing issues.
« Reply #1 on: May 18, 2020, 05:45:52 PM »
Some of the VTMB models (MDLs) have textures that face inward instead of outward so when you look at the model the textures appear to be missing. However, if you noclip into the model and look out you can see these "missing" textures.
I hardly understood what you wrote, because I know little about models, but can you give examples of models with textures inside? I never noticed some in-game...

Offline Norrwin

  • Neonate
  • **
  • Posts: 85
  • Reputation: +1/-0
Re: Mesh normals and active faces, texturing issues.
« Reply #2 on: May 19, 2020, 12:44:47 AM »
An example would be LeCroix's chair. I always knew the right armrest was "off" somehow but until now didn't know why or what the root cause was. The left armrest has the textures applied properly to the outside but the right one has the textures reversed and applied to the inside.

Offline Psycho-A

  • Russian Board Moderator
  • Methuselah
  • *
  • Posts: 291
  • Reputation: +31/-1
  • Bloodlines SDK developer
Re: Mesh normals and active faces, texturing issues.
« Reply #3 on: May 21, 2020, 06:19:52 PM »
Hi Norrwin!
What kind of MDL decompiler are you using to get your SMD files with these issues?

Offline Norrwin

  • Neonate
  • **
  • Posts: 85
  • Reputation: +1/-0
Re: Mesh normals and active faces, texturing issues.
« Reply #4 on: May 21, 2020, 08:22:29 PM »
Hello, I just want to say I am really enjoying using the SDK!

I am not using a decompiler, the issues exist in the original game files, models/scenery/furniture/chair_executive/chair_executive.mdl for the example. I'm trying to convert them to X files and import into Blender to work on them. But when I do use a decompiler the only one I have ever tried is Crowbar from SDK v1.93.

For the issue you can either look at the chair in LeCroix's office (or wherever else it exists in-game) or open it in HLMV, in HLMV it may be easier to see if rendered flatshaded. Either compare to the left armrest or compare to chair_executive_ruin.mdl which oddly enough does not have the issue (but had different geometry as well). This might be a poor example but it it the easiest one to understand, my real issues are with models using animations which is also why I'm trying to use Blender.

The SMDs in my post are exported from kHED just to test what the "Reverse Vertex Order" command did, they were never compiled or used for anything. They match up to the image of the cubes, left is texture on the outside and right is texture on the inside.

Offline DDLullu

  • Neonate
  • **
  • Posts: 90
  • Reputation: +208/-1
Re: Mesh normals and active faces, texturing issues.
« Reply #5 on: May 22, 2020, 06:14:08 AM »
You just find a new bug for the patch, usually a $nocull 1 in the vtm will correct that. Take a look at the picture below.

Offline Wesp5

  • Administratrix
  • Antediluvian
  • *****
  • Posts: 6670
  • Reputation: +885/-28
  • Unofficial Patcher
Re: Mesh normals and active faces, texturing issues.
« Reply #6 on: May 22, 2020, 08:03:53 AM »
You just find a new bug for the patch, usually a $nocull 1 in the vtm will correct that.
I corrected that myself and it was all that is needed to make this hardly noticable issue go away :). So if you know any others, Norrwin, please post them!
Also DDLullu, while you are here. Do you think it is possible to change the Lone Wolf ending cutscene model so that Damsel could be included instead of that Brujah player model? The models are models/cinematic/LA/Streets/End_LoneWolf.mdl and models/cinematic/LA/Streets/End_LoneWolf_female.mdl.
« Last Edit: May 22, 2020, 08:17:03 AM by Wesp5 »

Offline Norrwin

  • Neonate
  • **
  • Posts: 85
  • Reputation: +1/-0
Re: Mesh normals and active faces, texturing issues.
« Reply #7 on: May 22, 2020, 10:05:12 PM »

You just find a new bug for the patch, usually a $nocull 1 in the vtm will correct that. Take a look at the picture below.


Yes it turns out $nocull 1 is a workaround for this. I found out about $nocull command two days ago and was trying to use it on some hair but it never worked for me so I never thought to try it here. Now I am thinking I might have made a bad spelling in a path or file name, maybe I should go revisit that experiment  :chinscratch:

I corrected that myself and it was all that is needed to make this hardly noticable issue go away :). So if you know any others, Norrwin, please post them!


If it is hardly noticeable is a subjective thing, having invested countless hours understanding the problem, the root causes, and the solutions I am very emotionally invested so I think it is a big deal  :grin:


I did go through the UP files I have and all the other instances except this one seem to have some sort of workaround, if I had to guess I would say by MooCHa as I saw his name associated with one of the fixes that had model edits.

 

SimplePortal 2.3.7 © 2008-2020, SimplePortal