Hey guys,

I have a problem with my vgui_movie_displays. I use them for the monitors in the exit elevator of my map, and in general they are working fine. But I have a rendering issue which causes the displays to be rendered on top of everything else. Here is an example (the white displays are intended):
http://steamcommunity.com/sharedfiles/filedetails/?id=265645507

Any idea what could cause that? I have the same setup in other maps (I'm just using self made prefabs), but I don't have any problems there. This map is the only one that has the problem.

Perhaps it is because you are using prefabs and not instances.

Just a wild guess.

No, prefabs aren't the reason why I get the rendering issues. Prefabs / Instances only matter while in hammer. I use prefabs because I can manipulate them better.
They are based on some already existing prefabs and instances I found, so I know that they work (which they do in other maps).

What I may have discovered is that the blank / white video which plays there could be a reason for the issue. When I replace them with an actual video, it seems to work fine.
Aren't the white screens just videos as well? Why would a white video cause a rendering bug, but other videos don't? I would really like to use the white screens in the map.

@Sprowl: that is not a bug; that happens just because the material being used on the elevator screens ("elevator_video_lines.VTF") has a parameter inside its .VMT that makes it to be rendered always in first plane:

$ignorez 1 (meaning "ignore the z axis")

(this might remind you the skyboxes "bug" drowning/leaking the whole map)

UnlitGeneric
{
$translucent 1
$basetexture "vgui\elevator_video_lines"
$vertexcolor 1
$vertexalpha 1
$no_fullbright 1
$ignorez 1
$additive 0
}

The solution, if it really bothers you, is to use a custom texture for them which is exactly the same except erasing that line from the .VMT.

Hey jose,
thanks for the reply. I can't try it right now, but I'll try it later today. One thing though:

The videoscreens are .bik files. When I don't load a specific videofile for the vgui_movie_displays, does the game load a vmt to display a vtf file which looks like the white screens? Seems kinda complicated. Also if it really uses the $ignorez parameter, why isn't it rendered ALWAYS on top? Right now it happens sometimes, and not with all screens at the same time.

Sprowl wrote:
When I don't load a specific videofile for the vgui_movie_displays, does the game load a vmt to display a vtf file which looks like the white screens?

I believe so, and that texture shown in the screens is the texture I was meaning, "elevator_video_lines". This is a texture using the shader UnlitGeneric, therefore using its alpha channel to glow (= emit light) by its own. If you check out the texture's alpha channel, you've got this:

I can't check all this atm, but when I arrive home this evening, but I'm pretty sure I'm on the right track :p

That looks more like the black border of each video panel which is used as an overlay above the .bik video. The actual video would be behind it.
If that texture has the $ignorez parameter, then my screenshot would show that border above everything else with the white .bik file staying where it is (behind the elevator), but it also does show the .bik video.
I'm not sure who's right here. We'll see later I guess .

Well, to me this is how it works: the screens are textured on that texture. If you don't select a video to show up, that texture will be the empty white screens you see. But when you choose a video .BIK to be displayed, it is displayed in front of the texture (notice that you have to place your vgui_movie_display at least some units in front of the screen brushes) and rendering with priority over the texture. Also maybe they disable the screen-brushes behind... dunno until I check it at home.

For me it's more like this:
You have the vgui_movie_display which simply displays a .bik file after it gets activated. This .bik file has the orientation of the vgui_movie_display entity, so of course you have to have enough space betwen the entity and the background (the walls in the elevator room) or rlese it would just end up beeing inside the brush. The vgui_movie_display doesn't modify any textures in the map, which means that the walls always keep their textures (you can see it with noclip).

When the video is displayed you see, of course, the .bik file. But the game also puts the border-texture, which you just posted before, in front of it to simulate a monitor.

What you say now is, that the border-texture ignores the rendering order. But the bik video doesn't have any reason for that just because the texture in front of it has that paramter. At leats it wouldn't make much sense... . Except maybe the .vmt information of the border texture is getting used on the .bik file as well...
Edit: ...which wouldn't make sense because the whole problem doesn't exists when using a real .bik file (which btw uses the border as well)

OK, I just watched one of my solution videos to watch the elevator screens

What it looks to me is that the screen texture needs to be "$ignorez 1" in order to mix with the .BIK videos because you can clearly see how the background texture delimit the image, its borders, etc. as if it was an overlay on top of the video. Therefore you'll better keep that parameter in the texture's VMT; alternatively, you'll need 2 textures, one with the parameter and other without it to be used when you don't load any video...

I'm pretty sure that if you erase that param, you'll see the videos displayed without any overlay drawing the borders, but just the plain videos (which might look a bit unrealistic)...

josepezdj wrote:
[...]because you can clearly see how the background texture delimit the image, its borders, etc. as if it was an overlay on top of the video.

No, if you use a broken background (with cracks and stuff) you won't see those. The background doesn't matter, or where the vgui_movie_display is placed.

Sprowl wrote:
No, if you use a broken background (with cracks and stuff) you won't see those

Because 1. they haven't got an alpha channel, and 2. their .VMT doesn't contain the $ignorez 1 parameter. You can check that out

Sprowl, I'm pretty sure of what I'm saying, that parameter is the one in charge to render stuff in a first plane and it definitely is what was causing what you can see in your first picture

EDIT

Try using for exampler these textures (which are the "dirty" ones):

- elevator_video_overlay1
- elevator_video_overlay2
- elevator_video_overlay3

They should appear in first plane as well due to they have the same params than the "elevator_video_lines" texture.

You can also make a version of one of the cracked screens but adding an alpha channel to the texture, and adding the parameter inside its .VMT, I'm sure you'll get what you keep with certain amount of opacity in the alpha channel on the first plane, thus on your videos.