What's new

2025 Roadmap

bolsover

Alibre Super User
One thing I am wondering: Alibre is a .NET application, right? So why is it emulating x86 code on Windows 11 for ARM (in Parallels on Mac) then?
Couldn't it just use the native ARM .NET runtime? Emulating the x86 version of the .NET runtime sounds unnecessarily inefficient. Could Alibre perhaps compile the application as Windows for ARM binary without any rework? That would be nice!
Alibre is implemented using .NET 4.8 framework. Full ARM support was not added until .NET 4.8.1. Interestingly, PDM server components use .NET Core 5.0 which is fully supported on ARM.
It's my guess that some future version will use .NET Core 5.0 (or maybe even later version) but I'm not about to hold my breath waiting for it!
 

EPowIPi

Senior Member
I think the limitation that Alibre has in their application is the platform and dependencies of the HOOPs geometry core and engine! The problem for end users of libraries like these are that they have to use the same .NET CLR and processor architecture. I'm sure Alibre could build and release many variants of processor architectures, ie. x32, x86, Arm64, etc ... IF the dependant libraries were available in those architectures too!
Good point, fingers crossed these 3rd party libraries are also compilable/available as ARM64 binaries. I guess ARM64 will become more relevant in the Windows world, too. And Mac users who are running Alibre via Parallels might be worth it (if it is mostly mere recompilation) alone!
 

bolsover

Alibre Super User
Good point, fingers crossed these 3rd party libraries are also compilable/available as ARM64 binaries. I guess ARM64 will become more relevant in the Windows world, too. And Mac users who are running Alibre via Parallels might be worth it (if it is mostly mere recompilation) alone!
Thinking about other platforms (mac/linux), if Alibre targets .NET 8.0 or later then it might be possible to have native Alibre under linux/macos.
 

EPowIPi

Senior Member
Thinking about other platforms (mac/linux), if Alibre targets .NET 8.0 or later then it might be possible to have native Alibre under linux/macos.
That would be great! The more Microsoft transforms Windows into a data collection endpoint the more people might start to look out for alternatives.
 

simonb65

Alibre Super User
Interestingly, PDM server components use .NET Core 5.0 which is fully supported on ARM.
It's my guess that some future version will use .NET Core 5.0 (or maybe even later version) but I'm not about to hold my breath waiting for it!
PDM is the main part of the Alibre ecosystem that really needs to be multi-platform. It should have been spec'd for Linux and Synology/QNAP NAS build distrubutions from day one! Just developing a server application ('service') on a windows platform, that is primarily supposed to be hosted on the same machine as the client as is so last century and not very enterprise friendly! I'd be interested to hear the rational behind the current thinking and where the architecture requirement actually came from (i.e. customers or dev?).
 
weldments toolbox (weldments is early stages right now so don't quote me but that's the goal)
Weldments! Does that mean multi-body solids? I always found that the best way to design weldments.

We all know the #1 requested feature is to be able to run scripts from a toolbar though...right?
 

stepalibre

Alibre Super User
Weldments! Does that mean multi-body solids? I always found that the best way to design weldments.
The assembly constraint system, part catalog, configurations, toolbox, 3D sketch environment and other core systems would all need updates for a true weldment design workflow.
We all know the #1 requested feature is to be able to run scripts from a toolbar though...right?
This might be easier with the UI overhaul.
 

Max

Administrator
Staff member
Weldments! Does that mean multi-body solids? I always found that the best way to design weldments.
Don't know the answer to that yet. In reality, weldments is early stages and whether it makes it into v29 or a follow up is unknown. There's a lot to figure out, multibody or assembly approach included. Once we have a direction, we'll be able to be more explicit.
 

stepalibre

Alibre Super User
Don't know the answer to that yet. In reality, weldments is early stages and whether it makes it into v29 or a follow up is unknown. There's a lot to figure out, multibody or assembly approach included. Once we have a direction, we'll be able to be more explicit.
Weldments?
Parts can have multiple lumps(bodies), which are referred to as pieces. The API has enough topology information exposed to build a multibody addon or tool. AD wasn't designed for multibody therefore features such as design explorer providing the edges, faces and vertices collections and other features like check part can cause user confusion in the context of a multibody design. Lumps(bodies) automatically merge when they touch making a combined piece. Multibody is an abstraction on top off single body or whatever the API calls it. A multi-lump Alibre part when exported is the same result as what Big CAD produce just without internal attributes/settings.

Multibody has nothing to do with weldments. When you say weldment that could be a separate environment like sheetmetal, a Weldment tab on the ribbon in parts and/or assemblies or a plugin like Frame Builder. To add multibody, Boss and Cut features would need to support it. They currently don't support pieces(lumps).

When you pattern geometry those are pieces (lumps/bodies).

1739414382153.png
1739414358476.png

Sketch tools would need to be updated to support regions, that would allow you to make multiple bosses or cuts by selecting regions in a single sketch. The way check part, properties and other features work would need updates:

1739412880882.png

