Forum posts
Looks good. Really nice.
Postin' yer .qc file content could be o' use here. 
Doesn't look bad for a first one, not at all.
One problem with it, and I've had it myself before, is that the wood relief continues at the edges, while there's little wood left there to show relief. This occurs especially at the left and right of your texture but also a bit between the planks, vertically seen.
The dark spots are nice, but on real wood the relief would curve around it. The color makes the wood look 'wet', too. A lighter color would suit better I think, depending on what sort of wood you need. More variation in both color and relief would improve the texture, anyway.
But, again, good work for a first texture.
One problem with it, and I've had it myself before, is that the wood relief continues at the edges, while there's little wood left there to show relief. This occurs especially at the left and right of your texture but also a bit between the planks, vertically seen.
The dark spots are nice, but on real wood the relief would curve around it. The color makes the wood look 'wet', too. A lighter color would suit better I think, depending on what sort of wood you need. More variation in both color and relief would improve the texture, anyway.
But, again, good work for a first texture.
Do a search for texture tutorials or sites from texture artists. What also helps is looking at reference photographs and studying other textures. It will take some time before you get the hang of it though.
Anyway, what I usually do when creating textures is:
1. Collecting (lots of) reference images.
2. Creating a basic shape image, usually just a black 'n white line-drawing.
3. Creating a basic color image, layering it over the line-drawing.
4. Adding a greyscale relief image, to add depth. I often save this as another file for convenience.
5. Adding detail, refining the texture. Uses a wide array of brushes, effects and what not.
6. Testing. And untill I'm satisfied with the result, I go back to step 5 again and again.
You're probably going to experiment a lot to find out what brush and what effect suit what particular material best. Also, some people start with photographs as a base for their textures, others (like me) go for totally hand-drawn. That depends on what style you're aiming for.
I would advise you to just try something and be critical on your work (and ask others). You'll learn.
Anyway, what I usually do when creating textures is:
1. Collecting (lots of) reference images.
2. Creating a basic shape image, usually just a black 'n white line-drawing.
3. Creating a basic color image, layering it over the line-drawing.
4. Adding a greyscale relief image, to add depth. I often save this as another file for convenience.
5. Adding detail, refining the texture. Uses a wide array of brushes, effects and what not.
6. Testing. And untill I'm satisfied with the result, I go back to step 5 again and again.
You're probably going to experiment a lot to find out what brush and what effect suit what particular material best. Also, some people start with photographs as a base for their textures, others (like me) go for totally hand-drawn. That depends on what style you're aiming for.
I would advise you to just try something and be critical on your work (and ask others). You'll learn.
Even better.
Thing is, I probably do some more planning ahead when mapping. So I hardly ever come across a situation where carving would be faster. I also think it's the experience you have with a tool, or the feeling for it, that plays a role in how fast or easy it really is.
When I need a grass and a floor brush, I create one and copy it by shift-dragging it, so you could say I don't even use clipping in this situation.
But yeah, I'm a control-freak, so carving isn't my thing by nature anyway.
When I need a grass and a floor brush, I create one and copy it by shift-dragging it, so you could say I don't even use clipping in this situation.
But yeah, I'm a control-freak, so carving isn't my thing by nature anyway.
I'd use the clipping tool, but hey.
Hmm, true point, Habboi. These forums lack a 'topic was moved' notification.
Gunter, this is the HL1 forum. Plus, carving has very little to do with this.
gunpun, the transition is as simple as using two brushes: one for the grass part and one for the floor part. Make sure they do not overlap, but touch each other at the transition edge. That way you'll avoid the ugly z-fighting effect, where two surfaces 'fight' to be rendered on top of the other.
gunpun, the transition is as simple as using two brushes: one for the grass part and one for the floor part. Make sure they do not overlap, but touch each other at the transition edge. That way you'll avoid the ugly z-fighting effect, where two surfaces 'fight' to be rendered on top of the other.
That's correct. You could put a note about it in your readme file (or somewhere else where it'll get more notice) but other than that, there's nothing you can do.
Oh well, it's not as if it's looking that awfull without 32 bpp...
Oh well, it's not as if it's looking that awfull without 32 bpp...
Look at wikipedia for Phong and Gouraud (or Lambertian) shading. Explains a lot.
I've been working on a model loader for a school project recently, hence my little research.
I've been working on a model loader for a school project recently, hence my little research.
Hmm, it's a layer of trees and nothing behind it. It's not that there's not enough trees, it's the way they're used that lacks. Besides, the background trees don't work well together with the ones in the map area.
In HL it was Gouraud or at least basic diffuse shading that was standard, Phong adds some specularity and color to it as far as I know. I always think it looks so plastic.
I mean, why would Doom3 waste all these resources when there's good 'ol Phong?
Nice PSP bytheway. Good work on the details like buttons and trims.
I mean, why would Doom3 waste all these resources when there's good 'ol Phong?
Nice PSP bytheway. Good work on the details like buttons and trims.
Actually, Gouraud shading is more of a standard, not necessarily Phong shading. Half-Life doesn't use Phong shading, neither does Half-Life 2 (shading is pretty material-dependent there anyway).
And what's wrong with smoothing groups? They just affect the vertex normals, nothing fancy or immoral...
And what's wrong with smoothing groups? They just affect the vertex normals, nothing fancy or immoral...
Now my only question is, do I need this set strickly because of my graphics card?No. HL doesn't start in 32 bpp mode by default, so it's the same for everyone, not just you.
Use the -wadinclude csg parameter. You specify a wad name after that parameter and csg will put all used textures from that wad into the .bsp file itself. It doesn't get easier than that for the user.
I used to get that glitch with my volumetric light beams, as seen in Guidance. Usually happens when a lot of overlapping is going on. Changing HL's color depth to 32 bit (wasn't the startup parameter for that -32bpp?) did the job. Keep in mind - Windows color depth may have been set to 32 bits, but a game does not necessarily use these setting.
Bytheway, that mech looks awesome.
Bytheway, that mech looks awesome.
Such a topic title from you, Seventh? I had expected better of you... 
What an awfull songtext. Disgusting.
What an awfull songtext. Disgusting.
Well, perhaps that's why letting others take a look at the map could help. It might be that you've adapted a work method that structurally causes such problems to pop up?
The last years I mapped for HL hardly ever gave me problems, while in the first time I encountered many.
Same goes for programming: only recently I learned how to avoid memory leaks, something I didn't know how to for years. That's all because some other guy took a look at my code.
The last years I mapped for HL hardly ever gave me problems, while in the first time I encountered many.
Same goes for programming: only recently I learned how to avoid memory leaks, something I didn't know how to for years. That's all because some other guy took a look at my code.
Hehehe... that's a nice one, ZL.
He only uses 6 wads...
The .map file is organized into entities: an entity contains some data of it's own, and certain types can (or must) also contain brushes. So I organize brushes under entities because that's the way they're organized in the file itself. World brushes belong to entity 0, the world entity, bytheway. You'll need both of these numbers if you want to use Hammers Go To Brush number action.
Anyway, perhaps you can send me the map? Looks like you could use some more help than just a tool (plus, it could give me some more insight in what causes this particular problem).
And just a thought: I assume you didn't compile the map often? Looks like a lot of problem sources that seemingly all pop up at once. What helps me a great deal is saving the map under another filename after every major change, and compiling the map often. Good back-up system, allows you to fall back on an older version when you mess up one, and makes sure you always get a working map, or one with only few problems.
Of course, it's a little too late for that now, but still...
Anyway, perhaps you can send me the map? Looks like you could use some more help than just a tool (plus, it could give me some more insight in what causes this particular problem).
And just a thought: I assume you didn't compile the map often? Looks like a lot of problem sources that seemingly all pop up at once. What helps me a great deal is saving the map under another filename after every major change, and compiling the map often. Good back-up system, allows you to fall back on an older version when you mess up one, and makes sure you always get a working map, or one with only few problems.
Of course, it's a little too late for that now, but still...
-wadinclude is a csg parameter, not a HL startup parameter. So your zeditor.wad never gets included... that's probably the source of your problem.
Those faceys are nice. Funny.
Well, by selecting the arch shape rather than the block shape when creating a brush?
Uhm, actually... an env_beam has some properties of it's own for things like this. How about Life and Strike again time?
Just because I like things to be complete, I think it'd be a good idea to be able to raise the tiny scales to a minimum and lower the huge scales to a maximum... Now if there were a way to identify the brushes associated with entities and either set them aside or "forget" them so that only world brushes were affected by the resizing of the textures,I would be even more inclined to use it. That way the lights and other little what-not wouldn't be changed.That's possible, the current version already checks what entity a brush belongs to. World brushes belong to the world entity, which is always the first one, so yeah. However, if an entity surface causes the problem, then you'd still want to fix those. I could throw in something that tries to keep the right x/y scale ratio while fixing, too.
But, like you say, it doesn't help me with my current problem. I think I can only find this by ripping the map into sections and recompiling each section... Divide and conquere...
As for your problem, rather than ripping the map apart you can also put a big brush over half of the map and compile. If the problem is gone, it's in that covered half of the map. Or perhaps use cordon compiling (which essentially makes Hammer only put the things within the cordon to the .map file that is being compiled).
Perhaps texturing offending surfaces with AAATRIGGER, though, so one could easily see which face was messed up.Then Daubsters solution sounds better: invalid textures can be found with Hammers problem check so that'll take you to the problem straight away.
Hmm, I see what you mean... looks like a good idea. It could get difficult to retreive this info though, probably some looking around in the registry... and it would only work for Windows then (though I really don't know if this tool works on Linux in it's current shape :P).
Thanks for the help, Seventh. I inserted your text, I'm now checking for the 's' (not only for violations, but also for brushes and entities :P) and I'm updating the log formatting. How about a nice 'n tidy html format, which allows much easier-looking formatting?
@[VDC] Rad Brad: I could do a little work now and then. If you've got some suggestions, feel free to PM or mail them, or just post it here. Perhaps a tool (or an addition to this tool) that also fixes the 'violating' scales to the minimum/maximum you set? Would save you some work...
@[VDC] Rad Brad: I could do a little work now and then. If you've got some suggestions, feel free to PM or mail them, or just post it here. Perhaps a tool (or an addition to this tool) that also fixes the 'violating' scales to the minimum/maximum you set? Would save you some work...
Heh, thanks for the fast comments. Just a mis-type after a quick recompile. Fixed now.
About the English, feel free to rewrite it and send me a message.
About the English, feel free to rewrite it and send me a message.
Ok, I updated my tool: it now logs the report to mapname_log.txt, storing it in the same folder as the .map file. Violating texture scales are now sorted by entity and brush number and the log file contains a little text info to get people started.
Here's the download, again.
Here's the download, again.
Heh, that first one is nice.
The second one would probably be better with a single floating z, slowly moving up untill it pops.
The second one would probably be better with a single floating z, slowly moving up untill it pops.
I'm guessing that the decimal following the error text is the actual size of the texture?Yep, that's the scale that violated your tresholds. The line number is given in front of it, and .map files can be opened with simple text editors like Notepad. I wouldn't recommend MS Word for these plain text files. Personally, I use Notepad++ for things like this.
Yes, you can edit the .map file and load it into Hammer, provided you didn't make it an invalid .map file of course.
Tommy14 recommends scales between 0.1 and 10 bytheway, so I think those would be good tresholds.
A suggestion for future versions would be to add the brush number to your list as well as the texture size and a method for saving to a log file.Good suggestions, I'll see what I can do. The logging is definitely a good one, I had it in mind when I was busy with it but thought, oh well.
I figured out how to get brush numbers now so that's no problem either.
Too bad this wasn't the cause of your problem though...
Well CP, your thread seems quite popular. smile -Heh, yeah... I was surprized to see 44 posts...
And man, you guys got much further than I could've gotten on my own. I was stuck at 9 while posting this... We've done more than 50% by now methinks.
I assume you know enough about programming to see this wasn't a scripting job...
The Wicked
This is one of those web-based puzzle games as we've seen before. So that's nothing new here - most of you have been playing one of these through a previous thread.
However, I'd like to do something different here. Let's tackle this game as a group rather than each on his own. Once you finished a certain level, you post the url of the next level so everyone can start working on that one. I wonder how far we can get that way.
This does mean that it's going to be big spoiler alert from here, obviously.
So, who's in?
This is one of those web-based puzzle games as we've seen before. So that's nothing new here - most of you have been playing one of these through a previous thread.
However, I'd like to do something different here. Let's tackle this game as a group rather than each on his own. Once you finished a certain level, you post the url of the next level so everyone can start working on that one. I wonder how far we can get that way.
This does mean that it's going to be big spoiler alert from here, obviously.
So, who's in?
If I'm not mistaken, the aaatrigger texture has little effect on the working of the entities themselves, it's just a convenient way to texture triggers to make them easier to recognize. However, replacing them with the clip texture causes these brushes to block the player...
Odd problem if Hammer randomly changes your textures. I never encountered it. Textures showing up black might be a driver issue perhaps, otherwise I wouldn't know...
Odd problem if Hammer randomly changes your textures. I never encountered it. Textures showing up black might be a driver issue perhaps, otherwise I wouldn't know...
Hehe. If anyone would like to see some more functionality like this, give me a yell. I can occasionally do a little program now and then.
Oh, and for questions, demands and bug reports, you can PM or mail me - I prefer mail, since my PM box is at an all-time full... mail adress can be found in the readme or you can mail through my sites contact form.
Oh, and for questions, demands and bug reports, you can PM or mail me - I prefer mail, since my PM box is at an all-time full... mail adress can be found in the readme or you can mail through my sites contact form.
May I present you: Scalehunter
Simply drop 'n drag your .map file onto the program, enter the minimum and maximum texture scale and you'll get a nice little report. Have fun with it.
Simply drop 'n drag your .map file onto the program, enter the minimum and maximum texture scale and you'll get a nice little report. Have fun with it.
Did you accidentally hit 'fit' on a small, 1 unit thick brush or something?My little brother did that a few times. This error and my explanation have caused him to more or less hate the Fit button.
And then I have to explain it's usefull now and then, when used carefully...
Hmm, I've just found the .map file format specification on the old VERC, turns out texture scales are found at the end of each brush plane (oddly enough, faces are stored as planes and their intersections are calculated to get the edges and vertices... :S). A line like this:
( -128 384 128 ) ( -128 384 0 ) ( -128 640 0 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 2 0.1
stands for a face with it's texture scaled up 2 on the x axis and 0.1 on the y axis. Might be easier to find that way. A tool that checks texture scales surely is a lot easier, too... hmm, I'll see if I can do something.
but, as you demonstrate, they don't always provide consistent interpretations when referencing, dereferencing and casting are involved.I wasn't demonstrating anything with the STL string, but I tried to explain that char arrays and char pointers are a little different (than each other).
Namely, char*'s are compared as if they were null-terminated strings, char[]'s are compared by adress as you stated.
Anyway, that's the C way of dealing with strings, personally I prefer the C++ way with it's STL string. It's easier to work with than char arrays or pointers, and in case you need a char*, there's the c_str() member function (and to get a char array theres data() and copy() I believe). And usually workability is more important for me than absolute best performance so unless I need otherwise, I work with strings.
Assuming this is for CS 1.6, then you'll have to do the following:
Use a texture which name starts with the { character. The blue parts (actually the last color of it's palette, but that one is usually made blue) will become transparant.
To let the engine know you want the texture to have transparant parts, you must make an entity from the brush the texture is applied to, and set it's Rendering Mode to Solid and it's FX Amount to 255.
That's it.
Use a texture which name starts with the { character. The blue parts (actually the last color of it's palette, but that one is usually made blue) will become transparant.
To let the engine know you want the texture to have transparant parts, you must make an entity from the brush the texture is applied to, and set it's Rendering Mode to Solid and it's FX Amount to 255.
That's it.
STL provides a string class. Not a 'fundamental' type perhaps, but a usefull one nonetheless. It's member function c_str() returns a char* just in case you need that for function passing and whatnot.
I usually don't work with char arrays, but char pointers instead. Though these seem to be similar, using char* rather than char[] gives different results. For example, the == operator does actually compare the strings they contain:
char* a = "hello";
char* b = "hello";
if(a == b)
cout << "True";
else
cout << "False";
This prints True to screen. Changing b to "hello1" gives False. Comparing a string (#include <string>) with a char* gives the same results.
As far as I understand, the == operator compares char pointers as if they were null-terminated strings, comparing char by char, while it compares char arrays by their adresses.
I tested casting char arrays to char pointers, too, which gave interesting results:
((char*)s == (char*)t) == false, while
((char*)s[0] == (char*)t[0]) == true, provided both are assigned the same string value.
Not everything is clear to me, but there's a subtle difference between arrays and pointers. &s, for example, is the adress of the array, and while it's the same adress as the first element in the array (&s[0]), it's not of the same type: (&s + 1 == &s[0] + 1) == false.
I usually don't work with char arrays, but char pointers instead. Though these seem to be similar, using char* rather than char[] gives different results. For example, the == operator does actually compare the strings they contain:
char* a = "hello";
char* b = "hello";
if(a == b)
cout << "True";
else
cout << "False";
This prints True to screen. Changing b to "hello1" gives False. Comparing a string (#include <string>) with a char* gives the same results.
As far as I understand, the == operator compares char pointers as if they were null-terminated strings, comparing char by char, while it compares char arrays by their adresses.
I tested casting char arrays to char pointers, too, which gave interesting results:
((char*)s == (char*)t) == false, while
((char*)s[0] == (char*)t[0]) == true, provided both are assigned the same string value.
Not everything is clear to me, but there's a subtle difference between arrays and pointers. &s, for example, is the adress of the array, and while it's the same adress as the first element in the array (&s[0]), it's not of the same type: (&s + 1 == &s[0] + 1) == false.
Ant... lion? Hehe... hehehe...
Those checkboxes are for texture alignment. They're not magical stuff - in the end it's just texture coordinates for the engine to handle, all the same.
Usually, you only notice the difference on angled faces. With world alignment, all textures are aligned along the axis. If you have an angled face, the texture looks stretched (because, the texture is applied as if you were looking at it from one of the 2D views - from that particular view, the texture looks ok, but an angled face is always longer than you can see in the 2D view).
Face alignment aligns the texture taking the surface normal (direction) into account, solving the stretching problem.
This is why flat, axis-aligned surfaces have both checkboxes checked, but other surfaces can have only one checked.
Aanyway, onto those surface extends, those are usually caused by extreme texture scales. Above mentioned alignment modes have no effect on this as far as I know.
Usually, you only notice the difference on angled faces. With world alignment, all textures are aligned along the axis. If you have an angled face, the texture looks stretched (because, the texture is applied as if you were looking at it from one of the 2D views - from that particular view, the texture looks ok, but an angled face is always longer than you can see in the 2D view).
Face alignment aligns the texture taking the surface normal (direction) into account, solving the stretching problem.
This is why flat, axis-aligned surfaces have both checkboxes checked, but other surfaces can have only one checked.
Aanyway, onto those surface extends, those are usually caused by extreme texture scales. Above mentioned alignment modes have no effect on this as far as I know.
@BJ: I assumed he meant "s" rather than a generic string, but even then, the == operator works just fine. Both for char* as for string. Unless you really need non-case-sensitive checks.
I like that elite combine smiley. Very recognizable.
ROFL!
Now I just need the solution for the second task.I've given you some pseudocode, it shouldn't be too hard from there.
1 idea, 2 minutes, 3 smileys (well, in total now :P):Nice Kirby bytheway.