Tyrann: you are awesome.

just in case you didn't know. 

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. 

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... 

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. 

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!

tyrutils-0.6-46-g9c8cbfd-win32.zip 

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. 

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. 

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. 

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! 

and indicate which brushes (line numbers) cause problems Incan probably give you a hint on what is going on exactly. 

I know exactly where the weird brushes are in the current iteration of the map, but it's stable and vising properly (except if you noclip to the bottom there are tiny little rooms between the brushes).
Honestly it's just the way I've done the terrain. I'm not redoing the whole thing a third time as triangles now, it would probably drive me to murder. I thought of another possible way of doing the terrain just as I went to sleep last night but again I just want to get the map out as long as it vis's right now. 

But it would still be useful for me to see where what TB shows you differs from what QBSP will produce. 

you an email with the file with an explanation. 

On one map world brushes dont showing up (if they are compiled at all, not sure)- only funcs show up;
other compilers (txqbsp, hmap) compile same map fine.

Func_detail usage creates pretty much broken PVS.

Made in Netradiant. 

confirmed: happens when you move brushes between ents involving func_group, moving back to world doesnt help - they still dont get compiled, but moving to other funcs makes them appear.

As said, other compiler do fine
netradiant 

and probably cause netradiant leaves empty brush ents in .map

"classname" "func_group"
}
// entity 230
{ 

@slapmap: Weird. Can you send me a .map which shows the problem? 

This is something in bjp tools that I always used. Your light says it is not supported, though the lighting doesn't seem very different.

Also, I had an error about a missing face if I used light after newskip, but not when I used bjp light. Does your bsp support skip now, because if it does, I guess I can probably just switch. I'll probably want it for detail brushes anyway :)

_selfshadow and _shadow are awesome though! Thanks! 

sent 

@slapmap: Thanks for the test maps. Should be fixed now - try the new snapshot

@than: Yeah, my qbsp supports skip but I only just looked at newskip now and realised that it has water/slime/lava skip as well. That shouldn't be too hard to add. Will look at what is going on with lighting newskip'd maps... 

@than: does this give the expected results?

tyrutils-0.6-52-g4625245-win32

It's not 100% identical to the bjp tools when it comes to treatment of "local minlights", but it should otherwise just make minlights additive. 

thanks for that. I'll try to test it as soon as I can. 

I tried -anglescale (and -anglesense) 0.01 and 0.99 and sunlit area looks identical. Shouldn't it be dimmer with higher value or faces hit at non 90deg? 

@slapmap: oops, missed setting the sunlight variable from the command line. This should fix it:

tyrutils-0.6-53-gee2dc38-win32.zip 

does this actually work? I was experimenting the other day with setting it to really high amounts to see the effect... and even at "-gate 100", there is nothing apparent. My assumption would be that this would make the map very dark with harsh cutoffs. Am I confused on how this works? (I understand that it's intended to be used with very low settings)

Using the released 0.6 tools. 

should work - only affect 1/x, 1/x^2 lights though. Doesn't affect lights with the default linear falloff. 

Updated to affect linear lights as well in the next release (which I should do soon). 

Updated to affect linear lights as well in the next release (which I should do soon). 

Hmm, I still get no visible difference, even took screenshots - nothing. Sunlight is even no matter what value I use http://imgur.com/4GNXAzC

I use "light -anglescale 0.xx mapname.map"
to compile.



Again, thanks for quick updates 

I get a clear difference here - what keys are in your worldspawn entity?

-anglescale 0.5 (default)

-anglescale 0.0 

"light" "10"
"_sunlight" "110"
"_sun_mangle" "300 -65 0" 

@slapmap

Those keys look okay. Just check the light.exe output and make sure you're running version 0.6-53-gee2dc38. Otherwise, if you email the .map to me I'll try it here and see if I can tell what's going on. 

Would it be possible to have separate vis for water,slime and lava? This way you could have a controllable form of occlusion culling to help keep r_speeds low. 

r_wateralpha applies to all fluids, so you'd need to have some engine cvar that applies only to water in order to use that properly, otherwise you'd get HOM effects on the lava and slime that were blocking vis if their surface transparency was using the wateralpha setting :/ 

Nothing too earth shattering if you've already been using the snapshots, but if you're still on v0.5 or v0.6, there are some nice worthwhile changes:

* Unix man page documentation for the main tools (qbsp, light, vis)
* HTML and text documentation is generated from the man page sources
* qbsp: added support for using WAD3 texture wads used by Hammer
* qbsp: include clip brushes when calculating bmodel bounding box
* qbsp: enable creation of clip-only bmodels
* qbsp: recognise and remove *waterskip, *slimeskip and *lavaskip surfaces
* qbsp: added hintskip texture support
* qbsp: fixed some bugs parsing empty func_group/func_detail entities
* light: implemented self shadowing and full shadows for brush models
* light: implemented the "-soft" command line option
* light: implemented the "-addmin" command line option
* light: implemented the "_anglescale" (aka "_anglesense") key and cmdline
* light: remove support for negative color components (never worked properly)
* light: removed the "-nominlimit" option (now the default behaviour)
* light: removed the "-compress" option (a bad idea from long ago)
* light: make -gate command line affect linear falloff lights as well
* vis: changed the default testlevel to 4
* vis: added the '-noambient*' options to disable auto ambient sounds. 

So I decided to have a look at using your tools for making my deck remake into a singleplayer level (along with using the new version of trenchbroom) and all I get is constant errors about leaks that weren't present when I used TreeQ to compile the map.
I've tried to fix verts and such but to no success, the pointfile doesn't point to any leaks... 

To save Tyrann some time, can you send him the MAP file so he can debug it? :) 

Ok, I've forwarded the email that I sent to SleepwalkR as that contains the details. I've included the .map, the .log and the .pts file. Doesn't seem to point to anything with the confines of the map. Bear in mind that this fully compiles using TreeQ, I'm not sure why it doesn't compile with your new tools because I'm not so familiar with mapping for quake. 

I loaded the .map included in the download in Hammer got 20 brushes that could not be loaded. the missing brushes cause leaks. Loads fine in Trenchbroom and compiles without leaks using Txqbsp.exe 

Did Hammer say anything about why those brushes could not be loaded? 

Hammer gives no usefull info

Any way to get the map line number from selected brush? I found the missing brushes but how to pass on the info. 

Changed the texture in trenchbroom and saved. As long a brush order was not changed on save. brush starting at line# 15116-15127 and 15128-15139 are two that will not load in Hammer 3.4 build 2363 

Thanks, looking at it now. 

Wow, this is an interesting one!

There are some odd plane definitions, just off the grid like this one:

( 55.9998779296875 103.99990844726562 -72 ) ( 80.00042724609375 128.00054931640625 -72 ) ( 55.9998779296875 103.99990844726562 -88 ) tech04_6 0 0 0 0.5 0.5

But the pointfile my qbsp is generating looks like complete garbage. Might take a while to work it out, but I think it's worth finding out exactly what is going on. 

I only ever bring problems to the table, I'm kind of a jerk like that. But at least you have a complete maniac messing around with all these tools, should make for fun times! 

TB should round the plane points if they're this close to integers. OTOH, the way the vertices are generated, small changes to plane points may yield big changes to vertex positions. 

Getting this error:
---- GrowRegions ----
*** ERROR 43: Internal error: entity->iVertices > entity->cVertices

I'll mail you the map if that's ok? It's made in Worldcraft by the way. 

---- light / TyrUtils v0.7 ----
running with 2 threads
BSP is version 29
using minlight value 40 from worldspawn.
Colored light entities detected: .lit output enabled.
************ ERROR ************
LoadEntities: MAX_MAP_ENTITIES

BSP built with version 0.7
Same map will light with mhlight.exe 

@than:
had this error too.
was skip texture on some surfaces of clipped or vertex edited brush entity. 

somewhere in the map, given the number of clipped or vetex edited brushes in it. I don't see why that would cause a problem though :/

Are you also using Worldcraft 1.6a? I didn't think anyone but me used it these days (I think most people use 3d accelerated 3.3) 

@than, @Stahlkralle, @mechtech

Thanks for the bug reports guys. Both issues should be fixed now - please try the new snapshot and let me know if that's fixed it. 

Map compiles fine now!!!
The func_detail thing is working great. Like getting a new CPU. vis is no longer the enemy. 

---- GrowRegions ----
35%---- light / TyrUtils v0.7 ----
extra 4x4 sampling enabled

GrowRegions breaks with no error at 35% and then light won't run because there is no bsp :/

Did you manage to get my map to compile? If so, maybe there is some problem with the current version. It's currently under all limits and is compiling fine with aguirre's qbsp though. 

@than: yes it compiled here, although without textures - I'll try to work out which wads I need, but feel free to just email them to me if that's easy enough. 

Causes HOM. Works like slime but does the HOM like a worldbrush with skip texture.

Using snapshot from post #235 

I'm a dummy and messed up the test map. This time for sure, Rocky!

tyrutils-0.7-10-g7e6474c-win32.zip 

@mechtech: that's expected unless you compiled with -transwater so that liquids don't block visibility. 

Tyrann my mistake. -transwater did it.
Thanks 

Using -transwater switch causes vis to crash. No errors reported by the program. I get the windows crash warning. Then it goes on to light. Map will run. I emailed the map and wad. 

Thanks guys - there does appear to be a problem with the skip support at the moment. As a workaround, I've added a "-noskip" option to the latest snapshot so you can use that and then run the extra "newskip" tool afterwards.

I'll try to get to the bottom of it this weekend and get a proper fix in there. 

I'll give that a whirl 

@than, @mechtech:

Please give this snapshot a try - both your maps are compiling for me now.

There are still some interesting HOMs in mechtech's map which I'd like to try and solve before I do a new release, but they don't seem to be related to skip at all. 

Compiles, no vis crash, HOM is odd. I removed func_detail and compiled with Txqbsp, newskip, WVis and mhlight just to make sure I hadn't screwed up the map. Compiled without error and no HOM. 

As I thought, the HOM was my fault - qbsp bug.

This new snapshot should hopefully be bug free! I'll do a release if this one looks okay. Thanks again for testing! 

This new snapshot should hopefully be bug free!

You jinxed it! ;-) 

