as i remember it xp-cagey had somthing in his artical about the clipping hull that they would be the same as a round if you textured the back side of every ting with bevel and used normalized clipping hull.
edit: about all that world noclip stuff, just make a func_illusunary and texture it and the surounding world with null that way you will get a wall that dosent clip and dosent add wpolys, as this is already where a hole would be it shouldnt be bad for vis and only add 1 ent, it would be to mutch work for fare to little.
onthing that might be interesting tho would be addin a vis flag to ent's
Seeing as the compile tools have been through a number of authors over time, and styles of coding are often different in different places, perhaps people who are working out how the tools function in order to work on them could, when they come across something non-obvious that requires working out what exactly is going on, could write a short comment in that code explaining it.
Would make maintaining them, especially as a group of people, so much easier <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> The problem is let's say you edit it for NS.
Then anybody who wants to use the compile tools for Counter-Strike, The Specialists, DoD, and other major mods, will have problems. The clipping fields will be specialized for NS.
It is best to let the map creator decide exactly what clips and what doesnt.
There are two ways to go about it.... first, you can create a map with the clipping hull you want, and save that file. Then you can compile it again with all the lighting, but load the clipping hulls from the first compile.
Or you can code the tools to automatically allow you to decide which brushes have clipping or not. This could be anything from a worldspawn key/value with comma-delimiting for every brush that does not possess clipping, or by making it load a text file, etc.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Personally I don't see what harm more correctly behaving player hulls could do in any MOD. For axis parallell geometry they would behave exactly the same, for strange geometry they would behave better.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->as i remember it xp-cagey had somthing in his artical about the clipping hull that they would be the same as a round if you textured the back side of every ting with bevel and used normalized clipping hull.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I'd certainly be interested to read it, xp-cagey.com isn't working right now for some reason, was that where you found it?
yep, i tryed to open it my self to qute it but it was down then as weal <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad-fix.gif' border='0' style='vertical-align:middle' alt='sad-fix.gif' /><!--endemo-->
And making world brushes with the NULL texture add to vismatrix calculations.
And, I presume, BEVEL would also add to vismatrix calculations.
HINT brushes split world brushes, as well. Which can actually cause an increase in r_speeds because the hint brushes used can end up splitting world brushes in many places.
Just thought I'd mention that I've updated the docs site with the suggestions from FragBait0 and AJenbo in the other NS thread.
I've also added a link to amckern's site (duh!) <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
But null world brushes should not be included in vismatrix calculations. No matter how much light shines on a null brush, <i>it cannot reflect light</i>.
Thus, there should be no calculations for it. No matter what, it does not reflect any light. If the calculations make it reflect light, this is very bad.
I know you're not supposed to double post, but I think this is fairly important.
Null and Bevel faces are being included in vismatrix construction, this can be proven by creating a map entirely out of one texture texture and adding some lights, then compiling. Note the compile time. Now change the texture to NULL. Compile.
A NULL texture should not:
<i>Reflect</i> light. That is, no radiosity or bounce calculations should be performed on a NULL/BEVEL face.
<i>Absorb/emit</i> light. There is absolutely no reason for any calculation to be performed to figure out how much light it is emitting. It is a null texture and will not be rendered, period.
<i>Block</i> light. It's not rendered, it shouldn't be made to appear as though it is visible, and it should not cast a shadow. An invisible object simply does not cast a shadow.
I propose new textures:
INVISIBLE - Null texture that has absolutely no visual mathematical operations performed on it. Transparent to visual calculations (visibility checks go right through it.)
ETHEREAL - Bevel texture with no visual operations performed on it. Also transparent to all vis calculations.
SHADOW - Bevel texture that is only capable of blocking light, not bouncing.
I'd also like it if it were possible to create regions of void, in which the hall of mirrors effect would be present. Is this possible? Ergo: I have a wall that I want to act like a motion blur fixture, so I want to put a region of void into it. Is it possible?
My RAD doesn't crash, it merely creates shadows in the map that shouldn't exist and make the map ugly. In other words, it may as well crash, cause I can't use it in its current state.
I wasn't asking that, I know I must an older HLRAD, thanks. I was asking what's causing it (if you know what might be causing it, just to get an idea on when we're going to have a proper HLRAD).
Note: For all purposes, when I refer to light and visual calculations I mean the lighting, not the seperation of the map into leafnodes where leafnode <i>x</i> can see leafnode <i>y</i>, but not leafnode <i>z</i>. What I am talking about are the visibility calculations which take up a large amount of memory and a very large matrix.
Not only do they block light, they are also part of the vismatrix. Theres absolutely <b>no reason</b> a NULL or BEVEL face should be counted, or tested for.
Hence I proposed new textures to keep the functionality of the old ones, without the need for revising all the old articles on null brushes.
INVISIBLE - Like NULL except it doesn't have any visual calculations performed on it. It is completely invisible to all light. But it still has clipping.
ETHEREAL - Like BEVEL except it doesn't have any visual calculations performed on it. Essentially this is the ultimate 'Nothingness' texture. This texture does not clip, does not cause shadows. It is not used in vismatrix calculations, and it is completely invisible ingame.
SHADOW - Like ETHEREAL except it <i>does block</i> light. But it <i>does not reflect light, and no light calculations performed on it.</i>
Let's take an example map by a smart mapper... he's used null and bevel textures everywhere possible, possibly resulting in only one quarter of his brush faces being visible. But these faces are still used in calculations. So let's say he has 16,000 patches, but 75% (12,000) are NULL or BEVEL.
So the vismatrix is: Patches * Patches / 16 Bytes... Well, at 16,000 he has a vismatrix of 16,000,000B (15.25mB). But if you take away all the patches used in the null and bevel textures, you only have 4000*4000 / 16 Bytes, or 1,000,000B (977kB). Can you <i>guess</i> why this would be an important feature?
i dont know what is causeing it, i'm looking at 1.7 code, and trying to see whats changed, it might also be the new code that is used for entity shadows, and came into effect in p14, i was sent this file as a stand alone bit of code, so i can also see if this is causeing the crash, and also the entity shadows
EDIT: unless you are including faces that touch - thus not being visible...why? Are those faces not stripped out by BSP? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Yes I'm making the layout to one right now. And so far, just counting the basic un-detailed floors and walls, about three fourths of my textures are NULL. And when I add details such as steps, etc, even more textures will be null.
amckern: yeah that's what I meant, so you can compare the two code sets (using diff or something), try adding changes one at a time, find which one causes the problem, and (hopefully) fix it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo--> Would seem to be easier than digging through the whole code.
As a matter of fact, it's not a bad idea to ask for code for all (or the last 5 or so) of the releases, to help get a better idea what changed over time. Perhaps better to ask XP-Cagey to stick them all up on his site, if he doesn't mind.
To all the people asking for feature additions - wait till ZHLT 3 final is released. Get it working first! It's bad programming practice to add more functionality while something is broken.
Nothing to stop anyone from writing code to do these various things, just let it wait till 3.0.1. The key thing right now is to get a working, stable release.
though there is nothing stoping people from downloading the source, and trying to help me out, or by working on there own code for the tools, link is in 1st post
Yep, I think it's a good idea to get as many people looking at the code as possible to try and fix any problems for the 3.0 release.
Would look a bit silly if we made lots of publicity about them and they were broken <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
What's the best way to contact XP-Cagey, email or on the <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21248' target='_blank'>old ZHLT thread</a>?
Well anyways, you guys seem to be having fun there... Doing the things you do. Keep up the work, for the love of god get RAD working faster.
I had to wait 30 minutes to compile a simple map a few versions ago. Keep it up though.
While my Computer science skills come close to 2D conventional skills XD (omg) this is just a suggestion, why not make some tool thing or another, see how close one object is to a larger surface, and depending on the closeness, it would automatically NULL That texture to help you on your compile time. But that might just boost compile time even more, and make us slow people angrier.
I'll shut up and go back to my corner of self neglect now
Comments
edit: about all that world noclip stuff, just make a func_illusunary and texture it and the surounding world with null that way you will get a wall that dosent clip and dosent add wpolys, as this is already where a hole would be it shouldnt be bad for vis and only add 1 ent, it would be to mutch work for fare to little.
onthing that might be interesting tho would be addin a vis flag to ent's
Seeing as the compile tools have been through a number of authors over time, and styles of coding are often different in different places, perhaps people who are working out how the tools function in order to work on them could, when they come across something non-obvious that requires working out what exactly is going on, could write a short comment in that code explaining it.
Would make maintaining them, especially as a group of people, so much easier <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Reve
Then anybody who wants to use the compile tools for Counter-Strike, The Specialists, DoD, and other major mods, will have problems. The clipping fields will be specialized for NS.
It is best to let the map creator decide exactly what clips and what doesnt.
There are two ways to go about it.... first, you can create a map with the clipping hull you want, and save that file. Then you can compile it again with all the lighting, but load the clipping hulls from the first compile.
Or you can code the tools to automatically allow you to decide which brushes have clipping or not. This could be anything from a worldspawn key/value with comma-delimiting for every brush that does not possess clipping, or by making it load a text file, etc.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Personally I don't see what harm more correctly behaving player hulls could do in any MOD. For axis parallell geometry they would behave exactly the same, for strange geometry they would behave better.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->as i remember it xp-cagey had somthing in his artical about the clipping hull that they would be the same as a round if you textured the back side of every ting with bevel and used normalized clipping hull.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I'd certainly be interested to read it, xp-cagey.com isn't working right now for some reason, was that where you found it?
I really do hate making all these pyramidal structures.
And, I presume, BEVEL would also add to vismatrix calculations.
HINT brushes split world brushes, as well. Which can actually cause an increase in r_speeds because the hint brushes used can end up splitting world brushes in many places.
every ting should afect the vis matrix (except beveled or nulle ents) as it either blockes visabilaty or is visable.
plains sounds as a good idea
I've also added a link to amckern's site (duh!) <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
Reve
Thus, there should be no calculations for it. No matter what, it does not reflect any light. If the calculations make it reflect light, this is very bad.
Null and Bevel faces are being included in vismatrix construction, this can be proven by creating a map entirely out of one texture texture and adding some lights, then compiling. Note the compile time. Now change the texture to NULL. Compile.
A NULL texture should not:
<i>Reflect</i> light. That is, no radiosity or bounce calculations should be performed on a NULL/BEVEL face.
<i>Absorb/emit</i> light. There is absolutely no reason for any calculation to be performed to figure out how much light it is emitting. It is a null texture and will not be rendered, period.
<i>Block</i> light. It's not rendered, it shouldn't be made to appear as though it is visible, and it should not cast a shadow. An invisible object simply does not cast a shadow.
I propose new textures:
INVISIBLE - Null texture that has absolutely no visual mathematical operations performed on it. Transparent to visual calculations (visibility checks go right through it.)
ETHEREAL - Bevel texture with no visual operations performed on it. Also transparent to all vis calculations.
SHADOW - Bevel texture that is only capable of blocking light, not bouncing.
I'd also like it if it were possible to create regions of void, in which the hall of mirrors effect would be present. Is this possible? Ergo: I have a wall that I want to act like a motion blur fixture, so I want to put a region of void into it. Is it possible?
the link is in the 1st post
amckern
I wasn't asking that, I know I must an older HLRAD, thanks. I was asking what's causing it (if you know what might be causing it, just to get an idea on when we're going to have a proper HLRAD).
Not only do they block light, they are also part of the vismatrix. Theres absolutely <b>no reason</b> a NULL or BEVEL face should be counted, or tested for.
Hence I proposed new textures to keep the functionality of the old ones, without the need for revising all the old articles on null brushes.
INVISIBLE - Like NULL except it doesn't have any visual calculations performed on it. It is completely invisible to all light. But it still has clipping.
ETHEREAL - Like BEVEL except it doesn't have any visual calculations performed on it. Essentially this is the ultimate 'Nothingness' texture. This texture does not clip, does not cause shadows. It is not used in vismatrix calculations, and it is completely invisible ingame.
SHADOW - Like ETHEREAL except it <i>does block</i> light. But it <i>does not reflect light, and no light calculations performed on it.</i>
Let's take an example map by a smart mapper... he's used null and bevel textures everywhere possible, possibly resulting in only one quarter of his brush faces being visible. But these faces are still used in calculations. So let's say he has 16,000 patches, but 75% (12,000) are NULL or BEVEL.
So the vismatrix is: Patches * Patches / 16 Bytes... Well, at 16,000 he has a vismatrix of 16,000,000B (15.25mB). But if you take away all the patches used in the null and bevel textures, you only have 4000*4000 / 16 Bytes, or 1,000,000B (977kB). Can you <i>guess</i> why this would be an important feature?
Have you actually ever made a map?
EDIT: unless you are including faces that touch - thus not being visible...why?
Are those faces not stripped out by BSP?
[edit - Yay, the thred is 3 pages long!
amckern
If not, why not try asking XP-Cagey for it?
i might ask cagey for the older code, if he still has it
Have you actually ever made a map?
EDIT: unless you are including faces that touch - thus not being visible...why?
Are those faces not stripped out by BSP? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Yes I'm making the layout to one right now. And so far, just counting the basic un-detailed floors and walls, about three fourths of my textures are NULL. And when I add details such as steps, etc, even more textures will be null.
As a matter of fact, it's not a bad idea to ask for code for all (or the last 5 or so) of the releases, to help get a better idea what changed over time. Perhaps better to ask XP-Cagey to stick them all up on his site, if he doesn't mind.
Nothing to stop anyone from writing code to do these various things, just let it wait till 3.0.1. The key thing right now is to get a working, stable release.
Would look a bit silly if we made lots of publicity about them and they were broken <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile-fix.gif' border='0' style='vertical-align:middle' alt='smile-fix.gif' /><!--endemo-->
What's the best way to contact XP-Cagey, email or on the <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21248' target='_blank'>old ZHLT thread</a>?
Am I fitting in yet?
Damn.
Well anyways, you guys seem to be having fun there... Doing the things you do.
Keep up the work, for the love of god get RAD working faster.
I had to wait 30 minutes to compile a simple map a few versions ago.
Keep it up though.
While my Computer science skills come close to 2D conventional skills XD (omg)
this is just a suggestion, why not make some tool thing or another, see how close one object is to a larger surface, and depending on the closeness, it would automatically NULL That texture to help you on your compile time.
But that might just boost compile time even more, and make us slow people angrier.
I'll shut up and go back to my corner of self neglect now