Area portal troubles

[tltrude]

The map I'm working on has nice Starwars doors (func_door) that open into the ceiling. But, i'm having problems with the area portal brushes showing with the doors close (not all the doors, just some). Then when the door is opened the portal doesn't turn off. I get one working right and another door starts doing it. Doh!

Could it be the shader for the door texture? Anyone else had this problem? BTW, the area brushes are constructed correctly (thin brush inside the door brush), and the edges of the doors are inside wall, ceiling, and floor pockets.



The above door is one of three which are bad. All three are around one area (two rooms with a window and non-portal door between). There is a forth door to this area that leads to another area and has no problem--except it only opens the other area portals. It's weird that the non-portal door will turn off all the bad portals when it is opened, but the bad doors wont.

[crunch]

I have never experienced that with area portals.
But I also rarely use sliding doors.

But just so I understand what you are saying, the door opens, but the area beyond it does not get drawn?

I don't see how a texture shader would affect the portal, though.
This is a long shot, because the portal should open at the start of the door movement, but maybe try lip/0 in the door's k/v.

[tltrude]

Yes, the area portal looks like caulk, or the void, when it does not open. When you step through it looks like normal. But, with some doors the, the portal can be seen with the door closed--even though the door is 16 units thick and the area brush is only 2 units thick and in the center of the door brush.

There are no errors in the console. And, sometimes you can open another nearby door (one with or without an area brush) and the portal that is showing will open.

I could make the doors script_objects and turn the portals on and off in the script, but the portals would still show through some of the doors when they're closed.

Most of the shaders, for all these Starwars textures, had to be rewritten to work in mohaa--not by me. All the shaders look like this one.

Code: Select all

textures/impdetention/door1
{
	qer_keyword metal
	qer_keyword wall
	surfaceparm metal
	{
		map textures/impdetention/door1.tga
		rgbGen identity
		depthWrite
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
		depthFunc equal
	}
}

[small_sumo]

Make a regular door at the same place and cover it in nodraw set up the portal with it instead of the fancy one. Just an idea.

..........

[tltrude]

I tried lip 0 and changing the door texture to an mohaa texture, nothing helped. Then I added an origin brush to the top of one of the bad doors and the problem was gone for that door. So, I am trying that with the other doors now.

Normally I don't use origin brushes with func_doors, but I guess it is important for the area portal--at least for doors that open upward.

[small_sumo]

Wow those textures look good in the pic at the top. Very cool.

[crunch]

If the insertion of an origin brush solves the problem, that would be an excellent "Tip of the day."

Especially since they're not normally used with sliding doors.

[tltrude]

I put origin brushes on the other two doors, and they still have the problem.

[Random]

Well T-man i tried to reconstruct what you are talking about and i had no issues with the areaportals. I created a room with doors leading out in all 4 directions, but now windows in the rooms, and they seem to be working fine when i use r_showtris 2. The rooms are sealed and they show when the doors open. I created doors that move up, down, and half up half down.

I would be happy to share with you the test rooms i built to see if that holds any answers for you but somehow i dont think i did anything special other than the doors dont overlap into the walls or floor, although the doors that move down do go through the floor.

One thing i did notice though is that the doors the move half up and half down dont open when i click the auto open box?

Sorry i couldnt help more and hope you find the answers.

Random

[tltrude]

Well the map has nine areas. I tried testing the (main) inside part of the map for leaks by filtering out and deleteting anything that wasn't important to the structure (including patches), and copying what was left to a new map. I then changed the doors to the outside (4 doors) into structual brushes and compiled. There were no leaks into the void, so the structure is tight. Also, none of the remaining doors showed any area portal problems--weird.

So, I not suprised that you couldn't reproduce the problem, Random--thanks for trying.

If I can only find out what causes the "bleed-through" on the door faces, I could fix the portals by scripting them. For some reason, the func_door brushes think they are area portal brushes--the area brushes are not part of the func_door, they are just inside them.

Here's a tip, never copy the classname from one func_door to a new one--makes both doors leak in the compile.

[crunch]

This problem really has me stumped.
I have another suggestion, however.
I don;t know that it will change anything but it is worth a try.

I don't know if the listed order of the shader characteristics matters, but I
noticed that the shader you showed above is written in different order from a regular MoHAA door shader.
Perhaps changing the shader could solve the problem.

Try this shader for that texture:

Code: Select all

textures/impdetention/door1 
{ 
   	qer_keyword metal 
	   qer_keyword wall 
   	surfaceparm metal 
   	{ 
      		map textures/impdetention/door1.tga
		      depthWrite 
      		rgbGen identity 
      } 
      { 
     		 map $lightmap
		      rgbGen identity  
     		 blendFunc GL_DST_COLOR GL_ZERO 
      		depthFunc equal 
   	} 
} 

Again, it may not solve it, but it's worth a shot.

[tltrude]

As I said above, I tried an Mohaa door texture, and still had the problems. But, I tried yours anyway and, of course, it didn't fix it.

Another symptom - The two doors only bleed through on one side.

The area in question (lets call it area A) really has 5 area portals. There is a func_window in the ceiling. And, on the other side of the room above it, there is a hatch in the floor leading to a small elevator shaft to another area (call it area B). That hatch has a scripted area portal. The elevator is a func_door, but it starts well below the hatch and has a script_origin attached--to open the hatch when it get near it.

So, of two doors that are bleeding, only one can be seen from inside area A. The other bleeds when you step through the door, into a large elevator shaft that is also an area (call it area C), and close it. That elevator shaft leads to a massive outside door on the surface. Also, in that shaft, there is a small double door (opens up and down) that leeds to area B, where the first eleavator I spoke of is.

Hope this is making sence, I can't send the map to anyone because it belongs to Vampir, but I do have permission to show screenshots, if anyone wants to see what I'm talking about.

[hogleg]

Hey, I know u guy's r the pro's so I read all the posts. Well Tom your earlier post say's:

"An area has to be sealed by structual and area brushes. And, it can't have func_windows or other entities (like exploders) in the walls. The area brushes have to be hidden inside the door brushes, so they can't be seen from either side of a door. But, you probably know all that."

But in this string you wrote:


The area in question (lets call it area A) really has 5 area portals. There is a func_window in the ceiling. And, on the other side of the room above it, there is a hatch in the floor leading to a small elevator shaft to another area (call it area B). That hatch has a scripted area portal. The elevator is a func_door, but it starts well below the hatch and has a script_origin attached--to open the hatch when it get near it.

So Im to take it its okay to have a function_windows in the ceiling but not in the walls?

[tltrude]

No, the room above is part of area A because the func_window is not structual, and you can see through it. So now, the area portal brush in the hatch, shown, is one of area A's seals. In affect, there are three rooms in area A, but the windows don't allow them to be seperate areas.

[bdbodger]

Did you try filtering out the detail brushes to see if you accidentally left a leak in room A ?