I compiled with the new snapshot. HOM is gone. I expanded the use of func_detail in the map. I haven't found any bugs yet, I'll keep trying to break things.

I do have an idea that might be useful for beta testing. Could a command line switch be setup to cause func_detail to use a specific texture. I could then run through a map and see better what can be optimized.

example

http://www.quaketastic.com/upload/files/screen_shots/detail1.jpg
http://www.quaketastic.com/upload/files/screen_shots/detail2.jpg 

If so:

WO_OT?!?

That looks sweet as furk. 

That was an experiment I did with the texture set from Sock's website. Made some models with Gmax, hacked up a few I found on the internet to reduce poly count. At the time all it could ever be was one room. Vis time was prohibitive, so the map is unvised.

Then TyrUtils showed up. In the second shot you can see what I turned into func_detail. Vis treats it as just a box. Vis in under 2 minutes!!!

The unvised version with texures and sound is here http://www.mediafire.com/download.php?e2m52lju85lldv5
Use Fitz V it has hi rez skins. 

Broke something :)

Latest snapshot does not generate a correct pointfile. In Hammer pointfile shows up well outside the map grid. 

light / TyrUtils v0.6

0....1....2....3....4....5....6....7....8....9....************ ERROR ************
\
LightThread: no model has face 8213
0....1. 

