[Solved] Problems with Modulate

[IAmKnotMax]

https://www.dropbox.com/s/ltsr7ctpdkb7d0r/Team Fortress 2 2019.05.24 - 02.39.57.01.mp4?dl=0
(Link above is to a video of my problem)

Can anyone help me with how I'm supposed to keep stuff like this happening, that causes Modulate and/or the model drawing over particles completely or coloring them?

All textures for the model use VertexLitGeneric and Modulate, and only the $basetexture parameter. No $translucent on any textures, as I've been told for some reason that parameter causes problems, but I have reason to believe Modulate really hates particles especially when 2 Modulates can draw over particles causing a full draw-over.

I need my map to be made entirely out of models as this is a port of the Spyro the Dragon levels, and I want to allow special things like vertex colors. The problem of "just bake the vertex colors onto the textures" is that in Blender, if I bake the vertex colors onto the textures, I'm forced to use a single image and 4096x4096. So there is massive texture blurring and compression involved when I attempt to go completely past this problem.

And yes, I'm very sure Modulate is causing this, as I've compiled the models without the vertex color models and the problem is gone.

 

[ficool2]

First of all before you do anything, be warned about porting entire levels as a model.

Multiple players and physically-simulated entities touching the same prop_static WILL cause the server to lag and WILL cause crashes (the more convex collision pieces you have in the model, the worse it will get)

I have ported Goldeneye 64, Super Mario 64, Mario Kart DS and Mario Kart WII maps and unfortunately all of them suffered server lag and crashing until I removed their collision meshes

In that case I highly advise you make the entire level not solid, and then instead use 3dsmax's Wall Worm tools to convert the collision mesh into brushes. (If you need more info on this part, PM me) This will stop those issues.

2nd, make sure you have $mostlyopaque in your .qc (very very important to fix render issues for Modulate shader), and also make sure that you are doing the $model render order trick correctly (also try swapping the $model render order)

3rd, unfortunately there is no way to avoid the Modulate bleeding issue onto decals/particles. $mostlyopaque will partially solve it, but it will still happen from some views. I found that splitting the prop_static into many many seperate models migitates this

4th, slightly unrelated but for the vertex coloring I advise you strip the mipmaps from the vertex color texture, it will shave off a lot of file size from the map especially if uncompressed

Unrelated but I recognise you from somewhere

 

[IAmKnotMax]

First thing, the model is split into 5 parts, 3 parts being what is visually seen because there are 66 materials in total. Their collision model have been split by $surfaceprop sounds too, which is why there's 5 parts of the model.

Second, I do have 3ds Max, but it's the 2017 version as I have problems with later versions when I had to transfer some vertex color data from one level mesh to another (A program I used to get the levels had to save the vertex colors as UVW coordinates, so there needed to be a way to convert it back, a 3ds Max script being one of them). So I'm not sure if 2017 Wall Worm would have the same function/features and I haven't used Wall Worm at all. I mainly use Blender for modelling.

Third, I use $mostlyopaque in all of the qc files. I've been told about this too but I already have it in my qc's. I have no idea about the render ordering besides a random thing I was told about how Blender gives models an order, such as what is newer or older, and I'm quite sure they have proper ordering. 1, 2, 3, was exported, then vertex colors for 1, 2, 3 were exported, all in that order.

Fourth, I already know about mipmapping. I almost always have it disabled, but for textures that are gigantic, I'm not sure if disabling mipmapping for it is a good idea. (up to 4096x4096)

Also I have no idea where you could recognize me from

 

[ficool2]

First thing, the model is split into 5 parts, 3 parts being what is visually seen because there are 66 materials in total. Their collision model have been split by $surfaceprop sounds too, which is why there's 5 parts of the model.

Second, I do have 3ds Max, but it's the 2017 version as I have problems with later versions when I had to transfer some vertex color data from one level mesh to another (A program I used to get the levels had to save the vertex colors as UVW coordinates, so there needed to be a way to convert it back, a 3ds Max script being one of them). So I'm not sure if 2017 Wall Worm would have the same function/features and I haven't used Wall Worm at all. I mainly use Blender for modelling.

Third, I use $mostlyopaque in all of the qc files. I've been told about this too but I already have it in my qc's. I have no idea about the render ordering besides a random thing I was told about how Blender gives models an order, such as what is newer or older, and I'm quite sure they have proper ordering. 1, 2, 3, was exported, then vertex colors for 1, 2, 3 were exported, all in that order.

Fourth, I already know about mipmapping. I almost always have it disabled, but for textures that are gigantic, I'm not sure if disabling mipmapping for it is a good idea. (up to 4096x4096)

Also I have no idea where you could recognize me from

I just checked my Mario Kart DS map

Looks like there is no hope to fix this issue, you have to deal with it

As for 3dsmax: Wall Worm should be able to work with 2017, I used it before but I use 2019 now, not much of a difference anyway. I use Wall Worm solely to export geometry into brushes since no other program/plugin is able to do it, and I never found one after spending ages searching for such a tool

The model order part: Source renders models in the order they appear in the .qc.
E.g.
$model "vertexcolor" "vc.smd"
$model "shadowmap" "shadowmap.smd"
$model "geometry" "geometry.smd"

In this case, vertexcolor would be rendered first, then shadowmapping would be rendered beneath, and both would render on top of geometry. Since they are rendered in different orders, zfighting doesn't occur even on identical polygons. This is what I meant by changing around the render order

