Custom geometry scripts

[Jim Fenbert]

I've been experimenting with the new custom components in OpenVSP 2.9.4 and I'm very impressed.
I followed along with JR's presentation for modifying the Cone.as and have read through the documentation on the wiki.

It didn't take long before I realized I was going to want the functionality of the XSec tab, the Airfoil tab and possibly the Skinning tab.
It would be great if they could be exposed to scripting as objects that could be used without recreating them in each script.
For now I tried to recreate the XSec tab and had a few issues.

I noticed not all of the GDEV devices are available. Will they all be available eventually?

The BoxGroup.as example has this comment:
//==== UpdateGui Is Called Every Time The Gui is Updated - Use It To Deactivate/Show/Hide Gui ====//

The example shows how to deactivate a device but I could not figure out how to hide one. Is hiding GDEVs possible?

Also the code to deactivate a slider in the example: UpdateGui( WidthSlider, GetParm( geom_id,  "",  "Design" ) );
generates an error:                                               GetParm::Can't Find Parm ZXMVXWZOXR:Design:
however I've found that if I use:                               UpdateGui( WidthSlider, "" );
I don't get an error and it seems to work.
I originally thought that UpdateGui was replacing the PARM associated with the GDEV but this doesn't seem to be the case since I don't have to reconnect the original PARM when I reactivate it.
Exactly how does the UpdateGui method work? It doesn't seem to be documented in the wiki.

Is it possible to change the size of the tab?
When I add a lot of GDEVs to the tab it doesn't expand to fit them and if I try to drag the window larger the sliders just get taller.

I found this comment in the CustomGeom.cpp
//==== Set XSec Location - Not Using Parms To Avoid Exposing Dependant Vars ====//
void CustomXSec::SetLoc( const vec3d & loc )

since CustomXSecs don't use PARMs for position and rotation it would be nice to have methods to get the values (for script XSec tab).

I noticed that AngelScript can implement #include directives and OpenVSP's implementation supports it.
I found this very useful. I've used include files for my utility methods and also for the XSec tab to make it reusable.
However after I did this I realized it doesn't work with how the scripts are imbedded in the VSP files.
One work around would be to use the include files in development and then just combine them for production scripts.
Any chance OpenVsp could somehow combine the includes in the VSP file?

[J.R. Gloudemans]

It didn't take long before I realized I was going to want the functionality of the XSec tab, the Airfoil tab and possibly the Skinning tab.
It would be great if they could be exposed to scripting as objects that could be used without recreating them in each script.
For now I tried to recreate the XSec tab and had a few issues.  

I noticed not all of the GDEV devices are available. Will they all be available eventually?

 

More GUI devices and precanned GUI is on the list but depends on time and priorities.  Its taking us longer to get out a stable v3 release than anticipated.

The BoxGroup.as example has this comment:
//==== UpdateGui Is Called Every Time The Gui is Updated - Use It To Deactivate/Show/Hide Gui ====//

The example shows how to deactivate a device but I could not figure out how to hide one. Is hiding GDEVs possible?

Not yet, but on the same list as above :-)

Also the code to deactivate a slider in the example: UpdateGui( WidthSlider, GetParm( geom_id,  "",  "Design" ) );
generates an error:                                               GetParm::Can't Find Parm ZXMVXWZOXR:Design:
however I've found that if I use:                               UpdateGui( WidthSlider, "" );
I don't get an error and it seems to work.
I originally thought that UpdateGui was replacing the PARM associated with the GDEV but this doesn't seem to be the case since I don't have to reconnect the original PARM when I reactivate it.
Exactly how does the UpdateGui method work? It doesn't seem to be documented in the wiki.

Sorry this is a bit tricky.  UpdateGui does associate the Parm with the GUI.  But when you provide a parm association in the AddGUI then UpdateGui automatically gets called with the current custom component.  I did this because it reduced a lot of code you have to write.  I will put a better description in the wiki. 

HeightSlider = AddGui( GDEV_SLIDER_ADJ_RANGE_INPUT, "Height", "Height", "Design"  ); 

