That sounds very interesting!

PS: I wouldn't bother with scaling - I mean there might be some situations where you might want to scale a prefab (e.g. the depth of an arch) - but you've got to worry about what the textures do on the surfaces that get affected by the scaling (e.g. inside of the arch), and you're probably better off just making multiple prefabs to cover the small number of scale variations that you'd want. 

The dev builds now have Hexen 2 support ("-hexen2" flag for qbsp. Thanks Spike!), and also the qbsp "-epsilon" flag from txqbsp.

http://quakespasm.ericwa.com/job/tyrutils-ericw/ 

I'll start a dedicated thread around here eventually, so as not to hijack this one, but I thought I should mention I finally got around to cleaning up and releasing the instance thing I talked about.

The changes I made to that other project, VMFII, turned out to be awfully clumsy implemented that way, so I turned the code into its own wrapper project. Curious parties can try out Quinstance from the releases tab of its Github page: https://github.com/ItEndsWithTens/Quinstance

Instructions are included, have fun! 

So it's almost like how external bsp's are used as bmodels? 

I'll tentatively say yes, I believe it's something like that, but I've never worked with bmodels before, only heard vague whisperings of their existence.

I think the best way to describe it is that it's like using prefabs, but any changes you make will automatically be applied to every instance you've already placed, and using a standalone tool means it's editor and compiler agnostic. 

Can Jackhammer render a preview of the func_instance? That would be crazy. 

I'll add support to TrenchBroom 2 as well. 

Sadly no, eric, you don't get a preview in Jackhammer. I only focused on JH when building the included FGD because it's the editor I was using. Positioning things can be slightly irritating when you can't see what you're placing, but keeping Quake running in a window makes it easy to adjust/recompile/reload/repeat, so it's workable. Of course I'd love to see actual display of the instance contents, but it's just wishful thinking for now.

SleepwalkR, that sounds wonderful! Bear in mind I'm not trying to present this as the be-all end-all solution, just one I found useful for my own project. If someone comes up with a better way to do things, I'd be just as happy to use that. 

a copy of the other map's contents will have appeared where the func_instance once was

Are they aligned by their center coords? If this is the case, I would probably try to make func_instance a brush entity of the same size as the prefab, like a bounding box. That would help keep things on grid. 

Ah, thanks for the question, I'll need to clear this up in the documentation. The instance contents are not positioned based on their collective center, no. The center of the point entity and the origin of the instance map are lined up. All objects in the Filename map get offset from the func_instance by the same distance they're offset from their own map's origin, so it's reasonably straightforward to predict where things will be when all's said and done.

The Source engine tools' version of instances does have a func_instance_origin that lets you define a custom origin, actually, but VMFII doesn't yet implement that, so it won't work with Quake maps until that changes.

I should have a News post written up in a few minutes, so if it's accepted we can take further discussion over there. Hang tight! 

When using func_detail, you have leaves (subdivided volumes of the map, including func_detail) and clusters (volumes ignoring func_detail). The vis speedup when using func_detail comes from vis only looking at portals between clusters.

What it was doing before was writing a copy of the visdata for a cluster for each leaf in that cluster - I just changed vis to write a single copy of the visdata for each cluster, and then all of the leaves in the cluster reference the same visdata offset in the bsp file.

All this really does is shrink the bsp file (telefragged.bsp is 10mb smaller) and maybe load a tiny bit faster as a result, but it seems like a nice optimization. Seems to be safe with old engines (winquake.exe) too. 

 

Does light use the pvs data (if present) in any way to speed up traces? 

i believe that was true in quake 2 light compilers, but not quake 1. (unless somebody added the feature to quake 1 light compilers) 

czg, my light tool doesn't use vis data. I experimented with it a while ago, but the code was messy and I couldn't get much speedup from it. I could have been testing the wrong map (was trying telefragged.bsp). It probably would help if there are a lot of delay 2 or infinite lights, but also good vis blocking.

another idea I had is to shoot a bunch of random rays from each light, and use the furthest distance hit as a bounding sphere for the light, sort of a rough guess at the pvs. haven't tried this, though. 

is minimum intensity contribution as bounding sphere already implemented? once a delay 2 light drops below a half percent intensity or so it might as well be cut off anyway, right? 

That's implemented, the -gate option. I think "-gate 1" means to cut off lights when the brightness would be 1/255. 

I think enabling the multithreading a few years back was the most significant speed boost to light. 

Warren, yeah, for sure, the threading is amazing.
Lunaran: lol, you prompted me to take a closer look at the "-gate" switch, and seems it was broken in�tyrutils (was calculating a bounding sphere that was too large). I was wondering why using like "-gate 25" wasn't speeding up maps with lots of delay 2 lights. I think I fixed it.. 

 

I've been using -gate 10 forever... are you saying it's done nothing forever!? :( 

I asked several times in the past about what exactly the "gate" number referred to and what was the range. I never really got a good answer. My working theory is that it's the rgb value of the lightmap, 0-255. So if you set -gate to 20, everything below that is pure black? Or am I totally wrong. What always threw me off was that many references state the default value is 0.01 or some other nonsense. 

Gate -10 seems to light faster than gate -1.
A tiny bit. 

-gate 10 versus -gate 1. 

I think it's been broken since it was added to tyrutils in 2013. If you have a map with lots of delay 2/5 try the devbuild in #158.
On jam6_ericwtronyn I get a huge speedup, like:
No gate: 60s, gate 5: 7 seconds