AD doesn't leverage lumps, so how would a multibody system work, what would be different? Is it a new kernel/framework, lib/extension or are lumps getting promoted? If the current tools were updated and expanded to include more complete unified workflows these continuity issues would be resolved. AD API is missing many core features as it is, adding multibody and/or weldments, will these new core features have an API? If more and more new features are added without API access or updates what does that say about the API? Both API and scripting are clearly 0 on the roadmap. I guess that's how it has always been. With Windows 10 end-of-life approaching among other tech. building with Alibre is a step backwards. After the UI overhaul and .NET transition by v32, a 3rd party developer ecosystem might be available (if AI hasn't taken over too much). I understand, if the company is focused on UI and codebase transition, that leaves little left for 3rd party development which is built on the core. Some updates for API and Alibre Script users would be great.
 
Last edited:

Max

Administrator
Staff member
Slow down, Stephen!

I'm really not sure how to respond to your post. I said we don't support multi-body modeling today (as the term is traditionally used in the context of modeling strategies) and you point out the ways in which we do not currently support multi-body modeling, so - I...agree? And I don't know the answer to how we might or might not do it - as I said in the post you quoted - at this time.

Our API has historically been consumed by a very small percentage of customers and then larger partners - so while we do put some priority on API completeness, we also rely on requests to signify where that effort should best be spent. So, if you have specific requests for the API, just send them to me (not here, in this thread).
 

stepalibre

Alibre Super User
Slow down, Stephen!

I'm really not sure how to respond to your post. I said we don't support multi-body modeling today (as the term is traditionally used in the context of modeling strategies) and you point out the ways in which we do not currently support multi-body modeling, so - I...agree? And I don't know the answer to how we might or might not do it - as I said in the post you quoted - at this time.

Our API has historically been consumed by a very small percentage of customers and then larger partners - so while we do put some priority on API completeness, we also rely on requests to signify where that effort should best be spent. So, if you have specific requests for the API, just send them to me (not here, in this thread).

Yes we agree, I was explaining Alibre currently has features that are similar to a multibody workflow that can be expanded. I know you said it's in early stages right now. If the API was more complete this would likely increase its use. Many interfaces and methods are incomplete, which is different from them not existing at all. If Alibre's API is user driven, it will never have parity with the GUI because most users don't use the API. They don't use the API because it's incomplete and difficult to use. Because it's difficult to use users don't know what to ask for to even get started. You don't add and update the API because only a small percentage is using the API... You see the cycle? The API needs to be utilized and actively maintained by Alibre developers as new features are added to the GUI, to add it to the public API. That's the only way the API will ever get close to having parity with the GUI. There are many ways to generate the public API or structure the internals of Alibre to enable automated creation of AlibreX.
 
Last edited:

Max

Administrator
Staff member
Yes we agree, I was explaining Alibre currently has features that are similar to a multibody workflow that can be expanded. I know you said it's in early stages right now. If the API was more complete this would likely increase its use. Many interfaces and methods are incomplete, which is different from them not existing at all. If Alibre's API is user driven, it will never have parity with the GUI because most users didn't use the API. They don't use the API because it's incomplete and difficult to use. Because it's difficult to use users don't know what to ask for to even get started. You don't add and update the API because only a small percentage is using the API... You see the cycle? The API needs to be utilized and actively maintained by Alibre developers as new features are added to the GUI, to add it to the public API. That's the only way the API will ever get close to having parity with the GUI. There are many ways to generate the public API or structure the internals of Alibre to enable automated creation of AlibreX.
I hear you, but I disagree that the reason most people don't use the API is because there isn't 100% parity. 95% of our customers are simply not developers, and neither want to nor are capable of using it. That being said, of the people that want to use it and are capable of using it, depending on what you want to do, there can certainly be roadblocks here or there. It's just a tradeoff on our end of spending time satisfying the 5% by doing "completeness" in the API without clear indication that someone wants a specific thing.

Our product is vast and when you suggest complete parity, that is actually a monumental undertaking. As well, its inarguable that some things in the API will be way more used than others. Our existing API is not trivially implemented - people can and have made fully integrated FEA addons, CAM addons, etc. with it. I do have no doubt that some things that you do are not available - which is why being specific about your needs will be helpful when we eventually deal with the reality that time and resources are limited and we need to focus our efforts.
 

VECDESIGN

Senior Member
I have attached one of the most complex designs I've ever created using Alibre to relax the discussions. The primary challenge was utilizing Alibre for this project, but we managed to achieve our goals. I agree that if an API is offered, it should be comprehensive and regularly updated in tandem with the GUI.

Regarding the term "multi-body," I'm uncertain of its exact meaning. Could you please provide a clearer explanation? What significant improvements are anticipated with this feature? In my experience, Alibre's current approach of treating multiple closed surfaces as bodies, combined with boolean operations, hide/show functionalities, and configurations, offers considerable flexibility. I've never felt the need for additional capabilities in this area and can't envision a scenario where enhancements would lead to substantial cost or time savings.

However, I believe that improving certain features and addressing existing issues are essential steps in the roadmap to enhance the software's capabilities, reduce modeling time, and prevent crashes. The asymmetry of the attached parts and molding constraints make these some of the most complex designs I've worked on, and I don't see how multi-body functionality would improve them.
 

Attachments

  • HL.zip
    1.3 MB · Views: 35

Max

Administrator
Staff member
Multibody modeling is a big topic - it may be most instructive to simply google "Multibody modeling CAD" and watch a video. But at a high level, it's like having an assembly open where you're really in a part workspace and can access each part all the time with part modeling features. You can designate individual geometry within a part file as a separate entity. It can dramatically speed up certain kinds of workflows, or confound them, depending on your skill and the required task.

And the video is super cool. Could you share that model with us?
 

stepalibre

Alibre Super User
Thanks Max for you time. One way to provide an update to API/Scripting in the meantime is to create a mechanism to allow Alibre Scripts to run from a menu/toolbar as mentioned above.

I have solutions for running Alibre Script scripts out of the addon, but a built-in system/tool is always preferred:

 
Top