WhiteShdw Posted December 16, 2002 Share Posted December 16, 2002 Originally posted by AKPiggott You could be right, but it doesn'y explain why I don't get the error in SOF2Map. That is weird indeed. But it is an error that also occurs in Sof2map. LDJ used Sof2map for his original DoTF map and it had the same problem. I just can't win. I've worked long and hard on this level, it's just shaping up to be really good and it looks like I'm going to have to scrap it. Before you do that, would you mind giving me a crack at it? I really want to get this problem solved. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 16, 2002 Author Share Posted December 16, 2002 Cheers White but I think I've solved it! I removed the "fs_game base" parts from the BAT and now the shaderlist only loads once! It appears the error was with the BAT the whole time. I'll compile it tomorrow morning and let everyone know how well it goes. Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 16, 2002 Share Posted December 16, 2002 I'm keeping my fingers crossed Link to comment Share on other sites More sharing options...
Emon Posted December 16, 2002 Share Posted December 16, 2002 If your compiles in GTKRadiant are slow, then turn off BSP monitoring in Prefs and shut it down into sleep mode when you compile. Link to comment Share on other sites More sharing options...
Emon Posted December 16, 2002 Share Posted December 16, 2002 Glad to see you got it working, hopefully. And yes, never ever scrap your work because you can't get it to compile. ALWAYS give it to one or more people and let them try it out first. Wouldn't want to loose something that works perfectly. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 17, 2002 Author Share Posted December 17, 2002 I just compiled it, I still get the error "SV_SetBrushModel: NULL". What causes that? A pain really because I can't find out whether I still get the shader error. Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 17, 2002 Share Posted December 17, 2002 Do you get that in Radiant while compiling or do you get it in your junk.txt that's generated by Q3map2? I've never seen that error before, but maybe we can check out some Radiant forums and or some Q3map2 forums for it. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 17, 2002 Author Share Posted December 17, 2002 I found out what it is. It is when you have a brush that has 0 thickness. I think this problem was generated with the bobtools crush cleanup "fix". Luckily, I was able to find a backup of my level that GTKRadiaint created shortly before I ran the brush cleanup. That was very lucky, I thought the level was completely screwed for a moment. Vis compile with this week old version of the level is taking unusually long. I recently went and converted a load of structural brushes to detail brushes, so the backup was probably created before then. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 17, 2002 Author Share Posted December 17, 2002 Damnit. I compiled it and still got the same shader error. It can't be the BAT then. However, I discovered that the brush cleanup wasn't causing the null brush error (it was something else that I can't be bothered to explain). So I'll see if compiling after cleanup helps. Also, what extensions can I use to speed the "vis" up? With Q3Map2 it takes over 5 hours, with Sof2Map it takes about 2 hours. Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 17, 2002 Share Posted December 17, 2002 maybe you can take out the lightstage, if you hadn't already done that. Or if you can't do that, delete "-super 2" and if you're using it, "-bounce 8". That's really for a final compile. But it's weird that it takes longer than Sof2map. It should be faster. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 17, 2002 Author Share Posted December 17, 2002 It's only the vis part that's slower. Light takes about an hour in Sof2Map, it takes half an hour in Q3map2. Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 17, 2002 Share Posted December 17, 2002 that's even more weird. The Vis part is usually the fastest part of the compile. And Q3map2 should surely be faster in that area. Light can be slower, because you can add so many smoothing options. Link to comment Share on other sites More sharing options...
Emon Posted December 17, 2002 Share Posted December 17, 2002 Q3Map2's BSP and vis stages are more complex and create better output, so they take longer. Meta and patchmeta, which reduce surfaces over the map by merging surfaces and that sort of thing slows it down, but the BSP in the end is better. Link to comment Share on other sites More sharing options...
Leslie Judge Posted December 18, 2002 Share Posted December 18, 2002 And... you can use -fast to make the VIS phase faster. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 18, 2002 Author Share Posted December 18, 2002 Cheers everyone. I just compiled it after running the brush fix. Guess what happens when I run it? NullPolyShader. OK to sumarise, my level compiles OK with Sof2Map (disregarding the memory thing). It used to compile OK with Q3Map2 until about 6 weeks ago, this suggests an error in the map, but this error doesn't seem to bother Sof2Map. There is absolutely nothing wrong with the file structure of my textures or anything. I can confirm that. It's something in the map that has done it. Anyone got any suggestions as to what that could be? Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 18, 2002 Share Posted December 18, 2002 It's not a specific Q3map2 error. It can happen with Sof2map as well. Maybe you would have gotten it with Sof2map as well if you didn't get the memory error. I think you should just contact Raven about it. They should know about it. Anybody know how to contact them? Link to comment Share on other sites More sharing options...
AKPiggott Posted December 18, 2002 Author Share Posted December 18, 2002 No it's Q3Map2 specific. I've been getting this error for a while now, but I just stopped using Q3Map2 and used Sof2Map instead. I didn't get the error with Sof2Map and I was quite happy using it, until I got the memory error. Here's a picture of the error in all its glory: The "NullPolyShader" message is constantly appearing in the top left hand corner. Hasn't come out on the screenshot though. Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 18, 2002 Share Posted December 18, 2002 I know you only have it with Q3map2 in this case, but it's not a Q3map2 only problem. This is what I get when I load LDJ's episode1 map into SP. And I'm 100% sure that it was not compiled with Q3map2, because I explained him how to use Q3map2 when he was working on his Carbon Freeze 2 map.(which also has the null poly shader error btw ) And he made Carbon Freeze 2, 2 maps after Episode 1. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 19, 2002 Author Share Posted December 19, 2002 I know the NullPolyShader error can be generated by any compiler, what I meant was that it is Q3Map2 specific in my case. I just tested my level in MP and I still get the error... so it's the same error as LDJ's but it must be caused differently. Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 19, 2002 Share Posted December 19, 2002 I'm gonna get in touch with LDJ, to see if i can get his mapfile. Shouldn't be a problem. I'm gonna do a little experimenting with that. Maybe if i can fix that one without completely remaking it, like we originally did, we'd be a little closer to a solution. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 20, 2002 Author Share Posted December 20, 2002 That will hopefully provide some light on the subject. Thanks a lot. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 20, 2002 Author Share Posted December 20, 2002 Ydnar suggested size could be a problem here. I'm gonna try compiling Raven's "kejim_outpost" map file. If size is an issue, the error should occur in this level as it's a lot bigger than mine. Link to comment Share on other sites More sharing options...
AKPiggott Posted December 20, 2002 Author Share Posted December 20, 2002 GREAT NEWS! I looked up on the memory error with SOF2Map and I found that changing the samplesize in the command line should help. And it did, bloody marvellously in fact. The level compiled brilliantly and in just over two hours too. So until another fatal error comes along, I think I'll stick with SOF2Map. Link to comment Share on other sites More sharing options...
WhiteShdw Posted December 20, 2002 Share Posted December 20, 2002 That is great news indeed. Link to comment Share on other sites More sharing options...
Evader Posted December 20, 2002 Share Posted December 20, 2002 But wouldn't changin' samplesize degrade the light resolution in map? I struggle with the same problem and what I'm tryin' to do is degrade the samplesize only on some big areas through the shader script. I'll let you know if I make it right. That is, if you're interested... Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.