Do portals work in 1.0.3?
by Masser · in Constructor · 09/18/2007 (11:47 am) · 10 replies
I've been having problems adding portals to my maps in Constructor 1.0.3. I gather from other posts that this works, but I can't for the life of me figure out how. No matter what I do, I cannot see any occlusion (light or object, in-game. I tried simplifying a bit and this is what I did:
1) Create a simple Cube primitive with a basic, opaque JPG image for texture (concrete), big enough to walk inside.
2) Hollow the Cube to .5 thickness.
3) Create a subtraction brush and put a doorway to the front of the cube. I now see a hole and into the cube.
4) Add a point light entity inside of the hollow cube. I can see the light project onto the walls with dynamic lighting display on.
5) Add a DTS object (crate) to bake-in.
6) Use the same cube that I used as a subtraction brush (I never deleted it) as a portal brush. I select the brush (which has a concrete texture) and apply the NULL texture. I then select Object: Brush: Brush Type: Portal from the left menu to make it a portal type. The brush turns pink.
7) I save the scene, close it and re-open it. I "Export as DIF" and bring the new DIF object into Mission Editor, relight all and play in starter.fps.
When I walk up to the building, I can see right into the doorway -- the light and the DTS object show from the outside. Walking into the doorway has no effect. Alternately, I have tried the same approach, but:
1) In step #6, I deleted the original brush used for subtraction and created a new one that is thin (.25 or so), a little larger than the doorway in height and width and placed it dead center of the doorway (so it shares no planes with other brushes). I follow the rest of the procedure and same result.
2) I follow this procedure, but at #7, I export using Map2DIF Plus. I get no lights at all, in-game and of course, no baked-in DTS so my test won't work.
3) I follow the entire procedure and IN ADDITION to adding a baked-in DTS in step #5, I add another right next to it in Mission Editor. I can see both, in-game.
Is my procedure for creating the portal brush correct? Portal brush type? Texture changed to NULL texture? Export using Export as DIF?
Please help.
1) Create a simple Cube primitive with a basic, opaque JPG image for texture (concrete), big enough to walk inside.
2) Hollow the Cube to .5 thickness.
3) Create a subtraction brush and put a doorway to the front of the cube. I now see a hole and into the cube.
4) Add a point light entity inside of the hollow cube. I can see the light project onto the walls with dynamic lighting display on.
5) Add a DTS object (crate) to bake-in.
6) Use the same cube that I used as a subtraction brush (I never deleted it) as a portal brush. I select the brush (which has a concrete texture) and apply the NULL texture. I then select Object: Brush: Brush Type: Portal from the left menu to make it a portal type. The brush turns pink.
7) I save the scene, close it and re-open it. I "Export as DIF" and bring the new DIF object into Mission Editor, relight all and play in starter.fps.
When I walk up to the building, I can see right into the doorway -- the light and the DTS object show from the outside. Walking into the doorway has no effect. Alternately, I have tried the same approach, but:
1) In step #6, I deleted the original brush used for subtraction and created a new one that is thin (.25 or so), a little larger than the doorway in height and width and placed it dead center of the doorway (so it shares no planes with other brushes). I follow the rest of the procedure and same result.
2) I follow this procedure, but at #7, I export using Map2DIF Plus. I get no lights at all, in-game and of course, no baked-in DTS so my test won't work.
3) I follow the entire procedure and IN ADDITION to adding a baked-in DTS in step #5, I add another right next to it in Mission Editor. I can see both, in-game.
Is my procedure for creating the portal brush correct? Portal brush type? Texture changed to NULL texture? Export using Export as DIF?
Please help.
#2
09/18/2007 (1:14 pm)
Thanks, Caylo. It sounds like my understanding of portals may be the problem here. I'll give this a shot and report back.
#3
I've been asking for tutorials that explain the theory behind portals. I only received one answer to look at: http://holodeck.st.usm.edu/vrcomputing/vrc_t/tutorials/editing/ which didn't really enhance my theory knowledge. I've since found a bit more info in the 3D Game Programming All-In-One book, but I wish I could find more. A few forum posts here and there and now you have my full battery of information.
I checked out your example files (thank you SO much, BTW) and when I export the DIF with and without portals and compare the two, I see the lighting is a bit different (darker in the portal version). So is the basic idea here that:
1) A zone that falls in the player's line of sight gets rendered in its entirety (lighting, brushes, DTS objects, sounds)?
2) You save processing power on objects (light maps, brushes, DTS, sound) that lie in zones JUST OUTSIDE OF the player's view? But don't most of these typically get occluded by virtue of being hidden faces?
In short, where do portals really pay off? Does the REAL benefit come from DTS and internal brush complexity occlusion? As a specific case: Picture a situation where I'm working on a building that has 5 floors, each with 6 rooms and windows to each floor. Would I need to put portals in each window (to prevent light leaks), across major sections of hallway (to capture a series of rooms) and between floors (tops of stair cases)? is this how it essentially works?
Sorry for the long questions. Any URL's you can send would also be greatly appreciated. I am not afraid to read -- I just can't find good info. I also need to finally get into engine compilation and get my hands on a debug version so I can see zones in-game.
Thanks.
09/18/2007 (3:57 pm)
Ok, so it would seem that my portal was exporting correctly and the issue was, in fact, my knowledge of portals.I've been asking for tutorials that explain the theory behind portals. I only received one answer to look at: http://holodeck.st.usm.edu/vrcomputing/vrc_t/tutorials/editing/ which didn't really enhance my theory knowledge. I've since found a bit more info in the 3D Game Programming All-In-One book, but I wish I could find more. A few forum posts here and there and now you have my full battery of information.
I checked out your example files (thank you SO much, BTW) and when I export the DIF with and without portals and compare the two, I see the lighting is a bit different (darker in the portal version). So is the basic idea here that:
1) A zone that falls in the player's line of sight gets rendered in its entirety (lighting, brushes, DTS objects, sounds)?
2) You save processing power on objects (light maps, brushes, DTS, sound) that lie in zones JUST OUTSIDE OF the player's view? But don't most of these typically get occluded by virtue of being hidden faces?
In short, where do portals really pay off? Does the REAL benefit come from DTS and internal brush complexity occlusion? As a specific case: Picture a situation where I'm working on a building that has 5 floors, each with 6 rooms and windows to each floor. Would I need to put portals in each window (to prevent light leaks), across major sections of hallway (to capture a series of rooms) and between floors (tops of stair cases)? is this how it essentially works?
Sorry for the long questions. Any URL's you can send would also be greatly appreciated. I am not afraid to read -- I just can't find good info. I also need to finally get into engine compilation and get my hands on a debug version so I can see zones in-game.
Thanks.
#4
Portals help define an area that once none of the portal area is visible the FULL area can be ignored. If any part of the portal area is visible, whatever is visible will be rendered, (and im not sure how Torque handles this...) the rest of that zone is considered for rendering= in the 'world' list. It is pointless to use LOTS of portals, because now you have created many of the 'thing' lists. It is also pointless to portal an area that is often visible(now the list reshuffling takes as much time as NOT being in a zone).
About your question regarding the building:
The inside of the building needs to be sealed from the outside, this would make ONE ZONE for the full building. If you are placing a large amount of detail (counting DTS detail) into one of the rooms, use another portal for that room. You dont need to portal EVERY room unless your using 1000's of polys for your BSP/DIF details.
The BEST way to learn where and when to use a portal is to watch your Frames Per Sec. If you come into an area or view that makes the FPS chug and stutter, portal it off. If that same area is visible from many locations and angles, portal will not help.
09/18/2007 (5:22 pm)
An simple but sorta flawed way to think of it is: Every 'thing' in the game 'world' is on this LONG list of 'things'. It takes time to check the list to see if the 'thing' should be rendered. By putting 'things' into a ZONE you have created an new 'thing' list for that zone, and now the MAIN 'world' list is shorter.Portals help define an area that once none of the portal area is visible the FULL area can be ignored. If any part of the portal area is visible, whatever is visible will be rendered, (and im not sure how Torque handles this...) the rest of that zone is considered for rendering= in the 'world' list. It is pointless to use LOTS of portals, because now you have created many of the 'thing' lists. It is also pointless to portal an area that is often visible(now the list reshuffling takes as much time as NOT being in a zone).
About your question regarding the building:
The inside of the building needs to be sealed from the outside, this would make ONE ZONE for the full building. If you are placing a large amount of detail (counting DTS detail) into one of the rooms, use another portal for that room. You dont need to portal EVERY room unless your using 1000's of polys for your BSP/DIF details.
The BEST way to learn where and when to use a portal is to watch your Frames Per Sec. If you come into an area or view that makes the FPS chug and stutter, portal it off. If that same area is visible from many locations and angles, portal will not help.
#5
One more question: When you refer to making the building all "one zone", I don't understand. The only way I know to make a portal "zone" is to seal off all of its exits with portal "plates" or at least all entrances from a common point of view (like a "main" entrance and the windows facing in its direction). Can portals be used like huge boxes that completely envelope a building or room?
In the case of my example building (where we'll assume, I have a daunting number of objects inside), there is a front door and a series of windows that face that same direction. Do I have to create a plate in front of the door and every window to effectively occlude the content of the building from the outside view?
or
Can I create one huge box around the building as a whole? Or at least, a very large plate that spans the entire face of the building (BTW, I tried this once and the null texture did freaky things to the walls around my windows)?
09/18/2007 (5:59 pm)
Caylo: That is an EXCELLENT explanation. I finally get it. Thank you.One more question: When you refer to making the building all "one zone", I don't understand. The only way I know to make a portal "zone" is to seal off all of its exits with portal "plates" or at least all entrances from a common point of view (like a "main" entrance and the windows facing in its direction). Can portals be used like huge boxes that completely envelope a building or room?
In the case of my example building (where we'll assume, I have a daunting number of objects inside), there is a front door and a series of windows that face that same direction. Do I have to create a plate in front of the door and every window to effectively occlude the content of the building from the outside view?
or
Can I create one huge box around the building as a whole? Or at least, a very large plate that spans the entire face of the building (BTW, I tried this once and the null texture did freaky things to the walls around my windows)?
#6
09/18/2007 (6:14 pm)
You would need a portal for anyplace there is not a solid wall. For a wall that had many windows, you will need to block each window with a portal brush. I have NOT had any luck with Torque portals using ONE large brush to portal off many openings in a wall, so i expect ONE portal brush per open place.
#7
Question: If you have LOD setup for a building and you are at a distance (let's say the full building is like 1000 brushes and the next LOD is like 50 brushes and you are far enough away to see a series of lower LOD buildings only), will the more complex version (which also contains a ton of DTS objects) be considered as well in the scene. Or will it merely substitute the entire building (and my lower LOD contains no objects) and only consider the brushes in the lower LOD buildings (until you get closer, of course)?
If so, maybe a good mixed strategy might be to use LOD to manage complexity from a distance (and NO portals to the outside -- windows or doorways) and portals for up close (segmenting internal rooms, floors, etc.) Do you agree?
09/18/2007 (7:19 pm)
Thanks. I attacked this exact challenge. I have a series of hollow buildings (dozens), all in close proximity. I just avoided portals altogether and used heavy LOD, such that you don't even see building complexity until you're right up on it. I have considered putting them between rooms or sections of rooms (or even floors) to occlude irrelevant floors. Now with your portal explanation, I'm beginning to think that may not be such a bad idea (as they are being considered even when not seen).Question: If you have LOD setup for a building and you are at a distance (let's say the full building is like 1000 brushes and the next LOD is like 50 brushes and you are far enough away to see a series of lower LOD buildings only), will the more complex version (which also contains a ton of DTS objects) be considered as well in the scene. Or will it merely substitute the entire building (and my lower LOD contains no objects) and only consider the brushes in the lower LOD buildings (until you get closer, of course)?
If so, maybe a good mixed strategy might be to use LOD to manage complexity from a distance (and NO portals to the outside -- windows or doorways) and portals for up close (segmenting internal rooms, floors, etc.) Do you agree?
#8
09/18/2007 (8:36 pm)
If this was already mentioned, ignore me. But for TGEA, only the legacy map2 dif TGEA exporter (I think thats what it's called) will even remotely export a portal.
#9
However, I want to revisit your original message. Baked DTS objects will NOT be occluded and WILL be rendered, even when in a portal zone. Placing the DTS objects into the building in the game editor, however, WILL WORK and not be rendered unless you can see inside the portal room. This problem with baked DTSs is either a bug or was never intended to work, but I've mentioned it to GG a long time ago and they said they would look into it. The explaination that I received from another member was that baked DTS objects are more of a conveinence, which is a trade-off, I guess. They do make great shadows when baked in, though ... so it would depend on if you have a lot of objects or if you can afford to not need portal occlusion.
09/21/2007 (6:04 pm)
Masser, you received a lot of good info ... I can't answer your last question because I haven't done any LOD as of yet.However, I want to revisit your original message. Baked DTS objects will NOT be occluded and WILL be rendered, even when in a portal zone. Placing the DTS objects into the building in the game editor, however, WILL WORK and not be rendered unless you can see inside the portal room. This problem with baked DTSs is either a bug or was never intended to work, but I've mentioned it to GG a long time ago and they said they would look into it. The explaination that I received from another member was that baked DTS objects are more of a conveinence, which is a trade-off, I guess. They do make great shadows when baked in, though ... so it would depend on if you have a lot of objects or if you can afford to not need portal occlusion.
#10
The saving, re-opening constructor and then exporting procedure is still needed, even if you didn't use the hollow function.
10/01/2007 (7:48 am)
I guess that hollowing a brush causes *additional* problems. I advise not using it until it is fixed.The saving, re-opening constructor and then exporting procedure is still needed, even if you didn't use the hollow function.
Torque 3D Owner Caylo Gypsyblood
THIS is a working portal map example with DIF (TGE 1.4version DIF), .map .qkm and .csx(all files to dissect the DIF with QUARK,Constructor or anything that is able to load a .map BSP file)