Get the files on post #248

I got that error when using newskip.exe
Latest version does skip removal. 

The external skip tool will cause that. I should probably reduce that to a warning and skip to the next face. 

Looked into the detail re-texturing thing a bit this morning and it's a little tricky due to the order in which qbsp currently sets up the textures/texinfo/etc. But it's a cool idea and I'll keep it on the todo list for later.

Those screenshots look awesome by the way. 

No major new features, but some important bug fixes since 0.7:

* qbsp: fixed surface edge corruption when using skip surfaces
* qbsp: fixed portal generation for transparent water and detail nodes
* qbsp: added "-noskip" option for troubleshooting skip related problems
* light: reduce "no model has face ###" to a warning
* vis: fix portal stack corruption in ClipStackWinding
* bsputil: added a "--check" option (beta!) to check internal data consistency 

nt 

Forgot to add a download link!

http://disenchant.net/utils/ 

dalay 4 -addmin = realism achieved, no need for radiocity!

I'm actually very happy now, for the first time I got truly good lighting out of q1 compilers. And better than from q-rad. No more dull flat outdoors! 

would be nice to see a picture of what kind of lighting you achieved with the delay 4 setting.

I always use addmin, but usually try and eliminate minlight for the final map, adding as much fake ambient as possible via fake bounce lights placed in the map. This is basically lights with low intensity and long falloff placed near highly lit surfaces to simulate light being reflected off the surface. I think it works quite nicely, but it's a bit of a hassle to set up, so some kind of automatic way to do it (or even real radiosity ;) ;) ;) ) would be a great help. 

