Parametric modeling, anyone?
-
MatterMachine - SketchUp: first contact!
This is through a socket, straight from the Unity webplayer plugin in Chrome, to a SketchUp Ruby thread.
The Ruby threads seem to refresh very erratically and somewhat infrequently. By far not fast enough to sustain, say, a 30fps link between MM and SU. It might very well be that that's as good as Ruby threads get. They are not much faster when run in a shell, outside of SU, so SU is not really to blame here we think.
If we rule out error from us, we will work through a C++ socket instead.
-
@tkluysk said:
MatterMachine - SketchUp: first contact!
This is through a socket, straight from the Unity webplayer plugin in Chrome, to a SketchUp Ruby thread.
The Ruby threads seem to refresh very erratically and somewhat infrequently. By far not fast enough to sustain, say, a 30fps link between MM and SU. It might very well be that that's as good as Ruby threads get. They are not much faster when run in a shell, outside of SU, so SU is not really to blame here we think.
If we rule out error from us, we will work through a C++ socket instead.
(disclaimer - i don't write code)
are you trying to get all of the drawing to happen in sketchup itself? because i would imagine that being pretty slow for this type of plugin as it's going to be creating lots of geometry very quickly and i don't think sketchup can handle it except for the most basic of operations.
what if it accepts geometry from sketchup (say, a line in a model) as input.. then does all the calculating/previewing/etc outside of the sketchup model space (or maybe in the space but using different type of preview drawing than normal sketchup?).. once a user is satisfied, the results are then drawn ('baked' in grasshopper terms) with real sketchup geometry.
or is what i'm describing already what you and jolran's sneakpeeks showing?
-
That's pretty much what they are doing. They calculate the parametric data and then translate that to the SketchUp native geometry.
Doing that is best done in a compiled language instead of Ruby - as Ruby is slow for that kind of work. For that Ruby C Extensions allow you to bridge any language you want really.
Creating bulk geometry via the Ruby API is another challenge - we're aware of that and we want to improve that. These kinds of extensions are good use cases to study in order to optimize the SketchUp platform.
-
^
oh, ok.
in that case, I'd only advise that you advise the compiled language is one that can be used cross platform
(C++ maybe?)even if mac/win version isn't developed in parallel, a language that doesn't make it impossible to go to mac further down the line.
-
@numerobis said:
powerful stuff
makes me happy in my pants
such a pity I won't be able to make use of this
-
@jeff We tried a non-blocking socket in the main Ruby thread for a bit (ie, not running in a slow second thread), and that actually worked fine. We're now using a C++ socket, which is still an order of magnitude faster. We are working on an efficient way to pass large amounts of geometry data from MatterMachine to SketchUp, at a respectable framerate (10+ fps). The socket seems fine with that.
The bottleneck is rapidly shifting to the translation of that geometry data to SketchUp geometry using Ruby, like you guessed.
On suggestion from Jolran and ThomThom, we are representing geo using fast(er) GL draw calls while the user is editing (using a slider or in-view gizmo). Ideally, we want to build proper SketchUp geo as soon as the user stops editing (mouseup). We'll see if that's realistic. We'd like to get a better user experience than the Grasshopper - Rhino interaction.
At this time, it looks like we should be able to compile for both Mac & PC, and even older versions of SketchUp using Ruby 1.8.
-
-
Hi Tom.
Regarding getting a better user experience than the Grasshopper - Rhino interaction, it might be difficult
I'm working a bit with that right now, and it's quite disturbing how entities get's lost sporadically after edits. So referencing existing Sketchup Geometry is not a piece of cake.
I'm guessing this is due to Sketchup being a "meshmodeler" and Sketchup has to create new faces all the time to fill in geometry. (Try creating a cylinder and rotate the top around center you will see faces triangulate. A reference to a face on that surface will get lost)
Using object id's, caching the selection, or using attributes is all the same....
-
@jolran said:
(Try creating a cylinder and rotate the top around center you will see faces triangulate. A reference to a face on that surface will get lost)
You could generate the mesh triangulated while you do live deformation.
And you might have better luck with manipulating the vertices instead - using Entities.transform_by_vectors. (That's what I'm doing with SUbD: http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=57480) -
@unknownuser said:
You could generate the mesh triangulated while you do live deformation.
That would generate new faces, you mean. ? Getting a nice deformation result is not what I'm talking about.
We might be dependent on information gathered from a particular face further in the node-chain. Like planes and stuff..
This must go hand in hand with user doing standard modeling tools, which is out of reach of the plugin, normally.I did noticed though, getting information from vertices is more predictable.
And edgeloops. All in all collecting data from containers is safer.It might be a workaround using vertices to collect data for a face, but not as straightforward.
It involves doing more lookups than should be necissary.Subd:
Ah, nice! So CEXT is doing stuff externaly then ?
-
@jolran said:
We might be dependent on information gathered from a particular face further in the node-chain. Like planes and stuff..
This must go hand in hand with user doing standard modeling tools, which is out of reach of the plugin, normally.Right. In SUbD I store all data in attributes in the definition. Currently, when the mesh is subdivided the control mesh is recreated entirely in attributes - even nested attributes. At the moment each limit-mesh entity has a unique ID that reference the ID of the control mesh so I can look up control mesh data. (I think that if a face is triangulated by autofold each new face will get a copy of the attributes.)
I do wish we could have a more generic way to create parametric tools in SketchUp though. A framework that could be used to kick start new creations easily without everyone reinventing the low level stuff all the time. But generic high performance frameworks are challenging to get right.
@jolran said:
Ah, nice! So CEXT is doing stuff externally then ?
CEXT in that last screenshot just reference the Ruby C++ Extension that does the calculations. I'm not sure if you refer to that as "external"..?
-
@unknownuser said:
Right. In SUbD I store all data in attributes in the definition. Currently, when the mesh is subdivided the control mesh is recreated entirely in attributes - even nested attributes. At the moment each limit-mesh entity has a unique ID that reference the ID of the control mesh so I can look up control mesh data. (I think that if a face is triangulated by autofold each new face will get a copy of the attributes.)
Sounds sofisticated. This gives me some ideas, thanks.
@unknownuser said:
I do wish we could have a more generic way to create parametric tools in SketchUp though. A framework that could be used to kick start new creations easily without everyone reinventing the low level stuff all the time. But generic high performance frameworks are challenging to get right.
Yeah, that would be ultimate. Have you started yet ?
@unknownuser said:
CEXT in that last screenshot just reference the Ruby C++ Extension that does the calculations.
Yes I was refering to a C-extension.
-
@jolran said:
Yeah, that would be ultimate. Have you started yet ?
haha!
Well, one first need to understand the problem. Working on SUbD gives me some insight to that. Keeping an eye on this thread is also a good source of information.These types of extensions haven't been so in a great extent for SketchUp. So finding a good design pattern isn't easy. Will need some experimentation and trials and errors.
@jolran said:
Yes I was refering to a C-extension.
I first started using C extensions for Vertex Tools - in order to implement the soft selection feature with any reasonable performance. Scripted languages are usually slow for calculations - Ruby especially so.
-
@unknownuser said:
I first started using C extensions for Vertex Tools - in order to implement the soft selection feature with any reasonable performance. Scripted languages are usually slow for calculations - Ruby especially so.
Yeah I have the impression Ruby works fine for a while, but when you hit a wall it slows down exponentionally..
I'm looking into the C-stuff. Got some help now..
-
Have to say, this would be a dream come true for me. I've also been asking for something like this for quite a while, particularly for doing complex panelisation operations.
@jolran - I remember you telling me once that you were working on something off the back of hatchfaces; is that the propject that you are referring to in this topic? I can't seem to find any link to it though...Care to share??
Best of luck to you all!!
Joel
-
Hi Joel.
No, this is a different thing than the one I was working on back then.
There are no release yet, and no date set.You can PM me for specific questions/suggestions, should you wish to
Advertisement