-
Posts
1,601 -
Joined
-
Last visited
Reputation
683 SpectacularPersonal Information
-
Occupation
Quality Assurance Solutions Engineer
-
Hobbies
snowboarding, macrame, beadwork, embroidery, Binding of Isaac, Marionette, arts & crafts, 3D Printing, reading, saxophone
-
Location
United States
Recent Profile Visitors
30,979 profile views
-
The Copy node uses HDuplicate. You'll need to use a Set Name after to name the new worksheet, otherwise it won't create a new resource. I'll make a note to try to handle that better. Also - the copy node is cool because if you don't wire the output of the copy node to something else, a copy won't get made. I'm not sure if that's beneficial in this case, but when I was looking it over, I saw that's how it's implemented.
-
How to embed user nodes in Marionette tool list
Marissa Farrell replied to BillW's topic in Marionette
Unfortunately, I don't think that's exposed to us in any meaningful way at this point. Part of the reasoning, I assume, is that you can have multiple WG libraries. I'll check to see if there are any workarounds (I've also been wanting WG library support) -
Determine grid of points in multiple polygons automatically
Marissa Farrell replied to chanjwcjj's topic in Marionette
To further speed things up, here's a network that removes the values from the original points list instead of having to cross reference the duplicates each time. Determine grid of points in multiple polygons_SAMPLE FILE_MFarrellV2.vwx -
Determine grid of points in multiple polygons automatically
Marissa Farrell replied to chanjwcjj's topic in Marionette
When a node is fed lists of different lengths, the default behavior is to match the shortest list with first elements of the longest list, and then it will repeat the remaining values against the last item in the shortest list. There are nodes that do not behave this way, but in your network, they do. You can use a Mix2 node set to Cross Reference to create 2 lists of equal lengths that create a match for each value, like you did to create your grid. I'm not sure what you expect your result to be since it appears your sample file removed many of the results of your Objects by Criteria node (your debug value says 4, but there is only 1 poly that matches criteria in your sample file), but here's a network with the changes I've suggested. (I tested by duplicating your test objects) Determine grid of points in multiple polygons_SAMPLE FILE_MFarrell.vwx -
3d Locus does not Rotate about a point?
Marissa Farrell replied to Benson Shaw's topic in Marionette
Most of the time when I change how a node works, I add an option in the OIP so users can still use the old behavior if they want. That way, we don’t need to keep around legacy nodes, but we still preserve the legacy behavior. I think it’s important to cut down on node clutter so users aren’t stuck asking, “Do I use this node or that one?” Instead, they can just choose how they want it to behave. For example, the original move node only supported moving an object relative to its current position. When I updated it in 2018, I added an option in the OIP to move to an absolute location, rather than making a separate node. Right now, I’m working on combining nodes that only work on 2D or 3D objects into one that supports both. Depending on whether the input object is 2D or 3D, it’ll use the appropriate functions. But in cases where a user might want to move something only in 2D even if they’re using a 3D vector, I’m adding options to force a 2D or 3D move, or let it auto-detect based on the input. The new default will be to let it decide automatically, but users can override that if needed. Another update I’m making is to the Get Vertex node. Instead of having different versions for 2D polys, 3D polys, and Meshes, it’ll now support all of them in a single node. This way, you can pass in a list that includes four 3D polys, a mesh, and then another poly, and it’ll still give you the correct vertex or point for each one. If you don’t specify an index, it’ll return all of the vertices for each object at once as a list of lists. This should help keep networks cleaner, since you won’t need to split out different branches just to support different object types. I’m hoping this will make Marionette feel more intuitive and less overwhelming to dig through. I’m also reorganizing things based on what the node does rather than what kind of object it works on, which is how the current library is structured. The goal is to help users understand that they’re not limited to different nodes just because they’re working with different object types. Ideally, any node that performs an operation on an object should work on all relevant object types. For example, I’ll make sure the rotate nodes handle loci properly without needing any kind of workaround. And please keep pointing out when you think a node should support something it currently doesn’t - this is a big library, and I often don’t catch missing functionality unless someone flags it. EDITING TO ADD!!! I’m also working on some “under-the-hood” handling for when a node expects a certain type of input but gets something else. For example, we’ve talked about cases where a node wants a vector input, but a user might naturally provide a scalar angle instead. In those situations, I want the node to be smart enough to figure out what you meant and respond appropriately, whether it’s a vector or an angle. I’m adding this in quietly for now - no big announcements - but as nodes become more flexible, I will update the port descriptions to reflect that they accept multiple types, even if the prefix is still there. The idea is to eventually drop the prefixes altogether once it’s been tested enough, but I want to make the transition as smooth as possible. The goal is to make nodes feel smarter without surprising anyone. -
Version 1.0.0
8 downloads
I wanted to share something I landed on today while working on friendlier usability for Marionette nodes. This node takes an input list and dynamically populates the OIP popup control. How to use it: • Run the network. • Deselect and reselect the popup node (if it’s already selected). • Choose from the updated options in the popup. • If you change the inputs, the node will try to remember your previous selection when you run the network again. Some helpful details: • It can differentiate between variable types, so if you feed it a 1 and a "1", it knows which one you picked. • If duplicate values are present, it selects the first matching item in the input list. • There are checkboxes to remove duplicates and sort the list alphabetically. Even if you use those options, the node still returns the index based on the original list. Limitations: • You’ll need to deselect and reselect the node any time you update the list. There’s currently no way to dynamically refresh the OIP while the node is selected. This is a bit of a hacky solution, so I can’t speak to its long-term reliability yet, but so far it’s been working well. I have other nodes in progress that build on this, but I wanted to share the base version in case anyone has suggestions or sees anything I’ve overlooked. Let me know what you think. -
This is the caveat which determines whether a change can be made within an update or has to wait for a version. Currently, when you bring a file from an earlier version into a newer version, the link to the Python file is broken in each node to prevent the concern you have. Due to this, when a node's functionality needs to be changed, we wait for a new version. Bug fixes and new nodes are the only changes we make during updates.
-
DB (database)Get Record Field don't works - Attach to EXTRUDE/SYMBOL
Marissa Farrell replied to Giobbe's topic in Marionette
Ah, okay, so you have a Database Connection. Currently we don't have nodes that support that, I made these back in 2016, and haven't looked at them since, maybe they will be useful? They're pretty ugly, but hopefully can supply the functionality you need... -
Many of these nodes were made before my time, and from what I can tell are exact translations of the VectorScript functions that were used. I don't think a lot of "user friendly" thought was put into them. For example, the Texture nodes have always been a headache for me. They haven't gotten the attention they deserve, but since there are so many, I've been tackling them in phases. A few versions ago I reduced the number of nodes by at least 75 since they did similar things to one another, but were named as if they would only work on specific object types. I'm currently going through and looking for gaps in functionality, poor implementation, etc., to get in for next version, but I do think it will be a phase-based process. If you have other specific nodes that you think deserve a more rapid facelift, please let me know. There are limitations to what can be done in an update vs. a new version.
-
You should be able to use the Transpose node in the Data Flow category for this.
-
The 'v' prefix is just to let users know they need to supply a tuple. You can either use a Point2/3D node or a Vec2/3D node when you see it. Vectors are 2/3D values. I'm working on making the library more user-friendly, so I will make a note to look into better ways to handle this.
-
I believe you're still able to make push requests that will be reviewed by someone with ownership to make edits. I'm not yet familiar with GitHub, so I don't know the correct terminology/method, but I'm 99% sure user edits are still allowed with review.
-
DB (database)Get Record Field don't works - Attach to EXTRUDE/SYMBOL
Marissa Farrell replied to Giobbe's topic in Marionette
So - my understanding is that you want to extrude a shape and attach information to it. Your file already has the poly extruded, so I am unable to see if it already had the record info attached. For Menu Commands, you will never need the Parent PIO node. That is only if you're creating a Marionette object. Here's a screenshot with some wiring modifications that might help you along. It's hard for me to test without the referenced database, and I'm not sure where your data should be coming from, so if you could give more info there that can help. -
Yes, this is a recent change. My understanding is the old wiki had security issues, so we've migrated to GitHub.
-
Giobbe started following Marissa Farrell
-
It looks like this has to do with the symbol names. It must not like some of the characters - if you choose a symbol named 'sym' then there isn't the error. I'm looking into a way to get around it, but for now it may be a limitation. HOWEVER - it appears that after the network is wrapped, you can use the button and choose the symbols again. Editing to add - I do think you'll want to wire a 2D Point node to your Insertion Point port on your wrapper, I'm not quite sure why, but it's throwing an error without it for me.
- 1 reply
-
- 2
-