Lscript Question

Here we go...
Code: 
//Globals for UI Helper function
var GRIDSIZE = 22;
var SKEW = floor(GRIDSIZE / 2);
var OFFSET = floor(SKEW / 2);

//Global UI Helper Function
gbox : w_x, w_y, w_h, w_w
{
      //All units are in grid coordinates
      //w_x = x coordinate, w_y = y coordinate
      //w_h = height, w_w = width
      //This UDF converts from grid coordinates to screen coordinates
	var retv[4];  //Return Values
	retv[1] = (w_x * GRIDSIZE) + OFFSET;
	retv[2] = (w_y * GRIDSIZE) + OFFSET;
	retv[3] = (w_h * GRIDSIZE);
	retv[4] = (w_w * GRIDSIZE);
	return(retv);
}

//Code Snippets...
var a[4]; //array to hold the return values from gbox()
//Sizing your requester panel...
//You only need Height and Width...
reqbegin("My Panel"); a = gbox(0,0,24,18);reqsize(a[3]+OFFSET,a[4]);

//A text box example
a = gbox(5,0,14,1); c1 = ctlstring("Item Name",itemname); ctlposition(c1,a[1],a[2],a[3],a[4]);

//A separator example
//Skew is used to offset the line to the middle of the box
a = gbox(0,1,24,1); s1 = ctlsep(a[1],a[3]); ctlposition(s1,a[1],a[2] + SKEW,a[3],a[4]);

gbox() makes things easier to move around and resize, though it doesn't make for very readable code. The function itself could use some tweaking; I could give it a "mode" setting, so it automatically adds offset and/or skew values for the main panel and separators, and maybe some variants, for centering things a little nicer.

This got the job done, though.
 
Another question:

While working on my Splines on Strips script, I had to write a bit of code that basically duplicated the "w" panel in modeler, for points -showing how many polygons each point was referenced by. Is there a native function that does this (like polycount() does for polygons)?
 
Question time... This has to do with 'publishing', aka releasing scripts to the public, especially work alike scripts.

Story : Sometime back in the LW 10 days, I wrote a handy little script for a friend called "Extend Spline", which does exactly what the name says... it adds a control point to the end of a lightwave spline, which you can use LW's tools on - it's really handy for styling hair guide curves. I did this shortly after I had purchased the Trueart True Hair tools, which includes a subset of the Easyspline tools... including Extend Spline (mainly both for my friend, and as a challenge for myself - A "Can this be done in lscript?" challenge).

A problem, possibly several, arise - I am planning on releasing an entire set of hair tools, written in lscript, for free. They're stable, reliable, a bit slow sometimes, but they do work, and work well. Unfortunately, they do some things that some of Truearts's plugins do, and I want to avoid what could be some very unpleasant business.

