There is an effective method for performing a complex task: to break it down into a series of simple operations!
Initially, I wanted a 3D drawing function without a library like OpenGL, starting from scratch, with one goal: to understand and master the process for creating elevations and sections, for example.
I obviously expected lower performance. And I’m discovering that this may not be the case. I expect to have a basic 3D engine in a few weeks. Then, later, I’ll be able to complete it and test its performance.
In the previous weeks, I’ve been able to code many solutions, which I’ve been able to test independently. I have almost everything, but I need to work on the error-free assembly of all these functions and the overall logic.
Here’s some initial code from scratch, from a year ago, displaying two simple volumes and allowing to test 3D interaction (click precisely on the volume and get a precise position on the geometry).
I worked on other projects, then I revisited this example. These 600 lines of code were rewritten, improved, transformed into a library, and other things were added or improved. The current focus is vector hidden-face rendering.
Note that my comment was ‘tongue in cheek’ but there was also a chance you were doing the same thing as I was (procrastinating). In my own case I would either leave the task being out of boredom or mental fatigue. It often made for more work.
These days I’m pretty focused and have a real reason for coming here (asking tons of questions).
Right now, I have a heavier workload, so I’m moving more slowly (but steadily on this project), which is ideal. I spend as much time documenting what I’ve done, and making diagrams as I do programming. For example, I had to identify the parameters so I wouldn’t get lost! But it’s very interesting, and there’s definitely room to improve the current possibilities for 3D vector drawing.
That’s not wrong! I’ve been caring for a dependent relative for over a year and coding definitely plays a role in avoiding procrastination : )
Using existing APIs is what everyone does, and it may seem unreasonable not to. It was even essential 20 years ago when it came to 3D.
As I told you previously, the goal was to understand and master the subject in order to further experiment with the drawing we need in architecture. It was also to have a 3D environment to experiment with 3D modeling and transformation algorithms.
Now that I’ve passed this stage, I’m discovering that there are advantages to this situation that I won’t go into detail about. There is one advantage I can tell you, though: not relying on third-party developers allows for a more compatible, more stable, and considerably smaller application.
That’s not all! While optimization work is required, the speed of our machines today is very exciting. Currently, it’s developed in Python, with the fewest libraries possible, and the most standard libraries. The code is as standard as possible, so that it can later be translated into C/C++.
Python, in theory, is 30 times slower than compiled C/C++ (like Ruby). The code is already fluid and fast for all the algorithms I’ve developed (3D visualization, modeling, parametric, etc.)! If I continue to make it smart as possible and it produces very good results in Python, I can therefore hope for even more power in C/C++ (between x 8 and x 30 times).
…
On this screen image, we can see the interaction (in red) with the 3D drawing better than on the animated GIF, integrated into the 3D engine, which allows you to locate a point with a dimension, for example.
An example of an algorithm to support the 3D engine: managing holes in a face using a special (invisible) triangulation, necessary for a vector (and not rasterized) result. Tested in 2D in March.
I had to re-familiarize myself with Revit recently. I remember everything thank god. But I really don’t like the program. I think what has happened to it (like almost every 3D software currently in existence) is that they keep piling bad code on top of bad code. They can’t improve nor fix even the simplest features now.
All of these programs were basically either started by a single individual or a small team. Back when these programs were first started software development wasn’t where it is today. Visual Studio didn’t have half the features. Frameworks weren’t as good… apparently… yet so many projects got started. I’m sure many failed but that doesn’t explain why nothing new is appearing in today’s space. Especially for programs that can model architecture.
Learning AutoCAD was pretty simple. The inner workings of the program were completely beyond me until I learnt the API. Now I can see that it’s not that complex. The GUI’s and many features are actually brilliant in spite of being created many years ago. The text editor is still ahead of pretty much every other software (AutoCAD clones are copying it with mixed results). I think it’s impossible to upgrade because nobody is good enough to re-build parts of the code. Relatively simple bugs from the user’s end would require huge amounts of man hours to fix internally.
Getting to my point finally… I’ve heard that as software grows, it becomes exponentially harder to both expand the software and fix issues. This goes up by orders of magnitude if things aren’t coded well (which is usually the case due to deadlines, fatigue, pressure, bad managers). And my point being that I guess I see why starting from scratch is so enticing. The ceiling is so high.
Commercial software tends to become as you describe, for the reasons you mention, but not only. There’s also marketing that pushes to add irrelevant features, leading to development that isn’t sustainable in the long term. Very often, ergonomics aren’t given much thought. And the users’ interests are no longer those of software firms and resellers…
Regarding the exponential problems that arise with software evolution, I’ve already encountered that, and it’s been very well resolved so far with method. I would have failed a long time ago without method. It can be restrictive or make the project stimulating and enjoyable, and it is.
That said, it remains a real question if you look at the evolution of most software. There are several reasons for this problem, such as the evolution of technologies, usage patterns, and, of course, development methods, as well as the reliance on third-party APIs. I hope to do better…
What you describe in Revit and AutoCAD is a poor overall approach to development, a concept that is running out of steam.
We need a strong, revolutionary concept, like SketchUp was in its time.
I still use SketchUp and Layout, but I don’t invest any time in them anymore.
I’ve made a few connections outside of the forum with people I’ve interacted with here.
It’s also very interesting to see how choices made in previous years have evolved.
Totally agree with a lot of what has been said here.
I’m still hanging around this forum. Even though I don’t use SketchUp as much as I used to, I still find it really interesting. SketchUp had such a different approach when it came out, simple, intuitive, and fun. Watching how it has evolved (and sometimes struggled) over the years is kind of fascinating, especially if you care about how software is built and how people actually use it.
I’ve used a lot of different tools, and I’ve seen firsthand how software tends to get more complicated and harder to maintain as it grows. Not unique to SketchUp. This it just part of how development works. A lot of helpful people particitate in this forum community, people who actually use the tools in the real world, and I really value that perspective. It helps me think more clearly about my own work and the tools I rely on.
So yeah, I guess I’m still hanging around because I still care. I like seeing how things are progressing (or maybe not), and hearing how others are tackeling the same kinds of challenges. (Even though I can’t get my own 3D engine started properly). It’s a way to stay connected to a interesting conversation about design, tools, and the weird paths software takes over time.
Just my thoughts out of the Box.
Let me give you a simple example of a revolutionary concept between programming and user experience, specific to SketchUp when it was released (and up until now).
Without thinking about it, you naturally draw on a volume or an invisible background, depending on your view. This already existed in other software, but it was as complex as having to create or modify a “construction plane.”
However, achieving this principle naturally and automatically is extremely simple; it’s just a few lines of code. You can calculate the perpendicular vector from any face or with the axis system. Then you simply compare it with the view direction to determine the most “natural” plane facing the user (I even have the impression that there is something even simpler).
There are also more sophisticated algorithms behind SketchUp’s simplicity. I assume this “natural” plane principle was more or less linked to the SketchUp patent (mathematic is not), because during its validity, it wasn’t seen anywhere else. Recently, we’ve seen this appear in other software with significant improvements to the UI.
And in the late 1980s if you wanted to do CAD on a PC, the machine needed to be fitted with an expensive display list processing (DLP) card to get anything visible on your screen. That was vector-only. Residue is still in AutoCad vector hatching and those single-line SHX fonts.
Interesting insights into these past solutions that allowed vector output, but with poor performance.
While vector computing is in principle much more complex, there is, however, a difference from that era: today’s machines are much faster, and they have much more memory, which allows for more data, processing, and a greater number of algorithms. And therefore, a different approach is needed.
