<!--QuoteBegin--Kage+May 28 2003, 05:09 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Kage @ May 28 2003, 05:09 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> info_compile_parameters is defined in the fgd file. There are so many fgds right now that you're better off just writing in the extra parameters in your fgd. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> He meant having the field actually do something once it's added to the fgd, which requires a change in the code that reads it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I actually added support for cliptype in info_compile_parameters when I added cliptype to the tools back in p3, but I haven't tested it. I also updated it when I added the normalized cliptype to p5. If you've tried adding the key-value pair directly from the command line, it won't process because I made the field a dropdown in the VHE objectproperties dialog, which IIRC requires integer values.
Here's the fgd addition (stick inside of info_compile_parameters):
I'll start publishing this information in future releases so you won't have to be psychic to know how I implmeneted things. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
On a slightly different note, it would probably simplify things if the info_compile_parameters entity wan't in future NS fgds; I believe that VHE allows multiple fgds to be defined for a game type now, and it would be easier to maintain the tool entities in a separate document since they reflect a different branch of development.
Yes, I do realise that Kage. Thanks for clearing it up Cagey <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Ok, i ran into another one of those odd limits, this time it's the MAX_SWITCHED_LIGHTS limit, i dunno if it's possible to increase it, but if you can, BIG Thanks ahead of time <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<!--QuoteBegin--crode+May 29 2003, 02:56 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (crode @ May 29 2003, 02:56 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I also have a problem that may or maynot be related to some sort of limits in either HL or compiling. See my post about it and see what you think
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=33462' target='_blank'>http://www.unknownworlds.com/forums/in...=ST&f=4&t=33462</a><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Allocblock errors can be pretty nasty to track down since you don't have a lot of information to go on -- there's some information on what they are and how to find them here: <a href='http://www.slackiller.com/tommy14/errors.htm#allocblock' target='_blank'>http://www.slackiller.com/tommy14/errors.h....htm#allocblock</a>
As that page notes, it could be related to your leaf saw into leaf error during compile...
I usually tell people to bookmark that page -- tommy14 has collected a huge amount of helpful information on compile problems into a single well-organized source.
I'm making a dod map and I use -cliptype precise. With legacy mode, everything goes like they're supposed to. But when I use precise some parts of the map doesn't clip at all, and some parts just have invisible walls.
<a href='http://koti.mbnet.fi/bugi2/kuvia/clip.jpg' target='_blank'>Picture</a> Area between those red lines acts like noclip, but the whole wall is one brush, and it isn't an entity.
<!--QuoteBegin--BuGi+May 30 2003, 08:17 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (BuGi @ May 30 2003, 08:17 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Area between those red lines acts like noclip, but the whole wall is one brush, and it isn't an entity. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Can you send me a cut-down copy of that map (preferably just that room if the bug is still present) for testing? I have another 2 test cases for this, but haven't been able to pin anything down. Are there any unusually thin brushes or unusually shaped brushes within 1024 units of that wall?
At this point, I've narrowed down the problem in the other maps to code that decides which way a bevel edge should face -- I currently take a dot product between the average normal of the two faces that require the bevel edge and the edge itself and flip the bevel if the result indicates they are over 90 degrees apart; this should always work in theory, but it's apparently not working fully in practice. When a bevel in one brush is backward, it has the potential to not only break the brush its in, but actually remove clipping information from other brushes during the phase that uses CSG on brush faces to create the hull if the resulting overall shape is illegal (e.g. the resulting brush has an inward facing normal).
I'm looking at alternative methods of determining the direction to face the bevel -- taking the dot product with a vector pointing to the centroid of the brush is promising. I am still working out what might be going on with the current solution since it should be working properly; I don't believe the borderline case of a 90 degree difference between a bevel and the average of the faces it cuts is possible on a convex polyhedron, but don't have a mathematical proof for that conjecture.
My original solution to the bevel facing problem was to simply point the vector in the same octant (quadrant in 3d instead of 2d) as the average normal of the two faces, but this was proven to be inadequate when the angle between the face normals was large. Although the current solution is more robust, there is evidently still a border case. I'll be sure to update when I finally nail this problem.
As it currently stands, each bug report appears to be due to a brush that is somehow violating the geometric assumptions I'm currently making (convex and all edges border faces that are less than 180 degrees apart... but that should be every case the code sees since brushes with 0 thickness aren't allowed by the compiler, right?). Tracking down the brush that is the source of the actual problem using the big block method has been a slow process--the location of the clipping hole is not necessarily the location of the problem brush, which has made it tougher to debug.
EDIT:spelling
EDIT2: a little more about the method used to determine bevel facing: if two vectors in 3d space have a dot product of 0, they are perpendicular. If the dot product is positive, they are less than 90 degrees apart; otherwise they are more than 90 degrees apart.
Assuming that two faces have normals less than 180 degrees apart, it stands to reason that the vector bisecting the angle between them should be less than 90 degrees from each. If the bevel face normal is also less than 90 degrees from the mean of the normal vector (substituted for the bisection of the angle), it ought to be facing the correct direction (i.e. although it might be over 90 degrees from one face normal, that wouldn't be true for both).
Thought: perhaps I need to take a more formal approach to bisecting the angle between the normals instead of taking the mean of the vectors?
Wow, highly thechnical. If my native language was English I might have understood it on the first read, but I think there is nothing to comment on in it for me anyway. <!--emo&::nerdy::--><img src='http://www.unknownworlds.com/forums/html/emoticons/nerd.gif' border='0' style='vertical-align:middle' alt='nerd.gif'><!--endemo--> (HEY! Who called this smily nerdy?!?) I assume you use 32-bit floats for performance reasons, right? Then, isn't it possible that these errors occure due to roundings? Some trigonometric functions after another might give you a 0,001 instead of 0 somewhere <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--> I do not really think this is the case, but you should probably make a testrun with 64-bit floats to go sure? (Hope there is not too much asm code in the tools... *looksatthesources*)
I made a copy of that part of the map, and the bug wasn't there anymore. Then I copy-pasted (select all) the whole map and the bug was gone. But I can still send the original .rmf
<!--QuoteBegin--BuGi+May 30 2003, 01:09 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (BuGi @ May 30 2003, 01:09 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I made a copy of that part of the map, and the bug wasn't there anymore. Then I copy-pasted (select all) the whole map and the bug was gone. But I can still send the original .rmf <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Since the problem doesn't appear to be inherent in the brush geometry (maybe a bad export to .map format was causing it?), I think I'll stick with the test cases I have now -- I really appreciate the offer though. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
i had this clips or no clips in strange places problem happen about 3 times in different areas. Usually it was fixed by rearanging the shape of the clips and remove any overlaping clip brushes
<!--QuoteBegin--A_W!seM4n_0nc3_Sa!d+May 28 2003, 05:12 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (A_W!seM4n_0nc3_Sa!d @ May 28 2003, 05:12 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Ok, i ran into another one of those odd limits, this time it's the MAX_SWITCHED_LIGHTS limit, i dunno if it's possible to increase it, but if you can, BIG Thanks ahead of time <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> IIRC, MAX_SWITCHED_LIGHTS is actually the count of all map entities minus the unnamed lights in the map, and can't exceed 1024 by default -- I'm not sure if I can raise that without causing more serious problems, since the total number of entities is capped in-game and going over it will cause a server crash. If you need to keep under the limit, removing any entity that isn't an unnamed light should help if I remember the actual purpose of the limit correctly.
<!--QuoteBegin--[watch.me.die]+May 31 2003, 04:59 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> ([watch.me.die] @ May 31 2003, 04:59 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey, just an idea, would it be possible to fix the vis problems with large entities?
- i.e. them being able to be seen everywhere on the map.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I don't know how much I can do with this, since the entity vis code doesn't appear to depend on any cache in the bsp; unlike the VIS table for the worldspawn, there isn't any permanent information for entity vis. I suppose I could look at the Quake code to see how the unmodified engine handles entity vis and brainstorm, but I think the amount of effort involved is going to make this a low priority for the time being.
Cagey, i need to talk to you soon. Im still dealing with this allocblock full issue. From what i can tell its from either having over 4000 brushes, too many func_illusionary brushes or something similar to this
please find me soon. Ill be on gamesnet irc #clan-cis or #nsmapping
UPDATE Ive narrowed it down to this: If I texture a few more brushes I get the allocblock:full error (been confirmed on another PC) If I null a few brushes I dont get the error
This leads me to believe there is a cap on the viewable textured faces in the map. I would like to solve this without deleting a bunch of area. Ive worked on this map for 6 months now it would be a real shame to hack parts away.
For all you Batch Compiler users out there, a specification file for BC supporting OptPlns can be found: <a href='http://countermap.counter-strike.net/Nemesis/index.php?p=4' target='_blank'>http://countermap.counter-strike.net/Nemes...s/index.php?p=4</a>
Ithink i found a bug in optplns.exe Wen I cver a "trigger_hurt" (wich does 100000 damage per second) with the null texture and use optplns on it, the trigger hurt does not hurt anymore.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
will we see any updates on this tools in the future or not? i would to see new features. And could someone make a list with all the new introduced arguments and features? i think they are not in the readme(are they?)
I guess it's time for a state of the tools post <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
The list of features that the "p series" of tools has added to the 1.7 build with each release will be at the bottom of this point, along with a listing of known issues.
I haven't stopped Half-Life tool development, but with the exception of trying to remove some bugs in the CSG and BSP code I doubt that I'll be spending more time working with the current HL tool codebase. I am currently writing a faster and more memory efficient version of the CSG and BSP process from scratch (no firm release date, sorry) that will replace the p series of HL tools once it's out of beta. Unlike the hacks I've thrown together to date (such as opt_plns), the new tools will be released with full documentation and an actual installer once they have been tested. Once I am at a point where I need beta testers, I will probably make a post to this thread asking for them. I am going to keep this a solo project for the time being because I intend to also make it a part of my portfolio while I job hunt.
The bad news about this process is that I won't be adding new features to Merl's toolset (I will still fix bugs if I can get solid test cases with enough counterexamples to narrow down the behavior). The good news is that I have optimizations in mind for the new tools that would be extremely cumbersome to write using the existing codebase; since I'm starting from a blank slate, I'll be able to lay out the inner workings of the code in a manner better suited to future improvements. I firmly believe that the ground I've lost in performing the rewrite of the tools will be easily made up by the time saved when I work on really getting down to the nuts and bolts of optimizing BSP output. I hope to have a debugged, improved replacement toolset out by the end of the Summer (no promises).
If you would like the source code to the 1.7p10 build, talk to me privately about it (PM or <a href='mailto:webmaster@xp-cagey.com'>email</a>). I haven't heard from Merl about merging the clip code improvements with the main development branch in well over 4 months, so I'm more than willing to pass the torch on to other programmers and forget about my original goal of maintaining a single public source code offering.
If you would like to suggest feature additions for the new tools, please email them to me -- I'm collecting suggestions now so that I can design the tools to accommodate them later. I will be setting up a forum at my <a href='http://xp-cagey.com' target='_blank'>website</a> for tool discussion in the near future.
<b>"p series" features by release</b> (the file 1.7p11 readme.txt expands on this information): 1.7p - raised limit on MAX_MAP_PLANES to 64K 1.7p2 - raised limit on lightdata to 6MB 1.7p3 - introduced new clipping code, see this thread for syntax and details 1.7p4 - bugfixes, added -cliptype normalized 1.7p5 - bugfixes, raised limit on MAX_MAP_BRUSHES to 32K, released p series compatible ripents.exe, added "zhlt_noclip" and "zhlt_invisible" keys to solid entity definitions, added -nullfile <filename> switch to command line, introduced optimized geometry routines to speed up HLRAD. 1.7p6 - bugfix (CSG) 1.7p7 - bugfix (RAD) 1.7p8 - workaround (RAD), added temporary "-oldmath" switch 1.7p9 - bugfix (RAD), removed temporary "-oldmath" switch, added support for older hullfile format used by HL SDK 2.2 1.7p10 - bugfix (RAD) 1.7p11 - raised limit on lightdata to 8MB, added -lightdata <#> command line variable to add arbitrary lightdata amounts to a map
<b>opt_plns.exe features by release</b> (the file opt_plns_readme.txt expands on this information): 1.0 - first release 1.1 - improved algorithm 1.2 - bugfixes 1.3 - bugfixes, added "-nopause" command line switch 1.4 - added "-logfile <filename>" command line switch, added support for unlimited tex,light,and vis data, added more forgiving filename parse
If you have questions about the usage of any feature, email me for guidance.
<b>Known issues</b>: Using the <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>first cliptype bugfix</a> (present in "precise" and "simple") aggravates a bug in CSG processing that slices large sections of level geometry that shouldn't be cut. I've confirmed through a brute force test of generated brush shapes that the ExpandBrush routine is guaranteed to always create a brush that completely envelopes the volume of the brush it operates on, which has led me to conclude that there is a problem down the line that is causing the "holes" that people are seeing in their finished levels' clip hulls. This problem may or may not be related to the source of "leaf saw" errors which are only possible if either the final BSP geometry or the portals derived from it aren't valid; any errors in the final geometry or portals would point to mistakes or bad assumptions in the CSG or BSP routines that combine the brushes into a single face list and then form the BSP tree.
P.S. - I <i>will</i> be updating the Mapping Guidelines after NS 2.0 is released.
-lightdata <#> is now a variable like -texdata <#>; use it to raise the amount of light data allocated for your map if you get a MAX_MAP_LIGHTDATA error. This is a new error report for an old problem--the compiler used to die without any reason given if it ran out of lightdata space. The default lightdata is now 8MB; it is 4MB in Merl's build.
I've added position information to the "too many lightstyles on a face (?,?,?)" error -- the question marks are now the actual position where the error is happening. Only the first error of this type is reported by default because there can be thousands of them generated in a single compile. If you really want to see all of the places where this error is occuring, use the -verbose switch on HLRAD.
Cagey, it appears that p11 has a bug in hlrad. I used this newest version of hlrad to compile, and it gave me strange lighting. It's like it's fullbright, but not...kind of hard to explain. There's a few blotches of colored light in the general area of where they should be, but they are definitely malformed. I then compiled my map with p10, and it had none of these errors. Here's an example (I have more if you need them):
Room compiled with p11: <img src='http://kage.ottergoose.net/ns_blitz_test0001.jpg' border='0' alt='user posted image'> Room compiled with p10: <img src='http://kage.ottergoose.net/ns_blitz_test0010.jpg' border='0' alt='user posted image'>
These pictures are not gamma corrected, because the first one would be a flashbang if it were.
This isn't an absolutely urgent problem, because I am not using any of the new features present in p11 (yet), but I think you should definitely look into this.
<!--QuoteBegin--Kage+Aug 22 2003, 07:55 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Kage @ Aug 22 2003, 07:55 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> This isn't an absolutely urgent problem, because I am not using any of the new features present in p11 (yet), but I think you should definitely look into this. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Rolling back the download to p10 -- thanks for the heads up...
I doubt you're doing much, if anything, with these tools anymore, but I have one minor feature request for your new toolchain, if you can accomplish this, if it even is worth doing at all for that matter.
Allow one set of brushes to be used for the clipping hull, and another set to be used for the visible model. Basically zhlt_noclip on one entity, and full null texturing on another linked-to entity, which uses the second entity for defining the clipping hull of the first one.
Quick example: Assume you have a pillar with a huge chomp taken out of it, as if by claws or teeth. A simple and clean CSG Subtract, if done right. But, you don't want players to be able to wiggle into that nitch, and possibly get stuck, etc, etc, so you want to have a seperate clip-hull func_wall textured in NULL. But, the original pillar is another func_wall for BSP effeciency. Seems a waste, two func_wall entities in the same place, while one entity could do the same thing as both of them.
Why not use CLIP? Simple, CLIP-textured brushes disable the skulks wall-climb last I heard. =-.-=
<!--QuoteBegin--WolfWings+Aug 28 2003, 01:53 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Aug 28 2003, 01:53 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I doubt you're doing much, if anything, with these tools anymore, but I have one minor feature request for your new toolchain, if you can accomplish this, if it even is worth doing at all for that matter.
Allow one set of brushes to be used for the clipping hull, and another set to be used for the visible model. Basically zhlt_noclip on one entity, and full null texturing on another linked-to entity, which uses the second entity for defining the clipping hull of the first one.
Quick example: Assume you have a pillar with a huge chomp taken out of it, as if by claws or teeth. A simple and clean CSG Subtract, if done right. But, you don't want players to be able to wiggle into that nitch, and possibly get stuck, etc, etc, so you want to have a seperate clip-hull func_wall textured in NULL. But, the original pillar is another func_wall for BSP effeciency. Seems a waste, two func_wall entities in the same place, while one entity could do the same thing as both of them.
Why not use CLIP? Simple, CLIP-textured brushes disable the skulks wall-climb last I heard. =-.-= <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I've been thinking about how to accomplish that with the new tools, and I'm not sure if it's possible--I would need to be able to create a hybrid vis hull that included the planar cuts / physical definitions from the clip_hull model without those faces; if I just use the clip brush information in the clip hulls, that's no different from what CLIP texturing does now...
Heh... I just got an idea on how this might work--set aside an alternate content type (SOLID_INVIS) for brushes with a new texture that would be an alternate of CLIP, process normally through CSG, remove the faces like null in BSP, treat SOLID_INVIS like EMPTY content for VIS and RAD, then set the content type to SOLID in a post-processing step so that skulk physics works OK. The drawback would be interaction with hitscan weapons and other items that use hull 0 - they would treat the new brushes as solid areas, too. You'd lose the ability to have marked surfaces for items like bulletholes or sprays in areas that were encased in this brush type. You'd also be looking at an increase in the number of nodes, leaves, and planes for the main hull.
Complex but possible -- in the new tools, the behavior of any texture in any stage will be set through a properties interface, so that people could potentially build their own effects like this.
Okay, as of late I've been getting a very interesting set of lines in my log-file for my map-compiles testing Nancy segments...
SDF::4
As in, hundreds if not thousands of lines of JUST that, in the BuildFaceLights pass. What gives? It seems to light just fine, but this seems like an error, or possibly a debugging message still in p10?
<!--QuoteBegin--WolfWings+Sep 3 2003, 01:46 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Sep 3 2003, 01:46 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Okay, as of late I've been getting a very interesting set of lines in my log-file for my map-compiles testing Nancy segments...
SDF::4
As in, hundreds if not thousands of lines of JUST that, in the BuildFaceLights pass. What gives? It seems to light just fine, but this seems like an error, or possibly a debugging message still in p10?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> It's a debug message that's been left in from Merl's 1.7 build... it's tough to reach, requiring the following conditions:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> for (i = 0; i < max_nudge; i++) { // Make sure we are "in the world"(Not the zero leaf) if (leaf_mid) { SetSurfFromST(l, surf, us, ut); leaf_surf = HuntForWorld(surf, face_delta, p, DEFAULT_HUNT_SIZE, DEFAULT_HUNT_SCALE, DEFAULT_HUNT_OFFSET);
if (leaf_surf) { if (TestLine(surface_midpoint, surf) == CONTENTS_EMPTY) { if (lightmode & eModelLightmodeConcave) { #ifdef HLRAD_HULLU vec3_t transparency = { 1.0, 1.0, 1.0 }; if (TestSegmentAgainstOpaqueList(surface_midpoint, surf, transparency)) #else if (TestSegmentAgainstOpaqueList(surface_midpoint, surf)) #endif { Log("SDF::4\n"); <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'll make sure it's removed from p11 -- since it's apparently for debugging it should have been a developer message rather than a log message anyway.
If you're curious about some of those conditions:
TestSegmentAgainstOpaqueList is true when a light is blocked by an opaque object face.
eModelLightmodeConcave corresponds to bit 3, or zhlt_lightflags values 4-7 integer.
Ah, it's from the semi-extensive lightflags-6 pipework I turned into a func_illusionary in the rebuilt Subspace Interface Array hive in the WiP Nancy... gotcha. :-)
As for WHY I did that... I built seperate and far simpler clipping brushes as a func_wall for them, along with the fact it cleaned up the BSP cuts noticably, so a Skulk can skitter along the pipes without falling off now. As for why type-6? Concave corners, which had the 'black seams' bug with just type-2.
Comments
He meant having the field actually do something once it's added to the fgd, which requires a change in the code that reads it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I actually added support for cliptype in info_compile_parameters when I added cliptype to the tools back in p3, but I haven't tested it. I also updated it when I added the normalized cliptype to p5. If you've tried adding the key-value pair directly from the command line, it won't process because I made the field a dropdown in the VHE objectproperties dialog, which IIRC requires integer values.
Here's the fgd addition (stick inside of info_compile_parameters):
cliptype(choices) : "Clip Hull Type" : 4 =
[
0 : "Smallest"
1 : "Normalized"
2: "Simple"
3 : "Precise"
4 : "Legacy"
]
I'll start publishing this information in future releases so you won't have to be psychic to know how I implmeneted things. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
On a slightly different note, it would probably simplify things if the info_compile_parameters entity wan't in future NS fgds; I believe that VHE allows multiple fgds to be defined for a game type now, and it would be easier to maintain the tool entities in a separate document since they reflect a different branch of development.
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=33462' target='_blank'>http://www.unknownworlds.com/forums/in...=ST&f=4&t=33462</a>
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=33462' target='_blank'>http://www.unknownworlds.com/forums/in...=ST&f=4&t=33462</a><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Allocblock errors can be pretty nasty to track down since you don't have a lot of information to go on -- there's some information on what they are and how to find them here: <a href='http://www.slackiller.com/tommy14/errors.htm#allocblock' target='_blank'>http://www.slackiller.com/tommy14/errors.h....htm#allocblock</a>
As that page notes, it could be related to your leaf saw into leaf error during compile...
I usually tell people to bookmark that page -- tommy14 has collected a huge amount of helpful information on compile problems into a single well-organized source.
<a href='http://koti.mbnet.fi/bugi2/kuvia/clip.jpg' target='_blank'>Picture</a>
Area between those red lines acts like noclip, but the whole wall is one brush, and it isn't an entity.
Can you send me a cut-down copy of that map (preferably just that room if the bug is still present) for testing? I have another 2 test cases for this, but haven't been able to pin anything down. Are there any unusually thin brushes or unusually shaped brushes within 1024 units of that wall?
At this point, I've narrowed down the problem in the other maps to code that decides which way a bevel edge should face -- I currently take a dot product between the average normal of the two faces that require the bevel edge and the edge itself and flip the bevel if the result indicates they are over 90 degrees apart; this should always work in theory, but it's apparently not working fully in practice. When a bevel in one brush is backward, it has the potential to not only break the brush its in, but actually remove clipping information from other brushes during the phase that uses CSG on brush faces to create the hull if the resulting overall shape is illegal (e.g. the resulting brush has an inward facing normal).
I'm looking at alternative methods of determining the direction to face the bevel -- taking the dot product with a vector pointing to the centroid of the brush is promising. I am still working out what might be going on with the current solution since it should be working properly; I don't believe the borderline case of a 90 degree difference between a bevel and the average of the faces it cuts is possible on a convex polyhedron, but don't have a mathematical proof for that conjecture.
My original solution to the bevel facing problem was to simply point the vector in the same octant (quadrant in 3d instead of 2d) as the average normal of the two faces, but this was proven to be inadequate when the angle between the face normals was large. Although the current solution is more robust, there is evidently still a border case. I'll be sure to update when I finally nail this problem.
As it currently stands, each bug report appears to be due to a brush that is somehow violating the geometric assumptions I'm currently making (convex and all edges border faces that are less than 180 degrees apart... but that should be every case the code sees since brushes with 0 thickness aren't allowed by the compiler, right?). Tracking down the brush that is the source of the actual problem using the big block method has been a slow process--the location of the clipping hole is not necessarily the location of the problem brush, which has made it tougher to debug.
EDIT:spelling
EDIT2: a little more about the method used to determine bevel facing: if two vectors in 3d space have a dot product of 0, they are perpendicular. If the dot product is positive, they are less than 90 degrees apart; otherwise they are more than 90 degrees apart.
Assuming that two faces have normals less than 180 degrees apart, it stands to reason that the vector bisecting the angle between them should be less than 90 degrees from each. If the bevel face normal is also less than 90 degrees from the mean of the normal vector (substituted for the bisection of the angle), it ought to be facing the correct direction (i.e. although it might be over 90 degrees from one face normal, that wouldn't be true for both).
Thought: perhaps I need to take a more formal approach to bisecting the angle between the normals instead of taking the mean of the vectors?
I assume you use 32-bit floats for performance reasons, right? Then, isn't it possible that these errors occure due to roundings? Some trigonometric functions after another might give you a 0,001 instead of 0 somewhere <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
I do not really think this is the case, but you should probably make a testrun with 64-bit floats to go sure? (Hope there is not too much asm code in the tools... *looksatthesources*)
Since the problem doesn't appear to be inherent in the brush geometry (maybe a bad export to .map format was causing it?), I think I'll stick with the test cases I have now -- I really appreciate the offer though. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
- i.e. them being able to be seen everywhere on the map.
IIRC, MAX_SWITCHED_LIGHTS is actually the count of all map entities minus the unnamed lights in the map, and can't exceed 1024 by default -- I'm not sure if I can raise that without causing more serious problems, since the total number of entities is capped in-game and going over it will cause a server crash. If you need to keep under the limit, removing any entity that isn't an unnamed light should help if I remember the actual purpose of the limit correctly.
<!--QuoteBegin--[watch.me.die]+May 31 2003, 04:59 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> ([watch.me.die] @ May 31 2003, 04:59 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey, just an idea, would it be possible to fix the vis problems with large entities?
- i.e. them being able to be seen everywhere on the map.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I don't know how much I can do with this, since the entity vis code doesn't appear to depend on any cache in the bsp; unlike the VIS table for the worldspawn, there isn't any permanent information for entity vis. I suppose I could look at the Quake code to see how the unmodified engine handles entity vis and brainstorm, but I think the amount of effort involved is going to make this a low priority for the time being.
please find me soon. Ill be on gamesnet irc #clan-cis or #nsmapping
UPDATE
Ive narrowed it down to this:
If I texture a few more brushes I get the allocblock:full error (been confirmed on another PC)
If I null a few brushes I dont get the error
This leads me to believe there is a cap on the viewable textured faces in the map. I would like to solve this without deleting a bunch of area. Ive worked on this map for 6 months now it would be a real shame to hack parts away.
<a href='http://countermap.counter-strike.net/Nemesis/index.php?p=4' target='_blank'>http://countermap.counter-strike.net/Nemes...s/index.php?p=4</a>
Wen I cver a "trigger_hurt" (wich does 100000 damage per second) with the null texture and use optplns on it, the trigger hurt does not hurt anymore.
And could someone make a list with all the new introduced arguments and features? i think they are not in the readme(are they?)
The list of features that the "p series" of tools has added to the 1.7 build with each release will be at the bottom of this point, along with a listing of known issues.
I haven't stopped Half-Life tool development, but with the exception of trying to remove some bugs in the CSG and BSP code I doubt that I'll be spending more time working with the current HL tool codebase. I am currently writing a faster and more memory efficient version of the CSG and BSP process from scratch (no firm release date, sorry) that will replace the p series of HL tools once it's out of beta. Unlike the hacks I've thrown together to date (such as opt_plns), the new tools will be released with full documentation and an actual installer once they have been tested. Once I am at a point where I need beta testers, I will probably make a post to this thread asking for them. I am going to keep this a solo project for the time being because I intend to also make it a part of my portfolio while I job hunt.
The bad news about this process is that I won't be adding new features to Merl's toolset (I will still fix bugs if I can get solid test cases with enough counterexamples to narrow down the behavior). The good news is that I have optimizations in mind for the new tools that would be extremely cumbersome to write using the existing codebase; since I'm starting from a blank slate, I'll be able to lay out the inner workings of the code in a manner better suited to future improvements. I firmly believe that the ground I've lost in performing the rewrite of the tools will be easily made up by the time saved when I work on really getting down to the nuts and bolts of optimizing BSP output. I hope to have a debugged, improved replacement toolset out by the end of the Summer (no promises).
If you would like the source code to the 1.7p10 build, talk to me privately about it (PM or <a href='mailto:webmaster@xp-cagey.com'>email</a>). I haven't heard from Merl about merging the clip code improvements with the main development branch in well over 4 months, so I'm more than willing to pass the torch on to other programmers and forget about my original goal of maintaining a single public source code offering.
If you would like to suggest feature additions for the new tools, please email them to me -- I'm collecting suggestions now so that I can design the tools to accommodate them later. I will be setting up a forum at my <a href='http://xp-cagey.com' target='_blank'>website</a> for tool discussion in the near future.
<b>"p series" features by release</b> (the file 1.7p11 readme.txt expands on this information):
1.7p - raised limit on MAX_MAP_PLANES to 64K
1.7p2 - raised limit on lightdata to 6MB
1.7p3 - introduced new clipping code, see this thread for syntax and details
1.7p4 - bugfixes, added -cliptype normalized
1.7p5 - bugfixes, raised limit on MAX_MAP_BRUSHES to 32K, released p series compatible ripents.exe, added "zhlt_noclip" and "zhlt_invisible" keys to solid entity definitions, added -nullfile <filename> switch to command line, introduced optimized geometry routines to speed up HLRAD.
1.7p6 - bugfix (CSG)
1.7p7 - bugfix (RAD)
1.7p8 - workaround (RAD), added temporary "-oldmath" switch
1.7p9 - bugfix (RAD), removed temporary "-oldmath" switch, added support for older hullfile format used by HL SDK 2.2
1.7p10 - bugfix (RAD)
1.7p11 - raised limit on lightdata to 8MB, added -lightdata <#> command line variable to add arbitrary lightdata amounts to a map
<b>opt_plns.exe features by release</b> (the file opt_plns_readme.txt expands on this information):
1.0 - first release
1.1 - improved algorithm
1.2 - bugfixes
1.3 - bugfixes, added "-nopause" command line switch
1.4 - added "-logfile <filename>" command line switch, added support for unlimited tex,light,and vis data, added more forgiving filename parse
If you have questions about the usage of any feature, email me for guidance.
<b>Known issues</b>:
Using the <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>first cliptype bugfix</a> (present in "precise" and "simple") aggravates a bug in CSG processing that slices large sections of level geometry that shouldn't be cut. I've confirmed through a brute force test of generated brush shapes that the ExpandBrush routine is guaranteed to always create a brush that completely envelopes the volume of the brush it operates on, which has led me to conclude that there is a problem down the line that is causing the "holes" that people are seeing in their finished levels' clip hulls. This problem may or may not be related to the source of "leaf saw" errors which are only possible if either the final BSP geometry or the portals derived from it aren't valid; any errors in the final geometry or portals would point to mistakes or bad assumptions in the CSG or BSP routines that combine the brushes into a single face list and then form the BSP tree.
P.S. - I <i>will</i> be updating the Mapping Guidelines after NS 2.0 is released.
-lightdata <#> is now a variable like -texdata <#>; use it to raise the amount of light data allocated for your map if you get a MAX_MAP_LIGHTDATA error. This is a new error report for an old problem--the compiler used to die without any reason given if it ran out of lightdata space. The default lightdata is now 8MB; it is 4MB in Merl's build.
I've added position information to the "too many lightstyles on a face (?,?,?)" error -- the question marks are now the actual position where the error is happening. Only the first error of this type is reported by default because there can be thousands of them generated in a single compile. If you really want to see all of the places where this error is occuring, use the -verbose switch on HLRAD.
Room compiled with p11:
<img src='http://kage.ottergoose.net/ns_blitz_test0001.jpg' border='0' alt='user posted image'>
Room compiled with p10:
<img src='http://kage.ottergoose.net/ns_blitz_test0010.jpg' border='0' alt='user posted image'>
These pictures are not gamma corrected, because the first one would be a flashbang if it were.
This isn't an absolutely urgent problem, because I am not using any of the new features present in p11 (yet), but I think you should definitely look into this.
Rolling back the download to p10 -- thanks for the heads up...
Allow one set of brushes to be used for the clipping hull, and another set to be used for the visible model. Basically zhlt_noclip on one entity, and full null texturing on another linked-to entity, which uses the second entity for defining the clipping hull of the first one.
Quick example: Assume you have a pillar with a huge chomp taken out of it, as if by claws or teeth. A simple and clean CSG Subtract, if done right. But, you don't want players to be able to wiggle into that nitch, and possibly get stuck, etc, etc, so you want to have a seperate clip-hull func_wall textured in NULL. But, the original pillar is another func_wall for BSP effeciency. Seems a waste, two func_wall entities in the same place, while one entity could do the same thing as both of them.
Why not use CLIP? Simple, CLIP-textured brushes disable the skulks wall-climb last I heard. =-.-=
Allow one set of brushes to be used for the clipping hull, and another set to be used for the visible model. Basically zhlt_noclip on one entity, and full null texturing on another linked-to entity, which uses the second entity for defining the clipping hull of the first one.
Quick example: Assume you have a pillar with a huge chomp taken out of it, as if by claws or teeth. A simple and clean CSG Subtract, if done right. But, you don't want players to be able to wiggle into that nitch, and possibly get stuck, etc, etc, so you want to have a seperate clip-hull func_wall textured in NULL. But, the original pillar is another func_wall for BSP effeciency. Seems a waste, two func_wall entities in the same place, while one entity could do the same thing as both of them.
Why not use CLIP? Simple, CLIP-textured brushes disable the skulks wall-climb last I heard. =-.-= <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I've been thinking about how to accomplish that with the new tools, and I'm not sure if it's possible--I would need to be able to create a hybrid vis hull that included the planar cuts / physical definitions from the clip_hull model without those faces; if I just use the clip brush information in the clip hulls, that's no different from what CLIP texturing does now...
Heh... I just got an idea on how this might work--set aside an alternate content type (SOLID_INVIS) for brushes with a new texture that would be an alternate of CLIP, process normally through CSG, remove the faces like null in BSP, treat SOLID_INVIS like EMPTY content for VIS and RAD, then set the content type to SOLID in a post-processing step so that skulk physics works OK. The drawback would be interaction with hitscan weapons and other items that use hull 0 - they would treat the new brushes as solid areas, too. You'd lose the ability to have marked surfaces for items like bulletholes or sprays in areas that were encased in this brush type. You'd also be looking at an increase in the number of nodes, leaves, and planes for the main hull.
Complex but possible -- in the new tools, the behavior of any texture in any stage will be set through a properties interface, so that people could potentially build their own effects like this.
SDF::4
As in, hundreds if not thousands of lines of JUST that, in the BuildFaceLights pass. What gives? It seems to light just fine, but this seems like an error, or possibly a debugging message still in p10?
SDF::4
As in, hundreds if not thousands of lines of JUST that, in the BuildFaceLights pass. What gives? It seems to light just fine, but this seems like an error, or possibly a debugging message still in p10?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's a debug message that's been left in from Merl's 1.7 build... it's tough to reach, requiring the following conditions:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
for (i = 0; i < max_nudge; i++)
{
// Make sure we are "in the world"(Not the zero leaf)
if (leaf_mid)
{
SetSurfFromST(l, surf, us, ut);
leaf_surf =
HuntForWorld(surf, face_delta, p, DEFAULT_HUNT_SIZE, DEFAULT_HUNT_SCALE,
DEFAULT_HUNT_OFFSET);
if (leaf_surf)
{
if (TestLine(surface_midpoint, surf) == CONTENTS_EMPTY)
{
if (lightmode & eModelLightmodeConcave)
{
#ifdef HLRAD_HULLU
vec3_t transparency = { 1.0, 1.0, 1.0 };
if (TestSegmentAgainstOpaqueList(surface_midpoint, surf, transparency))
#else
if (TestSegmentAgainstOpaqueList(surface_midpoint, surf))
#endif
{
Log("SDF::4\n");
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'll make sure it's removed from p11 -- since it's apparently for debugging it should have been a developer message rather than a log message anyway.
If you're curious about some of those conditions:
TestSegmentAgainstOpaqueList is true when a light is blocked by an opaque object face.
eModelLightmodeConcave corresponds to bit 3, or zhlt_lightflags values 4-7 integer.
As for WHY I did that... I built seperate and far simpler clipping brushes as a func_wall for them, along with the fact it cleaned up the BSP cuts noticably, so a Skulk can skitter along the pipes without falling off now. As for why type-6? Concave corners, which had the 'black seams' bug with just type-2.
this is what i get when i try to compile
** Executing...
** Command: Change Directory
** Parameters: C:\SIERRA\Half-Life
** Executing...
** Command: Copy File
** Parameters: "C:\SIERRA\Half-Life\Ns\maps\ns_proxima6.map" "C:\SIERRA\Half-Life\ns\maps\ns_proxima6.map"
** Executing...
** Command: C:\DOCUME~1\NEWMIC~1\MYDOCU~1\MAPPIN~1\CAGEYS~1\hlcsg.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\ns_proxima6"
** Executing...
** Command: C:\DOCUME~1\NEWMIC~1\MYDOCU~1\MAPPIN~1\CAGEYS~1\hlbsp.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\ns_proxima6"
** Executing...
** Command: C:\DOCUME~1\NEWMIC~1\MYDOCU~1\MAPPIN~1\CAGEYS~1\hlvis.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\ns_proxima6"
** Executing...
** Command: C:\DOCUME~1\NEWMIC~1\MYDOCU~1\MAPPIN~1\CAGEYS~1\hlrad.exe
** Parameters: "C:\SIERRA\Half-Life\ns\maps\ns_proxima6"
it doesn't actually seem to bother itself about compiling... any ideas whats wrong?