These tools include:
1) Make Hair (creates little stub hair curves bases on a polygonal selection, one to a polygon).
2) Extend Spline (mentioned above)
3) Select Spline Start/End Point
4) Select Spline Next CP/Prev CP
5) Smooth Spline
6) Trim Spline
7) Quad Strips to Splines (yes, I've got it working.)

As you can easily see, most duplicate functionality that exists in commercial plugins, and I don't want to be seen as someone who is taking business away from others in an already tight market...

Any suggestions or advice?
 
Kryslin said:
Question time... This has to do with 'publishing', aka releasing scripts to the public, especially work alike scripts.

Story : Sometime back in the LW 10 days, I wrote a handy little script for a friend called "Extend Spline", which does exactly what the name says... it adds a control point to the end of a lightwave spline, which you can use LW's tools on - it's really handy for styling hair guide curves. I did this shortly after I had purchased the Trueart True Hair tools, which includes a subset of the Easyspline tools... including Extend Spline (mainly both for my friend, and as a challenge for myself - A "Can this be done in lscript?" challenge).

A problem, possibly several, arise - I am planning on releasing an entire set of hair tools, written in lscript, for free. They're stable, reliable, a bit slow sometimes, but they do work, and work well. Unfortunately, they do some things that some of Truearts's plugins do, and I want to avoid what could be some very unpleasant business.

These tools include:
1) Make Hair (creates little stub hair curves bases on a polygonal selection, one to a polygon).
2) Extend Spline (mentioned above)
3) Select Spline Start/End Point
4) Select Spline Next CP/Prev CP
5) Smooth Spline
6) Trim Spline
7) Quad Strips to Splines (yes, I've got it working.)

As you can easily see, most duplicate functionality that exists in commercial plugins, and I don't want to be seen as someone who is taking business away from others in an already tight market...

Any suggestions or advice?
Click to expand...

Since your stuff is lscript and TrueArt's tools are actual C plugins, TrueArt's stuff will always be faster. So if the user wants better tools then they would go the commercial plug-in route. But if someone can get the functionality they want, free is always more popular than commercial.

I don't know if that helps clarify your situation. I'm sure you're coming with good intentions.
 
My hope is that the TA stuff does more than what my simple, basic stuff does; I do intend to put a note to that effect in the zip archive; "If you want more capable tools (that do more than the basics), go here..."
 
You could include text in any dialogs pointing to the commercial plugin suppliers, and make the point that their offerings WILL be faster (generally).
 
Next up...

This is less a lscript question, and more of a vector math question...
I've been playing around with writing a bias map generator that emulates what Sasquatch's combing panel does, to a certain degree...

Here are the results, so far...


In the picture on the left, there is a noticeable area that pokes straight up in the center, and one on the right hand side of the frame. This is a FiberFX issue, caused by an unforseen interaction between the bias map and gravity (gravity appears to be applied before the bias map is - when gravity is set to zero, issue goes away) that I will be reporting. The main problem I'm having is generating my combing vector; I make a vector from an effector point, to the vertex, then normalize it. Using the vertex normal, make a perpendicular vector, and add that to the surface normal. It actually works quite nicely, up until the combing vector has less of a slope than the vertex normal, causing the perpendicular vector to flip.

Any suggestions on how to keep that flip from happening? It's quite visible in the right hand frame. If it wasn't for that, this would be quite a handy little script.

I've included a code snippet, so my explanation above will make more sense...
Code: 
   //The vertex map's base name...
   mapname = "fur_bias";

   //The effector point, to brush away from...
   var away_s = <0.00, 1.806, 0.1561569>; 

   //In the future, this will be transparent;
   //effector point will be determined by surface, along
   //with any falloff needed.

   //halfvec is used for remapping purposes.
   var halfvec = <.5,.5,.5>;

   //Our vertex maps...
   mymap = VMap(VMRGB, mapname, 3); //Straight up bias map
   mymapalt = VMap(VMRGB, mapname+"_rm",3); // bias map remapped to 0...1 range

   vc = verts.count(); //verts[] is an array containing vertex IDs
   //Adds a perpendicular vector to the vertex normal,
   //based on a vector between the effector point and
   //the vertex being evaluated.
		
   for(i = 1; i<=vc; i++){
      vn = vnorms[i]; // Array containing vertex normals
      av = pointinfo(verts[i]) - away_s;  //Make a vector from the effector point to the vertex
      bv = normalize(av); // Normalize it
      pv = makeperp(bv,vn);  // Make a perpendicular vector pv = bv - (bv dot vn) * vn;  since ||bv|| = 1, ||bv||^2 = 1, division term not needed.
      nv = normalize(vn + pv );//Normalize it
      mymap.setValue(verts[i],normalize(nv));  //Set the map value to it.
      rmv = (nv * halfvec) + halfvec; //Remap the value to 0...1
      mymapalt.setValue(verts[i], rmv);  //set the alternate map value to that.
   }
 
Off the top of my head... it might be your use of dot in make perp. Dot gives you the angle between 2 vectors (or comparison rather as a 1 to -1 range)... But that function (sin) only occupies half the unit circle, so at some point you get the same value but from the flip side.

Try cross instead...

pv = cross3d(vec1,vec2);
 
I'll give it a try. Ooooh, that gives me an idea... Use Cross3D to get a vector perpendicular to both, then use it again to get the actual perpendicular vector I need...

using 2 dot products yields better results than taking the perpendicular of a projected vector, and reduces the problem area, but it still exists....
 
Kryslin said:
In lScript, is there any way to get the part name associated with a polygon?
Click to expand...

Dodgy said:
There's no way to retrieve parts in Lscript. You can assign them, but not retrieve them. You'll have to Parts to Surface and back to find those.
Click to expand...

Yes, you can.

Code: 
@script modeler
@warnings
@name "Part Name"

main
{
    selmode(DIRECT);
    selectedItems = polycount();

    if(selectedItems[1] == 0)
    {
        error("Nothing Selected");
    }

    editbegin();
        for(loop = 1; loop <= selectedItems[1]; loop++)
        {
            partName = polygons[loop].tag("PART");

            info("Part Name: ", partName);
        }
    editend();
}
 
Matt :

Coolness. You know, this needs to be added to the lscript docs (amongst a whole lot of other things...)

RH:

Here's the results of using the idea you gave me:


I also added a simple test, based on the dot product - if the dot3d(vn,bv) > .9, I have it check to see if the vertex + bn is greater than vertex + vn; If it is, I swap vn and bn before making the perpendicular vector using 2 cross products.

I might have to apply some smoothing to even things out, but things look good so far...
 
Kryslin said:
Matt :

Coolness. You know, this needs to be added to the lscript docs (amongst a whole lot of other things...)
Click to expand...
I'd like to think that would go without saying, assuming it's not there. EVEN IF IT IS THERE, it obviously needs to be made more findable.
 
Any estimate on how such an LScript documentation update would cost? EDIT: that is, cost to have done? Not to the users.

If Python were as fully implemented for LW/LWM as LScript is, I'd say put some LW3D bucks into Python documentation, cookbooks, LScript>>Python conversions, and examples. But it appears we still need LScript.

(By cookbooks, I mean modular Python routines that are like Legos for constructing other, more complex Python scripts.)
 
Last edited:
jeric_synergy said:
If Python were as fully implemented for LW/LWM as LScript is
Click to expand...

Python IS far more implemented than LScript. Python wraps the LightWave SDK, so what is available to the C SDK (which is more than LScript has) is available to Python. The only thing is that Python is harder to pick up than LScript, apart from the PRIS (Python Reduced Instruction Set) implementation, which is in Modeler only at present.
 
Python wraps the LightWave SDK, so what is available to the C SDK (which is more than LScript has) is available to Python.
Click to expand...

I don't think so in Python you will make 3rd party renderer, VPR previewing class, custom polygon, interactive tool, etc. handlers.
 
You must log in or register to reply here.
Back
Top