"The reality is that the end result of what you're describing would not be very unique since Rhino/Grasshopper already exists in that role and has far more momentum and resources behind it than what I would be able to muster."
I understand your point of view. Clearly.
It's true...Rhino/Grasshopper is a super STRONG duo, but I anyway thing that Moi + Max's Node Editor with their "lightness" and easy of use could have been a great alternative.
Anyway...I don't want to bother you with these considerations.
I respect your choice...it's your job and you know what you need and what is good for you and your product.
I'm not sure if NodeEditor should be a default part of MoI, because IMHO most of MoI users NodeEditor don't use so often and I like that such excellent tool as like NE is, can be part of MoI as an "accessories", as well as all excellent scripts that are created by all MoI community. This is a marvellous example of people cooperation across the world.
I think that to MoI users would suit first more intuitive "grouping" instead of "style way" together with some form of primitive instancing like "copy/paste with adequate orientation of changed parts with same part name". In other words if I modified one part (solid, curve), so rest of parts with same name would be modified too with their own orientation in model. It would be great to have check box: "modify rest parts" in info panel :-)
In any case I respect for amazing work on nodes from James, Karsten and other Node experts.
I would like to know if it is possible to create node which respects law of reflection of light. It means to have point/flat light source (solid) with rays (curves) as an input and curved surface - reflector (rotate conic curve) with Rho as a variable. Rays impacted of surface would be reflected to the detector (plane) in specific distance. This would be very nice educative tool. 2D would be enough :-)
Thank you for the links. There is much to learn from all the code available. It might be a file security issue that is preventing the Base64 conversion. Looks like Max ran into the same issue four years ago. The code looks right, but nothing happens.
Thank you. Max's heightmap program outputs the CurvesU and CurvesV in a line sequence while the ConvertPts component (CurvesU) outputs in XYZ-XYZ etc then draws a line back to the next XYZ step up from the far point. The CurvesV setting did not output anything.
ConvertPts might be updated to a new conponent ConvertPts2 for resequencing the points in a line order.
Unless there is an existing Node component that is being overlooked.
Thanks for getting back to me. Did using a low res image input reduce the output number of points?
>> Unless there is an existing Node component that is being overlooked.<<
"Points2/PointsExt" node can be used to order a single point Arrays into a sequence of discreet arrays, however it necessary to know the xLenght, yLenght & zLenght. Assuming the point output correlates with the image input, a 60px x 40px image will be xLenght = 60, yLenght = 1, zLenght = 40.
To connect pointArray output to "Points2/PointsExt" node, use "Points2/SplitPts"node as intermediary
(only x y & z outputs need be used).
If this is a bit confusing, DM your beta js file & I'll demonstrate.
In my original proposal for ImgSampler (http://moi3d.com/forum/index.php?webtag=MOI&msg=9581.2) I had a point array input to dictate the numArray output length, perhaps this was the wrong way around. Maybe it would be far simpler if instead the image size determined the U & V dimensions of output point array.
Ideally then the image resolution could be varied dynamically with dialled input so that a higher res image may be imported and pixelated to suit the desired point array data. There is a lot of information available for pixelating images with JS & HTML online.
Essentially, this entails reducing the image size while retaining the display size with imageSmoothing disabled.
The pxWidth & pxHeight would then be the Unum & Vnum of output pointArray.
.