What's new

2025 Roadmap

EPowIPi

Senior Member
New year, likely new Alibre versions on the horizon :)
Could the Alibre team give us any hints which areas the upcoming V29, V30 etc. versions will focus on? I guess bug fixes and further PDM polishing for the next version? And perhaps some convenient or even groundbreaking new features in other areas on the midterm roadmap?
Just curious where the voyage is heading towards!
 

Stu3d

Senior Member
Maybe new user interface...
 

EPowIPi

Senior Member
Did they announce that they switch to an annual release plan? Thought two-three releases per year were more the norm than the exception in the past? So more "imminent" than "way off"? (My irony detector might not be fully adjusted yet ;) )
 
Last edited:

Max

Administrator
Staff member
High level is:

Next dot release - Mayish - big upgrades to fillet tool, "real threads" option in the thread tools (for 3d printing), likely the standard parts library will be done
vNext - end of year - total UI overhaul product wide, and a weldments toolbox (weldments is early stages right now so don't quote me but that's the goal)
 

UGMENTALCASE

Senior Member
High level is:

Next dot release - Mayish - big upgrades to fillet tool, "real threads" option in the thread tools (for 3d printing), likely the standard parts library will be done
vNext - end of year - total UI overhaul product wide, and a weldments toolbox (weldments is early stages right now so don't quote me but that's the goal)
Oooo weldments toolbox? What could this be? :)
 

Ex Machina

Alibre Super User
High level is:

Next dot release - Mayish - big upgrades to fillet tool, "real threads" option in the thread tools (for 3d printing), likely the standard parts library will be done
vNext - end of year - total UI overhaul product wide, and a weldments toolbox (weldments is early stages right now so don't quote me but that's the goal)
Oh my GOD, that f*ing exciting!!!
 

EPowIPi

Senior Member
Good idea to make fillets even better. Definitely a weakness of FreeCAD that is more unlikely to improve any time soon...
 

WillAdams

Member
As a person who is still learning, my request/recommendation on the UI would be one which doesn't require a mouse --- a major stumbling block in my usage is that in order to have easy access to a mouse I have to work at my desk in the basement.

By way of comparison, I was able to work through the initial tutorial for a new opensource tool, Dune 3D fairly easily: https://github.com/dune3d/dune3d/discussions/118 since it has a UI which makes use of gestures on touch screens/trackpads.

Yes, I realize that this is yet another indication that I should break down and try Moment of Inspiration, but I kind of blew my discretionary software budget on Plasticity, and I crashed-and-burned trying to learn it as well (I think my license is good for updates through v3, so maybe I'll try again later). In the meanwhile, I'll keep working w/ PythonSCAD, which at least programmatically makes sense to me.
 
  • Like
Reactions: tyc

EPowIPi

Senior Member
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!

1738229696208.png

Edit: Found this: "
Visual Studio 2022 natively supports building and debugging Arm64 apps on Arm-based processors. However, if you build your app with the AnyCPU setting, which is the default for most .NET projects, your app will run on an Arm64 device using x64 emulation. While this may seem counterintuitive, this approach allowed many apps with x64 dependencies to work reliably under emulation without requiring additional build or dependency changes.

Unfortunately, under these conditions, it means your app won’t benefit from the native capabilities of the Arm64 CPU and may suffer from reduced performance and increased battery consumption.

To solve this problem, the Windows 24H2 update introduces a new setting for your app manifest files. This setting allows you to specify a list of supported architectures (currently amd64 or arm64) for your app, indicating that it should run natively on those platforms. For example, if you include arm64 in the list, your app will run using the Arm64 CLR on Arm64 devices when supported, even if it was built with the AnyCPU setting."

 
Last edited:

simonb65

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!
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!
 
Top