Working With Func_detail Stuff
#45 posted by ww on 2018/03/16 00:56:49
Is a bit of a pain. Would be real handy to just rely on standard func_groups/etc for organizing in editor and then just slap a detail flag on whatever as needed. Maybe handling it like q3map2 does is possible. Would feel more consistent and be less of a headache to work with for sure.
Like...a Spanwflag? Interesting.
#46 posted by Qmaster on 2018/03/16 17:43:17
But maybe I missed something. What is the point of func_group if you can just group a bunch of func_detail or standard brushes in the editor?
Just Like In Q3 + Radiant,
#47 posted by ww on 2018/03/16 18:51:13
a simple "detail or not" flag for the compiler with filtering in editor. I don't know if anything more is needed for quake? To me func_detail_ seems unnecessary and it'd be much better just marking brushes as detail. You could have detail stuff and worldspawn linked together in func_groups then atleast.
I did notice too that func_detail_wall and func_wall don't behave the same in game; custom entity keys were removed from func_detail_wall I think.
#48 posted by Kinn on 2018/03/16 18:59:41
To me func_detail_ seems unnecessary and it'd be much better just marking brushes as detail.
That requires a new map format.
That's why func_detail exists. To allow you to flag detail using the existing quake map format.
#49 posted by ericw on 2018/03/16 19:00:29
I can add support for the quake 3 .map format's detail flag (stored per-plane in the .map file). @Qmaster in GTKRadiant there is a shortcut key to turn the selection into detail, so it could be handy if that's your editor.
#50 posted by Kinn on 2018/03/16 19:07:27
I did notice too that func_detail_wall and func_wall don't behave the same in game; custom entity keys were removed from func_detail_wall I think
They are completely different beasts.
func_wall is a separate entity in game, potentially interactive.
func_detail_wall becomes "baked" into the world geometry on compiling, like func_detail. Unlike func_detail, it doesn't chop up world faces that it butts into.
#51 posted by metlslime on 2018/03/16 19:18:41
An alternate approach is to adopt just the UI aspect from q3radiant (the keyboard input) -- under the hood the editor could be using that flag/unflag operation to move the brush from world to func and back. Don't show it to the user as an entity, show it as world brushes with detail flag, but store it as a func.
#52 posted by Kinn on 2018/03/16 19:27:25
you'd also still need to support _phong and all the other keys that you'd want on detail too...
#53 posted by ww on 2018/03/16 20:34:25
Would be awesome to have q3 style detailing as option eric. Wanted to ask this ages ago.. Before pestering niger to add support -)
Will be easy enough to just use func_groups to add keys I assume.
#54 posted by mankrip on 2018/06/26 23:34:31
It just occurred to me — are BSP entities self-shadowed?
For BSP entities that doesn't cast shadows onto the world, it would make sense for them not to cast shadows over themselves either. This would also require them to support backfaced lighting, like the lit liquids does.
#55 posted by ericw on 2018/06/27 02:02:20
They're not self-shadowed; you can opt to it with "_selfshadow" "1" though. Enabling world shadows with "_shadow" "1" implies self-shadowing too. (All of this should be consistent with tyrutils).
#56 posted by anonymous user on 2018/06/27 04:14:51
Can I use these to compile q2 maps?
#56
No. But you can compile Hexen 2 maps.
Check out this page near the bottom for compiling tools. http://maps.rcmd.org/tutorials/q2_mapping_today/
#58 posted by ericw on 2018/06/27 05:48:12
Not currently, but the next update will have experimental support for q2 in the light tool only (so it'll be possible to use this 'light' in conjunction with a quake 2 qbsp + vis), thanks to m-x-d's contribution! I've been slow to get to testing it but planning to soon.
#55
#59 posted by mankrip on 2018/06/27 13:12:44
Nice. Can you implement an entity field to enable lighting from the back, like in the liquids?
This would be useful for opaque glasses such as the func_illusionary stained glass windows in some E4 maps (they're completely black from behind when you enter their secret area), and for new stuff like ice bridges, etc.
@mankrip
#60 posted by Qmaster on 2018/06/28 04:20:16
I think it's actually textured with "black" on those levels, but what you want is _mirror_inside 1. Or was it _mirrorinside 1. To add backfaces inside the brush.
#61 posted by mankrip on 2018/06/28 09:00:04
No, adding backfaces is a different thing. I'm talking about letting the surfaces be lit from behind, just like EricW already did for the water.
Argreed
#62 posted by ericw on 2018/06/28 09:51:48
this would be a good addition. "_light_from_behind"?
#63 posted by mankrip on 2018/06/28 23:24:19
Yeah, that could work.
Bug With _lightignore?
#64 posted by Esrael on 2018/07/13 13:06:29
I have a platform with "_minlight" set to 300 and "_lightignore" set to 1 and the result looks less uniform than expected:
https://media.giphy.com/media/xiBtcFw60XXFvNYIMn/giphy.gif
It looks like the torches affect the minlight of the platform even if it's supposed to ignore all lights, right? The darker areas of the platform also looks very dark even if _minlight is set to 300. Is this supposed to happen?
Add A _maxlight Key?
#65 posted by Esrael on 2018/07/13 13:10:06
Forgot to write in the previous post, that the problem made me wish there was a "_maxlight" key to prevent some areas from being too bright, so that's something for you to consider implementing in future versions. :)
Multiple Minlight Excluded Textures
#66 posted by Esrael on 2018/07/13 13:24:10
Sorry for the spam, but I keep remembering stuff in drops. ;C
Currently the "_minlight_exclude" key allows for only one texture, right? Could you make it possible to have more than one texture be excluded by separating the textures with a comma/semicolon etc?
I Figured It Out!
#67 posted by Esrael on 2018/07/13 13:46:58
It turned out that the cause of the non-uniform brightness was the "_dirt" key in the worldspawn. That affected the brightness of the elevator in the narrow hole. I solved the problem by adding a key/value combo of "_dirt/-1" for the platform.
But my two previous suggestion posts still stand. Something for Eric to consider implementing. :) Sorry for the spam again! @_@
+1 for _maxlight key
it would be handy to give certain brushes a range with _minlight and _maxlight
_project_texture
I know from experience this is a tough feature to work with and it's currently pretty limited. But if it could be improved I think many more ppl would use it. I was able to get a pretty decent result in my 100b4 map. The big 4 on the far wall is a projection.
I'm wondering if there's any way to rethink this or improve the functionality somehow?
|