So, we have York and Aikson are going to talk to us about the state of FreeCAD.
So please give a warm welcome to York and Aikson.
Hi.
Hi.
Is the microphone, yeah.
Hi. Hello everybody.
So this is what we're going to talk today.
I will make a short update of what's going on, what has been done recently with FreeCAD.
And Aikson will talk more about the assembly side of things.
What do I go to the next one?
Page, huh?
The next page, yeah.
Oh my.
Oh, it's hard to use other people's software.
My goodness.
We'll get there.
Wow, it's good in the browser.
We'll get there.
Basically, I will already talk while we are there.
Yes.
Okay.
So the main thing everybody is always asking us is when is version one point there ready?
And I have good news for you.
It's almost ready.
I know we've been saying that for like five years, but I swear it's almost ready.
We basically, we have two more things that we think we cannot call it one point zero without that.
It's the top naming problem and assembly.
That's basically what I'm going to talk about briefly.
And I will talk about these other things too.
That's basically all that we are doing now and what you could already,
you can already see if you use a development version.
Can you go one further?
I hope so.
Something, something.
So, um,
Oh,
proprietary platforms, you know what that is.
It's not responding.
I go back.
Okay, let's just do it on the browser.
Yeah.
So, um, that's a teacher.
A lot of things.
Woo.
Thank God.
I don't know what to say.
So top naming basically is,
it's the main course of, of free cad is a problem we have with free cad since a long time.
Basically when you transform geometry,
any geometry in free cad has named components with this is edge one, this is edge two,
that is face one, face two.
And when you change the geometry,
the open cascade kernel of free cad reconstruct the things,
the thing, and especially with, with sketches where there is a computation needed
to know which edge depends on, on which one the order is shuffled.
And this prevents or this hinders all the naming.
When you reference one edge by name, for example,
if you say, I'm building upon one edge, edge one,
and then your edge one is somewhere else, your model breaks.
Everybody who has worked with, worked with free cad knows that problem.
That's our main course.
And it's basically about to be solved.
Hopefully.
Crossing fingers that we'll see when it's there if it holds a promise,
but it's basically a fork of free cad,
which is the, the link three branch.
It's working there already.
So we have an example of it's working and, and it's working really reliably.
So basically there is a new engine that keeps tracks of the name
and renames things as it needed.
And that is the last piece of this is being merged currently.
So in the next few months, who knows this is done.
So this is basically everything I just explained.
Assembly.
Dr. Co will talk about it in a moment.
We have lots of new stuff in the sketch.
That's basically where most of the new stuff is being done now.
We have auto constraining, which is much better.
We have lots of people are working on really interface things and having the workflow in the sketch or more streamlined,
removing some unnecessary operations.
Now you can build these things and you erect a grid to try and other shapes and you already have the right conference put for you.
You just need to edit.
If you want to change anything, we have on screen inputs.
So you make a rectangle, you click two points and you can enter the dimensions there without having to build.
We don't have to go click anywhere else.
So those are like small UI improvements.
But we are beginning to get into UI and UX and try to address all those little things and make see what we can do to make things flow better.
Lots of teaming and UI work is being done too.
There are new teams coming, trying to solve, make all these little widgets a little bit better,
a little bit less different one from each other.
There are light teams for who likes light teams, dark teams for who likes dark teams.
Everybody is having fun with this.
It's surprising how everybody use them to say, oh, wow, this is so much better and it's just teaming.
But you can do so much with that in terms of having your own application like behave more the same across, across where benches etc.
Before I let Aksion talk just a last word about what's happening around Fricade.
We are in a kind of exponential growth now.
Things are like pouring everywhere and new developers coming from all kinds.
We have a non-profit since it's our second year now.
The FPA is the Fricade Project Association.
And we begin to finally, we begin to learn how to spend money.
Like it would be hard to earn money, but it's actually much harder to spend it in an open source project.
How do you do that responsibly, transparently?
How you make the best of the money?
It's really something we had to learn and it took more than a year to begin to learn about it.
Some Fricade veterans have also created a commercial company around Fricade, which is Onsell,
which is its aim is basically to try to sell commercial solutions to people who need commercial stuff.
Companies who are not comfortable with taking an open source software.
And so the idea of Onsell is to bring them a commercial package.
So with all the stuff that companies need around an open source software to feel more comfortable.
And as always, Blender is our main inspiration into all this.
Like how they managed to get to higher commercial levels and still, it's still a community project.
And that's basically what we're trying to do here.
Like maintain Fricade as a community project and try to wet our feet with that commercial world.
We want Fricade, but without getting lost in the way.
So I'll let action talk about the assembly system now.
Testing, testing, can you hear me?
Alright, thanks.
Okay, I'm going to talk about what is called the Onsell assembly solver.
I'm part of Onsell and assembly will be LGPL.
And the work starts from my work.
Oh my.
There are your slides now.
I know, but...
How do I get out?
Get out?
Escape?
There's an escape?
Oh my.
Can you go just page...
Oh yeah.
If you go that way, you have yours.
Alright.
So basically, my work starts here.
Goodness, what is so tough suddenly?
I have a very little introduction while you're looking at it.
There was at the time a second Fricade project.
When Fricade started, there were two projects, two open source projects named Fricade.
And one of them was ours that we know.
And the other one was something that I called launched.
And now after like 15 or something years,
Dr. Ko is like putting his Fricade inside our Fricade.
And it's like a cosmic combination.
Both Fricade are joining into one effort.
Right.
I started out doing this in earnest in 1991.
And this project here, I started out as Fricade
and I launched it in the year 2000.
So predating Fricade.org.
Anyhow...
So the important thing here is this software here
is a multi-body dynamic software
which is equivalent to say, Adams for those who are into multi-body dynamics,
which is probably the premier multi-body dynamic software used in industry
by Boeing, Ford, Caterpillar and so on.
So I was in the theory of multi-body dynamics in the 1980s.
So I really got absorbed into it.
But the license for Adams was, of course, ridiculous for a professor.
And I just said, okay, I know how to do it, so I decided to make it.
So the next question was, you know, do I program in FORTRAN?
Do I program in C?
And I said, if I did that, I'd be 20 years behind.
And I was just saying, you know, let me look, see what is more productive.
As it turns out, in the 90s, small talk was the big rage.
Small talk had just invented the GUI.
Small talk had just invented the mouse, integrated IDEs and so on.
So I used small talk for this program.
And within a year, I was able to get a simulation going.
And then I spent about, you know, three to five years, depending on how you count it,
to get what you see on the left side.
Speak closer. All right.
On the left side.
And I tried to commercialize that.
Indeed, we did form a company.
And we got bought up by Adams.
I decided to leave to start my own.
And I put this, as you can see, the graphics here is, of course, pretty bad.
Just extrusion.
2D is extruded. That's it.
So I made add-ins for space claim.
And the motion simulation is mine, still running in small talk.
But the simulation now works with space.
And the system is quite capable.
It can do systems like this.
And hopefully, FreeCAD will be doing this in the future.
Certainly in kinematics and assembly, that will be all LGPL.
We, the multi-body dynamic side, the dynamic side, we undecided at this point.
Okay.
So hopefully soon FreeCAD will be able to simulate systems like this.
Okay.
All right.
Back to my slide.
15 minutes left.
Okay. Good.
So the theory, if you're interested in the theory,
the theory is right there.
Okay.
It's in open office format.
And this is just a summary page in PDF.
And for those who, you know, want to get into the details, it's all there.
Okay.
And hopefully it's reproducible too.
All right.
So this is the open source version, which is in C++.
All right.
In order to make it work in FreeCAD, I had to translate it from small talk to C++.
And that was an exercise that really taught me something interesting too.
So translating from C++ would be similar to translating from Python to C++.
So, all right.
A little bit more on the theory.
I'm supposed to make it technical.
I guess they want me to impress you guys with the technicality.
So.
It's basically you have the world frame or the inertial frame.
And then from there you go to the assembly frame for, and then from the assembly, you go to the part frame.
All right.
And then from the part frame, you have markers frame.
All right.
And then from the marker frame, you go to the end frame.
And the end frame can be on a point or it could be on a curve or it could be on a surface.
All right.
And the point itself could be moving relative to the marker and the curve itself could be changing shape relative to the marker.
And why would I want to do that?
For example, if I have an actuator moving a piston or hydraulic piston out as a function of time, I want to be able to describe the movement of the E marker relative to the M marker.
And that would be the purpose of having things move.
So once you have the kinematics where the position of things are, the next thing is to use constraints to make sure that they connect in an interesting way to make your mechanism.
All right.
And the constraints are basically absolute constraint, Euler parameter constraint at point.
That means they are at the same point in the plane.
The lines are perpendicular.
They are at a certain distance, constant velocity in couplers and so on.
Extruster.
So the equations and we solve this in a right way, mathematical, exact way.
You should get kinematics and dynamics quite nicely.
So right now we have a lot of assemblies in free cat, but I don't think any of them solve the full kinematic equations completely in 3D.
So with that, you can create joints like this, rigid, prismatic, revolute, parallel, cylinder, cylindrical, spherical, and so on.
And hopefully almost all of modern day mechanisms could be solved using this combination of joints.
So let me share something that I think is most interesting that I discovered in this practice.
So I started on a small talk, which is very Python like.
So I think that could be shared with you guys.
Going from small talk to Python or Python to C++.
I was a bit worried, you know, how do you do it?
And, you know, C++ is of course a terrifying language to me.
But I realized that actually I don't need to use all the bells and whistles of C++.
Let me just get into C++ so that you can get into free cat.org.
So I made C++ in a way that is small talk like.
And once I was able to do that, miraculously, the small talk and the C++ could stay on side by side and look very similar.
And as a result, I was able to do a translation in about 6 months when I was worried, wow, it may take quite a long time.
So I want to pass this on to you because Python people may want to do that too.
You want to, you have developed something in Python, it's nice, but it's slow.
You want now to put it into C++ to make it fast.
And you have never wanted to do that because it's just terrified of C++.
But now I think there's an opportunity. It's not that difficult.
Okay, so you will make Python and C++ look alike.
So what's the secret?
I don't worry about protect and private. Everything is public.
All variables are public. Functions are public and virtual.
Okay, and the secret is to use smart pointers, shared, underscore, PTR.
If you do that, then the C++ objects behave very much like the Python object.
Okay, and in the past, you are afraid to use pointers because you worry about memory leaks.
Okay, you worry about when to use new and delete.
And if there's a match, you are guaranteed to have memory leaks.
And then the other thing is in C++, you have copy by value or copy by reference.
But if you use shared pointer, those things, you don't have to worry.
The only slide additional is the worry of circularity.
You have one shared pointer, A to B, and if B points back to A,
that would be a circular reference.
All you have to do is you use a shared pointer from A to B,
and then from B to A, you just use a plain raw pointer.
And that circularity for shared pointer will not be a problem.
As you go around in a bigger circle, you just have to break one of those with a raw pointer,
and you should be in good shape.
So that's my, I guess, extra bonus message to you guys about Python to C++.
That's it.
Just one last thing to add is that there is already a version of this working in FreeCAD
that you can get in the on-cell has a special build of FreeCAD that they issued
which already contains part of this.
So that's testable in their build and soon in main FreeCAD.
Okay. Are there any questions?
Hello, thank you very much for the very nice talk.
I'm very curious with all this new powerful functionality,
what your thoughts are about possible changes to the user interface.
If it will be easy to integrate, if there need to be new concepts in the user interface,
maybe if there would even be visual programming,
like how do we envision that users can use all the functionality that you introduce?
Assembly has been around in a long time, so I don't think there's anything unusual.
So we are developing something on on-cell,
but I believe that any of the assemblies can use my solver to get good assembly solutions.
Hello, can I ask if there's any roadmap for the path work bench
and in particular about using the fourth access, the available ability,
if that is on the roadmap at all?
Yes, what do you know about that?
Sorry, could you repeat?
Brad Collette is the, I guess, originator of path.
From talking to him, he wants to make it as professional as possible,
or as solid as possible.
So I'm sure it's in our roadmap, but I don't know exactly what that roadmap is.
I mean, it's certainly a high priority. Let's put it that way.
So my question is, is there going to be a default assembly workbench
and a DAST case with one one?
Good question.
You want to?
I think we have Pierre Boyer creating one in on-cell,
and we call it an integrated assembly.
But like I said, for everyone to work together to create one nice one for freeCAD,
it's definitely our goal.
So we'll put our integrated assembly out, and as usual, freeCAD is open source,
and people can give a lot of input, hopefully constructive input, and then we can move on.
Yeah, just to add something, we hope that this will be the one that unifies everybody.
But it would still have all the others, and there are many paradigms,
and other people who want another sort of assembly in that will stay.
We just hope there will be like a good default that most people will want to use.
There's a question online.
Once toponaming is solved, would you allow adding custom names to elements, faces, edges,
for example, instead of only having generic names like face1, edge2, etc.,
a user could attach custom strings?
I'm not sure I understood exactly the question, but the thing is, yes,
the translation engine that we're...
There is a kind of mechanism that maps the older edge1 to the new edge1
and keeps tracks that's always the same edge that gets named edge1.
That engine is also able... You can use custom names there.
So instead of edge1, you could change the name to left edge.
And so, yeah, I think that's what the person is asking,
if you can begin to customize the things and give labels and names to things.
And yes, that's already in the engine.
Thank you very much.
Super news for the topological naming problem,
but I think the one most interesting to me is the change in the UX.
I think that's one major, major wall for beginning users.
Another question I have, I was recently listening to a podcast from Opulo,
a machine making pick and place for electronics,
open source but commercial.
And what I found very interesting is they said,
we want to build with FreeCAD just so that our machine can be the best.
How much emphasis do you put on building features in FreeCAD
to support this community open hardware approach of just contribution,
like building... So for code, it's very easy because you just add line of code,
and you have a Git diff. What about Git diff in FreeCAD somehow?
Yeah, we're thinking about that all the time.
Of course, it's very hard to obtain.
It depends a lot on what's your use case, what you want to see in diffs.
But if you look at the FreeCAD forum, you have several threads about that,
people looking for possible solutions.
I would say none of the other software...