Many thanks for the valuable information, really 
And the link too, much appreciated.
Looks like you know what youre talking about.
I'm probably not gonna dig into this just yet. Maybe if I reach a dead end with the Webdialog class.
I wan't to build an opinion if it's worth the effort first.
Hi!
@unknownuser said:
Could you add an offset parameter in the crosshatch window to allow the creation of one of the more common basic hatch patterns like this // // // ?
If you scroll back a few pages you can see that it is the roadmap of using costum patterns. Where one could use any type of pattern one wish.
However I like your idea, and it could be expanded into a feature with inbuilt patterns.
We could call them "vector-patterns".
Now they would not have so many adjustable parameters, cause the dialog would get swamped. But they would be created by code and not tiled groups, so they (may) be faster to intersect.
Unfortunally I'm working a lot on another plugin, so this plugin is not prioritized.
Especially since Lo had the Hatchpattern function added, I was under impression people where content with that..
But if there is more interest I might be able to squeeze in an update when time permitts. I have by no means given up on this plugin..
Check out the help files, if that does not work for you, you can PM me and fire the questions. Or if you rather post a question in Hatchafaces topic thats fine too.
@unknownuser said:
I was thinking in LO I might want to explode the scene and apply a different line style but I now see that RichSections don't display in vector mode.
You do know that you can do this in Hatchfaces ? If you want real edges as hatches from section slice that is.
@unknownuser said:
A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated
So, the dialog does not freeze during Ruby operations ?
How about window modal behavior. I mean how do one activate a dialog through Ruby plugin, must the C# program or whatever being used already be up and running?
I assume you already have tried this in practice.
Sorry bout the noob questions 
Nice try Pilou 
I think you are missinterpreting "random placements" wrong in this case.
Builing a "climbing-route" one use same colorcoding. So one can see where to climb!
But in order to create various difficulty the placements of grips are spaced out left and right of that route. And I guess that kind of random placement is what leochok is looking for. So maybe draw a path on Surface first and Place Components left and right of that path until on reaches the top ?
Sometimes on doesent climb straight up as well. On might traverse to the left first and then gradually move to the top. Hence the use of a path..
Hi leochok.
Interesting topic! Have made a couple of commersial indoor climbingwall projects myself.
I'm a climber(or was), so know quite a bit about bouldering in particular.
It's difficult to place Components randomely and yet in a realistic position for just climbing. You don't want an undercling as a crimp for ex
So I suggest fine tune placements manually. Component spray get's you started good enough. One important thing when working with Components and any sort of alignment-plugin is to have them centered and aligned at Origin to start with.
You can PM me if you like to discuss this more in depth..
JSmaker is not an option I think.
I use JsPlumb. It's depended of Jquery UI, which is a bit sketchy when dealing with CSS3 transforms. It does not recognize them 
So zooming is very fun to deal with 
Anyway one have to write nodecreation functions oneself and where endpoints should be added. Jsplumb is only a view technology. Does not do any type of layout (yet).
I've been looking into D3, and it's an awsome framework! But also very low-level so it would take ages to come up with something that's even close to where Jsplumb is now.
But still very interesting...
edit: Removed some off topic ramblings..
@unknownuser said:
I think the same method can be applied for c++ gui, e.g. qt, as well. A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated.
Great! It's just the small detail of learning c++ then
Seriously though, I was under the impression these kinds of 2 way Communication was not possible outside webdialog-World.
I would really like to know more.
Oh, I wish I'd taken up on C or C++...
Anyway, I gather Windows only ?
Both plattforms ought to be provided to keep people happy.
@unknownuser said:
if you simply delete the area of a face, it becomes 4 lines. The entities are not consistent. They are so flexible. And if this is not a issue, one can make some effort and create a Visual Programming interface for su.
That is why I use Open GL objects through a tool's draw class to visualize entities for "Visual Programming interface". It is to sketchy to try to alter Sketchups entities parametrically. Subdivide a face with a slider and youre toast, as you mention.
The biggest problem, as I see it (so far) is that a webdialog freezes during any Ruby operation. Making webdialogs only really usable being used as a form-submit type of thing. One have to write very efficient Ruby code that masks that behavior.
I wonder how other type of GUI's, you mention behave during Ruby operations..
Ahh, right. I think I got it. Sketchy shadows on geometry. I was locking my imagination on cast shadows.
Let's see what Pilou can dig up, but I also feel there is need to combine several plugins for this.
I imagine having different edge-patterns available for styling would be helpful ?
Really should release the pattern tiling even if it's horrendously slow...
Hi Dave.
When you mention "hatching plugin" are you refering to Hatchfaces ?
I'm not sure I understand fully what you want to achieve
It's quite possible to Project vertices onto a plane. However if the "shadow angle" is not ideal many vertices might get stacked around same position making it very hard to rebuild geometry.
Did not Tig have a silhuette plugin projecting to workplane or something like that ?
I was thinking aligning the workplane parallel to shadow(if possible)
There is BoundingBox.intersect
But I gather you want to be more precise than so. So it will cost to calculate intersections for many Groups however you do it.
You don't mention if is this is on 1 plane or 3d.
Draw method, in a tool. Sorry, my misstake.
Calculations for nodes are done outside the tool class. Passing through those methods
I collect information to be sent to a container that the Tools draw method fetches
information for rendering. I have a bit of work left there to get things organized.
The data changes constantly so it will probably cost more to iterate what is needed to be updated then to redraw everything in 1 go.
Since mostly dealing with Points and vectors, the new data will probably be totally different then the old anyway.
I just clear the old data and bring in new, sort of, without going into details..
There are different types of data though. Persistent data that references to a Sketchup entity for ex, can be cached and updated only when switched.
Anyway got a new situation now(TOPIC), have to redesign a lot on the Ruby side.
I've studied your render cache. It's very nice and good example. Need to study it more though.
Thanks for the input
A little bit, but not systematically. There's room for improvements for sure 
It certainly looks like it's the draw class taking time to build OPEN GL geom.
One indication is that when I disable preview everything runs pretty fast and smooth but the containers(arrays and hashes) holding the data for the draw class are still there.
First I thought the Garbage collector was having it's saying in this, cause I'm clearing a lot of data through updates (which happends frequently). But now I doubt that is the main issue. Could still be though, not sure..
I have to try to pinpoint this down in a different approach. I doubt though one can display dense OPEN GL preview fast in Sketchup. So might have to rethink my design a bit.
How Heavy geometry does your render cache work fine with ?
Well, Think Grasshopper GUI sort of thing for a minute. (Any parametric modeler GUI would be applicable.)
Sketchup would need to give some visual feedback during changes in the HTML.
I use drawing transient geometry through a tool's class draw method.
I suppose I could refactor and/or simplify the way I currently draw "viritual" geometry, but only to a certain extent. The update methods still must run and do it's calculations to produce the output.
The wait would off course be the same even if the HTML did not freeze.
BUT, I do Believe the user would not experience the wait as long during RUBY updates if one could navigate the HTML and/or get some progress feedback.
Luckily I have implemented the ability to disable preview for each node, but normally the end Product will be the most geometric dense.
I think I'll have to simplify the visual geometry a little. That's the only solution I can come up with.
But all in all, the freezing behavior would be very annoying for the user.
Thanks for answering, Chris.
Total showstoper 
I was working on separating Ruby updates from javascript when I noticed I did not
get any difference/timing in the HTML..
That means that webdialogs can only "practically" be used as forms with SUBMIT behavior, I suppose..
Sighs...
The question is related to this old thread, and I wonder if the issue is still the same ?
http://sketchucation.com/forums/viewtopic.php?f=180&t=17595&hilit=webdialog+freeze&start=30
WebDialog stops when Ruby runs
This is quite disturbing when dealing with interactive webdialog that need to execute larger ruby operations.
It's the first thread about this problem I've found so maybe this problem is already solved.
@unknownuser said:
AdamB wrote:
So I saw this thread and spend half an hour playing with building a WebDialog progress bar.What I planned to do was have a Javascript driven animated progress bar and a simple call from Ruby to update the percentage.
The html/js is trivial but I came unstuck because the WebDialog stops when Ruby runs. Now I don't understand because I supposed that the browser would be running in separate native thread.
Somebody mentioned they'd experimented earlier with this and failed. Was this the same issue?
Adam
Yes, same issue. Scott Lininger is aware of the problem.