Talk:Geometric

The "Clean" version is, if not 'clean' whatever that means, *MUCH* more readable. I really wouldn't consider using any code that required a legend to decipher the function and variable names, but I can read and therefore more confidently use the more verbose version. Thanks!

It is more of a personal preference really. For me it really jacks up the appearance and readability of my scripts to have lengthy technical user defined functions, for which I already trust to work and only need to know its purpose, input and output. The only case I would see for people to want such extensive names are newcomers to this library or LSL itself. I do agree it was a bit overkill, but the incredible length for something we as humans see as objectively simple wish to see it comparitively minimal on having the least impact on readability. The primary issue I see is the vital documentation I just wasn't able to give immediately, just felt the more technical people might be happy with being able to start bouncing ideas and make cool products. I am working on some documentation though. --Nexii Malthus 03:16, 20 May 2008 (PDT)

Pictures?

Perhaps we could use some visualization for the functions? I am not sure how to make a consistent looking set of images and diagrams to explain each set of functions of what they do. I will try to see what I can do but any help is appreciated. --Nexii Malthus 16:21, 7 June 2008 (PDT)

Sounds like a good idea. What type of help do you want? -- Strife Onizuka 18:59, 7 June 2008 (PDT)

Well basically an idea regarding what kind of reference graphs could come into place, like the style to fit with the simplicity and give a good idea of what it is about. --Nexii Malthus 12:44, 15 June 2008 (PDT)

Clean up

I cleaned up the page a bit, sorry about removing the entire scripts together with yours Strife, but I saved all of it on my own user sub page though for future reference. I would like to offer different LSL scripts and information at hand on each function window but I could never clutter the page like that at the cost of easy readability for browsing each function quickly. Essentially what I am trying to grab onto is collapsible sections, I believe there is a way to infuse normal HTML/javascript into the wikipage using templates? This is basically going into advanced wiki editting which your quite good at Strife, this could be used for instance in other pages of the wiki as well. I am just trying to expand as much as technically possible.

I don't mind, there was a typo in it anyway that I hadn't gotten around to fixing and I wanted to update it for the new long function names and variables (but hadn't gotten to it). -- Strife Onizuka 00:38, 16 June 2008 (PDT)

Typo in Box and Ray, Intersection Distance, or is it correct?

I added line breaks to this function to make it more readable so it doesn't scroll off the right side of the screen. While checking it against the old code to make sure I changed nothing, I noticed an odd asymmetry between the code blocks:

<lsl>

   if(llFabs(dB.x) > 0.000001){
       D = (-eB.x - oB.x ) / dB.x;

( . . . )

       D = ( eB.x - oB.x ) / dB.x;

( . . . )

   if(llFabs(dB.y) > 0.000001){
       D = (-eB.y - oB.y ) / dB.y;

( . . . )

       D = ( eB.y - oB.y ) / dB.y;

( . . . )

   if(llFabs(dB.z) > 0.000001){
       D = (-eB.z - oB.z ) / dB.z;

( . . . )

       D = (-eB.z - oB.z ) / dB.z;

( . . . ) </lsl>

The two "-eB.z" do not look correct in that third part. I assume it should look like the first and second parts: <lsl> if(llFabs(dB.z) > 0.000001){

       D = (-eB.z - oB.z ) / dB.z;

( . . . )

       D = ( eB.z - oB.z ) / dB.z;

( . . . )</lsl>

I don't understand the math at all, so maybe it is correct. I am pointing this out just in case it is a typo. Scalar Tardis 15:21, 15 June 2008 (PDT)

That is a bug, good find. -- Strife Onizuka 00:42, 16 June 2008 (PDT)

Polygon and Point, Intersection Boolean - does it work?

Hi - I'm attempting to make an equivalent of HTML image maps in LSL, using the llDetectedST function.

I tried the Polygon function to check if the touch is inside a polygon, and i get some odd results. For example -

gCPXx([<10,10, 0>, <10,50, 0>, <50,50, 0>, <50,10, 0>], <4,3,0>);

Returns true - even though the coordinates are obviously outside the square.

Am I missing something? --Hippyjim Starbrook 08:30, 22 March 2009 (PDT)

I'll work on it. -- Strife ^{(talk|contribs)} 06:38, 23 March 2009 (UTC)

Line and Line, intersection point

vector gLLxX( vector A, vector B, vector C, vector D ) ...

The function returns <1.00000, 0.00000, 0.00000> for the lines <0, 0, 0> to <10, 0, 0> and <1, 10, 0>, <1, 20, 0>.

These lines do not intersect, which you can easily see when you draw them on paper.

Ratany Resident

You have confused lines with line segments. If you draw two lines, one that goes through the points <0,0,0> and <10,0,0> and another that goes through the points <1,10,0> and <1,20,0>, you will find they both intersect at <1,0,0>.

You can either use Geometric#Line_and_Line_Segments.2C_nearest_line_segment (gLSLSnLS, check to make sure the two points are the same) or you could use the following: -- Strife ^{(talk|contribs)} 21:13, 28 December 2013 (PST)

<lsl>vector gLSLSxX( vector A, vector B, vector C, vector D ){

   vector b = B-A; vector d = D-C;
   float dotperp = b.x*d.y - b.y*d.x;
   if (dotperp == 0) return <-1,-1,-1>;
   vector c = C-A;
   float t = (c.x*d.y - c.y*d.x) / dotperp;
   if (t < 0 || t > 1) return <-1,-1,-1>;
   return <A.x + t*b.x, A.y + t*b.y, 0>;}</lsl>

Caveat and suboptimal implementation of gLXdZ

gLXdZ only works if D, the direction vector, is normalized. That caveat is not mentioned in the function description. Also, it uses llSqrt(k*k) instead of llVecMag(k), which looks suboptimal. --Pedro Oval 15:37, 8 March 2014 (PST)