It's cool, the code is written now. It support relative and full paths as best it can. Now to add multiple WAD support to ToeTag itself... 

I'm having a bad feeling about my map ever getting finished.

First I got a (new) error, this time in the VIS, a nasty "Vismap expansion overflow".
I thought I'd try something to (try and)fix it, I made large parts into a Func_wall.
The (fast)Vis works OK now.
Only now the Light does not work, I don't get any errors but the level is full bright.

Now I understand the phrase "don't give up your dayjob" 

Well, mapping for Quake is actually one of the harder disciplines. Quake is relatively primitive and therefore has many gotchas for stuff that modern engines don't care about. It's very unforgiving at times. :) 

Either your map is VERY huge, or it's leaking. Are you using the latest (Bengt Jardrup's) compile tools?
Turning stuff into func_walls has to be done with caution. It lowers the VIS time, but may well be contraproductive in other areas.

A map usually doesn't get fullbright over night (heh). Double-check your settings. Or maybe it's caused by func_walls + skylight.. 

You didn't box it, did you? 

So we can see it. Beware the maximum post length though, you may have to split it into two halves...

The QBSP log would be the most helpful 

** Executing...
** Command: Copy File
** Parameters: "E:\Quake\ID1\MAPS\map.map" "e:\Quake\Id1\maps\map.map"


** Executing...
** Command: F:\gametools\WorldCraft\QTools\Qbsp.exe
** Parameters: e:\Quake\Id1\maps\map

TreeQBSP v2.05 -- Modified by Bengt Jardrup

Input file: e:\Quake\Id1\maps\map.map
Output file: e:\Quake\Id1\maps\map.bsp
---- LoadMapFile ----
*** WARNING 06: No info_player_deathmatch entities in level
----+----+
13386 faces
2308 brushes
523 entities
79 unique texnames
2400 texinfo
27 texture frames added

Building hulls sequentially...
Processing hull 0...
---- Brush_LoadEntity ----
----+----+
2041 brushes
---- CSGFaces ----
----+----+
11736 brushfaces
14349 csgfaces
11889 mergedfaces
---- SolidBSP ----
15547 split nodes
6673 solid leafs
8717 empty leafs
158 water leafs
29675 leaffaces
26381 nodefaces
---- FillOutside ----
1177 outleafs
---- MergeAll ----
11626 mergefaces
---- SolidBSP ----
----+----+
7485 split nodes
3251 solid leafs
4188 empty leafs
47 water leafs
19866 leaffaces
15947 nodefaces
---- Portalize ----
4235 vis leafs
15742 vis portals
---- Tjunc ----
15158 world edges
55601 edge points
14249 edges added by tjunctions
2 faces added by tjunctions
---- MakeFaceEdges ----
----+----+
---- GrowRegions ----
Processing hull 1...
----+----+
----+----+
Processing hull 2...
----+----+
----+----+
---- WriteBSPFile ----
7856 planes 157120
22989 vertexes 275868
8326 nodes 199824
2400 texinfo 96000
17343 faces 346860
22072 clipnodes 176576
4994 leafs 139832
21337 marksurfaces 42674
81294 surfedges 325176
41390 edges 165560
106 textures 1737648
lightdata 0
visdata 0
entdata 40467

1 warning

Elapsed time : 0:16

Peak memory used : 22.1 MB

** Executing...
** Command: F:\gametools\WorldCraft\QTools\light.exe
** Parameters: -extra e:\Quake\Id1\maps\map

----- LightFaces ----
extra sampling enabled
523 entities read
lightdatasize: 364948
0 switchable light styles
83.0 seconds elapsed

** Executing...
** Command: F:\gametools\WorldCraft\QTools\vis.exe
** Parameters: -fast e:\Quake\Id1\maps\map

---- vis ----
fastvis = true
4235 portalleafs
15742 numportals
************ ERROR ************
Vismap expansion overflow

** Executing...
** Command: Change Directory
** Parameters: e:\Quake


** Executing...
** Command: e:\Quake\darkplaces.exe
** Parameters: +map map 

You should run the vis tool before you run the light tool!

I would recommend compiling the map using a command prompt (windows "dos box").

Copy your tools (TreeQBSP.exe, vis.exe and light.exe) into your e:\quake\id1\maps\ directory.

Then go through your start menu to Programs=> Accessories=> "Command Prompt"

Type (without the quotes) "cd e:\quake\id1\maps\" then press enter

Then type "TreeQBSP map" (where I noticed that "map" is the name of your map :), press enter and the program will run as normal

Then run vis, i.e. type "vis -fast map" or "vis map" then press enter.

Then run light, so type "light map"

Note: If im telling you things which are obvious to you here please dont be offended.
It is definately risky to run light before vis, and I think that might be the source of your problem.

Awaiting more feedback....... :) 

[quote #8651 posted by RickyT23]
You should run the vis tool before you run the light tool! [/quote]
I didn't know that, I always assumed that WC's standard was the right way. I'll give your suggestion a try.

What do you think about the figures though ?
Are they what you would call high, and is there room for adding stuff ? I still have to put some things in.

PS. it takes a lot to offended me ;), I'm actually very happy with all your help and feedback ! 

