> This is the main difference... and the reason why there is so little crossover
It's definitely _a_ reason, but not the only reason, and I personally wouldn't consider it the main reason. I used to be a mechanical engineer and now I work in software. Every day that I fire up solidworks for personal projects, I wish for exactly the kind of tool you described in GP. But the thing is, I wouldn't say that the choice of modeling kernel technology is the crucial point here. Frankly I think that the most fundamental problem is a complete lack of understanding between the two worlds.
In the MechE world, once you start talking about fabrication, manufacturing drawings and tolerances are really your bread and butter. This is such a profoundly basic thing for mechanical engineering, and yet completely absent from the kinds of modeling tools you see in video games and VFX. This is just a tiny example, but the real point, again, is a lack of shared understanding between the two domains. I mean... how would you go about capturing _design intent_ in one of these script-based tools? Even for something as trivial as drilling a hole in a rectangle, how am I going to know which corner to use for locating the hole?
As a MechE, your "source code" isn't the geometry you design, it's the history tree that lead to that design. It's the constraints and relations that you used to build the whole of the part. And I don't think that most people that work on software projects in this space have an appreciation for what that really means.
Don't get me wrong, CAD kernels are a hot mess. At every step, it's like you're basing the next function's source code on the compiled binary of everything you've written up to that point. It makes absolutely no sense. But it is, as of today, the closest analogue to how most MechE's I've talked to actually think about building parts. But I think that starts to get at the fundamental disconnect: people with a software background look at that and think, "surely something like CSG would be better; it makes things so much easier to compose". Whereas people with a MechE background look at these kinds of tools and think "ain't nobody got time for that." They're both right and they're both wrong.
It's definitely _a_ reason, but not the only reason, and I personally wouldn't consider it the main reason. I used to be a mechanical engineer and now I work in software. Every day that I fire up solidworks for personal projects, I wish for exactly the kind of tool you described in GP. But the thing is, I wouldn't say that the choice of modeling kernel technology is the crucial point here. Frankly I think that the most fundamental problem is a complete lack of understanding between the two worlds.
In the MechE world, once you start talking about fabrication, manufacturing drawings and tolerances are really your bread and butter. This is such a profoundly basic thing for mechanical engineering, and yet completely absent from the kinds of modeling tools you see in video games and VFX. This is just a tiny example, but the real point, again, is a lack of shared understanding between the two domains. I mean... how would you go about capturing _design intent_ in one of these script-based tools? Even for something as trivial as drilling a hole in a rectangle, how am I going to know which corner to use for locating the hole?
As a MechE, your "source code" isn't the geometry you design, it's the history tree that lead to that design. It's the constraints and relations that you used to build the whole of the part. And I don't think that most people that work on software projects in this space have an appreciation for what that really means.
Don't get me wrong, CAD kernels are a hot mess. At every step, it's like you're basing the next function's source code on the compiled binary of everything you've written up to that point. It makes absolutely no sense. But it is, as of today, the closest analogue to how most MechE's I've talked to actually think about building parts. But I think that starts to get at the fundamental disconnect: people with a software background look at that and think, "surely something like CSG would be better; it makes things so much easier to compose". Whereas people with a MechE background look at these kinds of tools and think "ain't nobody got time for that." They're both right and they're both wrong.