#8632 posted by Drew on 2009/06/13 15:17:02
Saving the file to c/program files/worldcraft/textures...
Maybe I'll try saving it in the wally folder?
Hooray For New Tools!
#8633 posted by JneeraZ on 2009/06/13 15:26:43
No, I'm not done yet but I do have TreeQBSP running on OSX and it solved my recent compiling woes. Well, it's hacked together so it works anyway. I need to go back and fix my hacks and smooth out some rough spots before I can call it "done" but at least I can compile my level again.
I'll work on LIGHT and VIS next... Woot!
Out Of Curiosity...
#8634 posted by JneeraZ on 2009/06/13 19:24:03
What is the standard today in terms of WAD specification? I know that multiple WAD support is a must but is it generally assumed that the worldspawn entity has full paths to the WAD files or are relative paths still expected to work (i.e. "gfx/metal.wad")?
I ask because it's getting hairy trying to support both and would be easier if I could just support full paths.
Initial BJP Tools Done
#8635 posted by JneeraZ on 2009/06/13 22:06:37
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!
Willem
#8636 posted by necros on 2009/06/14 00:52:30
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.
#8637 posted by JneeraZ on 2009/06/14 13:09:49
OK, I'll have to come up with a set of rules about where it looks for everything then.
Hmm
#8638 posted by nonentity on 2009/06/14 16:01:19
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.
#8639 posted by JneeraZ on 2009/06/14 16:10:20
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.
Hmm
#8640 posted by nonentity on 2009/06/14 17:15:48
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...
#8641 posted by JneeraZ on 2009/06/14 18:48:21
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!
Hmm
#8642 posted by nonentity on 2009/06/14 20:02:14
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)
Wait...
#8643 posted by metlslime on 2009/06/14 23:15:18
is is all this an attempt to avoid supporting both full and relative paths?
#8644 posted by JneeraZ on 2009/06/14 23:51:23
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...
Mapping Isn't All That Easy, Actually ...
#8645 posted by Ron on 2009/06/15 10:07:34
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"
#8646 posted by JneeraZ on 2009/06/15 11:11:12
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. :)
Ron
#8647 posted by negke on 2009/06/15 11:56:04
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..
Wait
#8648 posted by negke on 2009/06/15 12:01:35
You didn't box it, did you?
Post Your Compile Log
#8649 posted by RickyT33 on 2009/06/15 12:21:32
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
This Is It, Without The Func_wall Trick,
#8650 posted by Ron on 2009/06/15 13:15:45
** 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
OK I See One Possible Explanation:
#8651 posted by RickyT33 on 2009/06/15 13:25:50
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....... :)
I Didn't Know That ...
#8652 posted by Ron on 2009/06/15 13:39:50
[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 !
#8653 posted by negke on 2009/06/15 13:45:22
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.
As For The Figures
#8654 posted by negke on 2009/06/15 13:48:29
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.
Im Sure I Read Somewhere That Light Data
#8655 posted by RickyT33 on 2009/06/15 13:54:12
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
Yeah !
#8656 posted by Ron on 2009/06/15 13:57:39
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 ...
|