News | Forum | People | FAQ | Links | Search | Register | Log in
TyrUtils V0.11
TyrUtils v0.11 has been released:

*Support BSP2 format (qbsp requires the "-bsp2" command line option)
*qbsp: Fix animating texture bug when brushes are textured with alt-animations
* qbsp: Fix a crash in tjunc calculations
* qbsp: Exit with error if verticies exceed 65535 (BSP29 limit)
* qbsp: Add experimental "-forcegoodtree" command line option (thanks Rebb)
* vis: reduce "leaf recursion" error to a warning and continue processing

Download from the utils page as usual (Win32 / OSX / source).
First | Previous | Next | Last
AOlcoves 
...part of me says there's a programmatic solution to the alcove problem, the other part of me says full designer control is better. 
Cognitive Dissonance Much? 
But I understand that you guys would rather die than give up Fitzquake

...

You're as tactful as a rhino. 
I Never Played Anything With Bsp2... 
...because the engines aren't compatible with my laptop. Requiring a particular engine shuts people out, making things that work with all engines doesn't. It's not about loyalty to a particular engine, it's the opposite: allowing all the engines to play... 
Onetruepurple 
and where was the need to stir the fire after I already basically said I was sorry? Massive grudge much? 
 
Plus, it just gets strange when you add support for really high-res things, but then still use them alongside original unchanged low-res things. A 2048 normal mapped skin looks stupid on a 200 poly monster animated at 10fps.


Quake perfectly reproduced in Quake3, targeted specifically at Quake3 engine budgets and resolutions, would be joyous. 
 
Massive grudge much?

...

(although no worldcraft NOOOOO) 
Lunaran 
Moreso since I can't think of any post-Q3 engine that could pull off that goal successfully. Definitely not idTech 4 with its ridiculous portaling... 
Preach 
Going off topic, but if you've tried Quakespasm 0.90.0 and it didn't run on your laptop, I'd be happy to look into it if you want. It should run practically everywhere. 
Also Random Note For Gb 
If you need to keep using a func_wall in some situation, tyrann added support to make it cast shadows - just set "_shadow" "1" on the func_wall. 
OTP 
Portaling, and just the investment time of making the textures and models, lighting the maps, etc. It's not fun to spend an entire Quake map of time and not have an entire map. 
 
To say nothing of the amount of non-map work that would be needed for idtech 5. 
Ericw 
Is it possible to add _sunlight2 and _sunlight3 from AguirRe's tools? Some of my maps depended quite heavily on that. What it does is basically add a bit of minlight only around the areas that have sky, so you can still get 100% black shadows in indoor areas.

Stark black shadows around outdoor areas are quite rare in nature, hence why I liked to use it. I also liked how it seeped into neighbouring areas a bit. I found it quite natural.

The alternative with the current tools would be to manually place some local minlights around, but that's comparatively sketchy. _sunlight3 was nice and easy, but if I'm the only one who ever uses that, it might be too much work for you...

I really like the dirtmapping, so I don't necessarily want to switch back to BengtLightColoured.

Thanks for mentioning the _shadow key, I'll have to play around with that one. 
_sunlight2 + 1 
It really helps soften those hard shadows. 
New Snapshot 
osx win32 src

The only changes are more options to control AO:

- _dirtmode/_dirtdepth/_dirtscale/_dirtgain worldspawn keys
- _dirtscale/_dirtgain can be customized per-light
- _nodirt can be set on a light to ignore AO for that light (so it illuminates the AO shadows)
- _sunlight_nodirt can be set on the worldspawn to disable AO for sunlight

In the previous build, dynamic lights were not affected by AO, now they are unless you specify _nodirt.

If it's annoying with AO as opt-out I can make it opt-in, or add a command line switch to make it opt-in. I'm worried about the settings getting too complex, so feedback welcome.


re: _sunlight2/_sunlight3, I can put it on my to-do list. I tried deleting the lights in jam2_mfx and testing _sunlight/_sunlight2/_sunlight3 from bjptools_xt in the outdoor area and didn't seem much improvement between the different sunlight modes. I'm interested to see what Lunaran is cooking with metlslime's idea of distributing lights around a dome.

From what rebb was saying and what I've read, AO should be applied to fill lights that are simulating reflections/indirect lighting. so I'm interested to see what can be done with AO to fill in ambient light in outdoor areas. 
 
So... on your light you would put :-

_nodirt "1"

is that correct? 
Yup 
There's more detail in the light manual too 
 
ericw you mistyped RTFM 
Thanks Eric 
Zer Progs!??? 
 
And 
Yes it would be better to have it opt-in. Just activate it on certain lights. 
Yes Zer Progs!! 
I wander around a lot.. 
 
Yes it would be better to have it opt-in. Just activate it on certain lights.

Disagree. I just had a play with this, and I'd definitely want AO on all lights and I'd only opt-out when I come across the "alcove problem" (or similar situation) as described earlier.

It just looks too cool! Who cares if it's not physically realistic? 
 
I prefer opt-out too. 
Perhaps A Worldspawn Default... 
I was gonna suggest that perhaps you could set the default behaviour on the command line. Then I decided it would be nicer to just have it recorded on the map. So how about something like a "_dirt" key on the worldspawn which controls whether lights are dirtmapped by default, and then a "_dirt_override" key on lights which toggles them relative to the chosen default? 
Hm 
Yeah there are probably good uses cases for both default off and default on.

What about:

_dirt 1/-1 on worldspawn for setting the default on/off,
_dirt 1/-1 per-light for forcing it on/off for that light?

The the _nodirt and _sunlight_nodirt keys could be removed, though to keep control of sunlight we'd need _sunlight_dirt 1/-1. 
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.