EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: bostonman on November 30, 2020, 03:32:54 am
-
I don't do programming, but was talking to someone recently who told me all 3D modeling software (even high end) is programmed in Python.
My believe is that Python is more for scripting and wouldn't work well to create 3D software packages. I'd assume software is written in C, but then again, C is quite the low level.
-
No, there is no real 3D software written in Python. That would be a total nightmare to maintain.
Blender uses Python heavily for scripting and implementing minor functionality, but the core code base is all pretty low level C++.
-
Idunno about that. I once used a (budget?) 3D field solver (so, 3D modeling of the problem is a core function) that apparently was written in... Python on top of Java or something? It was weird.
Mind, I'm at best only disagreeing with your first point. Likely the second is absolutely true -- it... wasn't the easiest to use.
I'm sure there are games written with or around it, there's certainly PyGame, Python for Unity, etc. How much of such games count as "written in Python" is an open question: maybe it's simply used for scripting game logic, maybe it's used for mid level implementation (but 3D primitives are provided by the base engine and therefore implemented in C++ or whatever), maybe it's the whole thing. And in the latter case, you can still argue whether the libraries are written in something else; though for something like PyOpenGL I'm guessing it's just a wrapper for base OpenGL (as provided by OS/drivers) which would be pretty low level as these things go.
Games aren't usually "modeling software" but I would argue that there's at least a few with features that could be described that way. For example, character creation, or level editors.
Tim
-
who told me all 3D modeling software (even high end) is programmed in Python.
you probably met someone who keep wandering on the street. ask him what is OpenGL and DirectX and how to interface them to programming language, if he cant answer, dont trust what he said.
-
I don't do programming, but was talking to someone recently who told me all 3D modeling software (even high end) is programmed in Python.
My believe is that Python is more for scripting and wouldn't work well to create 3D software packages. I'd assume software is written in C, but then again, C is quite the low level.
I would guess that this person has seen some type of API on the 3D software that allows some automation of the tedious stuff or perhaps some data translation from MOCAP, motion control, etc, etc.
-
Some CAD software use Python for scripting. FreeCAD is a well known example. In FreeCAD, lots of functionality is implemented as plugins, which are written in Python. And in some CAD software, Python (or some other language) may be the only way to interface with the user. CadQuerry and OpenSCAD are two such examples. However, I don't think that it's possible to create an efficient CAD software using pure Python only. I believe, most of them use geometry kernels written in C/C++.
-
It's possible to do, and it's possible to hammer in a nail with a chainsaw if it's the only tool you've got and you're really determined to do it. I don't think any sane person is going to try using Python for that though. It's a fantastic language for quickly throwing together scripts to do all kinds of stuff, but it's not particularly fast from a performance standpoint.
-
but it's not particularly fast from a performance standpoint.
no computer programming language is near fast enough to do 3D rendering even C/C++ nor assembly... they need to access GPU HW, through OpenGL or DirectX API. Python can do this i googled there's OpenGL library for it. just provide OpenGL with 3D data, where to draw and ask it to draw thats it, OpenGL will do its magic finding whats available or not in GPU HW. slow programming language like Python will come short when there is specific editing/manipulation to the 3D data thats not available in GPU HW, like what AutoCAD/Inventor/Solid Work or probably Blender do. so yeah, python will not give good experience when it comes to complicated operation, but for just rendering some 3D object, about any languages that have access to OpenGL/DirectX including python can do the job.
-
Even for GPU rendering, you still need to move the data around for VBOs/VAOs. And that part still takes CPU time. And additionally inconvenient part is that it must be packed before being sent to the GPU. So you are either forced to re-pack Python objects before sending them to the GPU, or manipulate C-like types directly. This defeats the point of using Python.
-
You can use any language to do 3D, as long as you can get it to do the appropriate API calls into OpenGL or DirectX or something.
But yeah python is a bad choice for it. Doing 3D usually involves moving around huge amounts of data so always the more performant languages such as C++ are used. Yes OpenGL takes care of the rendering for you, but you still need to feed it the huge pile of triangles, texture data, maps etc.. and all of that needs to be loaded/generated into memory by the host language. Quite a bit of computation could be done there too when preparing the data such as calculating surface normals in order for lighting to work correctly, manipulating vertices for animation on every frame..etc
But i wouldn't be surprised if a CAD tool uses Python as a scripting language to automate some of the high level features.
-
Autodesk Fusion 360 uses Python as its scripting language.
-
Autodesk Fusion 360 uses Python as its scripting language.
huuu that made me grin from those LISP alternatives...
Alas...
Using Python for 3D makes me wonder like using
a PLIER instead of a screw driver...
Results vary
Paul
-
but it's not particularly fast from a performance standpoint.
no computer programming language is near fast enough to do 3D rendering even C/C++ nor assembly... they need to access GPU HW, through OpenGL or DirectX API. Python can do this i googled there's OpenGL library for it. just provide OpenGL with 3D data, where to draw and ask it to draw thats it, OpenGL will do its magic finding whats available or not in GPU HW. slow programming language like Python will come short when there is specific editing/manipulation to the 3D data thats not available in GPU HW, like what AutoCAD/Inventor/Solid Work or probably Blender do. so yeah, python will not give good experience when it comes to complicated operation, but for just rendering some 3D object, about any languages that have access to OpenGL/DirectX including python can do the job.
We had 3D rendering for many years before GPUs existed, even realtime, I remember playing games like Wolfenstein 3D, Doom, Duke Nukem and others back in the 90s. GPUs brought a huge leap in image quality but you certainly don't need one to do 3D rendering.
-
yup doom and quake is fine. you can do bitblit and integer trick in C back then, but not 3D surreal of today's standard..
-
My day job is graphics programming, so I'm pretty much knee deep in some of this stuff. Most of the high performance rendering engines are developed exclusively in C++. Especially games. Most 3D modelling software are also written in C++. That's not to say Python is never used for 3D applications. In fact, lot of the academic communities use Python to perform 3D computations, and in some cases piggyback on hardware accelerated libraries.
-
Classic discussion pattern, not limited to 3D work, you see the same in many areas, such as neural networks:
"Python is used to do X"
actually means:
"Python scripting is used as a front-end to configure a thing (written usually in C, C++, asm, plus VHDL/Verilog) to do X".
Basically this means, you write 100 lines of code that puts the wheels of the 1000000 lines-of-code professional piece (definitely not in Python) running.
And Python's definitely a suitable language for this.
Then you can say: "I program AI", and people who don't understand it will be proud of you, including your mom, dad and a potential employer (HR droids or a "I have never done anything myself" middle bosses).
And I mean, there's nothing wrong with that, if someone else has done all the work for you already then just use the existing solution.
-
Siwastaja: I agree 100% with you.
"3D Software" can mean a lot of different types of aplications.
If it means 3D CAD/CAM software, then it is certainly developed in C++ for performance reasons.
A CAD software is composed of essentially 4 modules:
- Kernal
- Database
- Graphics
- GUI
The Kernal is extremely complex and to process the huge amount of data, only C++ can be considered for this job. Imagine what it means to calculate any operation on a CAD model (wireframe, surfaces or solids). For example if you take a group of surfaces and calculate a complex multi-radii fillet with a second group of surfaces...
Again, the Database needs to be robust to handle the data of thousands of entities. Most of our customers are plastic injection moldmakers and file sizes of a regular project varies between 100MB and 500MB. Some get much bigger than that! That is a single file/project.
Graphics: you need to calculate a meshed triangle shell to send to OpenGL/Direct-X. Again this is a huge calculation effort and you need to communicate directly with the drivers. This is so complex that special graphic cards are offered (the nVidia Quadro series, for example), which have specifically tested drivers!
GUI: this is the frontend to the user. Again it is normally using some industry standard like Windows Forms or WPF. No need to confuse a professional CAD operator with some weird GUI. This GUI may then offer some ways of automating the job:
- keyed commands (AutoCAD users still love to type the commands or their abbreviations instead of clicking menus)
- macros
- API for .Net or other programming language environment
The last two items (macros and API) is where Python *MAY* come in action, like in case of Fusion 360.
Personally, I dislike the choice of Python. While it is certainly powerful, it is in my opinion NOT that easy to learn if you are not coming from an IT/programming background. Visual Basic is much easier for typical CAD/CAM operators to learn - this is what i have experienced in the last 25 years! Want a bit more difficult? Why not go directly to C#? Some GUI's in CAD/CAM application use a C# as their frontend.
Also, Python has a serious problem in a commercial environment: You cannot (as far as I know) protect whatever program you developed in Python. As a service company I don't like to develop automations for customers that can then reproduce my source code without me having any control over it.
Python is probably great for nerds to write quick hacks or within an academic/open source environment. In a commercial environment I have serious doubts.
Regards,
Vitor
-
Python is probably great for nerds to write quick hacks or within an academic/open source environment. In a commercial environment I have serious doubts.
The entire back end of the company I work for is written in Python. Bigger tech companies like Amazon also have a ton of Python. It's very heavily used in test automation scripting too. The customers access the software via the web front end, they don't have access to the source.
-
Not only that, but some package managers for the C++ ecosystem is written in Python. Conan comes to mind. It's used professionally everywhere.
Also, Python has a serious problem in a commercial environment: You cannot (as far as I know) protect whatever program you developed in Python. As a service company I don't like to develop automations for customers that can then reproduce my source code without me having any control over it.
You can. Python can be compiled in to a binary.
-
I might have been a bit rude when stating "Python is probably great for nerds to write quick hacks". Please apologize.
Python can be compiled into a binary, but as far as I know, not in the context of macro scripting for CAD applications, which is what I was referring to.
Regards,
Vitor
-
Blender at blender.nl ?
Blender is a very very nice 3D program, thats written in ways that enable everything to be scripted in Python, it seems. Its also FOSS. However, there are commercial add-ons for it that are not FOSS, which are licensed to individuals, they must use a different license. They seem to have successful business models.
If what youre saying is that you can't copy protect Python code adequately, not in a legal sense, rather in a practical one, as in cant obfuscate it maybe- that might be true. As its mostly text+whitespace.
[Edit: discussion that was possibly overreach removed]
-
What is licensing has anything to do with this discussion? Please do not derail one more thread with your political nonsense.
-
I think that the issue is not Python, but the words used.
All software was programmed in a programming language. But some software, can be programmed in a scripting language different from the original source language used when building the software.
Examples:
-EDA software (Xilinx, Altera, Synopsys, and others ) can be programmed/automated using TCL.
- Open OCD also can be programmed in TCL
Python is a language (like TCL) that can be embedded in an aplication:
https://docs.python.org/3/extending/embedding.html (https://docs.python.org/3/extending/embedding.html)
3D software that uses Python as a scripting language: Blender (already in this thread), Maya, 3DS Max
So, I think that your friend really wanted to say: "-All 3D modeling software (even high end) can be programmed in Python."
As this is EEVBLOG, one example of a very used software that can be automated/programmed using Python is GDB:
https://sourceware.org/gdb/current/onlinedocs/gdb/Python.html#Python (https://sourceware.org/gdb/current/onlinedocs/gdb/Python.html#Python)
-
I too think there is a serious language issue here. What do we mean by "used"? I am not nitpicking at all, because it really is very important. Let me elaborate.
In practice, current applications, games, and simulators that produce 3D visuals, tend to have the following parts. (Note that this is as general as possible, so others will definitely disagree on how the different parts are best separated. For this discussion, however, I believe this kind of separation is most useful.)
- Graphics Engine
This constructs and manipulates the data structures that describe the objects and environments visualized.
- Physics Engine, including Game Logic (optional, relevant only to games and simulators)
This handles the interactions between the objects and environments manipulated by the Graphics Engine.
Typically, the Physics Engine works in small time steps, often much shorter time steps than the visual update rate.
In Games, where you have independent actors (non-player characters, monsters, etc.) that implement their own logic – even if as simple as the ghosts in PacMan –, Game Logic is implemented either as part of the Physics Engine, or more commonly as a separate part; in many games implemented using a domain-specific scripting language like Lua or Python. Then, story developers don't have to write low-level code, and instead use that high-level scripting language with nice interfaces for telling the Physics Engine what that monster/NPC is doing. This too usually runs in time steps shorter (or at most as long time steps) as display updates.
In some cases, like the numerous monsters in e.g. Gauntlet, the Game Logic may actually implement flocking, or treating large groups of enemies as units, or as "limbs" of a single enemy. There's a lot of related research and discovery on this front, but as it is relevant to games in general and 3D, I'll not expand further on that.
- Rendering Engine
This takes a subset of the data structures maintained by the Graphics Engine – the small fraction that is necessary for displaying the current visual –, and renders (draws) it.
Typically the rendering is not directly to a visible display, but to a backing store or texture in the graphics display device memory (as opposed to generic RAM).
In the context of this post, Rendering Engine includes the mathematics of 3D projection, as well as mapping textures to surfaces, pixel shaders (that apply programmatic effects to textured surfaces), and so on.
- User interface
This is the part that responds to user actions, like mouse movement, keypresses, and so on, and acts upon them by notifying the Physics Engine, Graphics Engine, or Rendering Engine, depending on how simple the application is.
For local applications, it tends to be extremely simple. For a networked game, things become more complicated, because both the local instance of the game and the remote server must stay in agreement on what this particular player is doing, and what other players are doing. So, simple local applications can implement this part in whatever programming language they want, but real-time networked applications have this part usually written in C or C++.
If the application supports scripting on behalf of the user – often called extensions or plug-ins –, let's put that part into this section also. It is common to provide such an interface for modules to be written in a scripting language; Python is very commonly supported.
- Windowing Toolkit (optional, relevant only for when non-fullscreen)
The windowing toolkit uses the backing store or texture, and maps it to a standard window in the graphical user interface.
Usually, the Windowing Toolkit provides an event-based interface used to implement the User Interface also. However, there is no actual requirement that they are the same. For example, VLC and other media players support multiple User Interfaces in parallel (for controlling playback), not just the one provided by the graphical environment itself.
Sometimes the Rendering Engine is tightly coupled to the Windowing Toolkit (anything based on DirectX and Windows), or sometimes they are completely separate (any rendering engines based on OpenGL). So, do consider this separation model shown here as an abstract example, not anything directly applicable as-is to real life.
As of 2020, the Rendering Engine is almost always implemented in a separate, accelerated GPU unit, which may be integrated to the same chip as the CPU. OpenGL ES is probably the most widely used (because it is used on tablets and most mobile phones) standard for accessing these GPU units. On desktop machines, there is DirectX, OpenGL, Quartz. The support libraries that implement a programming interface to these – format the data structures, query capabilities, et cetera – are usually written in C or C++, with bindings (access by) other programming languages.
The Graphics Engines used in games are hot stuff, and also written in C or C++. For applications that show a single 3D object with simple lighting and texturing models, there might not be a graphics engine (or a physics engine) at all, since all data is used all the time, and the library interfaces' view transformation support suffices.
The Physics Engine is often a separate library written in a low level language, implementing all sorts of collision and damage stuff, so that moving objects don't just pass through each other – very interesting for games, and perhaps simulators, but you'll almost never find anything like it in a plain 3D viewer or editor. It can also be an integral part of the Graphics Engine. You can write a simple Physics Engine – say like Crayon Physics – in a scripting language, but for anything more complicated, C or C++ is used. Many newer graphics card support some sort of physics calculation acceleration, say via Nvidia CUDA or OpenCL, so that the fast vector math available on GPUs can handle most of this load (especially collision calculations).
Windowing Toolkit (or more commonly, widget toolkit) is the programming interface to the Graphical User Interface. There are many of these, as each operating system tends to have their own; but for portable applications, GTK+ written in C, and Qt, FLTK, and wxWidgets written in C++, are commonly used.
The toolkit itself is basically a library written in a low-level programming language, that exposes the capabilities of the graphical user interface used.
In this context, the windowing toolkit also provides the "surface" or "backing store" for the rendered visuals, and shows it inside the GUI window.
While written in a low level language, these commonly have high-level bindings to scripting languages like Python.
To recap, some parts and some types of 3D applications can be written in Python, but they'll rely on interfacing to libraries and hardware definitely not running Python.
Consider PyMOL (https://pymol.org/2/), a 3D molecular visualization application written in Python (sources at GitHub (https://github.com/schrodinger/pymol-open-source)). Its user interface (https://github.com/schrodinger/pymol-open-source/tree/master/modules/pymol) is written in Python, and it chooses the graphics backend (written in C++, corresponding to the Graphics Engine, Physics Engine, Rendering Engine, and interface to Windowing Toolkit) at runtime, based on what the Python code detects on the OS and availability at runtime.
I personally like to write the User Interface (and interface to Windowing Toolkit) in Python, because then the end users can adjust and modify that as they like, without having to have any development tools themselves. However, the logic on manipulating 3D objects (or even 2D ones) is typically implemented as a library (or libraries) written in C or C++, that the Python user interface code invokes. Thus, most of the time the processor is actually running code compiled from C or C++, and only when the user makes a change – say, at most 60 times a second – a little bit of Python code gets executed by the CPython interpreter.
If you've read this far, you'll now see why "used" is such a poor word here. Yes, Python can be used effectively to implement certain specific parts of 3D software, and is pretty often used for that. Games tend to use Lua more, though. Are there 3D applications that are written purely in Python? Well, yes, for simple viewers and such, because the non-application-specific stuff that does the most work, is written in a lower-level language like C or C++, but these tend to be very simple. Anything that can manipulate the 3D object or environment visualized will either use libraries written in a more efficient language, or be too slow to be enjoyable.
Similarly, you often see suggestions of using Python for scientific calculation, yet Python itself is not that efficient in handling large amounts of data. The reason is that there are libraries written in C and C++ and Python modules interfacing to those libraries, like SciPy (https://www.scipy.org/): while the Python code describes the operations done on matrices, arrays, etc., the actual machine code that implements those operations is written in C or C++. Because Python provides higher-level abstractions and garbage collection et cetera, it is easier for non-computer-scientists to implement calculations in Python, but still effectively leverage the speed of C/C++.
At the very core of this is the Python ctypes (https://docs.python.org/3/library/ctypes.html) module. Simply put, Python has a built-in mechanism for interfacing to libraries written in C/C++. (The other way around, embedding a Python interpreter in a game or application is also possible; but Lua is even easier for that.)