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
 
Does this one include lit water support? 
 
Yes, spike added it, but it's untested.
There are these command-line options:
[-lightturb] [-lightwater] [-lightslime] [-lightlava] [-lighttele]

-lightturb just is a shortcut for water + slime + lava + tele. 
Wow 
This is just crazy, so much advancements to ole Quake! Thank you all for the efforts, really...can't be said enough. 
Fifth 
btw, the key for phong shading has changed since the version you were using, you no longer need to give the texture name. The main improvement of this new version is having an angle cutoff, so it won't smooth around 90 degree corners by default (the cutoff is 89 degrees.)

Another new feature: when using phong shading I suggest setting "_anglesense" "1" in worldspawn, this affects all lights in the map that don't override "_anglesense".
This will make phong shading more visible and generally increase contrast.. it makes the angle that light arrives on a surface matter more than the quake default. 
 
I'm not sure I will change compilers unless I am really compelled to 
No Worries 
 
 
Does it apply phong shading to the whole brush? Not sure if this is desirable behaviour.

The thing I want most is a more tolerant or forgiving compiler like txqbsp 
Me Too... 
 
5th 
whats your problem?? 
MFX 
my brushwork sucks and I guarantee once my map is properly "sealed" it will leak like an incontinent old man who just drank 30 litres of water. 
Chat Chav 
 
"Chat Chav" 
sounds like an AI chat bot I can get behind. Maybe Microsoft can make it their next project after Tay failed.

"ur avin a giggle m8"
"u wot ill fukin slap u" 
Phong 
doesnt seem desirable to me to always have an object fully phong shaded. I think there should be a way to choose to either have the model phong shaded or certain textures. 
 
Dunno, I think with the angle cutoff and the fact that you can break it down into as many func_groups or func_details as you want, the current system seems pretty ok?

I'm just trying to envisage a scenario where that's not enough, and I'm struggling.... 
 
complex func_groups like this -
https://twitter.com/GavinEdgington/status/714465169649377281

Where I don't want to have to break up into small groups because it will make it a pain to move around and place. 
 
The angle cutoff is pretty flexible, if you set it to a low value like 30, only pairs of faces with normals up to 30 degrees apart will be smoothed together. So I imagine something in 30-60 would work well on that spaceship, and not add smoothing in unwanted places.

Also it's easy to check what the phong shading is doing, just compile with the light flag -phongdebug.

I could add back the list of textures to restrict phong shading to, if it's really needed, though. 
 
You guys are fighting the engine's weaknesses instead of playing to its strengths. Some things you're just not going to get control over without fundamental data format changes.

Pick what game you really want to be mapping for first. 
Or.... 
We'll continue working with quake and seeing awesome new tools to use and extend the life of the game. 
 
Was that a screenshot of something in an existing released map?

(Or what was that a screenshot of?) 
Baker 
map in development for AD. 
 
When trying to compile the vanilla GPL start.map:

*** WARNING 10: Reached occupant at (386 1554 132), no filling performed.

This error happens in a lot of places with the vanilla .map files. 
Mankrip 
you use the tyrutils qbsp? I guess so, this thread gives me the clue..

I tried to recompile those vanilla maps myself some time ago, several compilers had problems with them.

Whats the cause of those? I don't know, the map were rather tidy in my eyes, all integer coords and such. We all know there aren't any fancy brushes in them. 
Mankrip 
try -oldaxis switch? 
 
-oldaxis didn't help. Time to read the docs... 
Hmmm. 
try the first released qbsp.exe. Quadicted should have it archived. 
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.