The last two parameters "Height" and "Design" setup the automatic call to UpdateGUI.

Is it possible to change the size of the tab?
When I add a lot of GDEVs to the tab it doesn't expand to fit them and if I try to drag the window larger the sliders just get taller.

No, but I will add this functionality and maybe scrolling tabs.

I found this comment in the CustomGeom.cpp
//==== Set XSec Location - Not Using Parms To Avoid Exposing Dependant Vars ====//
void CustomXSec::SetLoc( const vec3d & loc )

since CustomXSecs don't use PARMs for position and rotation it would be nice to have methods to get the values (for script XSec tab).

OK will add. 

I noticed that AngelScript can implement #include directives and OpenVSP's implementation supports it.
I found this very useful. I've used include files for my utility methods and also for the XSec tab to make it reusable.
However after I did this I realized it doesn't work with how the scripts are imbedded in the VSP files.
One work around would be to use the include files in development and then just combine them for production scripts.
Any chance OpenVsp could somehow combine the includes in the VSP file?

I will take a look and implement if its easy. 

[Jim Fenbert]

Thanks J.R.

I was going to complain about the tangent strengths being capped at 10 by defaul,t but I see that was changed in 2.9.5.
That took me a while to track down. My geometry would look fine until I scaled it up.

I'm trying to use the GDEV_COUNTER but I can't get it to go higher than 10. If my IntParm is initially 12 it will show as 12 in the counter but if I press either of the arrow buttons it changes to 10.

Also I'm a little confused by the left/right tangent angles/strengths on the first XSec. It works as expected on the middle XSecs with 2 sides and on the last XSec which only has a left side.
But on the first XSec which would seem to only have a right side, I have to set the XSEC_LEFT_SIDE values.
This seems to be true on the skinning tab for stack and fuselage components so maybe it is "as designed"?

Thanks for you help.

[Rob McDonald]

On Wed, Oct 8, 2014 at 5:44 AM, Jim Fenbert <jfen...@gmail.com> wrote:
> I was going to complain about the tangent strengths being capped at 10 by
> defaul,t but I see that was changed in 2.9.5.
> That took me a while to track down. My geometry would look fine until I
> scaled it up.

