Forum posts

well I'll be darned. Thanks for the info!
camplo

It makes me mad cause I have made several successful textures that included transparencies....Somewhere along the line I got something mixed up and cannot get this texture to work right? I understand that the index color has to be blue. Its in the right spot ie the last spot on the palate. Still not working. I have two other textures that do work properly but in the wally they are displayed improperly. I'm riiiiiiiiiiight.

I just need a simple how to guide for transparent texture making. I use photoshop. Seem's like it should work rather copy and paste the image into wally or save as jpeg/bmp. And theres the color reducer which lets you set the palate. There's the translate color to fix the index. Whatever. Someone help me please.

everyone hiding their secrets or something?

nevermind I can't repeat it....

I did it on accident but it seems I might have found a way to make a clipping func_illusiony - non solid. The entity of the brush was func_ill with regular textures on the exposed sides with clipping texture on the non exposed sides resulting in a brush that did not clip bullets but clipped my player. if this really works then it beats putting a clip brush inside of a non solid func_ill, cause its just one brush.

I was just wondering what settings would get me some pretty trippy lighting. Like thick saturated colors bleeding into others almost as if made of melted crayon versus light. You know, Some really contrasty stuff.

So I made separate brush its own func_ill, the problem has been fixed. Thanks

I always do full vis. I had this problem in other maps and I am almost certain that I tried making them separate func_ills and that did not remedy the prob.....almost certain. Worth another try though. Here's another shot, one brushing working as intended while the brush in circle 2. is not.

The circled brushes are off in the distance and you looking from behind another brush that is supposed to be vines. The vine brush directly in front of you is showing completely clear where the brushes off in the distance are being drawn. Doesn't bother me but the asshole mappers at the server are going to complain.

Without immediately posting another pic, If you look at the pic and zoom in close enough. You'll notice that you can see the the vine brush (func_ill) on top of the vine brush taht is immediately in front of you. from the top view it would like like this

---

------|

| you| looking at -> | |

---

------|

But somehow the brush farthest away from you is on top of the brush immediately in front of you. I've always had this prob but never looked into how to fix it.

Help.Me!ugh.

See how the other brush shows over the top of the closer one. Thas no gud. They are func_ills with render set to the texture - some light. Will it still do that if i turn the render mode to normal? I don't care, cause i like the glow and would like to keep them glowing this way if i could. Texture lighting doesn't give the same glow.

Somewhere there has to be an official short cut list. I was able to find unlisted short cuts on what seemed to be "legit" list in a matter of seconds. For example ctrl-tab.

OK I think I got. Using Func_detail will eliminate uneeded cutting. Especially important when A brush is twisted. Any face that is mergable will be merged....A square made out of one brush versus 6 pyramids will have the same w_poly....A brush that is a func_detail still is affected by surface area and texture scaling....but it won't cut world brushes causing more unneeded faces.....

I just noticed that you were actually trying address my post.

"The second method of splitting brushes is the one that you are asking about here - putting a brush on top of another brush (like a cube crate on top of the floor) "

Thats not exactly what I meant. They say that to brushes touching cause cutting and thus more w_poly. What I said vrebatim above was

" So lets say you have a solid square made out of 2 smaller square brushes. The compilers can merge all faces as long as they are on the same plane?...thus it would big the same w_poly as if it where only one brush...."

In other words You have a cube....its 128x128x128. You clip the brush in half horizontally....then what? I'm under the impression that the compilers will merge the faces from 64x128 back to 128 x128 as long as it doent get cut by the sub divide that is....

OK, thanks for the informative post. Lotta good stuff in there but nothing pointing to the fact of whether or not the splitting of faces increases w_poly significantly. You know I had a map that was fairly open and unhint brushed. At first my ground texture was scaled to 2, but I later tried the texture at a scaling of 1 to find out.... I only gained like 80-50 w_poly, which ain't worth a pinch of salt so I of course went with the higher resolution, better looking, ground texture scaled to 1. I think right now at this point in my understanding level, my argument is that the amount of textured surface area being drawn is the deciding factor in whether or not an area has "too much" w_poly or not. So in this war the null texture is the first hero since its gets rid of a huge amount of unseen surface area and the 2nd hero would be keenly placed hint and skip brushes which as well remove large amounts of unseen textured surface area AND in the case of multiplayer, stops the drawing of players who should not be seen.

Just cause its old doesn't mean I don't want to understand how it works, dude, not to mention its the engine for the most popular fps ever..

Not too mention are you guys even mapping for multiplayer? W_poly and map design is very important and can be the difference between a map that can be played when the server is full and not lag like crazy and map that causes people to frickin time out. It, makes, a, difference.

Ok heres where I am at... My w_poly has way more to the with surface area of rendered texture than the amount of brushes and or cuts, cutting, faces, bla bla bla.

