What happens if you compile that model as a non-static prop model (and/or disable per-vertex lighting calculation for the model in some other way), then re-compile the map?

When disabling per-vertex lighting, it makes no difference. Also have the prop as a non-static prop made no difference either.

Only a suggestion...
Check inside your model for hidden faces. You may have joined a couple of opposing verts creating faces inside the mesh..

Edit, also check for non manifold vertexes, you may have disconnected doubles.

Originally posted by Pte Jack:

Only a suggestion...
Check inside your model for hidden faces. You may have joined a couple of opposing verts creating faces inside the mesh..

Edit, also check for non manifold vertexes, you may have disconnected doubles.

When using the edge split modifier, you are splitting the two vertices at 90°. So you would effectively have non manifold vertices at every sharp. I don't know of any other way of creating sharp edges on a model.

Correct...

to fix the problem, remove your edge split modifier(or turn it off), check your original mesh for doubles and internal faces and incorrectly connected vertexes. Clean up the mesh then reapply your edge split. Re-export and recompile.

I'm working a similar problem here with the roof on this train locomotive. I created the problem while indenting the ribbing using mirror and edge splits modifiers and applying them. It really pooched things up. LOL

https://i.imgur.com/U6nT3vP.png

Hmm, it didn't make any difference.

To be honest, there were no strange vertices out of position like the image you posted. Everything look pretty normal and how it should look in the model viewer in Blender. The normals are fine and facing the right way. There were no doubled vertices or anything like that.

I just don't know why the model is being lit this way.

Closer view of the one of the problem areas
https://imgur.com/ekUdyPQ

So it seems that every quad face gets split into two tris(s) and from the strange lighting after the compile, it seems that only one tris gets lit while the other one stays in shadow. I have no idea why it keeps doing this!!?!?

When you compile, Studiomdl optimizes the model and it tris it. (which is why imported decompiled SMDs are always triangled mesh.) Have you tried triangulating the mesh before exporting it?

(in Face Mode, Select all faces and then use the Quads to Tris function in the Face Menu option)

What does that exported SMD/DMX look like if you re-import the export back into Blender?

Also, try the recompile after converting quads to tris.

I was using the Triangulate module to turn my Quads into Tris(s) before exporting. I found that it minimised the potential for BadVertexData. So I was already tris(ing) it :)

Very strangely, it would seem that the process of the Source Blender exporter, where it converts the model to a .SMD, automatically marks sharps. I imported the .SMD back up into Blender and oddly enough, it seems to have marked a load of new sharps. It seems to be doing it randomly along flat faces.

Left Original | Right Imported
https://imgur.com/QDuDCkj

Hmmm... have you tried doing this with Blender 2.79 to see if it does the same thing?

You can't open a Blender 2.80 .blend file in 2.79, but you can append the model from the 2.80 .blend into 2.79. You may have to remove doubles to get it back to the original state then add your edge split modifier.

If the problem seems to go away when using 2.79, you might want to move this into the Bug report section here. I know that Artfunkel is actively investigating and trying to fix the problems the 2.80 update has caused and this might be something he needs to look at (especially with 2.81 sitting in the wings). But keep in mind he is pretty swamped with other "major" issues.

Okay, gave that a go. Sadly, it has made no difference.

