What Killed Lightwave?

General Forums Blender and CG Discussions
321

Python is a remarkably versatile and powerful language. It is heavily used in applications which require heavy CPU number-crunching capabilities, leveraging toolkits like NumPy, SciPy, PANDAS, MatPlotLib, Seaborn, Jupyter and many others. There is nothing “slow” about Python in these applications!

Also it is very popular as an extension language in many open-source apps, not just Blender. It is instructive to compare Maya and Blender in their adoption of Python: one just introduced a straight transliteration of its existing rubbish scripting language (MEL), while the other integrated it completely into the entire app, making every object in a Blender document directly accessible as a Python object, behaving according to common Python idioms.

2 Likes
322

I recall seeing a YouTube video just some months ago where it seemed they never figured out how to use quaternions to animate armatures. So you were prone to irritating problems like gimbal lock, which all the other major 3D apps have solved by now.

Couldn’t figure out the maths, perhaps?

323

Yes indeed it is, easy to learn relatively, easy to implement, very versatile and indeed powerful. However its not the best language to use depending on what you are doing.

I dont know of any app or addon outside of Blender that does fluid dynamics, granular solvers or any other really heavy computational work that uses python. Now i may be wrong and im quite open to being proven wrong, but Fume, Phoenix, Turbulance, Ice. Maya, Softimage XSI, C4D, 3DS Max and such all have fluid dyamics systems and not one of them to my knowledge runs on python.

Yes its a great language and is a must for all 3d apps, just look at all the addons on Blendermarket, most of them are python, but it is not always the best language to use.

Most of the addons we create inhouse are in C/C++ or MelScript for the low level ones. Yes we had and do indeed still have python and its great to use, but not in all cases.

https://www.activestate.com/blog/python-vs-cc-embedded-systems/

https://www.reddit.com/r/Python/comments/6vpv2t/how_slow_is_python_who_is_it_slow_for/

1 Like
324

To the best of my knowledge addons that perform simulations or other processor intensive tasks (such as flip-fluids) do not use python at its core. Python is however used as a bridge between the simulation code usually in C/C++.

These sort of addons do not usually just call functions from blenders python api. There are usually for tasks or areas where blender (or the software) is weak in. For instance, you wouldn’t create a procedural particle system addon in python exclusively (by calling blenders api functions) or your addon would at its core be limited by blenders particle system.

This is why addons of this nature are more costly. Some addons or plugins are basically like writing separate programs from scratch and then linking them to the software. Example, X particles for cinema4d, even flip-fluids for blender.

1 Like
325

The point was long since made that python is not used to create full on plugins that alter or add to the core capability of the source code.

There is not any reason to keep arguing the validity of having python in Blender, nor the reason it is used by thousands of people to create useful add-ons for the community.

The difference between python and let’s say a scripting language for LightWave - on topic - is that more people are familiar with python.

And this is why other apps have come out in support of it.

If you want a more heavy lifting feature you go to other languages. Just like you do with any app.

Blender is no different than any other app in this regard. Additonnally you can go at the source code and create a fork.

The power of Python is exactly that it is universal and easy to use. And it gives us a wide variety of add-ons that offer functionality in areas that do not require heavy lifting.

I don’t think there is much else to be said on this.

And it is not a valid criticism of Blender in any way.

It is a non issue.

1 Like
326

Yep, compiled languages will almost always be faster than scripting languages. Scripting languages have to be interpreted and this slows things down in the process. There are advantages and disadvantages to both and each has their place for sure. :slight_smile:

1 Like
327

BTW One thing lw and modo do right is to have an growing amount of example scenes, done by the community, to learn from… Yes blender had them sporadically in the past, and even has some complex examples aviable, but(in my opinion) for a newbee, these are often too complex and do less focus on a specific feature itself.

I think such a call for content would not be a bad idea for blender too.

328

There is far more free content overall for Blender. I would say also of a superior quality overall. And also a wider variety and covering a fuller range of skills and level of complexity.

Probably in numbers 1000 to 1

Just two immediate sources. And both completely aside from the high level of professional quality and complexity of assets available directly from Blender open films. And here, very rare, you get to put your hands on assets from a very accomplished film crew. Now moved mostly to the cloud:

There have been discussions about adding content to Blender downloads. Or as an option. But the general feeling is to keep the DL of Blender simple and low footprint.

There are improvements that could be made however to the dissemination of resource links during the download process or on a splash screen. I am not sure if a decision has been made regarding this.

But clearly your post shows that a higher awareness of what is available is needed.

329

Well, interpreted languages don’t have to be slower than compiled code - there is such a thing as JIT compilation and I certainly wouldn’t mind seeing it in Blender. Perhaps then we could have Python modifiers and such. However, nobody has to my knowledge produced a JIT Python interpreter. I’m confident someone will eventually produce one though, seeing how popular Python has become.

