This already exists in the interface customization; there are 3 optional buttons: “interact”, “option panel”, “attribute panel”.
Having developed a parametric engine myself, I can tell you that DC and LC are built on very similar foundations, but their applications are very different: DC is true parametric engine that drives existing geometry, while LC is a scripting tool that generates geometry. In principle, LC should be fantastic, as it is in other software, but bad strategic choices have turned it into a failure.
Dynamic crane component plus a small plugin layer using an observer.
Find the link to the discussion on the Biblio3D forum in the video description to retrieve the code and the component.
Hang this is cool. I haven’t got as far as thinking to move the crane like you have. Very impressive. I focussed on operating the crane as an operator would, but what you’ve done will be even quicker. Thanks so much for sharing. the last time I did anything near to coding was back at school in '87 doing Basic on a BBC computer! man how times have changed. I guess now AI can do the coding, but would still like to teach myself.
I’ve shared my 1st 2 DC’s, crane & digger on the Warehouse. Since then I helped create a Luffing Jib Crane for use on an extradosed bridge we’re building in New Zealand. As you can imagine some complex lift plans for such a structure.
So thanks again for your generous share, I will definitely make use of your ‘instant move to lift point’ crane to speed up our method working. 3 cheers for Sim!!!
There’s a fair bit to unpack here, so forgive me for taking a little bit to jump in and give some clarity!
Let me give a quick rundown of some of the main points raised in this thread.
Live Component development: Our current focus is ensuring that the Live Component content library is up to scratch and developing features to integrate Live Components into SketchUp workflows (e.g., sizing using the scale tool).
Creating Live Components: Trimble Creator is not for everybody, and we understand that there is a learning curve that’s not very ‘SketchUppy’. We realize this and are working to make Live Component creation simpler. In line with the above point, we are doing so by shifting the onus to existing SketchUp functionality rather than requiring ‘code’ for Live Component behavior. Sizing with the scale tool and applying materials with the paint tool are recent examples of this.
Cloud vs. Local: When first developing Live Components, we knew we wanted them to work across platforms, so we needed a solution that would work on Desktop, Web, Mobile, etc. Being cloud-based streamlines our cross-platform compatibility and consistency.
All in all, though, I really appreciate the discussion! If anyone has any more feedback, ideas or anything else, please let me know. We keep track of this input in a few different places, but discussions like this are often the most useful.
Hello
To make Live Components usable, you need to:
Sketchup API: List the attributes of the Live Component, read the meta-attributes of each attribute (name, type, value) and be able to modify the value, and force redrawing.
This will allow Live Components to be used not just as drawings, but in a downstream and upstream production workflow. Inject a dimension, a list of points, etc., and then retrieve volumes, areas, quantities, etc., calculated by the graph.
There’s also a significant problem to address in the LC graph: the transformed groups must retain their own axis system. Otherwise, it’s conceptually confusing, and we lose the ability to measure copies that might have different dimensions (for example, decking boards of different lengths to adapt to the geometry, or a layout with boards rotated 90 degrees and boards without rotation). Sometimes you have to consider the length along the x-axis, and other times along the y-axis. Not to mention intermediate rotations where we no longer have access to any of the values.
These are, in my opinion, the two cornerstones that LC lacks and currently render it unusable in a professional workflow. The other shortcomings are anecdotal for the moment.
Hoping my recommendations will be followed. of effect.
DCs and LCs aren’t exactly the same thing and can become complementary as they mature. The advantage of LCs is the ability to work from scratch with points and draw meshes and curves, which is impossible in DCs except by subdividing the component (for example, a miter cut). I think the two are complementary!
And I agree with you that they
are victims of the same Trimbelian syndrome of abandonment after enticing announcements.
For now, it’s just frustration and a lack of progress.
DC is the work of several engineers, including Scott Lininger, hired by Google when it owned SU. DC received a minor update in version 7.1, but never again under Trimble’s ownership. It’s slow, probably because the dependency graph isn’t stored and needs to be rebuilt. So DC is dead. The problem is that users prefer DC to LC (and we understand why).
I wonder if all the development dollars that have gone into LCs could have paid for a brand new, ground up, updated and upgraded DC extension? If it’s not broken don’t try to copy Blender…
I say that neither should be extensions, but native code, then there would be no latency or redraws, probably less bugs. Two code bases, one for net and a robust, priority one for workstations (desk, laptops)
I think that LC’s should work as a native plugin like DC’s inside SketchUp and it could become a powerful tool if the development takes the right path, it could take some years to tune it but I bet it could compete with grasshopper and rhino if Trimble decides to invest on it. Parametric design has been growing the last few years, the initial impact has decreased but still grasshopper and geometry nodes are tools that I’d love to have on SketchUp.
Hello
Being multi-platform is a commendable idea, but the chosen technical solution doesn’t live up to the ambitions and the intended uses.
You don’t work on the same things or the same type of projects on a PC and on a tablet. The pro version is the desktop version! It should be prioritized! It’s capable of supporting local work as a plugin.
And for tablet versions with fewer system resources, a web version of the plugin is needed.
Without this, and without an API, you’re simply dumbing things down!
There’s no shame in admitting you’ve gone astray and correcting your mistakes. Listen to your professional user base who faithfully pay for their licenses every year!
There is another solution, DC code open source or not, it is possible for an independent developer to create a new parametric engine which would incorporate the DC conventions stored in the dictionary within the components/groups which would allow him to recover his belongings. This development would be an opportunity for a fresh start, and perhaps even a parametric engine that could work in other software. Remember that DCs are very simple: move, deform (group/component), rotate, and copy.
To be perfectly clear, parametric as DC is an application of a dependency graph. LC, Grasshopper, or Dynamo are based directly on a dependency graph, but they are not parametric tools in the sense we understand DC. Parametric analysis that drives an existing geometry is a bit more sophisticated.
Oh ya, this would be ideal. Any dev’s out there up for the challenge? I would definitely pay for a new, updated and upgraded DC extension subscription.
I have a parametric engine that goes a bit further, since it works directly on the geometry (ignoring groups and components), but it would be easy to add support for deforming groups/components. Currently, it lacks copy functionality. After that, it will need to be rewritten in C/C++, compiled into a library for different platforms, and then interfaced with Ruby. Then, the interface will need to be created in SketchUp using the APIs, which is the most time-consuming part… A large number of interested users would also be necessary.
