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
#487 
I've just tried it, and _dirt -1 doesn't work on func_detail. 
Addendum 
Well, actually _dirt -1 sort of works on func_detail. The water isn't dirtmapped now, but it still casts dirtmapping in the rest of the world model. 
 
Thanks for the report, I will fix it properly.
Probably I'm checking for TEX_SPECIAL and skipping casting/receiving dirt if that is set, need to also check if the texture starts with
"*" or "sky" in case splitspecial is used. 
 
Thanks.

A little feature request: Can you add individual options for -splitliquids and -splitsky? This would be more optimal than -splitspecial, since there's usually no reason to allow sky surfaces to be lit. 
 
It should be there already, just called -splitturb instead of -splitliquids 
:) Indeed 
It is; I've tried it out, and it worked.

Thanks, I've updated my compiler parameters. 
Actually 
Gosh I had no idea lit liquids were even supported in this tool. Any chance someone could give those quakespasm cheps a bit of a nudge? 
V0.15.7 Released 
Get it at: http://ericwa.github.io/tyrutils-ericw/

Not really any new features, but lots of performance improvements. It's something like 2-4x faster depending on the map.

Also fixed the regression with bmodels touching the world that Kinn reported.

full changelog: https://github.com/ericwa/tyrutils-ericw/releases 
 
minlight no longer bounces

I can't even begin to imagine how that worked or looked. 
 
V0.15.7 isn't compiling at all here.

** Executing...
** Command: C:\Dev\Tools\tyrutils\bin\qbsp.exe
** Parameters: -nopercent -splitturb C:\Projects\QuakeDev\Game\Quake\_QDebug_\maps\E1M2

* WARNING: File was not built!
"C:\Projects\QuakeDev\Game\Quake\_QDebug_\maps\E1M2.prt"
 
Addendum 
It was the 64 bits version. The 32 bits version is compiling fine. However, I'm on Win 7 64-bit. 
 
Maybe try installing the 64-bit version of the msvc 2013 runtime (vcredist_x64.exe)? 
Bingo! 
 
#499 
I'll try it.

In the meantime, I've confirmed that the worst part of the dirtmapping bug is now fixed; liquids won't cast dirtmaps on the world anymore.

They still receive dirtmaps, but at least this problem can be worked around by func_detailing them with _dirt -1: screenshot
Fast! 
Wow, 0.15.7 is incredibly fast! I don't have specific times, but it speeds up light on my map by a huge amount. No idea what kind of wizardry was performed for this, but it's really cut down on the iteration time for my map. Thanks so much! 
 
Pritchard - awesome :)

got some bugs reported and fixed already (to be in the next release):
- the "unmatched" target warning was broken
- skip-textured func_'s with "_shadow" "1" were broken (for making invisible shadow casters)

This one was tricky due to how I migrated light away from using the BSP for raytracing. The workaround I implemented has a limitation that the entire bmodel has to be textured with "skip", otherwise the skip textured bits don't cast shadows. Hopefully this covers the common use cases for that trick, though. 
Mankrip 
That looks pretty damn cool. How did you get the water to draw shadows like that? 
Only A Warning, I Assume This Isn't A Big Issue 
thought I would report it just in case.

vis.c: In function �LoadPortals�:
vis.c:1120:9: warning: ignoring return value of �fscanf�, declared with attribute warn_unused_result [-Wunused-result]
fscanf(f, "\n"); 
#504 
Using independent surface caches for texture & lighting, and combining them in realtime.

The drawing routines of liquid textures (and now, of power-of-two textures too) were mixed with the drawing routines of regular surface-cached routines, combining the texture & lighting in realtime before blending the result into the framebuffer.

It's not difficult to do, just really tedious. Involves modifying and rewriting a lot of code. 
Func_viscluster Support 
@ericw: I'm curious if it would be possible to add support for func_viscluster brushes in order to negate large open spaces. I'm of course assuming that vis leafs automatically chop up empty space into leafs every 1024 units. https://developer.valvesoftware.com/wiki/Func_viscluster

Spikespasm:
Host_Error: Mod_LoadLeafs: 121741 leafs exceeds limit of 70000. 
 
AFAIK, there is no chopping of space every 1024 units in this qbsp, that feature was added in quake 2's.

func_viscluster - this sounds like purely something to speed up the vis computation. It's probably possible to add to Q1 tools, it wouldn't help with reducing the number of leafs though. 
Strange Bounce Bug 
This just popped up now as I'm working on my map. Bounce lighting started generating random black spots in this one room of my level:
screenshot 1
Here's how it looks with bounce lighting turned off:
screenshot 2

Any idea what's causing this? I was changing my light entities around, but I can't figure out what I did that caused this. Has anyone even seen this before? Help would be greatly appreciated :s 
 
At least somebody's happy about this...

I tried running the map through 0.15.5 and the issue went away. I'm guessing then that this is an issue caused by the new approximation methods in 0.15.7... 
I Should Really Try Before I Speak... 
I hate making a third post like this, but I tend to write in a very "stream of consciousness" manner... Anyway, I tried the -novisapprox flag on the command line and the issue persisted, so that's not the problem. 
Weird 
I've never seen that, definitely a bug. mind sending me the bsp? 
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.