Ok heres my guess...... The compilers can merge faces...but not brushes. So lets say you have a solid square made out of 2 smaller square brushes. The compilers can merge all faces as long as they are on the same plane?...thus it would big the same w_poly as if it where only one brush....

Thanks.

Well I just did my own test and came to the conclusion that as long as the faces not showing have null on them that do not affect w_poly, I made a small world 256x256, a floor with a sky box. The variable was identical to the first with the exception that the floor was cut into 8 blocks with only the face, facing the world textured while all other faces where null. Both maps had a w_poly of 1.

I want to add things like a side walk, borders on walk ways, windows...etc etc
Is it really better for me to cut up my ground brush and wall brushes to add these things or would I benefit from using more brushes of func_detail, func_wall, and func_illusionary. The goal is to keep w_poly at its lowest.

How do you turn off the textures. I can get wire frame to work now but how did you get the textures to not draw?

Yeah I guess you can, or atleast try. Try doing it when the objects planes are off grid though... don't work out.

Turns out with that brush the angle got too sharp and could not be rendered so I just reshaped it so that face wasn't showing at all.

I still can make it break though

The brush on the left is not a tetragons but the brush on the right that appears to not render right is. The shape on the left has an extra vertice that is parallel to the other. So yeah I am starting to get better I guess. Thanks for helping you guys. This is the only place for support it seems.

Yeah I've been seeing that tetragons make hammer happy. thanks for the link. =)

I have the flouting point thingy installed. my problem is twisting faces. I have brushes that have been rotated of grid, so certain plains that needed to be flat were impossible to make since the true flat plane lay off grid. I see that now.... So how big of a deal is it to have a vertice lay off grid?

deleted

Thats what I do.

Vertex manipulation is so great. It makes brushing a lot more like molding something with your hands versus clipping everything. Its new to me cause I have been mapping in microbrush2 which has no vertex manip. I randomly shout out the words vertex manipulation because I cannot control my joy. Creating is much more fun with it. IF only they would come out with better software to map for gold source. Something with merging, a moveable grid, brush creation and manipulation inside the 3d view, pretty much a microbrush hammer hybrid....

vluzacn's HammerFloatingPointEnabler - yeah thats what installed. And I am sorry to bitch about it, thers not point in bitching but it frustrates me so this is my "release" As Bruce described hammer clip tool will set vertices off grid by tiny amounts no matter if you used it properly or not. The more "complex" the shape maybe the more hammer stuggles? I will put this ctrl-m to exercise really I think I'd be better off just going in and checking the vertices myself and use vertex manip whenever possible versus the clip tool in general. In microbrush2 I clip with not one grip what so ever and have brushed out several maps with it no prob, so its not like I am unfamiliar with the tools. I have committed myself to actually using hammer to brush out maps since I get tired of porting the map back and forth not to mention in microbrush I cant see any textures as I create. So right now I will only use microbrush to merge and mirror when needed.

hammer says my brushed structure is invalid but it compiles and looks fine in game so why it dont like it...I don't know.

wait it doesnt say that its invalid..hmmm.. whatever

And ctrl-m = manipulat brush not put every vertice on grid....I have this brush with an off vertice, usued ctrl-m to move it up 1 unit and then down one unit. Its a no go. Shift-V for the win.

are you sure its not hammer?

I can't call it. microbrush got er done though....ps-I have that new hlfix thats not called hlfix but it is supposed to be better but I forget what its called.

I want to say that it was just too complex? I'm not sure but I ported the map to microbrush (such a hassle) and mirrored the group of brushes and even rotated them.....then ported back to hammer (ooooh myyy gooooodnesssss) and everything was fine....The structures still come up as invalid and it compiles just fine and looks fine..now....

Wow, microbrush2 is calling my name...merge city.

So I got a structure I made. When I duplicate it and flip it horizontally and move out of the original everything looks good in hammer besides both structures coming up as invalid. I couldnt be the wiser to why they come up as invalid...but it compiles... and the original brushes are created as they should be, the mirrored brushes come up almost as they should but but have a few over hangs that arent supposed to be there and one of the vertices is way off where to brushes meet so its so obvious. They show in hammer just fine as they should appear in game...I have the new hl fix installed already...may I should try the old hl fix?

ok merging vertices was easy, just drag it to, and it ask.... so now how to add them.

Do I have to worry about merging brushes for the sake of optimization or am I correct that the compilers merge anything mergeable anyway.

Secondly, how or can I add or delete vertices?

Hey while I got your attention quick question please. I could merge brushes in microbrush 2.0 but not hammer. I've read that the compilers while merge any mergeable brush....so I don't have to worry about that do I?

