Well in all honesty LW is not dead, well not yet no matter what some may say. XSI still has a very lively following, is still very capable and professionals still use it and that is Dead.
I got into LW because personally at the time i could not afford and SGI computer and Softimage 3.8. I loved the software at work very much and then i found out that LW used a similar UI, namely words not Icons, which is what drew me towards it.
I managed to get a copy from a college in the south of England who was selling one of their seats, so i jumped on it, transferred the license and updated it to the latest version and that was a lot cheaper and in a time where you still owned what you brought.
I still use it today, renderer is still very good and i have Octane as well. Modeler on the other hand is really in need of a major overhaul and im not sure it will happen any time soon, hence i am here.
Add to that i have DeepFX, TurbulanceFD and some other stuff so LW is still capable in the layout aspect for me, i can also import stuff from Realflow, Houdini and Blender and i have Goz connection to ZBrush and also connection to 3DCoat if i had it.
The same thing many of us said about Blender a few years ago. Not the odd kid now though.
I think thatās why initially many stayed away from it. Not because it was not capable just that it always seemed to want to do it differently to most of the others.
Blender still does things differently, no layers but collections, what was wrong with layers, its the name most of these sort of software use, saving a lot of stuff in AppData, the right click select thing has gone now.
I think this has been already happening. And it will continue. It is possible in the foreseeable future that Blender could force the hand even more. This will be interesting to see.
Being an old git, it astonishes me that today, the average bod has access to some truly remarkable open source software. You can build up a highly respectable library of applications, all for free, which rival in power a lot of commercial apps. Itās hard for the ābig guysā to whine about how something is not possible, or too expensive, when open source, with limited resources, is producing that and more. Granted, not on every feature, or in every product, but as you say, it surely focusses the mind of the larger companies to take such issues more seriously. Though the larger companies, (you know who I mean), may consider just the bottom line and not the quality of development.
Thatās one thing OS has, passion for development, they build the features because they want 'em. Look at the addons, nine times out of ten, borne of a desire by the author for that feature in their own workflow. Big companies donāt have that luxury in honesty, speaking as someone who developed software for 30-odd years, I often wanted to add a feature which would of been beneficial to the user, but the bosses didnāt see the merit in something for nothing if it took me away from something else for a week.
Addons, Plugins, Scripts are in the most part pointers at where a certain app lacks features or the way the feature is implemented.
I cant remember the amount of times iāve heard āwhy do you need that, its already got itā, because its not just about what it does but how it does it.
How many fluid/fire sim plugins are there available for Max now, i can think of at least 3 or 4, sorry im not a Max user. Is it because they are all rubbish, no its because the approach and results are different.
Blender has built in fire shaders and sim, but the finished result i always found a bit lacking in the colour and such, so third party developers come in with several different answers to it. OS is what allows that and makes it easy.
Yeah two old gits going on about the choice the younger generation have, good luck to them and us is all i say, the more the merrier, the more choice the better.
One thing i do have a concern about is python. Its good, fairly simple to learn and offers a world of possibilities for the user. However as i have said before its not the ideal language for heavy computational work, its really a resource hog, not particularly fast and can rely on other stuff for it to work.
Im hoping we will see more addons in C/C++, not a coder myself really but i assume this is as possible to do in Blender as any other app.
Python has really no problem with performance as it can be just used as an intermediary between Blender and C++ or other high performance languages. Python is the most used language in Machine Learning, which requires crazy amount of computation throughput. The reason is itās simplicity and ease of use. It is used to call much more powerful library functions that do all the heavy lifting.
Only bottleneck is how fast can Blender transfer data from its own structures into Python. Currently at least image data is quite slow to access, but mesh data is already plenty fast, even if it isnāt completely direct pointers.
I wonder if the C++/C thing is more about having the code available? I dunno, though for sure the speed issue with Python is a problem. I have written a couple of small scripts I use on mesh clean up and they are really slow, I actually put output statements in them just so I know it hasnāt just hung. But at least Python opens up that scripting side of things.
Hereās the performance hit of transferring data between Numpy (a Python library) and C++: 0 (absolute zero). You literally canāt ask for more. The issue isnāt Python, itās how fast can Blender transform its data structures into either a C pointer or a Numpy array.
I donāt mean to sound negative, just want to dispell this seemingly very persistent misunderstanding.
But it is not just Blender, Python scripts in LW take the same hit in speed. Whilst a low level simple script its not an issue but something along the lines of Flip Fluids or Khaos must take a hit as they are computationally heavy.
Iām not an expert of python what so ever. I read this article with interest, it starts half way down to talk about Python.
Yes, Python is multiple orders of magnitude slower than C or Rust, which is why you donāt write inner loops with it. Most of the time you can do vector processing with Numpy, and if you canāt, you can just use C instead. Itās quite easy to link C code with Python.
If there was a direct C++ API for Blender addons I think that would be a different kind of hell, and in my opinion not an improvement. Now as things stand, itās very easy to develop and integrate various addons. With machine code, you have to juggle not just different ABI versions, but also different operating systems. Python makes all of this completely trivial.
In my opinion Python is the perfect choice. It has next to zero performance impact when being used as a bridge between Blender and other software or programming languages, and the addons can be very easily modified and shared (if itās pure Python). With C++ things get multiple orders of magnitude more difficult and complex.
I donāt see how either Flip Fluids or Khaos takes any performance hit from Python as itās used merely as a bridge AFAIK.
Yeah, all of this makes sense to me. What I am getting from this and some of my own first-hand experience with development teams is that you are not actually directly writing functionality at a code level. In other words to give an example. You are not writing the code that allows you to ācreate a non destructive Boolean between mesh A and mesh Bā. You are calling up the code in the host app that is written to perform this function. The speed of the Boolean is not based on Python but the underlying code that creates a Boolean. In a very oversimplified way of putting it.
So you get an addon such as Hard Ops which is calling up various functions, Bevel, Boolen and so on and ordering them in a certain way with a UI that allows the user to access these functions and arrange them non deductively in unique and useful ways.
Does that seem to be accurate?
By contrast a plugin such as Mesh Fusion for Modo would have had to create new non-existing code that would allow you do do things that the host app was not programed to do. And thus also would require more speed and perhaps even features python could not do.
Well the main thing is here that (simplified) thereās two types of programs: directly machine code that is fed to the CPU as is (C++), and interpreted code where the program code is run by an interpreter instead of directly by the CPU (Python).
The interpreters can include machine code libraries and their functions very easily and call those functions. Which makes running those functions as fast as ordinary machine code.
Dynamic linking just means loading machine code library into your existing program at runtime.
In practice, doing your programs in Python first and writing any performance critical code with C++ (that can be dynamically linked after compiled into a .DLL) is often highly productive workflow.
I thought we were getting on with our livesā¦ lol
Obviously you are a LW user who moved on or you could not make that statement. So I am not really going to argue the point as it would only be preaching to the choir.
But yes the character tools were one of the biggest things that were caught up in the old code.
