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
Tyrann: you are awesome.

just in case you didn't know. 
Cheers For The Info! 
Doesn't -transwater affect performance? 
It does insofar as it makes the water surface not block visibility, so everything beneath it is being rendered whereas it would've been visblocked if compiled with opaque water. Depends on how much additional detail there is underwater. 
Lighting Water, Lava, Etc. 
Hmmm, it may just work - it looks like the software engine might actually render the lightmaps if the light util generated them. Not sure about glquake. Surface subdivision might cause problems. I'll try an experiment. 
Yeah, it appears it can't be done with tools changes alone. Oh well. 
Cheers for looking into it! I still haven't checked out the latest snapshot... probably will do for the next map since everything is stable and I'm close to finishing... 
Too Bad. 
Tyrann, do you think that it's possible to make a *liquid do what a sky can do in regards to sunlight only upwards instead? Particularly ones that start off with *slime and *lava? At least then it would make some visual sense that they are fullbright. Obviously they would need .lit support and wouldn't be on by default. Maybe put it in the worldspawn. _mangle support might be nice if someone wants to do something funky in their maps. Just a thought. 
Lava Light 
Yeah, I've been thinking about making it possible to set a global lighting level to emit a glow from lava/slime/water surfaces - separate values for each type though. Wouldn't be directed via mangle, but using sample points along the liquid surface.

Shouldn't be too hard but would want to make sure of consistent light levels above and below the water and will need to see how much performace impact it has. 
No mangle is fine, I was just thinking that someone might find some uses for that somewhere down the line is all. Thanks for the answer. 
Maybe you could allow users to set up a file called surfacelights.txt or something that contains a list of textures that should emit light? Maybe it could be defined in a worldspawn key? In addition, having separate support for _lavalight etc. in the worldspawn would be cool. It gets a bit messy if you want to support multiple textures and use different colours, attenuation formula etc. Perhaps it could be set up in a text file? 
I had used Q1rad worked well, the effect was cool, then it broke when the map got large. Maybe light emitting textures could be done with a separate util then appended to the light map. Keep the light program on target without adding more complexity to it.

My ability to write code is limited to cut and paste so ignore me as needed. 
The version of the tools I'm using doesn't support -noambient to disable sounds applied automatically to skyboxes/water volumes etc... I've resorted to using the vis compiler that is coupled with quake adapter worldcraft. Is there a commandline option I am missing on your version? 
Yeah, had it on my todo list but had not gotten around to it yet. You can be my beta tester! 
Brush Entity Shadowing.. 
Not sure this is always desirable. Is there a way to turn off shadow casting for brush entities? It may seem like a weird request but I have a moving platform on top of a kind of cylinder and I don't want the mover to cast a shadow under it. BTW, I've made good usage of _minlight for brush entities, it's a nice addition :) 
the vis I'm using has options for -noambient, -noambientslime, -noambientlava etc etc. 
Brush model shadows should be off by default - they should only cast a shadow if you have added the "_shadow" key.

Those noambient options are what I just added to vis in the snapshot linked above. 
Ah Ok 
I did open the file and only look at the changelog, not the main text :P 
I've had a look at it. The -noambient switches work, but I get CutNodePortals_r: New portal was clipped away messages now that weren't there with TreeQBSP, also it's now saying I have a leak again even though I had fixed all my leaks in TreeQ. Could do with a -noents option so that I can use pointfile to find whatever is causing the problem (the pointfile particles are all outside the map again, grrr!) 
Try adding -particles 1000000 to the quake engine command line just in case you're running out of particles for the pointfile. 
It's not that, it happened with the previous version too. It just displays a line of particles completely outside the map.
When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities. I'm probably going to stop farting around with different compilers for this map now otherwise I'm never going to get it finished :P
(I have like 3 other maps I have started and need to get done too) 
Ah, ok - I thought you meant it was not pointing at an entity at all. I'll look at adding that option. 
When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities.

Having entities that are accessible to the void is the definition of a leak. So you should probably not have entities outside the map (brush entities are okay, point entities are the problem) 
The point is that I can't verify if it's a bsp leak *or* a void entity if I can't -noents, besides TreeQ and vis aren't signalling problems, just Tyr's latest version. It's all a bit weird to say the least.
Kind of having a problem with degenerating brushes for my terrain too, it's really odd. I'm losing interest in the map now, need to get it working as best as I can so I can move on. 
This Might Be A Result 
of using double precision floating point numbers in Tyrann's tools. It snaps vertices to integer coordinates if they are off by less than 0.0001, whereas TreeQ snaps them if they are off by less than 0.001. So if you have two vertices which are off by, say, 0.0005, they will be snapped to the same position by TreeQ, but not by Tyrann's tools. The result could be a microleak I think. 
You're Obsessed.. 
with microleaks! ;)

I'm using TreeQ atm and I'm still getting weirdness. It's probably due to me using cubes rather than triangles for this tri-soup business. Honestly I'm fairly clueless, but the map seems to be holding up ok... just hope people don't laugh too much at me when I release the .map file! 
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.