Blender future...

[rendermagic]

The stripped Blender idea was discussed here : viewtopic.php?f=13&t=7505

Hmm...I missed that thread somehow. Glad you referenced it here. I had a chance to read it and I think there's a lot of merit to a 'stripped' down version of Blender. Perhaps forking Blender wouldn't be too bad.

Carrying a long Blenders comprehensive 'modelling code' as baggage, however, just to suit Lux Render, is probably not ideal. Focusing on the renderer is probably a better use of our limitted resources.

For those that wish to continue using Blender as a 'modeler', there shouldn't be any difficulty in continuing to use Lux as a their preferred render engine. The idea of a 'Lux Studio' really solves any potential disruption of workflow.

I don't know if anyone has pointed it out already, but Blender's explicitly says they're not a coder's API (http://wiki.blender.org/index.php/Dev:2 ... IParadigms)

Blender is a tool allowing artists to create content, and not a coders API!

I got thinking about what it would take to develop a 'Lux Studio' application to add to the 'Lux Suite' of programs. I've worked on GUI centric projects before and it's really a pain in the neck if we continue with the idea that we should be 'cross-platform' friendly. There are other tools out there that make it slightly easier, like QT, but even they have their limitations. I think we can all agree that Blender has a really nice library of GUI widgets for their controls that could make development of a 'Lux Studio' much easier.

Perhaps forking Blender, stripping out most of it's modelling pieces, non-essential pieces, and beefing up an API is probably a better solution than the alternative: remaining tethered to Blender or developing a Lux Studio from scratch.

Imagine how the devs at Yafray are feeling about Blender devs, not to mention other FOSS render devs that integrate with Blender. Is there a chance that any of them would be interesting in a collaborative 'Studio Scene Builder' that is compatible with their scene files? Perhaps an effort such as that would make the migration slightly easier to envision.

[hedphelym]

There are a few that has this "studio" solution.

Maxwell - http://www.maxwellrender.com/index.php/maxwell_render_suite
Arion - http://www.randomcontrol.com/arion
octane - http://www.refractivesoftware.com/

I know we might not have enough coders now to create our own, but
my personal opinion is that it would be much better with a standalone app for luxrender (or integrated into luxrender the way it is now) and use this.

The main thing with many of many open source renderers is that they are mainly focused on Blender.
And this is the main reason why I stay away from a lot of open source projects, simply because it's too focused on blender.
Either that or I sit down and help out creating 3dsmax tools to enable us to use it with that.

I know blender is free, and that other apps are expensive and so on,
I've been working with animation and real-time 3d for 6 years now in one of the biggest oil industry companies, and throughout all my years
I have yet to see a high-end company that uses blender in they daily work, we all use 3dsmax, houdini, maya and so on.

The nice thing with all these apps (incl blender) is that they all export out to common formats.
So by creating something a "luxrender studio" then all of a sudden "everyone" can use it no matter what app they use for their models.
The threshold for learning how to use it is suddenly much lower, the exporters are not needed, the time spent developing that will be less.
new features can easily be implemented without needing to update all the different exporters and so on..

[rendermagic]

I think I may have been unaware that Arion and Octane had studios. It's been a long time since I looked at those two programs. Someone is welcome to correct me on what I'm about to say, but I thought I remember at some point I couldn't import common geometry (like STLs or PLYs) into their applications and/or I couldn't transform the geometry in the scene. If one were capable of importing and transforming geometry into a Lux Studio application, I think hedphelym is correct. We wouldn't need to continue developing the various exporters. Further, for those that have helped develop the existing Lux exporters, it would be interesting to know if their domain knowledge of the various software packages out there could make it easier for one to 'easily' open a a 3dsmax file in Lux Studio.

I know blender is free, and that other apps are expensive and so on,
I've been working with animation and real-time 3d for 6 years now in one of the biggest oil industry companies, and throughout all my years
I have yet to see a high-end company that uses blender in they daily work, we all use 3dsmax, houdini, maya and so on.

I have to agree with you about that.

I know it probably is already implied, but I can't stress the importance of making the idea of a 'Lux Studio' project API friendly. Without that, it will be far more difficult to gain commercial donations and help from other FOSS render communities (ie. Yafray). There's a strong chance that devs from those communities and a few devs from the Blender community would contribute.

Additionally, I would like to underscore the importance of implementing some sort of way of making a Lux Studio app not only API friendly, but also DLL friendly. I think it would be really nice if one could drop an executable in a folder that brings specific commercial functions to life while accessing the Lux core. I regularly face that challenge currently with my current employer that occasionally uses Lux. There's so much flexibility that I would love to commit back to the Lux community, but I can't because of the commercial interests that exists. It's clearly understandable why Lux isn't DLL friendly currently given the PBRT historic roots Lux inherited. Perhaps my thoughts might inspire that approach to begin to take shape in a Lux Studio project. Please take not offense...just re-stating the obvious .

The threshold for learning how to use it is suddenly much lower, the exporters are not needed, the time spent developing that will be less.
new features can easily be implemented without needing to update all the different exporters and so on.

I have to agree again. When I was first introduced to rendering, I looked at a lot of packages out there a few years ago. The first one I could finally get up and going and render my first scene, was on Maxwell Studio . There were obviously so many limitations, but at least I could use Maxwell to accelerate my learning curve. Once I had my mind wrapped around rendering, I began to explore for FOSS alternatives. That's when I found Lux. If it wasn't for my background learning in Maxwell, I would have never been able to spin up in Lux. Fortunately, I was tenacious and Jeanaphi was very helpful...but it still took me a good 12 or 14 weeks to really properly spin up. It's probably obvious without stating it, but most of problem was centered around trying to learn blender . And I wasn't trying to learn how to model in Blender...I already do that in a different modelling package. How do I get geometry into Blender...how do I position stuff...oh, and I almost forgot about the installation procedure etc.

I'm sure others will jump in and be able to share similar frustrations about blender.

[ejnaren]

While I basically agree on the potential of a full independent Lux-studio (although I do see the amount of development to get to a good solution is big), I too would stress that this subject is not a "Blender is evil -> we must free ourselves" subject.
It is either about improving on the lacking API of blender to support the potential of Luxrender or about recognizing the proposed, new potential in an integrated material+texture+camera render workflow in Luxrender.
The first is not the cause of the other. It is but a syndrome.

Right now blender is moving very fast and I know that the team have promised a much better render API and I believe it is coming. In time. But right now the people working on that API are in a position where they too have deadlines. (yes, like out in the real world in which they try to prove that Blender is capable of working). The open movie projects (that are a big part of the open source succes story behind blender) demands certain developments at certain times in order to complete the project on time and this pressure can limit some developments. This is just a sign that this is not a hobby business but a real world scale deal.

Further this does not mean that somebody with the guts for it (and it sounds like many here have that and are doing this) can not help in the integration of blender and Luxrender because they like using Blender. Not because Luxrender is dependent on it but because it is open source after all.

What I am saying is if people wants Lux to get out to more people and applications don't blame blender for holding it back.
In this case a modelling app independent route is a very viable suggestion.
Don't forget though that many of the developers and they community are friends between favorite apps and by sharing ideas, know-how and collaborating, building upon what is already a good foundation, these projects can go a lot further than when they keep fragmenting, splitting, forking or starting over.

Sorry if I sounded all mamma-ish. Its a good discussion and I wanted to keep it constructive and not destructive in regards to the title.

[Ze_Blob]

When I think about how many months dougal has spent on trying to get integration with the render api working I feel a measure of frustration.

We need our own modeling program that is actually FOSS, without paid devs, being influenced by people with money is the last thing we need.

Not sure where would be blender without donations and full time paid developers. What is so bad with money if it is well allocated ?

May be you should create a Luxrender foundation to gather donations and pay a few guys to improve the integration with Blender. I would be happy to contribute 30 euro, or more if i can, to help you guys to work on whatever you want (i trust you to know the current issues more than everybody else).

As some other people I would love to see some mat/texture nodes for Luxrender inside Blender, or Ptex in Luxrender. But who is going to work on this for free ?

[jeanphi]

Hi,

Let's not side track the discussion. The current discussion is not about money or Blender being evil. It's more about the fact that for a long time Blender has been the preferred integration platform for LuxRender because it was free, versatile, and integration into it was quite easy. In recent times this has changed quite a bit and integration into Blender requires a significant effort to work around various API incompatibilities (the fact that those chosen are relevant or not is an entirely different discusion). However we need to find a solution so that we can continue to develop LuxRender and test it, and having some sort of studio features would help, a more stable Blender API or concerted efforts to modify it would too.

Jeanphi

[khaos]

Hey all.

I just started with 3d modelling and Blender (Cycles/Luxrender) and I am actually a Software Engineer by day. I had to register an account, simply to post my opinion about this because I strongly feel about it. So I hope everyone cuts me some slack because I might not be totally in the loop.

In my very personal opinion, I don't think forking Blender or creating another open source modelling suite is going to solve most or all problems. Right now, Luxrender is render agnostic which is both a good thing and a bad thing. It broadens the user base by letting them choose their favorite modelling tool while on the other hand, it is a lot more work to maintain for the developers because they have to stay current with all 3rd party APIs. But at the end of the day, you guys can actually concentrate on what your product is all about: an unbiased, powerful and physically correct renderer without having to work on an actual modelling suite or maintaining a Blender fork which would all impose new time consuming problems and work.

Besides that, I don't think Cycles and Luxrender currently are in a very direct competition - if you can even call it a competition in the open source world. Brecht has always said that Cycles is geared towards animations and small studios. That's where the focus will be and as things stand now (and please correct me if I am wrong), this is not exactly the prime spot for Luxrender right now, amongst others for performance reasons. Ideally both camps should try to cooperate or learn from each other without rivalry because there is nothing to loose... only something to gain.

Having said that, what are the current problems with the blender integration? Or to be more precise, where are the problems and what is missing? What missing bits and pieces could be realized without any support from the Blender foundation and what needs some API work from their side? I believe, summing this up and writing it properly down on a wiki page and then opening up proper bug reports on both sides to keep track of the current state and its progress, would greatly benefit the developers in both camps and the users as well. I, for one, have the impression that Ton Roosendaal actually listens to their user base and wants Blender to grow into something the community wants. And if I recall correctly, recently there has been some incompatibility with the Luxrender integration and Cycles that caused a crash and was worked around by Brecht. Being on an one way street with full speed ahead looks different to me, honestly. Yet they are working on Cycles and they need to make changes to the API to fit their needs because after all, it is their new render engine... discussing those with every 3rd party plugin author would be tedious at best, hinder progress and is not really the most common approach as you can see with regards to the Linux kernel development as well.

Last but not least, I think (I know, for the xth time ) you guys should most definitely try to get more of a presence like in marketing. Update the web site more often with bits and pieces about the development, put out smaller releases more often and announce those everywhere where you can reach your target audience (not just on your own forum). And besides that, try to get into an open dialog with the Blender foundation and maybe lend a hand when it comes to improving their API (suggestions, patches, concepts)... but keep in mind, that API has to fit their needs as well as yours. I don't think they will turn down useful and constructive help.

I am sorry for this lengthy post but I would hate to see yet another project being forked because of a lack of communication and effort on both sides. Sometimes forking is a good thing (like the Xorg / XFree86 split) and sometimes it really hurts overall progress and just confuses the users or limits their choices (like all the Gnome2 forks/Unity/Gnome3/Gnome 3 forks... mess right now).

Thanks for enduring my endless chatter... and hopefully I could direct everyones attention to a different point of view for consideration.

[jeanphi]

Hi khaos,

The main issue, like I said in my previous post is that the Blender API is quickly evolving introducing various incompatibilities and we are constantly chasing those issues instead of focusing on LuxRender. Incompatibilities are often required to improve a software, but usually they are not done in the middle of a stable release branch.
Let's also note that we have tried to cooperate by making suggestions and proposing features and code for the API, we even proposed the use of our low level GPU acceleration library for Cycles, that would have helped both Cycles have broader GPU support and improve that library to meet the performance and feature levels required by both applications.

Jeanphi

[Carbonflux]

The current discussion is not about money or Blender being evil. It's more about the fact that for a long time Blender has been the preferred integration platform for LuxRender because it was free, versatile, and integration into it was quite easy. In recent times this has changed quite a bit and integration into Blender requires a significant effort to work around various API incompatibilities (the fact that those chosen are relevant or not is an entirely different discusion). However we need to find a solution so that we can continue to develop LuxRender and test it, and having some sort of studio features would help, a more stable Blender API or concerted efforts to modify it would too.

I agree, this is the core issue imo, we need a workflow bridge. It has been pointed out above in this thread and other threads that most commercial applications like luxrender have a "studio" app because it is a natural gap that needs to be filled.

I admit I am guilty of attacking blender but these discussions have helped me expose the deeper intuitions that might have been driving this visceral reaction, FOSS has always had work flow gaps in relation to commercial software, the main reason for this imo is because commercial app requirements are driven by client biased vertical market demands where as FOSS is driven by what is interesting.

Interest motivation leads to greater innovation than a market driven metric imo but in a way its auto-didactic so there are gaps in terms of the total project workflow because the application is not end product goal oriented as much as a commercial app would be because FOSS can be selective about meeting end user requirments.

[rendermagic]

I'll chime in again here...

I think Jeanaphi and carbon flux couldn't have articulated it much better. I think I/we may have misused a weighted term 'fork' which can imply a lot of negative baggage. If a fork were a solution to the current Lux problems, I doubt it would under the premise that we were throwing our hands in the air to the Blender devs and saying, "We'll show you!" It's probably more of a strategic solution that might be utilized in order to accelerate the development of a studio application for Lux.

I think Lux has one major identifiable disadvantage for those that are not already familiar with the Blender. That is, there's a very long 'spin-up' and learning curve that one must go through to really embrace the power of Lux. It's not that Lux is too complex, or more complex than other render engines in the same space, but it's actually a little more difficult to fully get working. Have a Lux Studio app will make it so much easier for newbies to use Lux.

I don't think the Lux Studio idea is anything but a solution to a current limitation. Unfortunately, as the others have mentioned here, the Blender devs have carved out a road map which makes it difficult for Lux to continue using Blender for it's "studio functionality".

I think we should continue to make the adoption of Lux easier and easier. GUIs have a great way of doing this. Following that, I think we could improve the documentation.

I hope none of previous comments were misinterpreted as being insulting to the Blender devs. I think they're all brilliant and have put together a great product for others to use. Up until recently, I think the Lux team has a done a fine job strategically leveraging that development to meet the goals Lux has. I think the motivation of Lux Studio should be no different than it was when Lux first started leveraging Blender. It's really all about allowing Lux to continue it's development as a great physically based render engine. Without a GUI, however, it's makes it really difficult for others to embrace that power. I, for one, has a very difficult time spinning up. Unless Blender would make it as easy or easier going forward, than there's probably far less reason to pursue a studio app.