1 Like
330

What killed LightWave?

Here is something to think about. Interview with Andrew Cross. 30 minutes long. Talks on and on and on about video, tricaster and all kinds of streaming stuff.

https://miro.com/app/board/o9J_kxUuxUU=/?moveToWidget=3074457346765077224

Someone asks him about LightWave and he laughs nervously. Gets rather cagey and careful. Won’t really make any announcement. Can’t say anything. He might get into trouble saying what he is going to say. But… there is something fantastic coming for LightWave. No details no hints. All hush hush. But it is going to be something wonderful.

Kind of waiting for some kind of stream-of-consciousness abstract, ominous and surreal Stanley Kubrick ending.

So just put this into perspective for a moment. This is NewTek. They owned LightWave.

It is their product. And so is all of the streaming stuff and video stuf they do.

Within all of the hours of talks this guy gives about streaming and video technology, he can’t say one word about LightWave. Not one word. They won’t talk about LightWave.

But oh, they have plenty to say about the TriCaster and live streaming.

I don’t think you have to take this too far to see that, well. There is your answer.

Sure, there will be people who well say… “oh… but the situation with LightWave is completely different…”

But before you go on down they rabbit hole of justification. Think about this.

NewTek created this situation. They are themselves responsible for creating a situation whereby they can not talk about it anymore.

It is not the developers fault. There is no one else to blame, when time and time again, the same thing keeps happening.

NewTek completely bungled the whole thing. And you can look at how they handle themselves in the PR world with the other products they have that it is clear, they had no idea what they were doing with LightWave.

Did a fine job with video streaming though. Got bought up by a company who is a leader in this field.

1 Like
331

https://numba.pydata.org/ should work fine as long as you copy any relevant data to Numpy arrays or Python lists first and don’t call any Blender specific functions inside the Numba block.

There’s also of course PyPy, but that would require replacing the entire Python pipeline.

332

Sure there is a ton of stuff out there, but for getting into a feature, some smaller scenes would be helpfull, like the eevee car scene in the blender download section: Nice looking not that complicated, easy to disect. Also for older features, it would be helpfull.

Its all about the “where do I start after I installed blender”…sending these people of the net to find their stuff on their own, adds to the frustration factor. (imho)…

Even a link to the blender cloud for learning purposes on the download page would be a good idea.

And no, this shouldn’t be included in the blender download. Look at modo, they release their content separate, and beside a large file an additional smaller zip file wich only features the content of the new release.

2 Likes
333

Yeah. I agree. And there has been a lot of discussion about this too. And I am with you on this one.

Yeah, it was discussed though. But I agree it would be a poor way to do it.

The solution I like best overall is obvious links on the DL page. And then links on the splash screen.

The argument against the splash screen is many of these sites are private, and also charge money and sell advertising. But mostly that they are private and that we don’t have control if they fail or change locations etc.

So to me the best idea would be to provide existing links on the DL page. And one link on the splash screen to the Blender website that hosts these external links.

334

What about the added costs of blender.org hosting what would be a huge amount of curated downloadable content? Perhaps an API for the imminent assets manager, to search for and download assets, although the staging area would need to be curated too…

335

Unless it’s a total re-design (combined Layout & Modeler for starters, sculpting better than Blender’s, non-destructive workflow, and extensive vector export), I’ll pass.

336

Precisely. Not that we need to beat that dead horse with a sadistic vengence…lol

But… yes. Exactly the point.

I almost feel bad because it is like kicking someone who is already down.

But at the same time they brought this on themselves.

So there you have it. We know what killed LightWave and now we know why.

The bulk of the 3D world has long since moved on to modern workflows.

LightWave is stuck in a workflow developed 20 years ago

In order to save LightWave it was imparative that they do 3 things.

  1. Concieve a realistic long range plan
  2. Inform the community of this plan, and continue to update them as it went along
  3. Follow through with that plan to the end

They did not even have to have 1) right at first. But if they continued to itteraete on 1) and proceeded with 2) and 3) they could have done it.

Incredibly they failed miserably at all three.

340

It’s probably more ‘official’ than ever in 2020. Supposedly, the entire LW development team has been dispersed. So it’s probably safe to say that LW has met its demise as of this year.

341

What kill lightwave? Blender killed her :joy:
But seriously it’s luck of development , any project that didn’t develop for quite sometime it’s stay behind the competition and consumers allways want the best ,no matter if it’s free or not!

342

Thanks Steve. :slight_smile:

343

Too bad, I wonder if they could relase the source, maybe some parts of it would be nice to use in blender, althought keeping two OS programs is probably a bit redundant…