Comparitive screenshots please! 

Using many small local minlights spaced around the sky flat
same with -addmin: sexy

I wrote a detailed post /tutorial explaining with some more pics.
I thought delay 3 would be the same, but it works differently, can Tyrann explain why? 

and the results are really nice too. 

Never occurred to me to try that. Thanks!

Also reminds me of the antilights feature... 

You can still see that you have used multiple light sources because there are some extra shadows, but overall it looks pretty good. Your blog has some nice map pics too - looking forward to seeing what you are working on!

Your geometry is interesting btw, did you work on some other game(s) before doing Q1 mapping? 

thank you slapmap! 

Thought it was worth a new release just to fix this silly bug with point files being incorrect.

2013-04-24 TyrUtils v0.9

* qbsp: fixed bad pointfile generation

Download from disenchant.net. 

Both delay 3 and delay 4 have no light falloff with distance, but delay 3 brightness is affected by the angle at which the light hits the surface whereas delay 4 has the same brightness at any angle of incidence. 

Does detail just mean they don't create new portals but can still block visibility? 

Detail brushes don't create portals and don't block visibility. 

 

Ver .9 creates a HOM that is not present in ver .8

Do you want the map? 

Yes please, send it through. Not seeing any HOMs in the one you sent earlier. Cheers dude. 

I think (not sure...) that using animating textures on detail brushes causes the compiler to miss out adding the texture to the bsp. I have just been doing some detail stuff on my map, and it seems to do the trick with regard to the compile times, but now I have a missing texture error on map load, which causes FQ to crash :(

Also, I started trying to play with hint and hintskip and am getting some warnings:
WARNING 09: Couldn't create brush face. I will mess around with that and see if I can fix it by recreating the hint brushes and send you the map if I can't. 

 

seems it wasn't the hints, since I removed them anyway.

I also had a few glaring HOM bugs too. Will investigate further soon. Very tired right now so going to bed. 

it was the hint brushes. I will experiment with them later.

The HOM bugs are extremely severe - this is happening in a bare bones version of the map with only the world brushes (no detail), the player start and light on level 4 vis.

vis runs well fast though ;) 

than: Yes, there are secondary shadows which can be reduced using more (but smaller value) ambient lights.
I rather get inspiration from interesting concept art and architecture.