I just fixed it with the vertex tool....one of the corners was slightly off grid and I fixed it with vertex tool..sorry for bitchin.

I cut two brush at a 45 degree angle and then join them.....and the planes arent perfectly lined up? Really?

well you shouldn't have entities touching he void anyway I would imagine but they are pushing the envelope so who knows what tomorrow may bring.

so I'm thinking, ok func_details are entities, which don't cut world brushes....so you could just about make a cut free map now. Sweet.

Func_Detail set to 2...cuts nothing...blocks vis....Func_detail everything for the win?

yeah according the post of vhlt, detail level 2 cuts nothing...

I made a map once where way too much was separated for the sake of optimization....cause thats the kinda person I am.

The dedicated server issue comes with a boat load of problems. First of all I can't even get it to the point of actually being able to join it without getting the protocol error. I But even worse is that I can get a server to start and run (even though I can't join it) but I can't use my map. It tells me bad surface extents but at the same time I can load it on my steam cs. Another road block it seems, the help is appreciated.

The separation of brushes to stop cutting is old news. I just started mapping this year and tutorials I have read that included such things are pretty old. But making your touching brushes alternate between world brushes and func_details is another beast. Sounds like it would work to me though. I bet someone knows for sure.

Isnt the X2 gui newer than atoms compilator?! pretty sure it is.... but not sure.

I'm too noob to know why actually. Maybe your map contains less complex shapes than mine? Did you install that thing that makes hammer export maps more accurately?

To your other statements in no particular order. Large areas and large open areas are not the same thing at all. A large area could have a huge building in the middle thus blocking vis until you climb to a height that is impossible to not see all other vis leaves.

About the e_poly vs w_poly. Most of the maps on the server have w_poly under 1000 and a lot of the times are almost always lower than or in the range of 500 w_poly. We have maps where the w_poly hits 1200, maybe a lil more in others. We have maps where w_poly never breaks higher than 350. Still the lag is directly tied to the e_poly from my experience. The lower the w_poly the more e_poly you can handle but pretty much NO MATTER WHAT when the e_poly hits 30-40 thousand and beyond, fps drop linearly as e_poly rises further. Don;t matter if the w_poly is 1000 or 100. The difference I think is something like 10 thousand e_poly's more the engine can handle before lagging when you have really low w_poly

"That's not right. func_detail still cuts other func_details. It does not make sense to make everything func_detail."

Well I thought if a brush isnt touching another, it wont cause it to cut. So I figure if a had 4 touching brush lined up and made, key word here, every other brush a func_detail, then no brush would be touching another brush inside its group, in other words. WorldBrush||Func_Detail||WorldBrush||Func_detail
Now no brush is touching another brush that would cause cutting. Does it not work that way?

"Bad idea. The func_detail blocks vis, but the floor has to be in one VIS-leaf. So for the engine the objects on the floor are in the same VIS-leaf as you and renders them though you can not see them."

I dont understand...The floor has to be in one vis leaf? you lost me. If I have a room sealed into two separate compartments by a wall that is func_detail....I still see whats on the there side?

Forgive me for being a noob, and thank you for responding!

what really is unclear is the detail 1,2 and 3. I just set them to 2 because according the post of the new vhlt tools, 2 doesn't cut anything.

" A large area means that everything visible from that area must be loaded even if it isn't exactly visible by the player."

That is untrue with hint brushes.

"func_detail is a mix between world_brush and func_wall. Like func_wall it does not cut other world geometry. Only other func_details, whose detail_level is the same or lower, get cut.
A Func_detail's clipping hull can be removed (make it similar to func_illusionary).
In all other points it is equivalent to world geometry. It casts shadows, it blocks VIS, and so on."

Now thats good to know. So if I make every other brush a func_detail I'll have my shadows and lower my w_poly theoretically. When I was under the impression that func_detail didn't block vis I turned choice brushes into func_detail only to have a small increase in w_poly but very small. Since it blocks vis and it would make sense to, for example, make the walls of a building func_detail while the ground is a world brush thus eliminating cutting there. My node size is already 64 and if I could make it smaller I would...but cannot. I still see room for improvement....Its not like I enjoy using hint brushes but lag is an issue when mapping for a online server. I did some more studying today and came up with this. At 800 w_poly and 38800 e_poly my machine lags about 2-3fps. What I could not conclude to is how many players were being drawn to create 38800 e_polys but I think I know how to figure it out. So in a nut shell the less players being drawn the less e_poly will be the less frame lag there will be. The e_poly from my experience has always been the main influence on lag online. It is still evident that w_poly plays a small role allowing for maybe 4000 more e_poly before lagging if the w_poly is something low like say under 400 w_poly. Long story short simple use of hint brushes always beats vis even at a node of 64(subdivide is 256).