Using Tool Textures - Prt 3
Difficulty: Intermediate |
| Category: CS:S > Mapping | Author(s): Logan Dougall |
Tools Texture Use: Part 3
Tutorial Quick Nav
1.0 - Brief Intro.
2.0 - A Glimpse
3.0 - Situation Example
4.0 - Getting Started
5.0 - Toggling I/O Use
 5.1 - Brief Intro
5.2 - Source for Commands
6.0 - Practical Uses
6.1 - Doors
6.2 - Windows
6.3 - Model Based Geometry
7.0 - Final Words/Warnings
Brief Intro Occluders, amazingly simple in how they work but if not created just right or used in a certain way, can cause more problems in your map than they solve. So I'm going to try and help you all out by explaining a little bit more about this texture and effect.
First things first, the texture by itself is utterly meaningless, it doesn't do a damn thing, just sits there and looks pretty...well blue but anyways. This is one of many textures that have to be used in coordination with a specific brush entity and other tools textures, otherwise its nothing, just blank space much like the toolsskip texture.
Now as for what the occluder actually does, well from its name you know it occludes things, ie Hides them from your view, and this is a very interesting and handy thought now isn't it. Each individual occluder can be enabled/disabled via the I/O system so this adds more options to its use.
A Glimpse as to the effect itself Basically we've got this room here that contains a large number of filing cabinets, no idea why they are there but it must be for a purpose, so to help limit the amount of info that a person is rendering at one time to improve frames, we are going to use an occlude texture/entity. I have done this visual example here quickly, the button activates and de-activates the occlude texture.
Now you can see that without out the occluder in place we see everything, the models are all rendered and my frames have gone to hell, so we click on our button to occlude these models from the players perspective, resulting in this:
*Shadows remain due to vrad actually "burning" the shadows on textures
Now do you understand the power of this texture and entity? it almost doubled my frames! So lets continue on and I will explain more about it.
Simple Situation Example I'm going to use another relatively simple example here, just a stargate with some plants around it, now normally because of how VVIS is run, the area will be divided into different leafs or just one large one because its an outdoor area, so everything is rendered to the player, even things behind walls/other models, so, this is where the occluders can come in handy.
So, heres my stargate and a few ferns in front,
but behind it I've got tons that don't need to be rendered at all from certain perspectives but because I'm in a box with Func_detail pillars and stargate platform, I need to use occlude textures to hide these when I'm looking at them from certain areas.
so this is our main target we want to hide. Lets get to it.
Getting Started First off, open up your texture browser and filter them to "tools/" so that only the tools textures are visable, select the occlude texture. Then re-open the texture browser and select either Nodraw or Trigger as these are the only two you can use alongside occlude textures.
Select the brush tool, with either Nodraw or Trigger as the texture, and create a very simple block wall where we want it to start hiding things, in this case I placed it behind the gate itself and matched its width hight etc.
Using the texture application tool select the front and back faces of the block, these are going to be our occluder faces, so apply the occluder texture to ONLY these two faces.
Now hit CTRL+T or right click and tie to entity, scroll through the list until you come upon func_occluder. Click Apply and then double check that the Initial state value is set to "Active"
I'm just going to explain why we just applied a Nodraw/trigger and an occlude texture onto the same brush if we were going to tie the entire thing to an entity anyways. Basically its like this, unlike most other brush based entities, this one is smart, it ONLY applies its function to sides of the brush that its designed to, in this case, those containing the occlude texture. It is in this fashion that one can designate from what angle/side objects will be occluded from, so for example if we only applied it to the front of the brush then things would only be hidden from that side and not from standing behind it looking forward. A single multi-faced brush could be used to block models from multiple directions, ie a cylinder with all vertical faces applied with occlude and the top/bottom with nodraw/trigger.
For instance, from the players point of view looking at that front face this is what would be happening.
All those small fern models are removed from the players view along that angle alone. Same would happen if standing on the other side of it in the opposite direction but not if you were on either side of the brush as there is no occlude texture there in the example.
So, we compile the map to test out our settings and see if everythings running smoothly.
*note I am using r_visocclusion 1 with cheats enabled to see what is being rendered/hidden. Green = Hidden/removed || Red = Rendered
Front
Sides
So you can see, a simple placement of an occluder made quite a bit of difference in rendering time. Now extreme overuse of occluders in a single area/perspective will actually increase how much info is being processed by your computer resulting in lag/fps loss, so be smart about the placement of the occludes so that they are working as best they can without overdoing it.
Toggling I/O Use Brief Info Due to the fact that this is more of an entity that we are dealing with and not a normal brush, that leaves us open with the option to do almost anything to it, within reason of course. The outputs that can be placed onto this entity are:Activate -> Heavily used for this kind of workAddOutputDeactivate -> Heavily used for this kind of workFireUser1FireUser2FireUser3FireUser4KillKillHierarchyToggle
We will mainly be learning about how to use these outputs with this tool, specifically I am going to focus on the Activate, Deactivate and Toggle commands as these are the only ones with some actual realworld use to the everyday mapper. No need for an advanced system of logic loops etc here.
So, being able to turn on and off these occluders for certian events is something very very cool for a mapper, we can actually force the engine to show what we want when we want and nothing more. Normally one would just run vvis and hope it doesn't take hours and that things are all visable and no glitch's, but from learning more about these tools textures you cut down on the "unknown factor" so to speak, so lets dive into another handy system, Inputs and outputs.
Source for commands So with our options open on how the occluders themselves can be triggered/used we just need something that will send this info to them. You should be trying to keep these as single server events that happen, ie a wall is destroyed ( happens to all players view ) or some such and not just that a person is in an area because you don't want to turn off an occluder in one area because someone walked into it and then the frames for the person someone else gets worse because that tool is now gone. its just not right, so try to think about these settings as we go through them as universal events and not personal ones. Personal events would be for single player things, we are strictly covering some multi-player tricks.
Triggers in any map can be very simple, its either a button getting pushed or door being opened, and easy things like that where an action opens a new area or removed/adds something that now blocks a view. Its all about how the situation calls for one.
a brief list of easy entities that can be used for enabling/disabling occluders:
func_breakable
func_brush
func_button
func_door
| func_door_rotating
trigger_multiple
trigger_playermovement
| trigger_proximity
logic_*
math_* |
This is just a quick list of ones but if you are interesteded in more advanced entity's or I/O use then I suggest you take a look at these tutorials as well since I will just be listing off steps from now on.
Requiring multiple events before activating
Buttons and Doors
Basic Triggers and Buttons
But even still, with that small list the amount of required events you can have before running commands on the occluder is quite extensive that even I have not had time to use them all. But however I will show you how to use some very good examples here.
Practical Uses Doors every building has them and you cannot see through them in real life so lets make this happen in css as well. Because a door has to become an entity at some point for it to work, the space it takes up is then ignored by the VVIS process so it may create leafs that go from one side of the door into the other, for maps with heavy model use (warehouse) this is the main issue you run into for bad frames.
if my example maps visleafs were broken up like this:
Then because of that blue leaf there I would still be rendering objects in the center of my block room on the left even if I should not be able to, the computer will still process all that info and render all models within it. Then from certain angles I would be able to see one of the other two leafs in there and they would all be rendered as well, Door closed or not, the computer doesn't care.
So rather than take the chance that the visleafs will be run correctly to remove them from view we are going to manually enable and disable the entire thing from the door entity.
I've added in the window on the door/walls to help show that things are removed from view. But you can see that its a normal warehouse type storage room with crates, original I know. Now I'm going to run through the steps on making a brush based door.
Assuming you've already cut out a hole in the wall via the clipping tool and created a brush that you want to be your door, select it and hit CTRL+T or right click and "Tie To Entity". Now scroll through the list until you come to the door entity's, you can use either a normal sliding door or the rotating kind, I used rotating.
Give this new door entity a name, for my purpose I just named it "d1" to keep it simple. Now any of the other settings for the class info that you wish to customize to you liking go ahead and do so, I just left mine at default since I don't need it perfect. Once you've done settings your interested in then go to the flags option, and set any other options that you need there, for me I just left only the "Use Opens" flag checked as I don't like doors that you bump into to open. This is all we need to do for the moment.
Creating the occlude brush is just like before, make one that is the same hight and length as the wall in question, but make it skinnier than the wall itself as we will be placing this inside the wall itself of course. its okay that it goes through all your objects and the door itself, the entity is non-solid so no worries there.
Now, since our door is starting in the closed state, open up the occluder entities properties and make sure its initial state is still on "Active", but unlike our other example earlier, we are not done, Give the occluder a name, I used "d1oc" so that I can remember later on that its the occluder for door1. Alright, now we are done with the occluder, we can ignore it for the moment and go back to our door.
The door is the source of our commands to the occluder so we need to give it some outputs now.
The first command that we are going to make is a simple one that when the door is opened the occluder turns off and everything inside is now visable. So go to the outputs tab on the door entity and create this output:
and now to make the occluder turn back on when we close the door we need another output like this:
Now its very important that the last command we just wrote says OnFullyClosed since we don't want everything to disappear the second the door starts to close, that would look bad. We just want it to turn back on when the door is finished closing.
This is all the I/O commands needed for our door, we can compile and test.
Windows Windows are in almost all buildings when you think about it, even bare bone warehouses have them, why, because its free lighting and doesn't cost power, so generally you should have these in maps as well. So lets get down to a couple of uses for occluders alongside some windows shall we? And from experience we all know windows can break :P
Now once again these are all situation specific and shouldn't be applied to every single window you have in your map, just the ones that will need this. For instance if you are using a window texture that is either completly solid/unbreakable and non-transparent then just leave it as a brush and let vvis do its thing, but if its breakable or transparent then an occluder can be used for the first one but an areaportal window would be best for the second transparent option, which will be covered in another tutorial.
Now taking a look at our test map here again you can see I already have two windows in place but with the entire occlude texture already going through them for the door trigger. Rather than leave it as one large blocking entity I'm going to split it up into three sections, one for the Door and 2 for each window. ( Removed walls so you can see how ) DO NOT HAVE OCCLUDERS TOUCHING This will cause them to be registered as a single entity, don't ask why or how, it just is. There is no other documentation on this but trust me that you should never have any NAMED occluders touching one another or their I/O's will not work as you want them to.
We will have to give each piece its own individual name of course, win1oc win2oc and d1oc and the windows themselves win1 win2. Now I've just added in a generic func_breakable entity as my window with an appropriate texture to suit. Since the texture is not transparent I cannot see through it, but just like the door explanation, it will not effect vvis so its transparent in the eyes of the build engine.
now for each window entity I'm going to create an output like this:
now also, because of the door being there in this situation, to make things render easier and less processing being done by your computer over what is and is not visable I'm going to have the door that when activated will turn off and on all three of the occluders, since we should be able to see everything from within the room should we not? so no point in leaving them there. This is optional and only provides a bit more optimization but not anything too largely noticeable of course and does require more entity work to ensure that once windows are broken the door will not turn the occluder back on.
In-game we have this now:
*Compiled with walls still hidden to help show effect
So you can see that with one window broken it will still hide the spam of models on either side of it to help perform better rather than render everything. Simple and effective.
Model Based Geometry This is something a bit different to try and comprehend, due to some maps becoming more and more brush heavy models are being used in their place to help make the map look just as good. So there may be a wall or object that blocks your view completly and is not in fact a brush and does not block vvis, so lets help the players out a bit and make it perform at least half as good as a normal vvis cut brush.
So in my example here I've placed a combine door on the side of my testing building and spammed some more crates in behind it, now I'm only going to place an occluder within the center of the gate model and not the extended wall as well due to the fact that I'm going to trust vvis to block view when near the wall anyways. Now you may be wondering why I can place an occluder that hides models within a model, well the answer is quite simple, it hides models based on their bounding boxes, those yellow boxes that surround a model. So only if the complete box is behind the occluder will it be hidden, so having one inside a model WILL work in this case as its smaller than the model itself.
So right now if I compiled it would be completly hidden but still see through the cracks on either side, but I'm not quite done yet, since this is a dynamic model I am going to use that feature and make it open/closable with the occluder as well.
so giving the occluder a name its going to just be "gateoc" and the model name "gate" to keep things in the same naming scheme.
So with a single output from a func_button brush here:
and these two here on the model itself:
We will be getting this final result:
Closed
Open
Now you can use occluders within any sort of prop, I just chose a dynamic one to show that I/O uses can be done there as well.
Final Words/Warnings Some simple rules and reminders here, Occluders while handy should not be used as your first tool for fixing a bad spot in your map, the proper use of hints and vvis optimization CAN solve almost 80% of problems. These should just be used on a case by case situation and not everywhere. Overuse of almost any tools texture causes more problems than they solve. Keeping a good balance is key.
Now just to reiterate some general rules/properties for occluders:They Do Not Block VVIS.They Do Not hide Brush's or Brush Based Entitys.Occluders have to be tied to func_occluder in order to work.Occluder Entitys only occlude with faces textured with tools/occluder.Occluder Entitys can ONLY be textured with tools/occluder, tools/skip and tools/nodraw for them to work.Occluders with Names CANNOT be touching or else they become one single entity.Occluders hide any type of Prop_ entity.Occluders hide models based on Bounding Box information.
While occluders are great tools always try to find a way to use them last as there are better ways to hide areas of a map more efficiently.
This is all the information I can provide on the tools/occluder texture atm, I may update this in the future but for now I will move onto the rest of the series.
Any questions or help post here or my profile/PM box.
Lost, |
| Added: 9 months ago | Tags: lost, logan dougall, tools, tools textures, toolsoccluder, occluder, occlude |
|
 Add Feedback Provide constructive feedback. What is "constructive"?You cannot post yet!Get involved on FPSB by posting your thoughts. Give authors your feedback to help them develop. To post in this submission register or login. |
 You cannot assess yet!Moderating FPSB is in your hands - when you assess a submission your vote determines its success or failure. To vote on this submission register or login. This Tutorial in a nutshell... Detailed & Well Written  2 x Detailed  2 x Well Written  1 x Helpful  1 x Informative You cannot stamp yet!Stamps let you apply characteristics to submissions to help others understand them. To stamp this submission register or login.
 |
Half Life Storm
The Mappers Corner! |
| Membership: On Request |
| Primary Skills: Compiling, Mapping, Modelling, Motion Graphics, Texturing, UV Mapping |
| Inception: 3 years ago |
Want more? Find related tuts. |
Subscribe
New Maps
You must login or register to access this!