Hello! It's quite sometime since I've played with Hammer and Portal 2. blame minecraft

Anyway, I've been trying to work with world portals and trying to make a frame for it.

The first thing I did was to edit a stock texture from the game, by adding a $color option to the .VMT.

The .VMT here:

LightmappedGeneric
{
$baseTexture "Tile/white_wall_tile003a"
$surfaceprop metal
$bumpmap "tile/white_wall_tile003_height-ssbump"
$ssbump 1

$normalmapalphaenvmapmask 1
$envmapcontrast 1
$envmapsaturation 1
$envmaptint .3 .3 .3
$detail "detail\white_floor_detail_height-ssbump"
$detailscale 80
$detailblendfactor 1
$detailblendmode 10
$color "[0 0.31 0.52]"
"%keywords" "portal2 chamber"
}

However, I've encountered a small problem.
The texture works if it's a func_detail.

But, once I turn in into a func_brush, it shows the original texture, without the color.

And, shining a light using a flashlight to it shows the color when it's a func_brush.

I have no idea what I'm doing wrong here. If anyone knows, please do let me know. Thanks!

Hey, man! Welcome back!

The possible cause might be in one (or the 2) of these params:

$detailblendfactor 1
$detailblendmode 10

In one hand, dim the detail a bit more: "0" means no detail at all while "1" means the detail being rendered fully and on top of your texture, try for example a value of "0.5" and continue from there

And try different blend modes... each of them causes a type of blend between the basetexture and the detail. In the blend modes is important to check the alpha channel in both textures, because some of the blend modes play with the alpha mask to intensify one texture over the other. Also I don't think that the blend mode type "10" actually exists! :p

josepezdj wrote:
Hey, man! Welcome back!

The possible cause might be in one (or the 2) of these params:

$detailblendfactor 1
$detailblendmode 10

In one hand, dim the detail a bit more: "0" means no detail at all while "1" means the detail being rendered fully and on top of your texture, try for example a value of "0.5" and continue from there

And try different blend modes... each of them causes a type of blend between the basetexture and the detail. In the blend modes is important to check the alpha channel in both textures, because some of the blend modes play with the alpha mask to intensify one texture over the other. Also I don't think that the blend mode type "10" actually exists! :p

I derped up there. :\ I posted the wrong .VMT file in my original post. I've changed it to the one with the texture I'm using for the frames.

I still tried changing the params for both $details though, but none of the combinations worked.

Stop referring to your .vmts as .vmfs.

Also why not just do what omni did and use a custom texture.
Plastic/concrete isn't a very fitting material for portals anyway.

He is using a custom texture, hence the title of the thread.

Omni actually didn't create new materials for his world portals. One portal uses the stock fizzler texture and the other uses his physics-field from Retrospective. That's why they aren't the standard colors--I imagine if he had polished them up for release (rather than just creating them as an experiment) he would have redone them in (brighter) blue and orange.

FelixGriffin wrote:
He is using a custom texture, hence the title of the thread.

The thread title says "custom colored textures problem" not "custom textures color problem."
He even said in the description that this is just a stock texture with a modified .vmt.

Also my point still stands about concrete not being a very fitting portal texture. And omni using custom stuff.

Caden wrote:
Stop referring to your .vmts as .vmfs.

Like I said, > Habzs wrote:

It's quite sometime since I've played with Hammer and Portal 2

It's been awhile since I've played with source as a whole. I got confused trying to post this thread within a small amount of time.

Caden wrote:
Also why not just do what omni did and use a custom texture.
Plastic/concrete isn't a very fitting material for portals anyway.

Haven't you been reading? > Habzs wrote:

The first thing I did was to edit a stock texture from the game, by adding a $color option to the .VMT.

I was implying that I quickly whipped up a .VMT to test if the color worked. I am using the stock texture as a placeholder.
Also, this IS a custom texture. Textures don't only consist of the VTF, you know. Changing values of the VMT makes a significant change in the texture itself. Therefore, my texture is custom.

Caden wrote:
Also my point still stands about concrete not being a very fitting portal texture. And omni using custom stuff.

Texture is still custom.

--

Habzs wrote:
Textures don't only consist of the VMF, you know.

Habzs wrote:
VMF

help someone please call the doctor im dying.

Caden wrote:
Habzs wrote:

Textures don't only consist of the VMF, you know.

Habzs wrote:

VMF

help someone please call the doctor im dying.

Well doesn't that just proves your ignorance.

Habzs wrote:
Well doesn't that just proves your ignorance.

.vmfs are map files m8 xDDDDDD

Habzs wrote:
Also, this IS a custom texture. Textures don't only consist of the VMF, you know. Changing values of the VMT makes a significant change in the texture itself. Therefore, my texture is custom.

Alright I don't know if you just deliberately ignored this or what but it's pretty obvious that when I said "custom texture" I was referring to something that was actually custom made and also fitting for a portal material.

Caden wrote:
Habzs wrote:

Well doesn't that just proves your ignorance.

.vmfs are map files m8 xDDDDDD

I was wrong there, I admit. Pardon my ignorance.

Caden wrote:
Alright I don't know if you just deliberately ignored this or what but it's pretty obvious that when I said "custom texture" I was referring to something that was actually custom made and also fitting for a portal material.

A more fitting texture is in the works. Like I said, using the concrete texture is a **placeholder to test** if colored textures worked.

OK Habzs, I've been testing this out and it definitely doesn't have to do with the blend modes or the detail blend factor. I've tried also multiple settings for the func_brush, I've tried different shaders, and even a 7.5 version (and without the SRGB flag) of the texture "plasticwall004a.VTF"... but to no avail.

Then I thought that, maybe because of what the parameter $color is and what it does, it only works properly on func_details not in actual entities like the func_brushes.

It's quicker if you forget about that parameter and make actual coloured textures for your frames

I'm attaching a switchable (multiframed) texture for you. You've got the blue one in first frame (0), and then the orange (1) so you can switch your func_brushes textured on this texture by a env_texturetoggle entity. I'm not sure if this is what you were looking for... Let me know

(Place both files under a folder josepezdj/detail/ or change the path inside the .VMT)

josepezdj wrote:
-snip-

Thanks! I still find it weird that the $color param doesn't work though.

Guess I'll whip up a proper frame soon. But for now, the portals with the appropriate colors:

ss%20(2014-07-04%20at%2010.15.17).jpg

What's up with that weird excursion funnel?

CamBen wrote:
What's up with that weird excursion funnel?

It's a re-texture I'm working on, I'm trying to recreate the excursion funnel from one of the teaser posters.

ss (2014-07-04 at 10.08.58).jpg