I have no clue what is causing this issue. I am pretty sure my technique for creating the model is fine (and to be honest, it isn't a particularly complicated model). I do not know whether this could be a .VMT issue, or whether is it a problem with Blender?

have nothing to do with materials or textures if the sharps are being created in both 2.79 and 2.80. It may be your modelling process.

Create your model. Leave it as quads, add your modifiers, but don't apply them before you export. Export your model and let Blender Source Tools and Studiomdl do the work with the modifiers. Try a compile. See if that fixes your problem.

One other thing to try, Select the object in Object mode and check the Object Property Panel, see if Auto Smooth is active, If it is, uncheck it and try your Export/Compile again.

Sorry, that should have been the Context Property panel (the old Vertex panel, looks like the inverted triangle) under Normals....

Still giving me the same results for both of those suggestions.

I'll post the Crowbar.exe compile log just in case there might be a problem there.

Compile log

Compiling with Crowbar 0.34.0.0: "**\****\******\*******\My Materials & Models\rks_materials_models\low-poly\Blender\models\props_lowpoly\RK_LowPoly_Stone_Fireplace_01a\RK_LowPoly_Stone_Fireplace_01a.qc" ...

Compiling ".\RK_LowPoly_Stone_Fireplace_01a.qc" ...
qdir: "c:\users\rupert\desktop\my materials & models\rks_materials_models\low-poly\blender\models\props_lowpoly\rk_lowpoly_stone_fireplace_01a\"
gamedir: "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\"
g_path: "RK_LowPoly_Stone_Fireplace_01a.qc"
Building binary model files...
Working on "RK_LowPoly_Stone_Fireplace_01a.qc"
SMD MODEL RK_LowPoly_Stone_Fireplace_01a.smd
SMD MODEL anims\idle.smd
SMD MODEL RK_LowPoly_Stone_Fireplace_01a_phys.smd
Processing LOD for material: RK_LowPoly_Stone_01
Model has 6 convex sub-parts
Collision model completed.
---------------------
writing C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\models/props_lowpoly\RK_LowPoly_Stone_Fireplace_01a.mdl:
Loading preexisting model: C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\models/props_lowpoly\RK_LowPoly_Stone_Fireplace_01a.mdl
Found 1 preexisting sequences.
bones 964 bytes (1)
animation x y ips angle
animations 112 bytes (1 anims) (1 frames) [0:01]
Building sequence index remapping table...
No re-ordering required.
sequences 220 bytes (1 seq)
hdr@0054EFE4=79C30200
ik/pose 164 bytes
eyeballs 0 bytes (0 eyeballs)
flexes 0 bytes (0 flexes)
hdr@0054EFE4=79C30200
textures 72 bytes
keyvalues 212 bytes
hdr@0054EFDC=79C30398
hdr@0054EFE4=79C30200
bone transforms 0 bytes
bone flex driver 0 bytes
bodygroup presets 0 bytes
Collision model volume 22896.00 in^3
collision 0 bytes
total 2000
---------------------
writing C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\models/props_lowpoly\RK_LowPoly_Stone_Fireplace_01a.vvd:
vertices 11328 bytes (236 vertices)
tangents 3776 bytes (236 vertices)
total 15168 bytes
---------------------
Generating optimized mesh "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\models/props_lowpoly\RK_LowPoly_Stone_Fireplace_01a.dx90.vtx":
body parts: 8 bytes
models: 20 bytes
model LODs: 12 bytes
meshes: 9 bytes
strip groups: 33 bytes
strips: 35 bytes
verts: 2124 bytes
indices: 984 bytes
bone changes: 16 bytes
everything: 3265 bytes

Completed "RK_LowPoly_Stone_Fireplace_01a.qc"
... Compiling ".\RK_LowPoly_Stone_Fireplace_01a.qc" finished. Check above for any errors.

... Compiling with Crowbar 0.34.0.0: "**\****\******\*******\My Materials & Models\rks_materials_models\low-poly\Blender\models\props_lowpoly\RK_LowPoly_Stone_Fireplace_01a\RK_LowPoly_Stone_Fireplace_01a.qc" finished.

what does your QC look like?

$modelname "props_lowpoly\RK_LowPoly_Stone_Fireplace_01a.mdl"
$cdmaterials "models\props_lowpoly"

$texturegroup "skinfamilies"
{
{ "RK_LowPoly_Stone_01" }
}

$scale 100.0
$surfaceprop "concrete"

$StaticProp

$bodyGroup "Body" {
studio "RK_LowPoly_Stone_Fireplace_01a.smd"
}

$Sequence "idle" {
"anims\idle.smd"
fadein 0.2
fadeout 0.2
fps 1
}

$CollisionModel "RK_LowPoly_Stone_Fireplace_01a_phys.smd" {
$mass 400
$inertia 1
$damping 0
$rotdamping 0
$concave

}