#332 posted by necros on 2016/02/10 23:22:17
Nice cold shadow with warm lighting done for exteriors super easy.
That is one of my favourite setups, but i've also found other cool combos like Yellow light and green shadows (eg: the interstellar skybox)
Sweet
#333 posted by Skiffy on 2016/02/11 01:00:17
I was suspecting as much. Nice to know that works! :)
Light Styles
#334 posted by necros on 2016/02/14 05:06:48
Is something changed with the way 'style' is done on lights? I have a bunch of lights in my map with no targetname, but I have manually set them to use style 12. I then was changing them in QC by directly referencing style 12 instead of doing the typical target/targetname shtick.
However, this no longer works with the new tyrutils (I was using aguirre's light before). I've checked my code and I'm still modifying style 12, but it seems like the lightmaps lost their styles..?
Necros
#335 posted by ericw on 2016/02/14 06:37:30
weird, that should work. If it was broken in the tool, I'd expect the regular flicker styles 1-11 would also be broken.
Try version 0.15.4 from http://ericwa.github.io/tyrutils-ericw/ if you're on a different version?
Ohh Ok
#336 posted by necros on 2016/02/15 02:53:13
i see, for some reason, delay 4 lights cannot have lightstyles in tyrutils?
can we revert that so that it works with all lightstyles?
also, it appears that delay 4, 'local minlight' is broken? it looks just like a normal light.
#337 posted by ericw on 2016/02/15 04:12:38
Ah, good catch, delay 4 lights don't support lightstyles. They are handled in a different function that applies minlight, and it just assumes the style is 0. Should be easy to fix.
As a workaround, delay 3 (infinite) should be almost the same as delay 4, especially on styled lights, because the engine will be blending the base lightmap with the styled one, so you wouldn't really get a minlight effect even if the styled light was using delay 4.
Delay 4 is working correctly for me otherwise, though. Maybe send over the map if you can't get it going?
#338 posted by necros on 2016/02/15 04:38:04
nm about the delay 4 not working. i think it was the dirt mapping making it look like it was attenuating. :P
Brush With Duplicate Plane
Trying to find problematic brush atm. Log blames line 66597.
Using notepad++ to edit .map file (manually cut bunch of entities and see if problem is gone) and through described process I found that compiler and notepad probably count lines differently, because given line was commented one (entity number) few times or part of a light entity.
What's the catch here? How can I find actual line that compiler refers to?
Smooth Shading ?
#340 posted by Skiffy on 2016/02/15 14:46:23
I remember seeing some screenshots and talk of smooth shade surfaces using textures with a prefix or suffix of some sort included to tell the compile that they should all be smoothly shaded together... It was this lovely set of tools correct? Still in development or another offshoot somewhere else that I am missing?
Feel free to correct my madness if I am imagining such things. :P
Skiffy
#342 posted by Skiffy on 2016/02/15 15:41:21
Ah that looks like it.... but the download links dont work anymore.
You can always email me and I will send you my compilers later from home? They have the smoothing
#344 posted by necros on 2016/02/15 16:26:59
i've lost track actually... but is the smoothing stuff not in the normal version we pick up from github?
More Final Release Planned?
#345 posted by Skiffy on 2016/02/15 16:41:12
No rush right now. I would rather wait for a more official release I guess with some notes in the text file I can refer to. I can keep myself busy with the monster update for now.
#346 posted by mankrip on 2016/02/15 16:58:13
It would be good if the compiler outputted the whole brush to the console when it causes an error.
#347 posted by mankrip on 2016/02/15 17:00:59
I'll wait for a release with smooth shading and lit liquids put together.
#348 posted by Kinn on 2016/02/15 17:46:56
lit liquids
Wait, what?
Which engines do/are gonna support this?
Mankrip
I would be happy with entity and brush numbers.
Kinn
#350 posted by mankrip on 2016/02/15 18:56:29
IIRC, Spike said something about FTEQW supporting it.
Retroquad also supports it, but there's still a lot of work to be done before it gets released.
Skiffy/necros
#351 posted by ericw on 2016/02/15 21:03:06
Phong shading is not in the releases on github yet.
Fifth has a build with it that is working, and I hope to post a new dev build soon that has phong shading too.
DeeDoubleU: weird, I don't use notepad++ but it should have a "goto line" feature that should take you to the right line. Anyway, I don't think "Brush With Duplicate Plane" is a serious warning, it's more a warning that the editor saved some redundant data.
#352 posted by PuLSaR on 2016/02/15 21:16:44
this document never gets old.
#353 posted by Skiffy on 2016/02/16 01:57:40
Lit water yeeeesss I look forward to that one because my level has murky water like a swamp / bog and I would love it to be dark shader fluids.
Swamp/bog
#354 posted by mfx on 2016/02/16 02:00:59
/triggered
Quake2 Plans?
#355 posted by Skiffy on 2016/02/16 06:35:48
Any plans to ever include radiosity in the light compiler for Tyr like in Quake2's Light compiler?
Regarding Quake 2... possible support for it using these compilers at some point in the future? I read it does support the map format but does it output quake2.bsp files?
Currently I think ArghRad is the lighting one for quake2 maps correct and no other tools came after that outdid it? I would love the AO / Dirt / Skylight / Sunlight from Tyr tools to be usable for Quake2. The main things Q2 still had is Smooth Shading and Radiosity though..
Just wondering because I love this toolset and some offshoot in the future would be great.
Radiosity
#356 posted by mh on 2016/02/16 17:33:02
It's actually important to understand that there are not one but two major differences to the Quake 1 lighting model in Q2. When people say "radiosity" it pays to be clear about which of these two is actually meant.
First one is actual "radiosity", as in the ability of surfaces to cast light.
Second one is bounced/indirect lighting.
Thing is, these two don't actually have any dependency on each other. It's possible to implement each without implementing the other.
So you can have surfaces casting light but without light bounces - similar to what these tools already do with lava surfaces.
And you can have indirect lighting but have it coming from light entities which the mapper must place rather than from surfaces.
Or you can have both; but presence of one doesn't demand presence of the other.
|