It is definately risky to run light before vis, and I think that might be the source of your problem.
The order in which one runs them doesn't matter. Both tools create individual data and store them in the BSP - they're independent from each other.

Ron: it seems as though while you're using the new TreeQBSP, it's still the old LIGHT and VIS tools that come with Worldcraft? If that's the case, switch to the BJP ones and see if that helps. 

They aren't too high or anything. There's still plenty of room for new stuff. TreeQbsp will tell you if the map exceeds any of the BSP limits. 

in a map can screw up the vis process. Maybe im going mad! :)

Ron: Negkes right about the tools, use these tools:

http://www.quaddicted.com/tools/visbjp.zip

Also TreeQBSP is good, but I remember AguirRe saying that TxQBSP was better for some reason, TreeQBSP didnt compile sickbase IIRC.

TxQBSP:

http://www.quaddicted.com/tools/txqbspbjp.zip

:S 

I wasn't sure if I was using Bengt Jardrup's Vis and Light's so I downloaded them again. I also did run the programs outside WC in a Dos box, combining both your suggestions. And it worked fine ! The fast Vis worked and Light as well !
And a lot faster too ! Thanks a lot ! Really, I'm quite happy, I've been working so long on this damned map now, it would be rather sad to have to bin it now ... 

The only warning is a superficial one, and with 22000 odd marksurfaces/clipnodes it must be a fairly large or detailed map :)

This is a useful source of info regarding Quake 1 mapping tools, buy AguirRe:

http://user.tninet.se/~xir870k/tooltips.txt

try runnning the bspinfo tool on your map too see the limits and how close you are to them...

Also post some screenshots please :DDD 

"The order in which one runs them doesn't matter. Both tools create individual data and store them in the BSP - they're independent from each other."

This is my understanding as well. If anyone has any concrete information about why vis should be run before light, I'd love to hear it.

AFAIK, as negke said, they are totally independent of each other. 

You can do is alpha testing - send your source to an established mapper who's already had to battle through the compile issues, they'll be able to point out known issues.

The less time you spend banging your head against a wall and the more time inventing cool stuff the better.

Don't know how much time I'll have this week, but probably by thursday I can take a look if you want - my emails under 'people'. 

To Rick: I'll run the bspinfo tomorrow or later this evening, I'm now doing a full vis, it's at 47.19 % at the minute and I've still got an estimated 7h 44 minutes to go. I think I will kill some time (and probably braincells too...) in the pub ! As for screenshots, I'll try to get some of more or less finished areas later. I have still got to do quite a bit of texture alignments and stuff like that to do. I don't want to post anything that's just not quite, ehm, good enough.

To Ijed: Thanks for your very generous offer !
I really appreciate it, and, if the offer still stands and you have time, I will gladly make use of your expertise. But to be honest, at the moment I'm back in and will battle on until the next problem arises.

Thank you all. You've made my day ! :) 

for the vis to finish, it will slow down as it nears completion!
I once had a map which took 6 and a half days to vis. And JPL, well he's the current record holder........

It must mean that the map has some large areas in it with a fair bit of detail, or some tiny details in it, or that there are places where you can see through a lot of rooms from some angles.... 

There are some basic tips to follow like - if you have gratings make out of brushes, func_wall them because each hole in the grating is a portal and VIS will need to process it and all of it's children. Very nasty.

The same goes for railings, cages, barred windows, etc. 

The only drawback there is if you were counting on cool shadows to be cast. In that case, well, suck it up and eat the VIS time. :) 

That said, I'm surprised that someone hasn't come up with a version of light that would cast light from func_walls (optionally, of course). If you aren't going to be removing the func_wall at some point through a killtarget, it seems perfectly reasonable to use it as a shadow caster. 

Something for you to do next weekend... 

Good job on the tools Willem. Multiplatform ftw.

This is my understanding as well. If anyone has any concrete information about why vis should be run before light, I'd love to hear it.

Some of the light programs use vis information to do quicker lighting. I think Lord Havoc's tool does this. Not sure on bjp's.

Some tests seemed to indicate that bjp's vis does more effective culling than others, btw. 

That said, I'm surprised that someone hasn't come up with a version of light that would cast light from func_walls

This has been on my compiler wishlist for a few years, along with other stuff like self-shadowing bmodels, global illumination, minlight on bmodels, light contribution caching for fast re-lighting after small lighting changes, "manual vis" (as used in medal of honor), portal-based vis (a static variant of the portal visibility used in doom3), hard-edged shadows, cubemapped lights, shambler clip brushes (hull2 only), nonsolid brushes (hull0 only), etc. I have hacked up the compiler sources a little bit over the years, but never enough to produce anything finished enough to release. (seriously, not even finished enough that i could use it for everyday mapping.) 

Even if that were true, lighting is very rarely the bottleneck. I suppose it could be cool if you were wanting to do fast iterations on lighting or something though...