removing all geometry from SceneKit, or modifying it on the fly - swift

I have a simple SceneKit view that displays antenna designs, like a TV antenna, or this less common example, a biquad.
These designs consist of a number of SKCylinders that are rotated and positioned.
Connected with that view is a NSTableView that lists the endpoints of the cylinders and lets the user edit them. When they exit an editor, the 3D view updates.
The problem is that my code current always adds new SKCylinders to the view with every redraw. So as they make edits, multiple copies of the SKCylinders end up in the view. I'm looking at the docs trying to figure out the best way to fix this.
1) should I simply remove all the geometry nodes before every draw and then make it fresh? Is there an easy way to find all the nodes that are geometry, rather than cameras or lights (or whatever)?
2) is there some way I can identify nodes within the collection so I could say that since line 5 of the geometry changed, I need to adjust node-with-something=5? I though about using name but I don't see a way to find a node by name
3) (2) is not a complete solution because I allow inserts and deletes in the list, so it might be "everything after this changes". Does that bring me to (1) or is there a better solution here?
Thanks for any advice!

I haven't used SceneKit yet but, from the documentation, it would seem that you can find nodes by name by calling:
SCNScene.rootNode.childNodeWithName( name, recursively: true)
or just iterate through childNodes recursively yourself.
Depending on the complexity of the nodes hierarchy, it may be tricky to implement insertions and deletions but, once you found the nodes you're looking for, that's just plumbing (prune and graft tree manipulations and such).

Related

Easy way to view what objects depend on an object in psql?

I'm forever going in to update tables/views/procedures/functions, but need to actually drop and re-add them due to changes in complexity. Then I have to deal with the child views one at a time.
Can anyone recommend an easy/fast way of viewing all the dependencies on a postgres object?
pg_depend table is what you need. Doc here.
It is actually graph where each node is modelled using 3 attributes, each row represents edge in dependency graph. There are some pitfalls (rule-view edges are not intuitive at first sight) but it depends on what you exactly need. Recursive queries are handy to get hierarchy.

Binding Text Blocks in a Master to Shape Data on the Master

I'm returning to Visio after being a power user in the 2000's. A lot of what I'd do back in the day was create custom masters and associate data with the shape with individual labels etc. on those masters. Sort of a multi-part shape bound to the shape data on a given master, with fine-tuned arrangement.
The shapesheet seems entirely gone in 2016 Pro and now we have the data graphic features, which are nice and interesting, but they don't give you the same degree of fine-tuning and baked-in support that my old approach of building custom masters did.
How would I go about taking a text block on a master and binding it inside that master to the master's shape data for a given property? I'm betting it's a custom expression, but I'm not sure what the syntax would be.
Oh, my overall use case here: I want to have a shape with fine-tuned fields that are always visible, but appear in different compartments on the shape. I want to link external data into the shape and have the text blocks pull the value out of the shape data and render it for the area in question. I may use Data Graphics for ancillary things on a case by case basis, but at a core, I know I want certain features to always be present in a master and styled in certain ways.
to display the property of another shape you need to reference it in the form:
sheet!N.prop.X
N being the ID of the other shape, in your case the parent.
Store this value in a intermediate field, the use insert/field.
Here's a tool to do this automatically: http://visguy.com/vgforum/index.php?topic=6318.0
To handle input options to custom properties I recommend the following
1) set up a custom property of the page as semi-colon separated list for holding the desired values. eg: prop.myOption = "A;B;C"
2) in the shape needing this option, set up am according field as fixed list. In the format cell write: thePage!prop.options.
That's it. This way you can edit the list in one central place and have all the shapes updated.

Control Order of Nodes When Using "Re-Layout Page" in Visio 2010

Sorry, this probably isn't the most ideal venue for asking this question, but I couldn't find a better SE site.
When I use "Re-Layout Page", the nodes at the same level (hierarchically) are scrambled, and I can find no way to control them.
Fixing them all once via renaming the nodes didn't work. The order they're created in and the z-index of the object don't seem to matter either.
Any suggestions?
It's tedious, but you have to select each connector one at a time (note: not each shape), in the order you want and "bring it to front." My drawing is a top-down tree, and I started from the (what I wanted to be) the leftmost leaf, worked up to the root (top) and then down the other side, staying connected the whole way. After setting the order this way, deselct everything and do the re-layout.
In general, any shape you want to move to the right, select its connector and "bring to front." But unless you do them all systematically, it will be hard to set an overall order this way.
I also tried to speed up the process by multi-selecting the connectors in the desired order, and then doing just a single "bring to front." However, I couldn't figure out what orderings this was producing. And there's the danger that you miss when control-clicking on a connector and you figure you should start over because the "order" isn't being set any more.
Hope it helps.

