Overlay Textures.
Merkaba
Digital Harmony Join Date: 2002-01-24 Member: 22Members, Retired Developer, NS1 Playtester
Digital Harmony Join Date: 2002-01-24 Member: 22Members, Retired Developer, NS1 Playtester
<div class="IPBDescription">Word of warning.</div> Using lots of overlay textures means using lots of entities. As we all know (me especially), the more entities that are in your map, the laggier it will be. I highly recommend against using overlays as a frequent form of light style. <b>Only use them when they are effective.</b>
If you insist that the effect is necessarry in multiple places in your map, consider modifying the original light texture you're using so the non-light areas are a lot lot darker, and then adding the texture to your custom .rad file. Not as good looking (because of the shade change from the adjacent textures to the dark border of the light), but has a similar effect and will save you lots of entities. Compare my custom light texture ~trn_ns in ns.wad to the original HL light ~trn_lt1, and you'll see I've made the border almost black so it looked more fitting in Hera.
If you insist that the effect is necessarry in multiple places in your map, consider modifying the original light texture you're using so the non-light areas are a lot lot darker, and then adding the texture to your custom .rad file. Not as good looking (because of the shade change from the adjacent textures to the dark border of the light), but has a similar effect and will save you lots of entities. Compare my custom light texture ~trn_ns in ns.wad to the original HL light ~trn_lt1, and you'll see I've made the border almost black so it looked more fitting in Hera.
Comments
Still, it doesn't follow that ns_eclipse is the fastest-running map, it has overlay textures out the wazoo.
Thanks Merkaba for pointing that out. Not that it matters much right now on my map, but good to keep in mind.
<-->Worst entities<-->
Fog, Particle systems, func_water
Animated objects (monster furniture)
All other Animated and Toggleable and changing stuff
evironment sounds
Large sprites
Static (seethrough) stuff wich does not change
<-->Entities with better performance<-->
Eclipse 1.0 has No weldables and less switches than any other map.
<b>Edit from Flayra:</b> Sorry, this is just wrong. No NS entities that mappers can place are any worse performers then any other entities. It's the total number of entities that's a problem, not the type of entities.
This will hopefully all be a thing of the past very soon, though. I don't want to go any more in-depth than that in case it doesn't work - don't want to get anyone's hopes up - but hopefully we'll be seeing lots more overlays in the near future.
I sort of get the idea from reading a few posts but I want to know how it's done. I've never maped for HL. I'm used to other games (which we had shaders in NS, it would probalbly fix alot of headaches for lightings/special effects).
I also read about the debates of overlays vs performance issues. I'm not planning to have a bunch of them. I just want to learn how to do them.
A function entity contains one or several brushes.
A function_illusionary falls into that category (never seen is or used it but I'm prety sure the logic still applies).
Therefore, why not put all brushes for every single light effects into one to 3 function_illusionary ? This would cut down on the number of entities. Each brushes would retain theire world coordinates. Off course moving one of those function_illusionary would result in moving every single brushes in it.
Plus, you take the chance of getting leaks.. plus, all the r_speeds those overlays will make, you'll have them "extra" everywhere in your map.
Bad idea.
The best way to go is to do it by putting all of the overlays OF A SINGLE ROOM in 1 entity, like im going to do in ns_democles.
Even this sometimes is too much and will cause the entity to be rendered from everywhere in the map - VIS just does <i>not</i> like large entities. Hell, some entities randomly render 100% of the time anyway; you probably don't want to encourage that any further. <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> Smaller rooms this is fine, but in larger rooms I'd recommend at least 2, maybe even 4 separate entities for overlays.
Hopefully this will all be rendered obselete soon enough anyway...
What is the bottom line ?
If the overlay thing will be a thing of the past, do you mean that all theire performance issues will disapear with the next NS version or that no one will ever use them again ?
If they will become obsolete, then all work in progress and new maps should not used them at all. So in other words, since I want to do an NS map, I don't want to have to redesign the lighting environements in a couple of months/weeks.
Also, I still didn't get any infos on how to create them. :-(
Using lots of overlay textures means using lots of entities. As we all know (me especially), the more entities that are in your map, the laggier it will be. I highly recommend against using overlays as a frequent form of light style. Only use them when they are effective.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
thanx, i'll keep this in mind. could you perhaps give some examples of where they would be considered effective and where they would be wasted/overused? perhaps with reference to maps/piccies if you please.
oh, and you're new avatar makes you look a bit like richard d james (aphex twin) ~;)
im sure you've played you're share of TFC.. so you know the official map ROCK2.
When you release the gas, there is s brush entity that is spread all over the map to trigger the death of every player that is not wearing suit or it the water.
How do you explain that? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
im sure you've played you're share of TFC.. so you know the official map ROCK2.
When you release the gas, there is s brush entity that is spread all over the map to trigger the death of every player that is not wearing suit or it the water.
How do you explain that? <!--emo&???--><img src='http://www.natural-selection.org/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--> <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
There are 2 issues here.
You <i>can</i> have an entity covering the whole map, but if the entity is visible, every face will always be drawn because entities don't have any sort of inherent vis culling feature--either the entire ent is drawn, or the entire ent is ignored. When the player is in a part of the map that draws the entity, every face in the player's view will contribute to r_speeds, which is why you don't want to use <i>visible</i> large ents.
The brush ent on ROCK2 is invisible, so the resultant problem with r_speeds is doesn't exist.
In addition to the above problem, NS has specialized code that checks the distance from the player's position to the <span style='color:gray'>ent</span> origin to determine if <span style='color:gray'>ents</span> should be removed (this is mostly a commander mode substitute for the vis based check on player position, which doesn't work as the commander is floating in the void). The larger an entity becomes, the larger the TopDownXYCullDistance must be set in the map's info_mapinfo to keep it from popping in and out of view... this means that other entities will be drawn from greater distances too in commander mode, again causing higher r_speeds. In my experience, commander mode r_speeds are far more difficult to keep under control than ground player r_speeds, so this is a significant detail.
<span style='color:gray'>EDIT: ent, not brush (CSG on the brain again <!--emo&:(--><img src='http://www.natural-selection.org/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo--> )</span>
TFC doesn't have to work around the problems of commander mode, so a visible entity could theoretically be created in a TFC map without any problem provided the mapper doesn't care about the entity's own r_speeds hit from having the faces drawn everywhere.
(btw, unrelated... 1000. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> )
Forgot that brush based entities (triggers) are invisible.. doh!
I'm curious how that misconception came about in the first place... *shrug*
But my fingers are lazy and 'entities' is twice as many chars (oops, another one) <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
<!--QuoteBegin--KungFuSquirrel+Mar 29 2003,06:44 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (KungFuSquirrel @ Mar 29 2003,06:44 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--Flayra+Mar 30 2003,12:44 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Flayra @ Mar 30 2003,12:44 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Note my edit in Olli's post above (sorry to edit, just don't want incorrect info going around).<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->I'm curious how that misconception came about in the first place... *shrug* <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'd guess that it springs from the assumption that items that place high demands on the client side (renderer, etc) would also affect server performance...
Now I've gotten curious--what resource is causing the server performance hit if every map <i>entity</i> ( there you go watch <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> ) is causing a uniform drain... I had (apparently incorrectly) thought that something like a static light or path_corner would cause less of a problem than an entity like a func_button that has to think, be used, etc. (although now that I really look at it, the number of times a function is called relative to total the number of frames would normally be low, causing the CPU hit to be an uncommon event). If it isn't already obvious, I haven't looked under the hood of the SDK at the actual game code--I've just been working with the compilers.
EDIT: not sure what happened with those quote tags, apparently it now wants a date and time for every entry...
And no one realy answered my other question : should NS mapers use overlays ?
If overlays won't be used in the next NS version, what will happen to maps that do ? I don't expect to have a finish map in 3-5 months and NS's new version might come out by then, so <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Create a brush with the base light texture, create a func_illusionary with NULL texture on all sides in front of this brush, then set it to rendermode additive and pick a fx amount. Next texture the side facing away from the original brush with the overlay texture and the same parameters as the base light texture.
- and voila, overlay <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> (hmm maybe I should write up a tutorial with pictures and stuff)
There's a couple out there. I'd written one myself for my site a little over a year ago but removed it a few months back. Can't remember off-hand where I saw the other versions of it...
Here I'm using C1A0_LABW3 from halflife.wad as an example. On the left, the texture scaling is low, causing the texture to repeat itself on the brush. Since each "patch" of texture is formed by two wpolys, the end result would be a wall made up of many little polygons. Your brush will be sad. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
On the right, the texture is scaled properly to fit the face. Only two wpolys are formed. Now you have a happy brush! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> Just be sure to put the NULL texture on faces that the player cannot see, and your solid entity will be ready for action.
(Please excuse the bad image quality and fake wireframe, I used MSPaint <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->)
Regarding the post above me.. why does HL use multiple polys to repeat textures like that? Don't 3D accelerators wrap textures in hardware?
I have some rather large overlay ents (<!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->) in Eniant, and accept the average of 15 more w_polys in exchange for the less in entities.
<a href='http://collective.valve-erc.com/index.php?doc=1037724409-55074800' target='_blank'>Overlay Lights on VERC Collective</a>
Here I'm using C1A0_LABW3 from halflife.wad as an example. On the left, the texture scaling is low, causing the texture to repeat itself on the brush. Since each "patch" of texture is formed by two wpolys, the end result would be a wall made up of many little polygons. Your brush will be sad. <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
On the right, the texture is scaled properly to fit the face. Only two wpolys are formed. Now you have a happy brush! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> Just be sure to put the NULL texture on faces that the player cannot see, and your solid entity will be ready for action. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Almost this entire post is flat-out wrong. Not to mention that it's not even applicable to the topic at hand. You're right that texture scale can lower wpolys, but past that first paragraph everything is commonplace myth. Half-Life doesn't even render its polygons that way.
Tons of good info and myth crushing. <!--emo&::asrifle::--><img src='http://www.unknownworlds.com/forums/html/emoticons/asrifle.gif' border='0' style='vertical-align:middle' alt='asrifle.gif'><!--endemo-->