Parametric modeling, anyone?
-
@tkluysk said:
Building 20000 triangles using Ruby takes about a second. That is too slow!
I've just crossed my eyes on the "Cricket for sketchup" thread, (Pixero's fault on Thea Render Forum
) where Thomthom talks about a way to visualize geometric operations before commiting them to actual geometry. This is supposedly faster than that sec you talk about, but I can't understand half of what is being discussed...Jolran is there discussing it too so you should PM each other even more!
http://sketchucation.com/forums/viewtopic.php?f=323%26amp;t=51564#p465815
Cheers,
João
-
We have alread PM each other but we are not on the "same page".
So there is no collaboration going on.That is simply the game.
Apparently Thomthom is on the "job".
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 policyAnyway. You will have an alternative when this .net application keeps crashing.
I'm not going to back off!@unknownuser said:
Building 20000 triangles using Ruby takes about a second. That is too slow!
I have no problem with 20K displaying it in OPEN_GL.
It will take a couple of seconds more even if you untriangulate the geometry.
An ex:
-
Jolran, please: I PM you for a reason.
As far as I'm concerned we are very much on the same page, big picture wise. But again, I respect and understand if you'd rather go solo on this.
ThomThom is not 'on the job'. He has given us some early advice, and has been very supportive, as he has been with you, I'm sure. And we hope to be able to tap his wisdom in the future.
Anyway, I take away your advice on the direct GL drawing. It's a good one.
-
Dear Tom. Please check your PM.
@unknownuser said:
ThomThomThom is not 'on the job'. He has given us some early advice, and has been very supportive, as he has been with you, I'm sure
Ok, I missunderstood that part.
And yes, he has.Best regards/
Joel -
@ 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 ?
Advertisement