 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
New beta:
https://github.com/ericwa/tyrutils-ericw/releases/tag/ericw-v0.15.10-beta1 Has the qbsp.exe -convert valve mymap.map and it will write out a copy of the map in Valve 220 format to mymap-valve.map. It can also convert to "quake", "quake2", "bp" (quake 3 brush primitives). I labelled it "beta" because it's not tested enough, light has a large change to how sample points are positioned. (so unexpected black faces should never happen any more, e.g. this) So it's the black artifacts around the floor tiles? Was that shot with -extra4? I should be able to reproduce it.
re: bounce, good point, it should be opt-in, I guess. "_bounce_styled" "1" worldspawn key? Thanks for testing and glad the No, no -extra4 or soft. I haven't been using those parameters as I test the map. If you like I can create a github issue with the
Also, interesting tidbit but nothing of any real issue: Converting the map to valve format through your tools seems to have reversed the order keys are listed in for TB2. Classnames are now at the bottom rather than the top. Not the case for newly created entities of course.
It's really easy to add though, i'll add it after fixing Pritchard's issue.
Cool! Sounds like a good addition Man that could open up some interesting visuals. Random dipping of light from clouds in an overcast sky...the strange pulsing of an alien sun...a simplistic day/night cycle (obvs no moving shadows but whatevs, it's not as if you can animate the skybox)... You could sync up the light variation with some variation in the fog and skyfog settings to sell the effect better. I did think it might be interesting if it was possible to have multiple different sunlight setups, all on a unique lightstyle (well you'd be limited to 3 I think) - morning, midday, evening - and you lerped their light intensities in QC (along with "night", but that wouldn't be a lightstyle, just an absence of light). But that's probably overkill and the shadows might still look odd. I'm not really sure what the performance implications are with massive amounts of lightstyled surfaces though. Are there any these days? I just looked up how lightstyles work, is there any limit to the length of the string? Or could you actually have a light that took a really long time to complete it's cycle? That would be a lot of letters...
Also seriously? It's done with letters of the alphabet??? Yeah, you can set up those strings and have the light cycle automatically, or you can just set a single brightness value explicitly (e.g. say you wanted a slow day/night cycle thingy, I guess you'd want to set up a slow think function and increment the brightness in the think)
Uhm, how come this QBSP generates a whooping 11k more clipnodes than other compilers on my map?!
Hmm, I don't remember touching anything related to clipnodes since this forked from tyrutils.
I just tried compiling ad_zendar.map and it looks like I can reproduce that: bjptools_xt_290914_phong2: 38011 clipnodes tyrutils-ericw_0.15.10_beta1: 44953 clipnodes So it's producing 18% more clipnodes than bjptools_xt. Is that the same kind of percent increase you're seeing / what are the total numbers of clipnodes? Around 41% in my case if my math is correct.
bjptools_xt 1.2.5: 27174 clipnodes tyrultils_ericw 0.15.9: 38372 clipnodes (Also roughly 700 more marksurfaces with tyrultils) I don't mind using the old txqbsp_xt in order to not exceed the standard marksurfaces limit, but I'd like to use this light.
I was wondering if the problem of light not passing through sky had been fixed. Negke thanks for the info, I'll look into optimizing the clipnodes sometime.
Rick: sometimes this qbsp will produce fewer marksurfaces, so try both. About making ordinary lights go through sky faces, I tried it a while ago and I don't think it's worth the code complexity, and it caused a significant slowdown. If I added a way to add entities to specify multiple suns would that help? Alternatively just make a hollow box connecting to the window, it should only add 1 extra leaf and a few sky faces. Tried latest beta and I receive too many light styles on faces when I didn't on the latest stable version. Going to assume that's with styles now bouncing?
A few notable black faces I was keeping track of are still showing as pure black. Just reporting! latest build from here has a bug.
Rotate_object arent lit, leaves them all black. i'll look into it. The git master and 0.15.10-beta1 versions of light are half-baked at the moment, I recommend the stable version 0.15.9.
When a deep lake full of mud or slime is in a very bright area, the lighting from the outside will illuminate it as if the liquid didn't exist. This is specially true for lakes under open skies with sunlight.
How complicated would it be to implement an option in the light tool for underwater faces to receive gradually less light according to their distance from the water surface? I suppose it could work this way: 1) If the face is underwater, check if the light entity is not underwater; 2) If the light entity is not underwater, make a list of all liquid surfaces between it and the underwater surface; 3) For each ray, check which liquid surface in its path is closest to the light entity; 4) Calculate the distance from the liquid surface to the underwater face, and use it to reduce the brightness received by the lightmap. Note: Light entities placed underwater shouldn't be affected by this, because their underwater brightness was deliberately set by the map author. I think this feature could be very useful, specially in areas with both water and slime - the slime would look more muddy than the water, because the bottom of it would be harder to see. Maybe this could be implemented through an entity field in func_detail liquid brushes. I don't think slime necessary glows or doesn't glow, though it depends on what kind of slime it's supposed to be...
In Lava's case, you'd never realistically be able to see underneath the "surface" so no one can say if it glows or not :P I feel like this effect could already be possible with negative lights - those subtract from the lightmap right? You could place a bunch of them underwater and it'd probably be possible to have the desired effect. I was thinking of Quake 2 where (all?) liquid textures had surface light. So I guess that's actually irrelevant.
Quake's palette shifting effect tends to make underwater areas too bright anyway but negative light would probably still help. Attenuate faster if the trace crosses a water surface.
How do you see this working with moving liquid bmodels? The volumetric water attenuation is certainly do-able; the raytracer is already set up to have side effects when a ray hits certain surfaces.
The latest stable release from last fall has "stained glass" support, i.e. if you make bmodel with "_shadow" "1" and "_alpha" "0.5", light rays going through the entity will be partly attenuated and pick up the color of the texture. So a simplified version of water attenuation would be not considering the distance traveled underwater, but just attenuate the ray when it goes through the surface. But on the other hand, I can imagine it would look cool to have bright sunlight at the water surface fading to black (thinking of an e1m4 type environment). Anyway it's a cool idea to add to the todo list. My first priority now is fixing the breakage that Pritchard reported a while back, which I'm making good progress on but kind of a bit drained on tbh. That's fine, just know that what you are doing is really really great! There is no going back to the old tools now.
Incidentally, is your light or qbsp multithreaded? I know vis is, which changed light to be my current bottleneck (bounce fun notwithstanding). Thanks, appreciate it :)
Light is multithreaded, qbsp is not. Qbsp could get a lot faster, it spends most of its time in CSGFaces checking if each brush intersects each other brush in the map. Quake 2's qbsp is multhreaded. The main performance tip for light is to avoid using -extra or -extra4 except on your final compile, and also add -gate 0.1 or something to reduce the overhead of delay 2 lights. Idea:
When a map is recompiled, compare its entities with the entities in its previously compiled BSP file, and use the radius of each light to determine which surfaces had their lighting changed. This way, when recompiling lights, the light tool can simply copy all unchanged lightmaps from the BSP file, and compile only the modified lightmaps rather than recompiling all lightmaps. Bounce lighting can make this complicated, so I'm not sure if it would be possible. I feel like if you're testing within each light's radius to see what brushes have changed, you're already doing a lot of the grunt work for compiling a new lightmap...
It could work for a rough and messy sketch if you were willing to let a lot of edge cases slip through and accept the odd corrupted face or two, but then you invite the possibility of someone releasing a map compiled with that option turned on... testing within each light's radius
Only for the light entities that changed. Quite often, it will be only 1 light. What I've been thinking of, that's sort of related to that, is making a light preview tool; it would be a small GUI application with a 3d view with WASD+mouselook. You would open a map file and the tool does qbsp and light and displays the result, except the light baking is done on faces near the camera first, and the 3d view updates as each face finishes baking. Then it would refresh whenever the
yeah, what I have always wanted is a tool that lets me edit the lighting in realtime. I think that a diff-based approach to recalculating lightmaps would be fast enough to make this possible. Most edits would only affect one light, which has only local effects. Of course editing the sun values would not be as easily optimized.
I'm not really sure what happens if you use old light data on a new BSP, but wouldn't it be pretty broken if you edited the brushwork around a light that hadn't changed. Say you made a ceiling, put a light on it, ran qbsp/light, then built the rest of the room and tried to patch.
I don't know what that would look like but I imagine it'd be quite bad... Yeah, that would be quite broken.
There are also complexities around light styles, combining lights with the same style, and packing in new lightdata/updating light offsets, which may in theory require to recalc for the entire BSP. Question: Does
Right now I'm on mobile and can't test it. Iirc, separate func_detail / group will be blended if the _phong settings allow it. But other bmodels never blend with each other or world.
Having a real time lighting renderer like ericw would be really neat. If you were able to cull light calculations to the player's view (You'd have to be very generous - bouncing their view around corners to find lights that should cast but would otherwise be missed), you could potentially have an engine that displayed in the traditional quake style, while keeping the main benefits of lighting in real time like moving lights.
I can already imagine a whole set of horrendous edge cases arising from this sort of thing, but it'd be a pretty neat thing to see and something that I'd hope modern computers would have the power to pull off... Yeah, I've just tested, and it doesn't work:
screenshot The back of the column is a func_detail with _phong 1. The front of the column is a func_wall with _phong 1 and _world 1. If _phong 1 worked on mixed entity types with _world 1, we could work around some of the BSP's planar/vertex accuracy limitations by alternating between func_detail and func_wall brushes. This would make the engine clip their planes at the rendering level, which is completely accurate and doesn't produce distortions. quake's lighting logic has some bias on its dotproducts that increses the amount of light on surfaces that are nearly perpendicular to lights (which is important for lights placed near said surface).
You can disable the effect with _anglescale 1 (I think it is now - vanilla hardcoded it to 0.5) the '_phong' key simply calculates surface normals on a per-sample basis instead of per-surface (thus meaning its misnamed as it doesn't change the lighting formula). It affects the lighting, but not the shadows. While it would be possible to push the sample worldspace positions according to the same calculated normals, and determining shadows based upon those, such things would be quite unreliable in practice - for instance, a concave surface curve would logically push those sample positions inside the surface, which would result in all traces being obscured with the surface shadowing itself. so yeah, that's why you get sudden lighting changes on the edge of pillars - because -anglescale is biasing the light on one side while the other side is in pure shadow. if you want to try it anyway, this is the maths I use in FTE for tessellation: vec3 w = p0*bary[0]+p1*bary[1]+p2*bary[2]; vec3 t0 = w - dot(w-p0,n0)*n0; vec3 t1 = w - dot(w-p1,n1)*n1; vec3 t2 = w - dot(w-p2,n2)*n2; w = w*(1.0-factor) + factor*(bary[0]*t0+bary[1]*t1+bary[2]*t2); you should be able to shove something like that into GLM_InterpolateNormal (and convert from glsl to cpp - I already renamed stuff from glsl). You'll then need to return the smoothed position back through multiple callers to the point where its copied into the lightmap samples array. Bonus points if you can calculate the barycentric coords (read: interpolation weights) for general polygons instead of just triangles. like I say, you'll need to clamp the shadow-point to never be behind the surface to avoid the more obvious glitches. once implemented properly you'll get smoother lighting around corners (although due to the nature of traceline shadows, it'll probably still be somewhat sudden without anglescale 1). @mankrip, smoothing between separate models is too difficult to attempt, imho, because smoothing relies on the model having been processed by QBSP. i.e. it involves walking around the mesh (exploring neighbouring faces to a vertex, and neighbouring faces to a face, etc.). If the models weren't clipped against each other, the smoothing wouldn't work.
@spike in current git, I wiped out the "traceline to position sample points" thing. Instead I'm trying to use the same code as phong shading, so exploring the mesh by following connections between faces. So in a concave surface, it should work properly and give world space positions that are consistent with the interpolated normals. Only problem is, it needs some more work.. Pritchard's case in #773 was failing because of t-junctions in the bsp. I want light to work properly if qbsp didn't add t-junc vertices, so I'm making light do it (in memory only). re: GLM_InterpolateNormal, apologies for the current mess I made in the code and weird names.. I tried using the glm library a bit, then decided I didn't like it. (100 layers of indirection/ abstraction for basic vector operations, slow as hell debug builds,..) On the plus side the test suite is growing slowly. Is there an automated way to import the configuration from the non-Steam version?
I've just bought JACK on Steam, and upon launch it didn't detect that the non-Steam version was already installed. Wrong thread. Wrong tab.
Anyway, thanks for the explanations, ericw and Spike. I'm already going to implement something which should serve as a partial workaround, but I'll keep this info in mind for future research. Quake's dotproduct is a simple dot(L,N) * 0.5 + 0.5; i.e a rescaling from -1..1 to 0..1 (excluding the spotlight cutoff for simplicity):
angle = DotProduct (incoming, l->facenormal); angle = (1.0-scalecos) + scalecos*angle; But scalecos is 0.5 (https://github.com/id-Software/Quake-Tools/blob/c0d1b91c74eb654365ac7755bc837e497caaca73/qutils/LIGHT/LIGHT.C#L13), so substituting: angle = (1.0-0.5) + 0.5*angle; And evaluate (1.0-0.5): angle = 0.5 + 0.5*angle; https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L403 Is it possible to make brushes with fence textures be compiled in a similar way to brushes with liquid textures?
By that, I mean making them become properly see-through. Currently, any brush with fence textures will clip any polygons from other brushes that touches them, which results in open holes where the other brushes should be visible. The only difference to liquid textures is that the pointcontents of fence brushes would have to be set either to solid or to empty. I guess the first case would give problems to the renderer, and the second case would give problems to the physics, but from the top of my head I'm not sure. I'm not sure how much interest there would be in changing how fence textures are compiled as it's already quite easy to resolve the "clipping" by making brushes using fence textures be a func_ brush such as illusionary or wall.
Pic. What's going on there? Any way to get rid of this without anglesensing the shadows from the spikes away?
Apparently it's related to the increased texture scale (2.5-3x). Jury-rebbed BJP light doesn't seem to have a problem with it (but it lacks several feature I require).
Make sure to use v0.15.9, the
If that's not the problem, I'm not sure from the screenshot, could I have a look at the There's a specific problem I'm having with it, when BSP entities partially inside of walls gets darker edges because part of their surfaces is in pure darkness.
If such entities were part of the world, their surfaces would be clipped by the compiler and there wouldn't be any parts of them in pure darkness. But to be part of the world, they would have to be compiled similarly to liquid volumes, without clipping other brushes. Currently I can work around this by making the other brushes that touches them into func_wall entities too, but IMO this isn't the most efficient approach. the renderer doesn't care if something's solid or not, just that its a leaf or node.
same with physics, really. just make sure those fence-solid leafs don't get merged in to leaf 0 like all other solids, and that vis considers them transparent despite solid (can't say I've really looked into the vis tool itself, maybe it already goes by leaf 0 instead). Thanks for the explanation. The BSP tree architecture is something I've not started studying deeply yet.
I also came across an issue with detail brushes. Not sure if it's a bug or simply a technical restriction and downside of the way detail brushes are done in Quake, and also not sure if it's a general thing or only applies to certain special cases.
I had a compact bit of architecure flush to the wall of a building and turned it into func_detail in order to use phong shading on it. The building's wall behind it remained solid world geometry. As it turns out, having the detail brush touch the wall like it did caused the compiler to disregard visblocking for the wall which resulted a situation where a large part of the interior was being rendered despite being completely out of view, causing wpoly to increase by 1500. Making the func_detail 'flatter' by including only the front part of the detail architecture didn't change anything; it seemed to be entirely related to the touching of detail and world brushes on that particular part of the wall. Now, this might be an edge case caused or faciliated by the shape and construction of that particular area (sloped brushes, same brushes for inside/outside etc), but still a potential risk to keep in mind, especially if remaining unnoticed until the final release of a map. If anything, this is meant to raise awareness that excessive func_detailing can be detrimental, too. Perhaps the code can be tweaked to make sure this can't happen, or maybe it something to live with due to the hacky nature of it. Some screenshots to clarify.
The face is the func_detail in question. The wall below is a door, but instead of only rendering the corridor behind it (hell knight), it even draws the atrium way out sight, much of its upper and lower parts. isn't a catch-all.
I have found in a number of my maps that I get a speed gain in compile times but not always ideal results in culling in the game. Good lighting and faster vis time and same, worse PVS splitting.
Source engine func_detail: Good lighting, faster vis time, and clean PVS since it treats them as func_walls. Thing is, I don't know how you would gain the benefits of true func_details (the Source way, the right way) unless the compiler turned them into info_notnulls or func_walls. Otherwise, the mod would need to support func_detail entity in its progs.dat Unless engine support for func_details was added. Currently the compiler de-entity-ifies them into normal brushes. But if they were kept... What you describe about detail brushes in the Source engine sounds close to my suggestion about see-through solid volumes.
Isn't all VIS/PVS data precompiled in quake? Why do we need to turn brushes into a specific kind of entity in order to get a desired effect?
Would it not be possible for VIS to just look at a func_detail, say "I'm going to treat this as if it were a func_wall" and be done with it? How does it work currently? Yeah, I'm going to take another stab at fixing func_detail's PVS issues. mankrip your suggestion sounds good to me, and it sounds like it'll share the same implementation.
How about (assuming I can get these to work :-) - func_detail_fence - same as "func_detail" but doesn't clip away world faces, so it's usable for fence textures. Like func_wall, but doesn't use up an entity. - func_detail_illusionary - same as func_detail_fence but no collision hulls. Like func_illusionary, but doesn't use up an entity, and as a downside it would block gunfire. Not sure if this would be useful? That's good.
func_detail_illusionary would actually be really useful to simulate crouching. The real ground would be lower, with a func_detail_illusionary ground a little above. Of course, this would affect monsters too, so its usage may be limited to small areas. I don't care much about quicker VIS times; all I want to achieve is phong shading and occasinally minlighting on brushes without taking up additional entity/model slots. Although marksurfaces eventually forced me to turn many of them into func_wall after all.
As for the issue I mentioned above, there's a workaround. As it turns out, phong and minlight also work on func_group, so making the big face a group instead of detail gets all the effects without the PVS problems. Good to know, albeit even more hax... LIT2 (see the opening post) supports increased lightmap resolution and we all went round the block with it a few years ago. No clear community consensus formed.
My own opinion is that it's a poor trade off for hugely increased file sizes, and it doesn't even look as good as you'd think owing to losing the soft edges on shadows. It could be useful to add a compiler/worldspawn option to set portal brush contents to CONTENTS_EMPTY, because as it is, using CONTENTS_WATER, portals can't be (partially) placed inside of slime and lava.
By the way, Quake's episode 4 already has maps with underwater portals. So, allowing portals under slime and lava would bring more feature consistency to mappers.
Used black for its teleport texture.
I think you mean teleport. Portal is something created by vis. That's not a terrible idea but I think it would serve better as an entity field: _overridecontents 1 or something to that effect. Just copy the teleport texture and call one copy *lavateleport and the other one *slimeteleport in your wad file.
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |