Parametric modeling, anyone?
-
@ JQL & DOD3R thanks for your encouraging words. We know we'll need those over the coming months!
-
@jolran said:
It would have been common curtesy contacting me as well since I've been
posting stuff about this plugin for over a year, and a longtime member of this forum..
But I guess this is the new Trimble policySorry jolran, I didn't connect the two project. I knew you where working on something paremetric - but I had no idea how far you'd gotten and the exact details. I haven't been able to keep up to date with everything the last year. Last time I checked in it was about concepts I think. The screens you have to show here is mighty impressive!
Rest assured we have no "policy" of excluding anyone. -
Don't worry Thomthom. You have helpt me so much in the past.
Therefore I was a bit surprised not getting any info at all, that's all.I must admit, I have been cryptic regarding this project. So I have myself to blame.
-
And we also have to be careful about sharing information which people come to us about. Some of it can be sensitive information which isn't meant to be shared.
I really like what I have seen so far from both of your projects, and it would be great if there was some way you all could benefit from each other.
We are here to answer questions should there be any. And we're paying close attention to these types of extensions as we're aware that there are improvements to the API to be desired. Performance is one of them.
-
I don't want to contribute to promote any argument here, but I take it Jolran's aproach is the way I'd opt as it is Sketchup based, but the web based viewer/product configurator is the sort of thing I'd need on some projects of mine I've just started to develop.
I really hope both of you achieve your goals wich will greatly contribute for the community as a whole. If, your combined achievements could be awesome faster though...
Again best of all,
João
-
@JQL Portability to the web/cloud is central for us, and you might agree that this is where all things CAD/3D will end up. But you're right: it makes for an odd marriage with SketchUp in its current state. But odd couples often work out great
We can think of a few elegant ways of integrating, though. Many plugin developers already resort to C/++ extensions for vast performance increase over Ruby, and we hear a C# wrapper for the API is on the way as well. Those apporaches are not very different from what we have in mind. If we (as in you included!) can demonstrate exciting applications done this way, we might get the SU team to play long, I'm sure.
For a larger pov, the MatterMachine integration might help shape people's ideas of what SketchUp's presence in the cloud could mean. The Sketchup Warehouses (asset & extensions) could become natural places to interact with SketchUp files, rather than pulling them into the desktop app. The WebGL viewer for SU files is a great step in that direction.
-
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..
Advertisement