If only you would debug our problems a little sooner (: That one took
me a while to figure out.

We have an internal scale value for Stack and Fuselage -- that way the
tangent strengths are non-dimensional. There wasn't a consistent way
to do that for custom components, so the scale is 1.0. The cap of 10
was fine when you assume non-dimensional values, but falls apart for
values in model scale.

> I'm trying to use the GDEV_COUNTER but I can't get it to go higher than 10.
> If my IntParm is initially 12 it will show as 12 in the counter but if I
> press either of the arrow buttons it changes to 10.

The counter has min/max values of 10 hard-coded (GroupLayout.cpp:807).
It looks like the only place we use it internally is to set the
'priority' for mass properties calculations. The limits can obviously
be made configurable, but you might be better off using a
GDEV_INDEX_SELECTOR, that is what we use to control the active XSec
for Fuse/Stack/Wing type Geoms.

> Also I'm a little confused by the left/right tangent angles/strengths on the
> first XSec. It works as expected on the middle XSecs with 2 sides and on the
> last XSec which only has a left side.
> But on the first XSec which would seem to only have a right side, I have to
> set the XSEC_LEFT_SIDE values.
> This seems to be true on the skinning tab for stack and fuselage components
> so maybe it is "as designed"?

It is 'as designed'. Perhaps I was being overly clever (XSec.cpp:936).

I did this to simplify all the GUI code. In the skinning GUI, when
you set two parameters to be equal with the '=' box, then both values
are controlled from the 'left' set of controls. For this and other
reasons, the 'left' set of controls ends up being 'dominant'.

The first cross section was going to need some special case code
somewhere. Using the Left value instead of the Right value for the
first section allowed me to get away with a lot less special case code
- and all in one place.

Rob

[Jim Fenbert]

On Wednesday, October 8, 2014 11:48:55 AM UTC-4, Rob McDonald wrote:

>> I was going to complain about the tangent strengths being capped at 10 by
>> defaul,t but I see that was changed in 2.9.5.
>> That took me a while to track down. My geometry would look fine until I
>> scaled it up.
>
>If only you would debug our problems a little sooner (:  That one took
>me a while to figure out.
>
>We have an internal scale value for Stack and Fuselage -- that way the
>tangent strengths are non-dimensional.  There wasn't a consistent way
>to do that for custom components, so the scale is 1.0.  The cap of 10
>was fine when you assume non-dimensional values, but falls apart for
>values in model scale.

I figured it must be non-dimensional. I only figured it out when I noticed that my slider had no affect after it reached  a value of 10.

>> I'm trying to use the GDEV_COUNTER but I can't get it to go higher than 10.
>> If my IntParm is initially 12 it will show as 12 in the counter but if I
>> press either of the arrow buttons it changes to 10.
>
>The counter has min/max values of 10 hard-coded (GroupLayout.cpp:807).
>It looks like the only place we use it internally is to set the
>'priority' for mass properties calculations.  The limits can obviously
>be made configurable, but you might be better off using a
>GDEV_INDEX_SELECTOR, that is what we use to control the active XSec
>for Fuse/Stack/Wing type Geoms.

GDEV_INDEX_SELECTOR is the one I was looking for but I guess I copied the code from the BoxGroup demo.
I even have it on my list of GDEVS that work in custom components. My bad.

>> Also I'm a little confused by the left/right tangent angles/strengths on the
>> first XSec. It works as expected on the middle XSecs with 2 sides and on the
>> last XSec which only has a left side.
>> But on the first XSec which would seem to only have a right side, I have to
>> set the XSEC_LEFT_SIDE values.
>> This seems to be true on the skinning tab for stack and fuselage components
>> so maybe it is "as designed"?
>
>It is 'as designed'.  Perhaps I was being overly clever (XSec.cpp:936).
>
>I did this to simplify all the GUI code.  In the skinning GUI, when
>you set two parameters to be equal with the '=' box, then both values
>are controlled from the 'left' set of controls.  For this and other
>reasons, the 'left' set of controls ends up being 'dominant'.
>
>The first cross section was going to need some special case code
>somewhere.  Using the Left value instead of the Right value for the
>first section allowed me to get away with a lot less special case code
>- and all in one place.

I suspected that's how the GUI worked but didn't realize that it would be cleanest to implement it in the XSec code.
Just a heads up, I showed Andy and he didn't like it. ;)

Cool, I have fairly functional XSec, and Airfoil Tabs.
I have to gray out unused GDEVs for the different XS_types so I can only fit fuselage or airfoil controls on one tab.
The only issue left is that I need to have a toggle button to control the 2 modes.
If I'm changing which XSec is current I copy XSec values to my parms.
If I'm changing the what the XSec looks like I apply my parms to the XSec.
Is there a way to tell which GDEV device triggered the update, so I can just tell if the GDEV_INDEX_SELECTOR has changed?
If not can the id be passed to the UpdateGui and UpdateSurf methods?

Thanks,
Jim

[Rob McDonald]

> I suspected that's how the GUI worked but didn't realize that it would be
> cleanest to implement it in the XSec code.
> Just a heads up, I showed Andy and he didn't like it. ;)

The GUI is one place it would show up -- but that isn't too bad.

The really nasty part is all the code that watches the 'C0,C1,C2'
settings and the '=' settings and uses the L value to override the R
value. To make the R value work for the first XSec, I'd need to make
all that code aware of the current XSec number and handle the special
cases throughout.

I'll look at it, but I strongly suspect that there will be higher
priority things to work on. There are lots of opportunities for bike
shedding and I generally try to avoid them.

> Cool, I have fairly functional XSec, and Airfoil Tabs.
> I have to gray out unused GDEVs for the different XS_types so I can only fit
> fuselage or airfoil controls on one tab.
> The only issue left is that I need to have a toggle button to control the 2
> modes.
> If I'm changing which XSec is current I copy XSec values to my parms.
> If I'm changing the what the XSec looks like I apply my parms to the XSec.
> Is there a way to tell which GDEV device triggered the update, so I can just
> tell if the GDEV_INDEX_SELECTOR has changed?
> If not can the id be passed to the UpdateGui and UpdateSurf methods?

I'll let J.R. answer this question -- all the custom component and
corresponding GUI stuff is his genius.

I'm curious, what are you trying to accomplish? Custom geom is pretty
powerful, but we've also made it a lot easier to build VSP and to make
new geometry types inside VSP. We would like for Custom Geom to be
flexible enough that you 'could' recreate the built-in components
using it, but that probably isn't quite true today.

In general, I think the custom components will really shine when
someone has a class of shape that they want to describe with a handful
of parameters. The TransportFuse example is a great example of this
-- using a very small number of parameters, it can represent a large
class of shapes of interest.

If you're making a custom component so flexible that you are
recreating the XSec/Airfoil type tabs, my gut says that it may make
more sense to do that in C++ inside VSP.

Of course, I can also see that you might want to set out to accomplish
something really ambitious with Custom Component -- it is a great way
to understand its limits and to teach yourself how to work with it.
J.R. and I will gladly take that feedback as a way to improve custom
components and remove limitations.

None of these things are hard lines. J.R. implemented the Duct type
as an example. I've thought about extending that idea to handle any
XSec type (or possibly TBLR XSecs). I'm not sure whether that should
be done as a custom component or a native C++ one.

2.9.5 has the bleeding edge Advanced Parameter Linking added. I
suspect that you and Erik will have a heyday with it. If you haven't
checked it out yet, give it a shot. No documentation or examples have
been prepared yet (:

Rob

[Jim Fenbert]

On Wednesday, October 8, 2014 5:37:56 PM UTC-4, Rob McDonald wrote:

>I'm curious, what are you trying to accomplish?  Custom geom is pretty
>powerful, but we've also made it a lot easier to build VSP and to make
>new geometry types inside VSP.  We would like for Custom Geom to be
>flexible enough that you 'could' recreate the built-in components
>using it, but that probably isn't quite true today.
>
>In general, I think the custom components will really shine when
>someone has a class of shape that they want to describe with a handful
>of parameters.  The TransportFuse example is a great example of this
>-- using a very small number of parameters, it can represent a large
>class of shapes of interest.
>
>If you're making a custom component so flexible that you are
>recreating the XSec/Airfoil type tabs, my gut says that it may make
>more sense to do that in C++ inside VSP.
>
>Of course, I can also see that you might want to set out to accomplish
>something really ambitious with Custom Component -- it is a great way
>to understand its limits and to teach yourself how to work with it.
>J.R. and I will gladly take that feedback as a way to improve custom
>components and remove limitations.

That is exactly it! This is probably my favorite new feature of v3.0
and I happen to have some time to play with it now.
I'm trying to figure out as much as possible. I hadn't even thought about
making new components in C++, but I think this experimentation will be
useful for that too. I'm just trying to wring it out and throw out ideas
for future enhancements.

I've been leaning towards tutorial type examples more than useful geometry.
I've also been trying to simplify developing new scripts.
I'm attaching 2 mods to the TransportFuse as examples. The first TransportFuse2
shows how easy it is to add an XSec tab to do non-circular fuselages
(probably not useful geometry).
The second TransportFuse3 includes my debugging tab which isn't complete
but has been a useful tool for me in learning this.

>None of these things are hard lines.  J.R. implemented the Duct type
>as an example.  I've thought about extending that idea to handle any
>XSec type (or possibly TBLR XSecs).  I'm not sure whether that should
>be done as a custom component or a native C++ one.

I'm still cleaning up my Airfoil.inc file but I'd like to try this.
If nothing else another example is always good, and having a custom component
script as a prototype should be valuable tool if is makes sense to move it to C++.

>2.9.5 has the bleeding edge Advanced Parameter Linking added.  I
>suspect that you and Erik will have a heyday with it.  If you haven't
>checked it out yet, give it a shot.  No documentation or examples have
>been prepared yet (:

I think I'm just about up the learning curve on Custom Components so I'll
have to check that out next.

Thanks,
Jim

[Rob McDonald]

On Thu, Oct 9, 2014 at 9:21 AM, Jim Fenbert <jfen...@gmail.com> wrote:
>>Of course, I can also see that you might want to set out to accomplish
>>something really ambitious with Custom Component -- it is a great way
>>to understand its limits and to teach yourself how to work with it.
>>J.R. and I will gladly take that feedback as a way to improve custom
>>components and remove limitations.
>
> That is exactly it! This is probably my favorite new feature of v3.0
> and I happen to have some time to play with it now.
> I'm trying to figure out as much as possible. I hadn't even thought about
> making new components in C++, but I think this experimentation will be
> useful for that too. I'm just trying to wring it out and throw out ideas
> for future enhancements.

That is really awesome! Glad that you're as excited about this
feature as I am. I think it has the capability to be a really big
deal.

> I've been leaning towards tutorial type examples more than useful geometry.
> I've also been trying to simplify developing new scripts.
> I'm attaching 2 mods to the TransportFuse as examples. The first
> TransportFuse2
> shows how easy it is to add an XSec tab to do non-circular fuselages
> (probably not useful geometry).
> The second TransportFuse3 includes my debugging tab which isn't complete
> but has been a useful tool for me in learning this.

Send me an off-line email and let me know what email address you'd
like registered with the Wiki (: That is where I'm trying to send
most of these kinds of documentation efforts.

We will have special Custom Component support in the Hangar, but it
isn't ready yet -- and won't go on-line until 3.0.0 is released in any
case.

I checked out your TransportFuse 2 and 3 -- I actually like the mods a lot.

I'm on a Mac, so I had to switch the '\' to '/' in the #include
directives. I kinda think that Windows will work OK with '/',
otherwise, we'll have to figure something else out.

> I'm still cleaning up my Airfoil.inc file but I'd like to try this.
> If nothing else another example is always good, and having a custom
> component
> script as a prototype should be valuable tool if is makes sense to move it
> to C++.

Cool.

>>2.9.5 has the bleeding edge Advanced Parameter Linking added. I
>>suspect that you and Erik will have a heyday with it. If you haven't
>>checked it out yet, give it a shot. No documentation or examples have
>>been prepared yet (:
>
> I think I'm just about up the learning curve on Custom Components so I'll
> have to check that out next.

Great. Let us know how it goes.

Rob

[Jim Fenbert]

Hey I tried to use the XForm Scale slider on a custom component and it doesn't work.
It appears that the upper and lower limits are set to 1.0.
I tried to change the values and limits in my custom script but wasn't able to get it working.

Is it possible to use this with custom scripts?
Is there more setup required?

[Jim Fenbert]

If I create a Seat with the supplied Custom Script which has error checking I get no errors.
However, when I save the vsp3 file and reopen it I get several "Can't Find Parm" errors for the design parms.

I've notice this one my Custom Scripts too, sometimes I even get a "divide by zero" error as well.
It doesn't seem to be causing any problems, yet.

Does loading geometry from the vsp3 file not go through the same Init/Update steps as in creation?
Is there something I need to do in my scripts to avoid these errors?

Thanks
Jim

[Rob McDonald]

Jim,

The Scale functionality and the capability to change the center of
rotation aren't currently supported with custom geometry scripts.

Supporting them would require the script writer to implement an
additional routine for each (though we may be able to figure out a way
to have do-nothing defaults). At this point, we had not implemented
that capability trying to keep things simple, but Scale is probably
worth doing.

Rob

> --
> You received this message because you are subscribed to the Google Groups
> "OpenVSP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openvsp+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.