Tyrann: Ah, thats why delay 4 lights produce smoother and brighter result.
And what is delay 5 formula? It's very bleak, have to make light value 100+ to make it noticeable. Cant figure what its useful for. 

Antilight? 

Could it be used to create shadows in a minlight 1000 scene 0_o 

Sorry guys, there was a pretty glaring bug there with the vis util - let me know how you go with the hint brushes as well, since I've only made simple tests for those so far.

2013-04-25 TyrUtils v0.10

* Documentation added for bspinfo and bsputil
* Fix vis bug due to missing vertex copy in v0.9 portal clip changes

Download from disenchant.net. 

Thanks, Tyrann! 

Thank you for the fast update. 

Yeah, I had a small issue when looking at a func_wall through a skip brush that went away with this update. Thanks Tyrann. 

in pretty much all versions. I've been using TreeQ because it doesn't seem to find invisible leaks, I've decided to try and move over to something with more features and I'm getting invisible leaks again. 

I moved to version 10 simply because the pointfile has been fixed, and it's pointing to something that doesn't have a hole in it. 

get it to compile after chopping out a bunch of brushes... honestly though they don't look screwed up to me at all. They all look grid snapped and valid. 

Send me the map file with the invalid brushes please - I can't fix these problems without test cases! 

I'm doing it now buddy chillax!... :P 

I have a version of my speedmap that hard-crashes the qbsp program in the latest build... (yeah it's that buggy as shit speedmap that I pretty much abandoned in a fit of rage) 

@Fifth: It might be a buggy map, but still interesting to see - I don't want qbsp to crash at all. Send it through if you don't mind. 

I had leaks and collision "holes" on my grid-aligned terrain as well, it often happens with complex non-axial geometry like terrain, because qbsp creates many usless splits everywhere from adjacent planes. Sometimes its just random and you can move geometry around and it becomes better (or worse).
Turn on r_showtris and marvel at the mess of q1bsp.

Is it even possible to make compilers stop splitting everything with everything and keep the original editor geometry, like q3map does, but still maintain q1bsp format compatibility? Why even brush_ents have splits inside an entity. Its already bad enough that splits are every 255 units just for compatibility with 90s software render. Ridiculously inefficient. 

To be honest in that speedmap I had messed around with a few settings in the hope that I wouldn't have to change my method of making terrain (which is somewhat similar to floor lofter method in UT)... it was pure laziness on my part.

Regards to the earlier invisible leaks it was some other bug in a different map (non-terrain).
I do want to make more interesting terrain but it looks like I'll have to make compromises if it's for Quake 1. Even making non-collision geometry and trying to make my own clipping using clip brushes seems to bring its own problems.
Even worse is that Q3 is probably a good game to make maps for in terms of stability and compatibility but it's a multiplayer game, who cares about that? It's good if you want to make a portfolio of work, but if you want to make a fun map to play then you'd get a bigger audience mapping for Doom 1 or 2. 

would it be possible to add in a mode where sunlight is replaced with an array of suns shining at different angles in a sphere? would be a nicer, more consistent (and easier) way of doing fake GI.

the sun array needs to be additive, but the values would need to add up to the final value specified as the sun level, so you'd probably need to make the individual suns in the array emit at maybe 1 or 2 brightness, which means you'd need floating point light values up until you right the results into the map file, at which point it would be safe to round them off. 

@necros: Sure it's possible, but not sure how good it would look for a whole lot more ray traces per surface point. Will put it on the TODO list as something to try out though. 

http://necros.fov120.com/temp/nesp10gi.jpg

Fake GI
Normal Sunlight

This is with 32 suns iirc. 

I had modded light.exe to do this a long time ago, and it does look good. You need a lot of suns for best results, though.

FYI, the mod was really easy -- BJP's "skyambient" already exists and uses a multiple sun method, but gives really flat results, and all you need to do is remove the clamping and make the suns much dimmer (and more numerous) and you'll get something that looks like GI. 

yeah, that's what i did for the above shots. i was hoping for some better integration from someone who knew what they were doing. :)

my version has a severe limitation because light levels are integer values but because of the number of suns, the actual light levels that those suns emit needs to be very low so you would need fractional values for all these low level suns. the end result would still be well over 1.0 so you'd just round the final result (after all the suns have been done, since they are done first) and then you would just light normally with the rest of the point lights. 

With a multithreaded light util the extra traces shouldn't matter. Light is never the bottleneck in map iteration anyway! Those tests look great, necros! 

ever apply clip textures to a func_detail... I just spent about 30 minutes tearing my hair out because of errors. 

Use a Skip texture instead. That gives you an invisible (solid) brush that will cast shadows. 

Remember that projectiles collide with skip brushes but not clip brushes, in case that matters to you. But yeah, if it's not possible to create a clip detail (which isn't a very sensible combination when you think about it) a warning from the compiler might be best. 