Puzzle Solver - TreeNode Help

I'm trying to code a puzzle solver app.
I need to find out how many moves it takes, and how many solutions there are.
I would rather not give too many details on the puzzle.
but the player moves around a grid ( say 5 x 7 )
as they move, obstacles could be captured so the state of the board needs to be tracked.
( this could be done as a string or an array )
I understand I need to create a TreeNode, starting with a root ( the players start position )
and give each node children of the possible moves until all the possible moves are calculated.
The puzzle stats could then be collected.
Number of Possible solutions, minimum number of moves to solve, average number of moves to solve, etc.
I have the puzzle logic created that will return if moves are possible and such.
I'm having problems creating the TreeNode structure and making sure moves are not duplicated.
The puzzle app itself is on the iPhone, but I'm writing this solver/editor on the Mac.
Any help would be VERY much appreciated.
Perhaps you could do a variant of a tree recursion? Traverse the tree recursively, having each end node return a value of how hard it was to get there (if there are costs associated with different moves) and a description of how it got there. This of course requires the player to only move in one direction, otherwise the tree-structure doesn't describe the problem. A bit more info on what your exact problem looks like would be helpful.
It might be a heavy algorithm, but it gets the job done.
For detecting repeated states, you would put the states in a set as you went along, and then check every time you found new states to see if they already existed. Though if space is an issue, you will have to resort to only checking if the children are not the same as the parent, or some kind of limited version of this approach.
A node class is very simple. It just contains a pointer back to a parent (if it has one) and the variable it holds (such as a state). You will also probably want other variables depending on your application.
When you get to a node, you use a successor function to get all the child nodes from there (the states that can be reached in one move) and add them to a list. You pluck from the list to traverse the tree.

iPhone -- Applying MVC when the view hierarchy has a parallel structure to the model hierarchy

I have a Triangle class. Each Triangle has three edges a, b, and c, and also three angles angleA, angleB, and angleC. In addition to the size (length or angle), each datum also stores whether it was entered by the user or was calculated based on geometric relationships to other data.
Corresponding to my Triangle class, I have a TriangleSidesAndAnglesView. This view has six subviews -- one for each of the angles, and one for each of the sides. The contents of the subviews depends on the information in the model class. The subviews are all of class TriangleDatumView.
Information can pass both ways. For example, if the user enters something in a text field corresponding to an edge or angle, the entered value needs to be passed up to the model.
I am trying to figure out how to keep everything organized. For example, should the TriangleDatumView objects contain references to the respective corresponding members in the model class? Does the TriangleSidesAndAnglesView need to keep a table of which TriangleDatumView corresponds to what model object? Should the TriangleDatumView for (say) edge b know that the name of the edge it is displaying is "b" so that it can write "b=" each time . . . or does it grab that info from the model?
Nothing here is fundamentally difficult. The challenge is organizing it all in a sensible way.
Thanks for any help.
A question I ask myself is "What do I want to be able to independently vary?" -- meaning, if I have a model, could I imagine a totally different implementation of the same interface or a totally different view for the same model. In the variations that I care about, what needs to be where.
So, if labels are always A, B, and C -- I see no reason to store labels in the model. If they can change, then yes, you should not hard-code them in the view.
Views in MVC often have references right to the model they are viewing. Sometimes the controller is an intermediary. Models should usually not contain references to views -- but instead use things like delegates to alert of changes to their state.
I'm in the "Do the simplest thing that works, and don't repeat yourself, refactor when necessary" camp. The issue with building in the complexity at the start is that it might be complex on the wrong axis -- let the features dictate how the interfaces grow.
A view controller could sit between model and view, managing an array of TriangleView instances. The controller adds, modifies and deletes views based on what is in the model, and does the same for model instances based upon changes to the parent view (typing in a text field, tapping and dragging, and other UI actions, etc.).