I will need your help in few month when i will make the repository of the English/ French Elephant nodes composants!
(+ a very little example)
Because many nodes are always a mystery for me...and I believe that will be useful for someones!
(something more modest like that... http://rhino.github.io/#System
re:
> Ps @ Michael : an object (say a solid) created by Elephant ( Elephant stopped or not) is
> just selectable by "box selection" and not by a simple click!
The object probably has hit testing turned off, there is a .setHitTest(bool) method on objects that can turn it on or off. Some geometry factories probably set it to off so that you won't start snapping on to the objects that have just been generated. That's for stuff like in the Extrude command you don't want to get object snaps on the object generated from your last mouse move.
If you run this script and do something to redraw the view (like zoom/pan/rotate) it should go back to normal behavior:
script: var objs = moi.geometryDatabase.getObjects(); for ( var i = 0; i < objs.length; ++i ) { var obj = objs.item(i); obj.setHitTest( true ); }
It's probably something that the node editor should do automatically on its output objects.
UPDATED: SOLVED (problem was "sweep" node mode setting, not bundleArray)
Hello Karsten,
I hope you new well.
I don't know that this is a bug as such, but I encounter a recurring issue with bundleArray node.
When bundling arrays, the item is dropped. This can usually be worked around by idxSelecting the last array item
& concatenating to the end of bundled array. In this instance (shown) the work around does not seem to work.
Can you please let me know if this is a bug or a feature, and if the former whether it would be a difficult fix
Hello James,
bundleArray was made to bundle the points to cross eg. curves. So it limits the output to the shortest input array. In your example the splitted arrays have length 180 and 183?? - so the output is 360 long. I have tried to make numarrays with 14 and - 14 (progression node) much longer as needed, bundled these - splitted the points/pointsext and injected the angle rz. Then used transform-rotation to orient your pathes and avoid that problem, but without success. So the problem seems to be somewhere else. I am very busy at the moment, so I can not have adeeper look. Sorry for that.
@Pilou: Please have a look to the progression node to generate your numarrays. After that also to the math node.
Thank you so much for taking the time to get back to me, & for the explanation.
As it turns out the usual solution (that I described in my earlier post) of appending the dropped item
to the end of the bundled array, did indeed work....the issue was the sweep node option set to "union" rather than "long".
That's i must make at the beginning of september!
Native Elephant - Extension
French / English ( + inside the node editor itself
that is 75% made for the French part and of course 100% yet made for the English part! ;)
If node.js code were modified so that a regular node could be opened up like a macro, to show its output label as an output slot, than the user could change the output slot label of the node to " " (space) ...
- Brian
Or else add the ability to change the output label to the information box...
I don't see much advantage in making the output label editable, after-all the colours indicate the type of data outputted and the nodes themselves have editable titles which could serve any explanatory role. In instances where the outputs require specific labelling, these should most definitely be retained (& IMHO should remain un-editable)
However, I think the idea would have great merit for inputs.
Often I find myself translating equations so that they have alphabetised variables. It can be a quite counterintuitive process of letter substitution. It would be ideal if the "maths" and "mathsPts" nodes allowed editing of the inputs, like shown:
Also adding new inputs ATM is a 2 step process: first RMB clicking "Inputs" then selecting submenu button denoting next letter. This second step could be removed.
Getting back to "Out" labels. Perhaps we could do an experiment. I could post an alternative nodeEditor folder with all unnecessary labels removed, and those that want to trial it could then report back whether or not they thought the removal of labels had an impact on their user experience.
Although as I said before, that the colour of the output dot indicates the data type, there are a few nodes with more than 1 output of a particular datatype. These cases may require labelling to distinguish between them, but often, as in the case of your "Centroid" node, an extra object output is the same as the object input. This output is useful because it means that a "Clone" node can be avoided. However if nodes could have multiple Obj outputs (similar to Num & Pt datatypes), these extra outputs would then be superfluous. The node may then be like this:
I'm not suggesting you alter your "Centroid" node, I'm only reinforcing the point that node title itself often has all the descriptive content needed to explain the nature of outputs.
PS Switch node is a beautifully elegant node that demonstrates that the absence of I/O labelling is not necessarily an impediment to comprehension and usage.....quite the opposite!
TopMod.gif
