News | Forum | People | FAQ | Links | Search | Register | Log in
Tyrutils-ericw V0.15.1
Hey, I got around to setting up a website for my branch of tyrutils: (complete with lots of screenshots of different settings of AO, sunlight, etc!)
http://ericwa.github.io/tyrutils-ericw
and making an "official" release of it.

Nothing major changed compared with the last snapshot (may 1st), but a couple new things:

* .lux file support from Spike, for deluxemapping
* gamma control with -gamma flag and "_gamma" key
* rename -dirty flag to -dirt for consistency
* fence texture tracing is now opt-in only with the "-fence" flag.
* light should run a bit faster


This doesn't have lit2. Not sure what to do with that, tbh.

If there's a demand for it, I was thinking I could make a tool that upscales all textures in a wad by 2x or 4x, and adds a "-2x"/"-4x" suffix to the names. You could then manually get the higher-res lightmap on certain faces by applying the upscaled texture, and lowering the texture scale to 0.5 or 0.25 in your editor.

The only real disadvantage of this hacky method over lit2 is more face subdivision by qbsp. This isn't great, but it shouldn't be an issue if the hack is used sparingly (and bsp2 can be used if needed for higher face/vert limits.)

Anyway, enjoy, I hope this is pretty bug-free.
First | Previous | Next | Last
Please Help Me? 
Could somebody help me with this little thing that annoys me so much :

https://drive.google.com/file/d/0BwxYkKdSD855Mzhuc3ViNVo5YzA/view?usp=sharing 
 
can you turn off texture filtering in game and see if this still happens? 
 
bilinear filtering -- the last row of pixels blends with the first row of pixels, since it's a tiling texture. 
 
In the black/red colored view it looks like the texture is mirror imaged. Is it one continuous surface going from from red to black or is it actually two different brushes? 
Rick 
It is same exact texture but one of axis is mirrored "-1" it is 128x128pxl, and those brushes are exactly 128x128 and next to each other.. so filtering is making this to happen, that is looks like it is.. like 0.5 pixels or something? 
 
..so filtering is making it to look, like it is 0.5 pixels off or something* 
 
get up close and toggle between gl_nearest and gl_linear and you'll understand what's happening. You'll need to hide this pixel-wide blend by not using the full width of the texture on that polygon. Either scale it up slightly or make the polygon slightly smaller. 
 
Thanks metslime, I haven't tried scaling up yet - maybe that will work. 
 
Any time there is a difference between the textures on adjoining surfaces there will be a noticeable line if GL filtering is used.

I call them GL seams, and any kind of rotation, x/y shift, flip, mirror, etc. will cause it. Even just pixel color differences will cause it. 
 
It is interesting.. it really looks like there isn't different pixels in this case, if I understood what you meant by that. I have no clue how GL filtering works, so basically I can't avoid these things to happen.

For example I should create texture that points out on every main angle? Then I should have seamless street texture to fill everything in middle.. I was trying to create streets which has some messy garbage on both sides but middle is a lot cleaner. It really seems like that brown/black line in middle is like texture's starting pixel line, because its end and beginning has different pixel colors. The way GL filtering works.. does it look every texture individually and doesn't care about rotation, x/y shift, flip, mirror at all and that is why something like this happens sometimes? 
 
Does it try to blend blend pixels with next pixels.. if I offset it by 1 it is already in beginning, so it tries to blend with those pixels? 
 
What I did when making a series of similar textures was to create one common frame to use for all. Basically just the outer 1 pixel border of a 64x64 square. I used that to make different variations where the middle part was different but the pixels around all four edges are exactly the same for all.

For 128x128, I just repeated the 64x64 frame. Textures made this way have no GL filter seam/line as long as they meet at the 64 unit boundaries.

To make sure no weird texture alignments happen, I never use texture lock. I only turn it on if I really need it. 
It Blends The Next Pixels, So Yes The Dark Pixels Are Wrapped Around 
I thought we would have moved on from GL filtering as a society by now. Horrible concept really. Yay filtering. Let's blur all the textures. No glasses for you and contacts thrown away for you and baske in the glory that is nearsightedness on a screen.

</endrant>
(P.S. I'm nearly blind and need powerful contacts so I may be biased.)

Also this blending is not a compiler issue. The adjacent face has a different texture alignment and therefore is split into a separate face for blending purposes but thats the extent of compiler related. 
 
I might have used texture lock too much.. sometimes it was just left pressed down. Checking something like that multiple times, especially when placing lamps and such things confuses a bit.

I must be weird, because in some cases I want to have more control over things how wide/high some brushes should be.. and if there is only texture available that is 32x32 for example, but I want it to be 16x32 or 32x16 I have to cut it and offset other half so 'borders' are in right place. Creating new textures sounds like, I would probably fail at trying, I'm not an 2d artist by any mean. 
 
You could split an existing texture in two halves in PhotoShop, then use them in your maps. This way you wouldn't have to offset your textures, which can be tedious. 
Its So Simple To Fix 
Just make the road so there's three brushes across the width instead of just two. 
 
Thanks Kinn, but I also tried out.. scaling up a bit and it worked. But if I need to do wider roads.. then I need to use your advice. 
Re: Ericw, Mapping Help Thread Post #17150 
don't worry, Linux package management just sucks..
what's the error?
I have hit the same thing on debian/ubuntu before, there's some magic flag to make apt-get work usually. also maybe we should move this to the OS thread...?


Thanks for being willing to look at it.

Initially when I typed "cmake .. -DCMAKE_BUILD_TYPE=Release" from within a newly created "build" directory as per the instructions that come with tyrutils-ericw, I was told that I had to install cmake using apt-get ... which I did, and then weird things happened.*

I thought the installation of cmake failed, because I still could not get the build process to work. I had another look, though, and it seems like the installation did work, but I need a higher version of cmake than the one that is in my OS's repositories:

cmake .. -DCMAKE_BUILD_TYPE=Release
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.1 or higher is required. You are running version 2.8.12.2


-- Configuring incomplete, errors occurred!


...which means I need to compile cmake from source, I guess?

*If you're interested, I can post the weird stuff that happened too. Basically, as soon as I typed "sudo apt-get install cmake", the terminal window was taken over by the drupal configuration/installation process, which keeps failing. This happens whenever I type "sudo apt-get install cmake" again. 
 
OK, the problem is on my end; I thought I supported Ubuntu 14.04 but mixed up which cmake version it had. I'll see if I can adjust the cmake script and report back.. 
@total_newbie 
Ok, I made some changes and updated the instructions for Ubuntu 14.04 x86_64:
https://github.com/ericwa/tyrutils-ericw#ubuntu-1404

If you are running 32-bit there will be more work to do but it should be possible as well 
Correct Link 
Absolute Path Not Possible With Qbsp. 
Not sure this is a bug, since it look deliberate in the code, but it would be interesting to know why. :) It treats any argument that begins with a '-' or with a '/' as a switch. Absolute path (linux), including relative to home, will begin with '/'.

Anyhow. It was an easy fix and the tools are awesome. 
@ericw, Re #534, #535 
Thank you! Will check it out and report back. Luckily I'm running 64 bit on my current primary computer. 
@ericw 
Thanks, those instructions worked. :)

Now I just need to gather enough courage (and set aside enough time in case of repeated failure) to attempt building TB2 as per your instructions, and I'll be back in business. 
Awesome 
 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.