I was being lazy when I was making the clip brush that's all... I have no idea what a clip detail brush would accomplish. :P 

Can be used to make a shadow where there is no structure (perhaps as a hint to a secret area?) without having to mess with recessed areas behind a sky texture (as seen in e1m5 where there's a Quake symbol shadow leading to the Quad secret) and then using func_illusion to make a false sky. Seeing as the detail brushes will get merged into the bsp as brushes and not as an entity it helps to keep the entity count down as you don't need to have the func_illusion brush.

The tricky part would be putting it where it won't be noticed by the player because it will of course act like a wall in all respects (with the exception that it won't be drawn on the screen). So it would have to be high enough to not block the players movements and not block a monsters attack in normal circumstances. 

You can use a func_illusionary with _shadow set to 1 and skip texture to make invisible shadow casting brushes without collision. 

Really? 

an invisible collision brush that doesn't cast a shadow? 

Didn't know that about func_illusionary either. 

When you compile with onlyents, switable light styles seem to get broken. I remember this being a problem in older tools that aguirre fixed in his tools. Maybe you could check that one out, Tyrann? 

you need to run light -onlyents after running qbsp -onlyents. This is true for the original tools as well, Ii think. 

I don't remember there being a -onlyents option on the original light. That might be what aguirre added as a fix. I'll take a look. 

-onlyents on light is only supported in aguirre's tools afaik, though for all I know, it maybe have been supported in the original tools. I always used tyrlight before switching over to aguirre's tools though (except for the time I used the WC1.6 compile dialogue... yuck!) 

you might be right. I have been using aguirre's tools for a long time now, can't remember what the original tools did and didn't do. 

yes, that's correct about onlyents on light. it was added to address the problem where doing onlyents with qbsp would break switchable lights. 

qbsp:
...
Opened WAD: \program files (x86)\worldcraft\textures\tech1.hlwad
*** WARNING 15: \program files (x86)\worldcraft\textures\tech1.hlwad isn't a wadfile
*** WARNING 01: No valid WAD filenames in worldmodel

And seriously???:
*** WARNING 06: No info_player_deathmatch entities in level

vis:
Seems okay. I love the resume feature.

light:
I'm getting a TestLineOrSky: tstack overflow

Bengt's light 1.43 gives me everything fine. Here's my light info:
454 entities read, 333 are lights, 40209 faces, 500M casts

Unless I'm missing some compile parameter, then I'm going to be sticking with ol' Jardrups light. The vis is wonderful though, thanks Tyrann! 

Not sure about the invalid wad file - can you email me a zipped copy?

Tstack is trivial to increase, will do that for the next release. 

Oh wait - TestLineOrSky has been removed for a while - make sure you're using the latest versions - http://disenchant.net/utils/ 

Does your light compiler support _sunlight2? If not is it possible to add that? 

The only version available on your website is 0.10. I have version 0.6 which is posted at the top of this forum. And sorry, I didn't realize that the wad name was cut off. They are .hlwad's since I'm using Worldcraft 3.3 with the quake patch. It's just the standard quake wads converted to hlwad...well with my own additions and modifications that is, scavenged from various places.

