My unfinished FM... - by Krypt
toolman on 8/4/2005 at 14:57
Had a mess with it this morning. Seemed to be a lot of off grid bsp that needed some quick alignment. And I think, too many portals close together that were causing weird bsp holes. It runs now, however the navmesh doesn't want to build :confused:
h42martin on 8/4/2005 at 15:37
1. Set gridsize to 1. Aligned 211 BSP-brushes.
2. Auto-published Meshes.
3. Deleted brushes:156, 160, 159, 157, 154, 153, 148.
4. Show Zone Properties Dialog. Option “Yes”.
5. Deleted brushes: 165, 163, 161, 166, 162, 164, 167.
After this it worked.
Also deleted StaticMeshActor__168, 166 and 149.
(Dirty meshes, Dun dirt 01 and ManChimney 03. Seems not to be fixed in the Auto-Publish routine. )
Made a new player start. (Player made a strange slow turn in the beginning.)
Rebilt AI-paths. (Fixed NavMesh)
SneaksieDave on 8/4/2005 at 17:06
Are you willing to post that fixed version, to save others the work? This might end up being the most-used skeleton and most-revisited-in-different-forms mission ever. ;)
h42martin on 8/4/2005 at 17:35
Have uploaded a fixed version of Krypts unfinished FM to the FTP site suggested by bukary. I have also sent him a mail.
epithumia on 8/4/2005 at 17:42
I've put the updated file at (
http://thiefmissions.com/thief3/demos/Krypt_1fixed3.zip)
However, this file is on the order of ten times as large as the original zipfile. I'm not sure what the structure of these FMs is supposed to be, but shouldn't this at least be compressed?
[Edit: point to the compressed file.]
SneaksieDave on 8/4/2005 at 17:51
Yes, definitely - compression works great for UNRs. Krypt's original version was compressed 76% in his zip file.
h42martin on 8/4/2005 at 17:53
Uploaded a zipped file of Krypts unfinished FM.
Krypt on 8/4/2005 at 18:35
Wow, nice job getting it to work h42martin. I never did the align BSP brushes thing because I didn't think that would have any effect on it loading. There were some brushes that were off the grid on purpose though, for some of the angled surfaces and some places where I did brush clipping. Hopefully it doesn't change any of the BSP visually or cause any errors, but it might.
Quote Posted by epithumia
However, this file is on the order of ten times as large as the original zipfile. I'm not sure what the structure of these FMs is supposed to be, but shouldn't this at least be compressed?
The way I got the filesize so small was by using an autosave unr file. Autosaves don't contain Navmesh or Flesh bsp data, which usually reduces the filesize by several megs. This is ideal for online distribution, since whoever downloads it can just rebuild it themselves if they want to. Just take the latest autosave unr (make sure it has autosaved since your last changes though) and rename it to whatever name you want.
Quote Posted by toolman
And I think, too many portals close together that were causing weird bsp holes.
If you mean the two portals in each doorframe, that shouldn't cause any BSP holes. That is the double-portaling technique null talked about in his post a while back. You shouldn't delete those :p I did have some BSP hole problems on occasion though since the BSP in places is a bit more complex than the engine is used to. I was able to fix it all by tweaking brush order though.
rujuro on 8/4/2005 at 19:02
Quick question about double-portals. Does that mean that when a portal is obscured by a static mesh it is considered out of view? I thought that portal visibility would be based on brush BSP information alone, but if that isn't the case then that is fantastic.
I'm having some concerns about the static mesh domes that I will be covering some buidings with, and was worried that the portals I put near the ceiling wouldn't actually help since only a static mesh would be blocking their visibility.
Krypt on 8/4/2005 at 19:18
No, all portaling is still based off BSP. Static meshes don't occlude at all. Double portals are just a technique that helps the occlusion match the BSP more closely, ensuring that it only renders what you can actually see.
