 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Map jam where every map title is a possible toolset name and the best map wins the right to name the tools
Cue "penispiler" ok - scratch arcaneutils. Thanks for the ideas.
probably "ericw-tools" is the pragmatic choice becuase I've heard people refer to it as that anway.. hm. You've added so much to TyrUtils that your fork is not really Tyrann's anymore. It deserves your own brand.
If a func_wall entity has skip-textured faces that goes deep inside the world's brushes, crossing multiple VIS areas, will said entity be "visible" across all those VIS areas, even though it has no faces to render in there?
Maybe this is more of an engine problem. I am guessing "yes" they will be visible. skip faces are deleted towards the end of qbsp so they're included in the model mins/maxs - I think.
To optimize for this case I think the engine could build a tighter visible mins/maxs by iterating over all faces/vertices of the model. I am guessing "yes" they will be visible. skip faces are deleted towards the end of qbsp so they're included in the model mins/maxs - I think.
To optimize for this case I think the engine could build a tighter visible mins/maxs by iterating over all faces/vertices of the model. the qbsp must(imho) calc model bounds according to the maximum of both rendered geometry as well as related collision structures.
Failure to account for collisions means you'll end up missing initial collisions, resulting in entities getting stuck and unable to leave again (more than just a precision error). This is true (although perhaps rarer) even in vanilla. It should be possible to support for delay 1/2/5 as well. it would be a bit different for these because they extend forever, so maybe "_falloff" would set the distance where they hit 1/255 brightness, or something?
Using TyrUtils v0.15.11, working on my Frozen map and have encountered some strange shadows. Look at the rock shadow just below the crosshair, this occurs in a few places in the map, the shadow is not very soft and has harsh transition between dark and soft:
https://i.imgur.com/yz7m73G.jpg Current settings: sunlight: 200 sunlight_color: 211 163 139 sunlight_mangle: 90 -55 0 sunlight_penumbra: 4 sunlight2: 200 sunlight2_color: 147 115 135 dirt: 1 dirtdepth: 96 dirtgain: 0.75 dirtscale: 0.75 bounce: 1 Its strange because the shadows look good in other places. Any ideas what's going on here? Is this the seam you mean?
https://imgur.com/a/IrMnN Are the faces that meet in the rectangle I drew phong shaded? Are they on the same plane? I guess it's the sample-point-positioning code not working properly. Is the map sealed? Sealing it may help if it's not. Aside from that all I can suggest is tweak the geometry. Unfortunately there's no easy fix on the tools side and any time I adjust this code it tends to break some maps and make others better. In general it looks like 0.15.9 was the sweet spot. I would revert to that but it can't handle faces that are partially covered, e.g. func_detail_wall. The map is sealed. I changed the geometry of the ground so that there was no seam between brushes near the shadow and the issue cleared up. Only the rock was a detail brush with phong, the ground wasn't.
It is tricky to get rid of all these seams. If I revert to using v0.15.9 can I still use bounce lighting? Yeah - bounce was added in 0.15.5.
All the old releases are on the GitHub releases page: https://github.com/ericwa/ericw-tools/releases/tag/ericw-v0.15.9 Sorry to hear but I'll try to fix it in the next release :-/ Tried re-lighting the stock id1, hipnotic and rogue BSPs with -extra4 -soft. The result is, many badly lit patches sticking out from brush seams and various corners are finally gone, and the shadow edges are just so much better, see an example here.
However, in hipnotic some maps lose some of their lights and become too dark. E.g. the start map loses the lighting from the two lamps in the room where you spawn, even if I run light.exe with no extra options. Any way I can fix this? Okay, so I ran hipnotic's start.bsp through several different versions of light.exe and the results are curious.
I've tried the original TyrUtils, then BJP's enhanced tools, and then finally found the original light.exe from the official hipnotic devkit. The exact same compiler that the original developers used. Still no dice, the map loses some of its lights if re-lit. Why does this happen? Did they delete some entities from the compiled Apart from hip1m5, hip2m6 and hip3m2, all the other hipnotic maps seem to be build with -range 1. Adding this option restores the original lighting. (The original hipnotic compiler also supports -extra, and they used it.)
Sorry for wasting your time, but maybe this will be helpful to somebody coming from a Google search. Working on my AD Advent map. I have a specific need to have the boundaries of my map func_detail with _phong 1. So i've enclosed the map in a skybox. I know that's inefficient but I need it to be this way. So my question is: should I use skip textures on the outward facing brushes of the func_detail? Will it make any difference in compiling or more importantly, performance? I am using 0.15.9 because of some issues other have already posted about before.
I ask because there are a large number of brushes in this case. If the outward faces of the func_detail touch the skybox, there's no need to texture them as skip because qbsp will clip them for you.
The time to use skip is when the faces are not clipped away by qbsp, i.e. you can noclip over to them and see them, but if you know the player can never get to a position where they can see the face, you can mark them as skip so they are deleted from the bsp. It gives a tiny performance boost and reduces the file size / limits a little.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |