Talk:Controlling Geometry Visibility and Compile Times

Detail brushes

I'm greatly confused when detail brushes are refered to as a whole class of brushes, because as far as I know, the "group" just consists of the func_detail entity. Is it really a class and a group too? --Andreasen 12:35, 7 Mar 2006 (PST)

Oh, nevermind, I think I figured it out: The prop_detail is in that group too, isn't it? --Andreasen 12:46, 7 Mar 2006 (PST)

Does the lightmap resolution matter if the texture is nodraw?

Ive noticed in official Valve maps they tend to increase the lightmap to 64, but does that actually help? -Regular K 15:59, 1 Aug 2006 (PDT)

This is kinda interesting. Does VRAD compile lightmaps on nodraw surfaces? If so, it might only be for lighting models correctly. But yeah, it might save some memory and compiletime.

Try mail Valve. :P --Sortie 08:48, 27 May 2007 (PDT)

Finding outs simple, jsut take a map you've worked on and is nearly done. there should be enough nodraw in that you could spot a diff in compile times. Just mark all nodraw faces and edit thier lightmap values. --Angry Beaver 10:08, 27 May 2007 (PDT)

There are no lightmaps generated for toolsnodraw surfaces. Though there are a number of reasons why you might see nodraw brushes with a high lightmap scale. Often surfaces had a different material than toolsnodraw previously, and the lightmap resolution was reduced in an optimization pass, then later changed to toolsnodraw. Also, since it's trivially easy to set the same lightmap density for all toolsnodraw faces using the Mark button in the texture browser, I often make all toolsnodraw brushes with a high lightmap scale. Then when I'm doing a optimization pass with the 3D view set to lightmap/luxel rendering mode, I know it's not a surface I have to bother looking at for reduction. Regardless, this is not actually significant since there is no performance implication. --JeffLane 13:12, 16 Sep 2007 (PDT)

What does it mean when you get a leak without a .lin file?

<deleted>, looks like a bug fixed by recent sdk update. --22g TargetPractice 12:37, 4 Aug 2006 (PDT)

It's an areaportal causing problems here. Are you trying something complex? --TomEdwards 13:04, 4 Aug 2006 (PDT)

I think was just a bug with the sdk. I've just tried to compile the map again after the sdk update and I've now got a .lin file. Thanks for the help.--22g TargetPractice 11:08, 5 Aug 2006 (PDT)

Merging this page / Restructure

I'm thinking that if we can just explain all of these individual areas well enough, we can move them to their own separate topics, and make this page more like a category page that refers to them all (while also providing a brief overview of the system usage). The same goes for that other page. --Andreasen 03:16, 14 Sep 2007 (PDT)

This article has needed attention for quite some time, as well as a reorganization of useful information with the multiple other articles on the subject. So hats off to you for taking on this work. That said, I would make the following points:

• Before making any more changes, please describe the reason for the changes you are making, and what you are proposing for the final result of this article. If the areaportal topic is an example, this is a very poor structure and has greatly reduced the usefulness of this article. The goal of this article is to provide an overview of the tools available to a level designer when dealing with performance issues. These tools vary widely in their style and implementation, so an article describing the basic principles and tradeoffs is necessary for people to get a grasp of all that is available. I would suggest a very simple and practical explanation of areaportals remain within the article, with links to more in-depth information. The basic idea is "here's the tools and what they do, and here's links to find out more information on how to use them". Some duplication of information is fine when the presentation of the information is different and has different goals!
• Try to avoid destroying the structure of existing articles while the work is in progress. This should not be necessary. It is fine to create even significant amounts of duplicate information while the work is being done and then remove the duplicate information when it is completed and you have received feedback (if any) from other editors. As an example, the information on areaportals was removed from main article, and only a simple link left in its place. This is very poor structure for anyone now reading the article as it does not explain why the reader should be interested in areaportals.
• Please refrain from adding large numbers of questions, uncertain information, and "TODOs" into the main body of articles that were previously functional and correct, such as in areaportal (which had correct information before its separation). Questions and incomplete additions like the ones added to this article should go into the discussion pages for clarification before inclusion into the article, which should remain as definitive as possible. If you do not have enough information to write on the particular subject, you should ask for assistance instead of relaying incomplete and incorrect information.

Your effort is admirable, so I hope these comments are taken in the good faith that was intended. --JeffLane 13:06, 16 Sep 2007 (PDT)

I did a partial revert of the most recent changes to the areaportal section this article, and added links to the new areaportal article. I do not believe the changes (given their lack of precision) were an improvement to the existing text. --JeffLane 13:36, 16 Sep 2007 (PDT)

Oh, I didn't happen upon this until now.

• As a merge had been suggested, I didn't know there was any need for this topic at all, at least not containing much information. My goal was to have these pages almost completely disassembled, and I left a note about it in one of the discussion pages of these articles the day before yesterday (or something like that) without recieving any objections. Still, I agree that I had removed a little too much.
• Okay, I will leave (significant amounts of) duplicate information around for awhile, but this invites the possibility that I might forget where the duplicate information is, or get preoccupied with something entirely different before I can remove it, and if left alone, duplicate information can be tedious to merge together again.
• I had no idea that I was incorrect about something, and was asking the todo-questions in mid-editing, for possible assistance from others as well as reminders for myself. Most, if not all, of these questions have already been removed as the article reached completion, and as for the rest, isn't that the purpose of the todo comments, to ask others to supply more information? Still, I'll try to keep/move incomplete information to the discussion pages, but keep in mind that people rarely check the discussion pages to articles. Thank you. --Andreasen 19:41, 16 Sep 2007 (PDT)

I must say, fantastic work, doing all this and organizing it like so. Fantastic, and thanks for taking time to truly illustrate all this.--Gear 13:25, 16 Sep 2007 (PDT)