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!)
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
One More And I Will Shut Up 
To make setting the sun angle easy you could just target your sunlight entity towards an info_null, to implicitly specify the direction of the light (the setup would look like a cute little solar system) 
Multiple sun entities instead of _sunlight2, _sunlight3, etc? 
Cool, blending the colors/intensity was something I wanted to try and will probably test out. control for the horizon is a good idea too.

If I'm going to add a new, tidier way to specify sun settings, I would be tempted to do it properly and make new entity types (light_dome for _sunlight2/3, light_sun for regular sunlight), and then strip them out when writing the bsp. Even the way surface lights are currently specified is sort of a hack, it should be a "light_surface_template" classname or something.

If anything is being stripped when light writes the entities to the bsp, it might make sense to make the light tool read entities from the .map file rather than the bsp, this would avoid a failure in case you ran "light" twice in a row. It would also mean you can skip the "qbsp -onlyents" when iterating on lighting settings, which could save a few seconds. 
with a sun as its own entity - you could support multiple suns by having multiple entities.

This is what I was thinking. Although, as someone with experience lighting a map with a fuckload of suns, beyond a very limited point (like two or three, which we have now) the line between imperceptibly subtle and clownishly gaudy seems to get pretty narrow. 
i'd like to have the ability to map lightstyles to sunlights... then you could have 4 'suns' that are always off, and flicker them randomly via QC. 
Yes! For thunder & lightning effects! 
that would be sweet. I think it's easy to do in terms of the lighting code, the only challenge is how to expose it to QC. That's probably another argument for using entities for sunlight, it could work the same as ordinary lights; if the mapper sets "targetname" on the sunlight entity, the compiler assigns it a lightstyle. 
I tried lightning tied to a skybox change a while ago, but every engine's got its own console command for the skybox and they're not consistent :/

You'd hit that 'max lightstyles for a face' limit quick though. 
yay for shadowmaps and rtlights... 
Moving all features that affect the world into entities would be neat.

"sky_fog" entity or something for easily copying fog between maps, etc... 
Suggestion: use the classname "info_world". 
And "info_world_sun", "info_world_fog", etc. in case of different entities for different features. Just to make it clear that such entities are global effects, not local effects. 
When are we getting phong shading?! WHEN?! 
If EricW doesn't implement it, I will.

But a proper implementation will most likely require surface flags (or, more specifically, surface groups), and the actual algorithm may not be Phong shading, but something that looks similar. There are a number of design issues to consider.

This is one of the features that I've been thinking about during this whole year, and it's not simple. 
And when are we having radiosity? Oh Lord, when? I wonder... 
for organic geometry how about something like "func_detail2" or "func_group2"? Something outside the regular thing that just applies it to a whole brush? 
I know it would be more ideal to apply it to surfaces but I would love to see something, *ANYTHING*, in the mean-time. 
better to have a key:val on any func entity


_smoothangle: 15

That way you can control which faces get smoothed based on angle. 
I would be all in favour of Quake 2 style surface flags... I know it's introducing a new format for Q1 but at this point does it matter? 
I would be all in favour of Quake 2 style surface flags... I know it's introducing a new format for Q1 but at this point does it matter?

You have to think about compatibility with editors like netradiant that are no longer being updated. 
This would create yet another legacy feature that would become redundant and require extra work to avoid conflicts and retain compatibility with.

Plus, most of the work I need to do before developing my approach is to implement a bunch of BSP debugging features in the engine, in order to analyze and tweak things properly without blind trial and error. The smoothing algorithm itself shouldn't require much time afterwards. 
What's the deal with q1rad? Does nobody use it because it doesn't have all of Eric's latest jingles and jangles or does it not really work all that well? 
It Works 
It is essentially the hl1 light tool ported to Quake.

The problem is that the final results can be quite washed out and lack contrast. I lit crdm2 with it and looking back now, oh god the lighting is awfully dull! 
the q2 light tool supported radiosity too. default 8 bounces, max 40. in retrospect, the best looking option would have probably been -bounce 1, which is what I'd use for quake if we had it (one pass of scatter and that's it). since Q2 came out when I was young and dumb I thought -bounce was one of those parameters that you set to the maximum when you do your 'final compile' so I basically released two needlessly washed out yellow Q2 maps.

vrad for source just does the max number of bounces it can, and when it runs out of light it stops, but their scatter and falloff equations were probably adapted out of a real optical physics textbook by an in-house mathematician they pay a half million dollar salary, so it always looks perfectly real in HDR. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.