Jump to content

Marissa Farrell

Marionette Maven
  • Posts

    1,473
  • Joined

  • Last visited

Posts posted by Marissa Farrell

  1. What about using a Popup OIP control instead of a boolean? You could use the 'Planar Boolean' node in the Operations category as an example.

    Basically you'd want to have it set up with Rectangle as option 1 in your OIP control, and Circle as 2.

    Then all you would need to do in your code below is have your output equal to the value of your OIP control

    Kind of like this:

    @Marionette.NodeDefinition
    class Params(metaclass = Marionette.OrderedClass):
    this = Marionette.Node( "popup" ) 
    op = Marionette.OIPControl( 'shape', Marionette.WidgetType.Popup, 0, ['rectangle','circle'])
    out = Marionette.PortOut()
    
    def RunNode(self):	
    self.Params.out.value = self.Params.op.value
    

    (okay, so exactly like that...)

  2. Hey Alan,

    Try using the node that you would use for 2D polys. In most cases for the poly nodes, you can use them for either 2d or 3d.

    (There are some exceptions, but I think this one should work.)

  3. Hey Alan,

    Looks like the parameter you're missing is vertPart

    vs.BeginRoof(p1, p2, upslope, riseDistance, runDistance, miter, vertPart)

    which is labeled as

    "Dimension of vertical miter for double miter style."

    in the Developer Wiki.

  4. I don't have a complete answer, but if you look at this page on the Dev Wiki, Pat Stanford made some comments a while back on how to get an object to texture by class.

    SetTextureRef

    Hopefully this helps?

    EDIT:

    You may want to use vs.SetTextureRefN, but I don't know that the same "-1" method applies, as I haven't tried.

  5. Currently any nodes that accept an input don't show their OIP controls when wrapped.

    I'm working on narrowing down the best way to solve this, but it probably won't be fixed for 2016.

  6. Name will only accept one object, however, in some cases (depending on what your script does) you are able to connect more than one Name node to the input port of the next node in your network.

    This won't work in all cases, though, depending on if there is any list manipulation going on further in your network.

    What does your script do?

  7. It doesn't really matter in the end, but using the TupleMap is only advanced in the sense that if you were adding vectors or points (i.e. (0,1,2) + (1,2,3)) you'd be adding the independent elements (so the result would be (1,3,5))

    If you're only trying to accomplish basic math, it's much easier to just use the + - * / operators.

  8. DomC,

    The issue with including user content in default content is that I believe we would need explicit permission to ship with it.

    I'm not sure where we're headed with regards to that, but to my understanding, we should soon have a better way to organize on the forums, in the very least.

  9. Hi Alan,

    What you've written is acceptable.

    The only thing I've noticed is that you used this line twice:

    calc = self.Params.calc.value

    Every user/programmer will have their own style of coding, it's up to you to use whatever you like best.

    I think that your code is very easy to understand, so I don't think there's an issue with you writing this way.

    A few notes that don't REALLY matter:

    1) Although using "Marionette.TupleMap" makes sense in Marionette networks, I've found it better practice to use use the standard operators on the small scale. (+, -, *, /)

    2) Adding comments to your code will always assure that the user can follow what you're doing. I'm glad you used the comments to say which operation is being used for which option.

    3) In the Params class, maybe you'd like to add descriptions using .SetDescription to the a, b, and c ports - this will allow descriptions of each of those to appear in the "Description" dialog brought up by the button in the OIP. That is another great way to help a user understand what a node does or requires to work.

    I personally believe that the most important part of coding is creating code that an unexperienced user will be able to understand moderately easily. It's also very beneficial to comment code because you may return to a project from months or years ago and not remember what a certain part does off the top of your head, or you may not remember why you did it a certain way.

    Hope this helps!

  10. Thanks Alan!

    I've gotten into the habit of organizing the scripts in the default content nodes when I make changes to them. I'm glad you noticed :) It's a work in progress.

    I'm hoping to cover all of them at some point, but with hundreds of nodes, it may take me longer than I'd like.

  11. In my earlier investigations (November-ish?) I noticed that the OpenGL calls are outdated.

    I've already pushed it through in-house. Hopefully something can be resolved soon, as for now, I don't think a function exists that uses the actual OpenGL prefs that we have, I was told the current command on the dev wiki is only relevant for the older engine we used before we upgraded (years ago.. funny how some things slip by :) )

  12. The simplest way I can put it is that when Python was introduced to Vectorworks, we duplicated the existing Vectorscript calls into a Python module called vs.

    All of the vs.FUNCTIONNAME() calls are still Python, but they're directly related to the Vectorscript function library (which is Pascal based).

    You can think of this kind of like translating code to a different language, and in this case we need these functions because they're linked specifically to the back end of VW. Both Vectorscript and Python calls from the vs module will do the same thing.

    You can still do pretty much anything you could do with Python within Marionette, the vs calls are really only important for manipulating VW data and creating/editing objects. Any math or calculations or external data saving can be done with vanilla Python just as you would if you were using standalone Python.

    I'm hoping to find the time to show some examples, but I'm not sure when that will be.

    Please let me know if you need more clarification.

  13. So basically what happens when you use the "Divide Curve" node is that it creates one long list of all of the points on all of the curves that went into it.

    I modified that node to chunk them into lists.

    I also modified the node immediately after it, "Every Other", to not absorb the entire list and flatten it, so it, too, outputs the right values.

    I commented the lines in each of those nodes that I changed, there is only one line in each.

    This revision will take a little longer to calculate and finish, but it gives you what you want. I can say that we are working on improvements for future releases to use different methods when working with large data, so keep your eyes open for my post when we get to the point that we can put it out there!

    Let me know if you have any questions.

    ubbthreads.php?ubb=download&Number=15623&filename=BrickWork.JPG

  14. I think it's because when you do the "Every Other" on your output from "Divide Curve", sometimes the "Odd" value will be the beginning of the next line.

    Let me think of the best way to remedy this.

  15. I think I'm just still a little bit lost here.

    Can you provide a visual of what it's supposed to look like, since it sounds like what's in the image shared above is not what you're looking for exactly?

    What is the "right position"?

    I'm up for the challenge.

  16. Attached is a Marionette Object of a threaded bolt, still in progress.

    Current "NumThreads" must be >0 and <=10, or you will get a failure. This will be fixed (and later removed and replaced with overall length). Fractional values should work.

    There is much more ahead on this, but I figured sharing now and allowing the community to play with it/improve on it could be beneficial.

    I will update the variables as I go to follow standard dimensioning of threaded objects, I just haven't gotten around to the math in some areas (such as major diameter, etc.)

    It will also later include a head, since that's obviously not there ;)

    ubbthreads.php?ubb=download&Number=15563&filename=ThreadedBolt.JPG

  17. I feel like in most cases, users aren't permitted to see the programming behind PIOs, this allows the creator to keep the complexity of the object hidden from the user (so they can't reproduce it and share it with others who don't have it by default).

    I've found that taking an object and creating a few viewports (say top, front, and right views) and dimensioning them helps to establish the relationships between different pieces. Then you can take those dimensions and decide which ones you'd want the user to be able to change, and after that you can begin defining it on a script level, either by using Marionette or just a Python script.

    Also, many plug ins within VectorWorks have been written using the SDK rather than VectorScript/python, and some functions haven't been properly brought into the VectorScript API, which is also a limiting factor in some cases.

    We're working to identify functions that would be useful in the VectorScript API, that aren't already there, and hope to include them in the future.

    In any case, I hope to produce a video series in the near future on some practices for programming object creation in 3 dimensions/thinking in 3D space. My primary tool will likely be Marionette, but I think I may dive into some Python scripting as well.

  18. Alan,

    I believe you're aware of the Developer Wiki, which contains our VectorScript API and is often a good place to start looking for the functions you may need.

    Another way you could do this, if you have a Marionette network that you'd like to consolidate into a singular node, it's pretty easy to just grab the pieces of the code within the nodes that you'd need. I've gotten into the habit of first writing what I want using the standard Marionette node set, and then I dissect the nodes to find the code snippets required to consolidate it.

    There are still functions on the wiki that we haven't introduced to Marionette, though, but most functions have an example posted on how to use them on the wiki, which could also be of use.

    Also, since we use Python 3.3 as the coding basis of Marionette, it may also help to familiarize yourself with some standard Python practices. I've always found this to be a useful resource. You can likely skip to Chapter 3, since within Vectorworks it's not really necessary to use an interpreter. (If you'd like to use one for a better understanding of Python overall, that's also fine.)

    I actually had never even touched Python before using Marionette, so Marionette has essentially been my Python teacher :)

    Please let me know if you get stuck or need guidance!

×
×
  • Create New...