ericwa
[Feature Request] func_viscluster for vis optimization
Would it be possible to implement func_viscluster?
I think it might be useful for more open maps, or maps with messier geometry that generates a lot of visleaves. I was playing around with a certain map file someone made, and it would've been simpler to mark certain areas with func_viscluster, than to try to adjust the geometry or convert things to func_detail. For some of the world geometry, it would have been quite hard to accomplish the task to add it all to func detail and create hidden simplified world geometry)
I don't know if it makes sense in the quake engine, but in source it was useful (though this was in part due to vbsp forcing a split every 1024 units)
interesting idea, I think this could be doable, you're basically just clustering leaves (in Q2 terms) manually. The other approach is to just make a box out of structural brushes and detail everything that is inside of it.
This is issue for map I'm making, it's a Battle Royale quake map, and I can func_details however I was hoping to not using them for everything in hopes of saving some FPS when behind mountains. Although I might have to do this as it currently takes 13 hours for vis on my 8core.
https://i.imgur.com/gI5MXpl.jpeg
Any other Vis features for speed improvements would be appreciated! 😅
Ah yeah I see. To be honest, just run vis with -fast. That should complete in less than a second, even for a map with a billion portals. If you're going to need to cover literally your entire map is a func_viscluster, there's going to be no difference to running -fast.
still helps for large areas? 🤔 still has a use no?
TBH, I would take any VIS tweaks and improvements I can get, I do enjoy this engine, but I do wish it had some source features to improve the render speeds because I have to render out my map, and I would like to do non fast😅
I can func_details however I was hoping to not using them for everything in hopes of saving some FPS when behind mountains.
You would lose the performance gains of using world geometry if you used func_viscluster
Also, if you're using all world geometry in that scene, you're doing it wrong. You shouldn't be using it on rough/irregular shapes. If you need VIS blocking on a mountain, build the visible part of the mountain out of func_detail and stick a world geo cuboid inside it
From checking tutorials like: https://gamebanana.com/tuts/12084
How I'm imaging this is implemented is, qbsp would compile as normal, then vis portals that are touching a func_viscluster get deleted (but we record which leafs/clusters were on either side before deleting them).
Similar to what happens when compiling a Q1 map with detail, qbsp would generate new "virtual cluster numbers"; the portals in the .prt front/back sides refer to these "virtual cluster numbers", vis calculates visibility between the virtual clusters and then at the end of the process, writes out the same visibility data for all leafs/clusters in each "virtual cluster".
This will be annoying/confusing for Q2 which has native cluster support in its .prt / .bsp formats, we'll need to use either a new .prt format or repurpose Q1's PRT2 which has a "virtual cluster number -> real leaf number list" mapping.