For the mipmaps: I meant actually *nuke* the mipmaps from the vtf. I have a QuickBMS script to do this but only for 7.2 version textures, or you can alternatively do it via GIMP's VTF exporter which does not create mipmaps at all if the flag is ticked
That can shave off quite a bit of filesize over several vertex color textures, for 4096x4096 this shaves off 6MB per texture

 

[IAmKnotMax]

Here's what one of my qc files looks like. I don't use those same names, maybe they're entirely different from using $model

$scale 43
$staticprop
$mostlyopaque
$modelname "spyro1/spyro_1_1_1"
$body body1 "spyro1_1.smd"
$body body2 "spyro1_1_vc.smd"
$cdmaterials "models/spyro1/artisanshome/textures/"
$sequence ref "spyro1_1.smd"
$surfaceprop rock


$collisionmodel "sp1_rock.smd"
{
$concave
$maxconvexpieces 1500
}

 

[ficool2]

Here's what one of my qc files looks like. I don't use those same names, maybe they're entirely different from using $model

$scale 43
$staticprop
$mostlyopaque
$modelname "spyro1/spyro_1_1_1"
$body body1 "spyro1_1.smd"
$body body2 "spyro1_1_vc.smd"
$cdmaterials "models/spyro1/artisanshome/textures/"
$sequence ref "spyro1_1.smd"
$surfaceprop rock


$collisionmodel "sp1_rock.smd"
{
$concave
$maxconvexpieces 1500
}

$body body1 "spyro1_1.smd"
$body body2 "spyro1_1_vc.smd"

You might want to swap these lines around, and also change $body to $model (although I'm not sure if it makes a differece)

Also this part is concerning:
$maxconvexpieces 1500

You might want to change this to $maxconvexpieces 128 for your own safety, and if you do hit this limit, then split up the model. >128 convex pieces per prop_static is bound for a disaster in multiplayer

 

[IAmKnotMax]

Also this part is concerning:
$maxconvexpieces 1500

You might want to change this to $maxconvexpieces 128 for your own safety, and if you do hit this limit, then split up the model. >128 convex pieces per prop_static is bound for a disaster in multiplayer

That would make for a *massive* amount of models. There's a lot of convex pieces because of spyro's odd level geometry. I wanted it to be accurate and combining a lot of the faces for geometry isn't going to cut it with how the collision optimizer will screw it over.

This level alone has a total of 3658 total convex pieces. Not much I could do to optimize the collision mesh if I want to keep this as accurate as possible.

 

[ficool2]

That would make for a *massive* amount of models. There's a lot of convex pieces because of spyro's odd level geometry. I wanted it to be accurate and combining a lot of the faces for geometry isn't going to cut it with how the collision optimizer will screw it over.

This level alone has a total of 3658 total convex pieces. Not much I could do to optimize the collision mesh if I want to keep this as accurate as possible.

The engine will die if each model has like a thousand convex pieces, you really need to split it into batches of 128 unless you want servers to fall apart with 8ish players

 

[IAmKnotMax]

Also, swapping the bodies position in the qc seemed to have worked. The particles don't completely disappear, which I guess is good enough since Modulate just doesn't like particles. Maybe I could split this all up in parts of what you say, but there's going to be 30 parts just for this. It's not a problem to actually split them up, since in Blender each convex piece is linked so I can just select 128 pieces and separate it, but damn I was hoping I didn't need so many parts just for this.

 

[ficool2]

Also, swapping the bodies position in the qc seemed to have worked. The particles don't completely disappear, which I guess is good enough since Modulate just doesn't like particles. Maybe I could split this all up in parts of what you say, but there's going to be 30 parts just for this. It's not a problem to actually split them up, since in Blender each convex piece is linked so I can just select 128 pieces and separate it, but damn I was hoping I didn't need so many parts just for this.

As I said earlier, the other alternative you can do that might be less time consuming is to convert the collision mesh to nodraw brushes with 3dsmax Wall Worm tools, that way you can make all the models non solid and just have the brushes serve as the collision without it causing the engine to choke

However, if you are doing this method, you must use a custom build of Hammer because the normal version of Hammer will destroy the brush vertex precision

 

[IAmKnotMax]

However, if you are doing this method, you must use a custom build of Hammer because the normal version of Hammer will destroy the brush precision

Right, so where can I find a custom build of Hammer?

 

[ficool2]

Right, so where can I find a custom build of Hammer?

https://forum.facepunch.com/dev/bvenk/Slammin-Source-map-tools

(be sure to read the entire post as some default settings are changed)

You will need Source SDK 2013 Multiplayer to be installed, and you'll need to follow the setup guide here: https://tf2maps.net/threads/slartibartys-hammer-compile-tools-configuration.38571/

If you use CompilePal, you will also need this: https://tf2maps.net/downloads/slartibartys-compile-tool-parameters-for-compilepal.7452/

Also just to demonstrate the difference, this is a brush after making an arch and saving/reloading the .vmf

Normal TF2 Hammer:

that Custom Hammer:

 

[IAmKnotMax]

Alright, I'll go through that whole process. I do have CompilePal, but I've been using a different compile program (VBCT) because I had to compile some maps that froze up my computer if I compiled it in Hammer. Thanks for the information

 

[ficool2]

Alright, I'll go through that whole process. I do have CompilePal, but I've been using a different compile program (VBCT) because I had to compile some maps that froze up my computer if I compiled it in Hammer. Thanks for the information

That Custom hammer actually solves the computer-being-frozen thing as it runs the compiling tools externally instead of within Hammer, as well as adding multi-threading support for compilers to ease the CPU usage a slight amount