What version is the latest? and does it support hlwad setups? 

After applying func_detail to brushes in my map I noticed with r_showtris that areas behind were showing up. The detail brushes were allowing vis to see through the brushes that intersect the func_detail. I found func_detail cannot be used like func_wall where you block the back and your good. The solution I found was a small void gap between areas.


Qmaster: Version .10 supports hl wad files and format 220 valve maps. Use Utils hompage link above.

Tyrann: the download link points to old version .6 

is actually just a wad3 .wad. AFAIK you cannot load this into TB. So either convert them to normal .wad using TexMex or download the .wad from somewhere (I suggest quaddicted's ftp). 

Version 0.10 is greater than version 0.60? Is this 0.6 + (4 * 0.1) = 0.1 ?? Version maths, what can you do *shrug*. Anyways, thanks, will try.

@FifthElephant: Gotcha, thanks! 

 

Using version 10 now :)
....hlwads load good...
CSG... everything fine
6183 brushes
35535 brushfaces
yadda yadda
---- SolidBSP ----
1...37 38 39 40 41 42 43 44 45 46*********** ERROR ************
Mixed face contents in leafnode near (140.00 40.00 0.00)

no bsp made

This mix point (140, 40 ,0) is a corner where 4 brushes meet. The two walls tjunc. The floor tjuncs with the walls. And a lava brush tjuncs with everyone else. And then qbsp gives me this juncky error. I don't get it, compiles fine in txqbsp. I'll see if I can reproduce it with just those brushes in a dummy map. 

 

I think that's not the junctions, just that you've got a sky brush touching a liquid brush.

Leave a gap between them, filled with regular brushwork if that'd cause a leak. 

Well qbsp finally worked. Wierd output though.
Seems I'm getting 352% for SolidBSP with every other % in between. After 100% they all run together.
....
57 mergedfaces
---- SolidBSP ----
1 2 3...... 94 96 98100101103105107108
110...347 349 350 352 200 split nodes
71 solid leafs
...

I'm still psyched up about having new compile tools! This is great. Multithreaded vis was way faster than my old one. Even between versions Tyrann has made improvements. Version .10 vis was about 8 minutes faster than .6 on a map with 6000+ brushes...surrounded by a cheater's cube!! :P

Tyrann's lighting was also much faster than my old bengt modified light, less than half as much time. Hurray for multithreading! 

Nearest sky brush is over 1000 units and several leafs away from that corner. But that's a good thought, you know I don't think I've ever tried bumping liquid up to sky before. huh.

Hrrmm... Still can't get tyr's qbsp to swallow this one map of mine. Granted, the map doesn encompass the ENTIRE grid in Worldcraft 3.3, but its only 16MB when compiled...so far.

Tried another smaller map. It worked FINE. 

@quaketree - no _sunlight2 support right now, but I'll add it.

