Gl_wireframe
Bahamut
Join Date: 2003-01-20 Member: 12522Members, Constellation
Join Date: 2003-01-20 Member: 12522Members, Constellation
<div class="IPBDescription">textures split weird :\</div>Heylo,
I'm still a bit of a newbie to the whole 3D mapping thing, even though I've been trying it on and off for quite some time now. I was just wondering, in the screenshot below, is there any reason that half life splits the textures so they're kinda like this dodgy ascii art:
------------------------------------------- <
-------------------------------------------
------------------------------------------- <
Like, say that was supposed to be one texture between the <'s and it was resized with the "fit" command, then the horizontal value was changed to match the vertical, so the texture was evenly proportioned. I then pressed "top" and "left" to make the textures align themselves properly. yet for some reason when I run the game, it splits the texture into two, even though there is no obvious intersecting brushes that would do it :\
I hope that makes a bit of sense to someone, please help me :)
Bahamut
I'm still a bit of a newbie to the whole 3D mapping thing, even though I've been trying it on and off for quite some time now. I was just wondering, in the screenshot below, is there any reason that half life splits the textures so they're kinda like this dodgy ascii art:
------------------------------------------- <
-------------------------------------------
------------------------------------------- <
Like, say that was supposed to be one texture between the <'s and it was resized with the "fit" command, then the horizontal value was changed to match the vertical, so the texture was evenly proportioned. I then pressed "top" and "left" to make the textures align themselves properly. yet for some reason when I run the game, it splits the texture into two, even though there is no obvious intersecting brushes that would do it :\
I hope that makes a bit of sense to someone, please help me :)
Bahamut
Comments
Then you may want to show a screenshot of what exactly you are talking about or describe it better.
So instead...
Basically half-life likes things to be at right angles. Things that are at funny angles and touching other walls or such will 'spiderweb' it so it's all split up and thusly forms nice perfect right angles around whatever piece of architechture is touching. Look below for what I mean. The pipe has 8 faces, and is touching a flat brush, and blows w_polys out of the water.
To avoid this, either make the offending piece of architecture just 1 unit shy of touching (not always the best solution, because it could be visible), or make it a func_wall entity, which also isn't very good, because then it doesn't show shadows when the radiosity file is formed. Notice how high the w_poly count is. Looking at the whole pipe fixture is about 250. That's higher then looking at my command chair booth, connecting hallway, and curved rooms at the same time.
I had one ready too
<img src='http://www.dark-order.com/geometry0000.jpg' border='0' alt='user posted image' />
So many people much smarter then me around.
By the way, I figured out what the problem was, the "fit" command on the texture alignment thingy doesn't make the texture fit perfectly, leaves a gap on either side for me at least, is there a version of hammer newer then 3.4?
I've been fixing bugs and adding features to the compile tools for a little over a year now... I started by downloading Merl's ZHLT source and poking through it until I understood how everything worked <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
My latest version of the tools is always available from a sticky thread in the main mapping forum.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Is there a version of hammer newer then 3.4?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
There's a 3.5 beta version patch available at collective.valve-erc.com--there's a link to 3.4 and the 3.5 patch in the new Mapping Forum FAQ under "What editor should I use?". Install the 3.5 patch over your 3.4 install.
Among other things, 3.5 beta lets you see models in the 3D window. I don't think it changes the "fit" button's algorithm, though.
Shame about the "fit" algorithm, ah well :)
In the second picture, the maximum size for any polygon is 240x240 pixels (as in texture pixels), so if you scale a texture on a face to 2 times it's original size, then the maximum size for that polygon will effectivly be 480x480 because each pixel is being stretched out. What is happening in the second pic is perfectly normal.
Not always. The best philosophie on func_wall is to use as few as possible since:
1. They add to the entity limit <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
2. When you put a lot of solids in a func_wall or its very big they get rendered very strangely (being rendered even when you cant possible see them)
3. They dont block light and tend to look strange when a light is on the other side shining though it.
4. In the worst case they have a higher w-poly r_speeds then an equivilent none entity solid.
5. When you can see only a small part of the solid entity the whole entity gets rendered. Normal solids dont do this.
When a solid has a weird angle or shape just keep the 1 unit gap between the wall/floor/ceiling. You can however if you are able to see the 1 unit gap put a func_wall in this gap (works pretty well on pipes)
[edit]typos etc...[/edit]
GreetzZz Kouji San
I'm still a bit of a newbie to the whole 3D mapping thing, even though I've been trying it on and off for quite some time now. I was just wondering, in the screenshot below, is there any reason that half life splits the textures so they're kinda like this dodgy ascii art:
------------------------------------------- <
-------------------------------------------
------------------------------------------- <
Like, say that was supposed to be one texture between the <'s and it was resized with the "fit" command, then the horizontal value was changed to match the vertical, so the texture was evenly proportioned. I then pressed "top" and "left" to make the textures align themselves properly. yet for some reason when I run the game, it splits the texture into two, even though there is no obvious intersecting brushes that would do it :\
I hope that makes a bit of sense to someone, please help me <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Bahamut <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
There are three types of face split made by the compiler tools:
1) The entire level is first carved into cubes of equal size to make level subdivision more managable (not part of my ideal algorithm, but it is the state of the current tools). These splits are by axis-aligned planes at regular intervals from the origin.
2) The level is then divided into convex leaf volumes recursively. While a section of the level has walls that haven't been used to chop 3D space, the tools select the wall that causes the minimum number of face splits and chops that section into two smaller ones along the plane of the wall. Both new, smaller sections then go through the same process. Eventually every wall in the level is used to chop 3D space (and the wall data is stored inside the structure describing the chop).
This is where moving things to a func_wall can help--entity walls are stored in a different structure (one set of BSP trees per entity) and don't chop up the main level.
3) Each face in the level is then checked for size and chopped up so that there are no pieces larger than 240 units (default). This is done because the Half-Life lighting system has built-in limits that don't allow a face to have more than 256 light values in a single face; light values are spaced 16 units apart by default, making 240 units in each direction a safe area to cover.