 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
These aren't perfect and require things like full paths for WAD files to work correctly, but they do work on OSX with multithreading support:
http://wantonhubris.com/BJPToolsOSX/ There are binaries in there as well as source code for those who are so inclined. I'll be massaging these a little as I get a new version of my level editor ready for release (one of these months), but these work! relative paths are prefered. there is a maximum limit to the number of characters you can put in a string, so when using multiple wads, if you had to type in the absolute path all the time, you'd quickly use up those chars.
Surely just getting it to check the folder the tools are in and <quake root>/gfx should be enough.
That and mebe a default WAD dir settings option added to search locales. Well, <quake root> and <quake root/mod>. There's a bunch of permutations. I'll figure something out. I'm probably just going to pass the Quake path and the current mod name to the BSP tool to give it a big hint.
Shit, forgot about mods (again). But yeh, throwing it the Quake path and mod name should let it find the WADs easily without having to search the entire HDD...
That's my current plan. I'm going to pass it the Quake directory and the current mod name. That will allow it to try looking in the gfx folder in the mod, the gfx folder in id1 and if those fail, use whatever it has as a literal path. That should be enough!
User defined custom 'uber wad folder' path from settings?
(I'm just making suggestions, all my WADs are in the Q3 map folder with my compile tools/batch files) 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.. 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'.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |