News | Forum | People | FAQ | Links | Search | Register | Log in
TyrUtils V0.5
It's been a long time, but finally I have something worth releasing, so here is version 0.5 of my map utils package:

* light and vis both now multithreaded on Unix and Windows platforms
* vis now writes a state file every 5 minutes so it can resume if needed
* qbsp and vis now support a form of detail brushes, similar to Quake 2. See qbsp.txt for further details.
* added a small optimisation to vis for a minor speedup (usually only 1-2%)
* build system re-written and lots of cleanups all over the code

Please test, break and report bugs as needed :)

* Announcement
* Utils Home Page
* Download: Windows, Mac OS X, source

My website has also had an update - let me know if I broke anything and hopefully the comments function also works.
First | Previous | Next | Last
 
will need to play with this on the weekend! 
 
Is there a way to put in some kind of occlusion brush in the same way that water used to be used before watervis? 
Floating Point Texture X/Y Offset, Too 
To keep Scampie's texturelocked trims aligned. 
This 
Is great. Thanks Tyrann. 
Tyrann 
This is great news (I do still compile Quake 1 maps occasionally). I will add a link to your tools to my tutorials once they support the full monty.

Actively maintained tools are basically the lifeline for any kind of modding. Thumbs up. 
Mac OS X Binaries 
I'll look into providing binaries for Mac OS X, would you like to host them on your site? 
Mac OS X 
Thanks SleepwalkR - I was meaning to do that anyway so I've just done a quick build on my ML machine and thrown that up on the utils page. Does that look ok?

Any tips/advice for providing OS X binaries appreciated. I'll hopefully be doing the same for TyrQuake with the next release. 
Awesome Stuff! 
Will definitely give these a whirl next time I compile a map.

Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :) 
Also... 
"After it took 36 days for my map to vis on a fairly decent 8-core machine I knew it was past time that we had something like this for Quake."

How long does your map take to vis now? Have you detailified it yet? 
Heh 
Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :)

I thought the same. Might go replay moonlight. By coincidence was looking at OUM the other day as well. 
Have Not Detailified It Yet... 
...but working on it. 14k+ brushes! :) 
Wish List 
* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast.

* Phong Shading on grouped brushwork. This would be awesome for terrains where the lighting is consistent across surface edges. It is difficult at the moment to create terrain wall sections without obvious light seams.

* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses. 
 
* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.

That's an engine issue I believe. 
 
If we even got the first 2 things on Socks wishlist that would be incredible. Is that even possible though? 
Ai Clip 
This is a C/Qc issue caused by the hull navigation.

You can solve it with an entity called a func_nodraw from the extras mod: http://www.quakewiki.net/quake-1/mods/extras-r4/

Coding one from scratch should be trivial since you just set the model to empty on runtime, I think.

All it does is make a solid brush that you can't see. It's not ideal because you can't shoot through it - but that's the limitation of Quake.

Minlight for entities would be awesome. Q2 has this and it makes life a little bit easier every time you add a door to a map. 
 
<quote>* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast. </quote>
Ooh, nice idea! That would be mega useful. 
 
Fucking tags. 
Clippa 
* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.

To be more specific about what the map compiler does which causes problems - the clip brushes get added to hull-1 (player size) and hull-2 (shambler size), but not the visible hull or hull-0 (point sized). I'm pretty sure that the visible hull and clipping hull-0 are stored separately in the BSP (but please correct me if I'm wrong).

If that's the case, then it should be possible to create clip brush variants where the brushes are considered in different stages. So for example super-clip brushes would be skipped at the visible stage, but included in hull-0 to hull-2, so grenades bounce off them and monsters can navigate them. It certainly ought to be possible to create sub-clip brushes which only affect hull-2, to prevent large monsters getting into parts of the map but allowing players in. 
It's "mangled Tags Monday" 
Get in 
Ideas 
Entity minlight - Easy. Will add that.

The AI clip thing, don't think it's possible. The thing is that Hull0 *is* the visible hull. There is no separate clipping hull for point size entities, they use the same bsp tree that the renderer uses. 
Phong Or Some Kind Of Smoothing 
It should be doable, but the information about which brushes are grouped are lost after the BSP has been produced, so can't use that as a basis.

A tweakable command line parameter (or worldspawn key) to set the maximum angle between two surfaces to consider for phong shading/smoothing should work and I believe there are Q2/Q3 tools that did this (though I forget the name now). Could also restrict it to faces with the same texture as well if that seems like a useful thing to do. 
 
recommend you call it "_minlight" since the engine automatically ignores keys that start with an underscore (this is so you can add new fields for the compilers that don't have to be in the progs.dat definitions list.) Otherwise players will get spammed with "minlight is not a field" messages. 
Phong Shading 
Hmmm...some way of specifying it to only use phong shading on faces that use certain textures might be a good idea...

Whilst we're all in crazy wishlist mode - what about an option for brush entities to cast shadows (on the world and other brush entities) 
 
@Tyrann, doing phong shading on surfaces with the same texture would be awesome. Another option is to use a keyword in the texture name. Maybe you can specify the keyword as a parameter.

Example command line : "-phong terrain" Textures containing the word "terrain" have phong shading applied to their edges.

Having the _minlight key on any entity would be awesome, I can think of plenty of situations where that would be handy. 
Phong Shading Texture... 
Or have it identify with certain texture names? Like how fluids begin with an * or animated textures begin with a + ? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.