@mechtech - I think you are seeing this effect (and it's normal - just fill in the cavity to remove the overdraw).

@Qmaster - Yeah it's not obvious, but the '.' in the version string is a separator, not a decimal point. The old treeqbsp progress counter is a bit whacky and will be getting replaced. Happy to take a look at the compile problem if you send me a .map and any wads I'll need to compile it.

I might make a discussion thread for the utils because we're not really talking about version 0.5 anymore :) 

Tried it on another large map of mine.

I sent you an email with my .rmf and .map files and the log that qbsp spit out zipped up in city_src.zip 

@quaketree - no _sunlight2 support right now, but I'll add it.

Spiffy. I'm guessing that adding features that other popular compilers already support can only boost the use of yours. 

@Qmaster: cheers, will take a look over the weekend. 

Qbsp support for displacement to brushes automatically with a command parameter of dispheight to set the thickness to automatically offset from a displacement surface's normal (negative normal that is) from hammer.

Oh and a command param to disable it such as
-nodisp 

Looks like I've got the same mixed face contents in leaf error.

The map is unsealed though, so will fill in the gaps first.

Comes under the same specifications as QMaster's map - the sky is nowhere near the brushes in question, although there is liquid there. 

The tools don't support non-rectangular liquid brushes. If used then they produce the 'mixed face contents in leaf node' error and don't build the bsp. 

That's pretty weird. Let me test that... 

Not just non-rectangular.

ijed: got a fairly simple test case which show the incorrect mixed face contents problem? 

Will send it sometime today. 

Looks like I won't have time today. I should be able to set up a few test maps easily enough Monday though. 

The small map I got to compile didn't have any liquid brushes.

The two larger maps I tried both gave errors on liquid brushes that were clipped at angles in the corners.

Wierd... I wonder what would have broken that support. 

Rectangular liquid brushes that get tjunc-ed such that they result in more than 4 sides (square/rect) volumes don't work either, although it seems kind of random from my few trials. Hard to make out what is going on when there is such complicated geometry clipping with this one large liquid brush.

I'd look into it but I'm busy this weekend. 

No problem, I've had very little time for this the last couple of weeks anyway. Will be away this weekend too, hopefully back to normal later next week. 

For me.

Not sure if this has already been requested, but a few people have been experimenting with GI solutions recently, starting with slapmap.

I know you mentioned implementing _sunlight before, how about making adding a new field as well _suns / _suns2 which would add additional lights in a distributed pattern to create the GI effect?

I haven't experimented with it properly yet, but it'd be pretty cool to have it at base level in the tools. 

_sunlight is of course already there, but I will be adding _sunlight2/3 to emulate the bjp tools behaviour and I expect I'll add another mode where the light sources are more evenly spread. 

Do you still need the test maps? Not in the office today.... 

what does light.exe warning: no model has face xxxxx try to tell me?
seeing no drawbacks, just curious.
maybe Alpha func_walls? 

Light checks the face number against the surface start/end numbers in the bsp submodels to determine which model it belongs to. I think metlslime's newskip tool changes the start/end numbers of the models when removing skip surfaces but doesn't actually remove the faces from the bsp.

In that case it's harmless, but if you're not using newskip, I'd be curious to know how you got this error. 

using rebbs jury rigged tools, which support skip removal. 

Ok, I suppose I don't need to warn about that. It's just unused data that was left in the bsp file after skip removal. 

can i d/l the latest Version of your utils?
the ones On your site dont seems to reckon -addmin and -soft1 switches.
just got a new machine, trying to Set up from zero, but cant get my old cmdline to run. 

It seems that targeting a light at an info_notnull crashes the light util.

Can't be sure of this just yet though, need to experiment some more. 

Whatever I've done it wasn't the spotlights - deleting has no effect on the crash. 

totally different cause.... 

It seems I've got the same crash as mentioned by Qmaster - tjunc, related to liquid volumes. 

@ijed: thanks for the test case, hoping to get back to some coding this weekend. 

The test is pretty messy though. I've been a worldcraft user for many years and there's a lot of things that it blinkers the user to that other editors don't.

So it's full of misaligned brushes and floating points. Other habits, like using the CZG Curve system blew up in my face and those sections I'll have to replace.

I usually have a new version per 24 hours, so can keep on throwing stuff at you once you're back into the swing of things. 

@ijed: Try this new snapshot. Fixes the tjunc crash for me. 

Thanks.

Will try it out tomorrow. 

---- LoadMapFile ----
************ ERROR ************
line 5: Token too large

The text describing the location of my 5 different wad files takes 290 characters. I'm assuming that the limit is 256. Kinda limiting really. What if my name was like 40 characters? What if I had the wad files buried 6 or 7 folders deep for organization?

It would be nice if the limit was increased for the line starting with "wad". 

use relative paths. 

 

@Qmaster: increased limit to 1024

tyrutils-0.10-32-g272816d-win32.zip