full rewrite is an interesting challenge and a clean solution, maybe the better way we could hope for, but I suspect there is absolutely no man power to perform it in a reasonable frame of time, and I mean a couple of years or so…
if not, hire a team of developers that can physically meet, make a roadmap. set milestones, and code it. in one go. like 10 people really smart on C and maths.
I think thou, like. you could learn from other OSS projects there are many open renderers out there.
full rewrite is an interesting challenge and a clean solution, maybe the better way we could hope for, but I suspect there is absolutely no man power to perform it in a reasonable frame of time, and I mean a couple of years or so…
And that what i’m saying that should be done in a separate branch, and without time constrains. IMHO, is better to have a full and well thought solution that serves all well than to try to fix an somewhat outdated engine.
With that said, i’m in no way saying that the present engine is BAD by any means. Just see the works from the Durian Team, the BBB and Elephants’ Dream, the works in Blender.org, Endi, Michalis, RobertT and you can see the engine is powerfull on its own. But AFAIK and read in many posts and blogs, adding features and attempts to make improvements to it can be somewhat of a challenge, and that is BAD, IMHO, for developers and for users.
2 cents again on the table.
BBB, Durian, ED all those follow a similar rendering style and this reflects what Blender can render.
It is simple as that. After month of testing and evaluating the RenderBranch the amount of limitations in it made me just to forget about it. If you all you need is a simple one bounce indirect lighting with basic material color based color bleeding than it is fast and good - while complex scenes can drastically slow it down.
For everything else Blender has nothing to offer.
What concerns me is that Ton says that funding is less an issue then finding coders suitable for that task.
I simply have to realize that I lead mystudents onto a bad track with Blender because in the past 4 years it did not evolve onto a level it has to be to be taken serious in the product and object rendering scene.
It just cannot compete with any other engine out there when you step out of your toon corner.
Blender has some cool bells and starts here and there but the most important part the render engine is just outdated, half complete and not able to compete.
As cool and fun the compositor is nobody is going to invest their time in it when first setting up a GI looking scene with Blender takes ages, the rendering is slow, and the end-result is not comparable.
A great compositor cannot make up for that lack.
I feel that the recent years in terms of features for animation, effects, and UI were a success.
I am sure that many people were and are impressed with how far they pushed the software.
Bur everybody who works professionally in a heterogeneous environment where different render styles are needed and has that experience will quickly notice that Blender internal just cannot deliver the needed tools.
I hope Ton might be able to get a system setup where development can grow and be secure to work on Blender weakest part, the render engine and push Blender out of the corner of what the movie projects needed to more what 3D C field define today - diversity.
That he has money but no coders concerns me a lot.
I am not sure how far code and directions can be borrowed and be used inspirational from other open source engines.
When even one man projects can deliver better GI results this must be somewhat possible.
I am sure it will be a hard road but I am more convinced that this is an essential step to do.
Otherwise Blender is pushed into a niche it can exist in.
In my point rendering is more important than a compositor.
If you can have a compositor with limited render capabilities or no compositor with decent render capabilities I think last one will rather be usable for most people who need better internal rendering qualities and just switch to an external engine.
The only options is to wait till the VRay exporter is complete or the Yafaray exporter with the Yafaray builds are complete. Till they are not fully functional it is a no go.
That would be such a wast since I always found that Blender has so many things to offer compared to other products. But maybe this were too many and dev time was stretched too much accross everything.
I might sound bitter and I am not dissing Blender as a good 3D tool since it is a great tool for specific needs.
Just based on my 6 years of experience with it and at the same time with other tools and trying to promote Blender
gives me the feeling of defeat now.
Seeing that last reply I would say this.
Unless you: Letterrip, plan on bringing a legion of developers to work on the BI renderer, why even try to work on it at all? Why not just have Yafaray or Luxrender developed so that all features that BI had are in those renderers and have the exporters read everything from the node trees to the particles?
The 2.5 method of rendering in an external engine is fairly painless and easy, and having Lux and Yafaray still means that the whole rendering part is still free and open-source.
Ace Dragon,
I’m trying to find out what artists ‘really want’.
I do think that better integration of external engines is one way to go, and might be the best way.
But then you have to deal with the contingency of having to work with the development goals of another team. ie. As Yafaray doesn’t handle multi-pass render (as far as I know) and so, it implies that a total use of compositing nodes isn’t possible.
Moreover, if the BF needs some particular features for the next open movie, will they have to deal with Yaf/lux code,create an alternate branch, or finally work again on internal and so making the whole focus shift to external renders pointless?
On the other hand, I have nothing against a better integration of Yaf/lux, and a better render API, but a total shift to external engines also implies its own problems.
If this problems can be handle really more easily than improving BI and if an external render (which one btw?) can be integrate as it can provide a shader/material tree inside blender (seems possible with Yafaray, as the maya exporter handle it, and also with Lux, as it was in their goals for the exporter), take use of particles, modifiers,etcs, feed the compositor nodes with multipass as efficiently as BI… Then, why not?
LetterRip
regarding what Ton says this seems to be the case. But would then all those BI only functions still work?
Such as the smoke engine or volumetric rendering. I feel it got so good that it is a pitty that with the last element rendering this good it all starts to fail when non-toon results are required.
Well VRay is VRay and it is integrated into quite many 3d packages.
Mental Ray has a shader coding and compiling engine but from my experience VRay is a snap faster.
If VRay is used so much I am sure there must be a way to get most things particle, fur, materials, textures to get translated into the vray shader equivalent.
But would that also work for Yafaray since VRay isnt really cheap.
Steaph
I agree with you - which is why for external engines I would promote VRay since that is a pretty complete engine or MentalRay since it is node based and could support Blender incase it would have a node material system fitting MRays nodes.
I’d rather this community support Lux and Yafaray more than Vray actually if we want to promote a quick and painless pipeline that’s completely open source and free.
Lux for example has a modern codebase and looks to have a solid enough foundation to add a large number of new shading features, they already have a good variety of GI algorithms and then a large number of ways to do sampling.
Yafaray is good too, now has SSS and is getting an exporter developed for Blender.
Vray could possibly support everything BI does plus GI, but it’s commercial software and would mean you don’t use open-source software from start to finish. (with the likely exception of your texture making program)
I do think that better integration of external engines is one way to go, and might be the best way.
Hmmm… Probably. Of course that means to talk with the other developers to have some common efforts to make things work in sync… As far as i remember and i know, Radiance tried that, and failed. (Well… if weren’t for that, we never would seen the born of Octane). Also there’s the case with Crystal Space…
The best you can do/guarantee to do is to write good exporters, but if i were you, i don’t bet on support for features that blender offers (compositor, secuencer comes to my mind). But the best is to try talking with the yafray/lux guys.
For what artists want, should be pretty obvious that a clear consensus will never be achieved. That’s why (if you analyze the competition) every software out there offers different options that results in different results that adapts to the need of every kind of artists.
You have: (and i will be pretty generalistic here)
- Artists that need the toon approach (BI serves well this segment, Yafaray/Lux/similar is useless here)
- Artists that work in fantasy settings and need to tweak for fantasy. (Ditto.)
- Artists that need the realistic approach (BI is not practical to use, you can get realistic results, but need some big effort and lots of time to do this, not counting post processing and color grading; Yafaray and Lux are good alternatives here).
- Artists that need full photorealistic approach (BI is useless, Yafray/Lux requires some work to get results here, but not much).
- Artists that need to combine live footage with 3D renders (BI requires a big ammount of effort to produce acceptable results, Yafray/Lux idem nowadays. Maybe OpenCL changes that when arrives to yaf/lux)
- Artists that work in Architecture/Design (BI is not suitable, unless is used for sketching ideas to the client, not final designs; Yafray/Lux Rules here.)
- Animators (BI can serve well in this area, but is slower and lack some key features (That not everyone uses, but the big boys will cry foul if these aren’t present (GI, caustics to name some); Yafaray/lux can be usefull/useless depending if realism is needed or not, Renderman based approach works here).
- Artists that want a free clone of <Insert your favorite commercial 3D appz here> (Go away)
So is hard and complex to make a solution that works for everyone. But you have an advantage: The source of Blender/yafray/lux are open, so you don’t need to reinvent the wheel and so, the ideas and algorithms also are open, so the problem is mostly reduced to implementation/make it work with the features Blender has to offer, and the external renders don’t.
The problem is not really complex, but tricky…
You speak out of my heart - besides toon and fantasy I feel Blender is cable to do anything comparable.
I followed the OSS since I started undergraduate and that was when Blender was still with NaN
and the big break through I hoped for never happened.
The way how things are right now is just that BI cannot compete - period.
"So is hard and complex to make a solution that works for everyone. But you have an advantage: The source of Blender/yafray/lux are open, so you don’t need to reinvent the wheel and so, the ideas and algorithms also are open, so the problem is mostly reduced to implementation/make it work with the features Blender has to offer, and the external renders don’t.
The problem is not really complex, but tricky…"
This what I am curious about. I also agree on that it is sad that Blender and external render engines were not able to find a ground to work together.
Ace my issue or lets better say fear with external engines is this:
First what if Blender and the render engine team cannot find a common goal.
As radiance case shows cross software collaboration seems not to be so easy.
I in case would be a coder of a 3d render engine would be happy to make it into Blender or improve BI.
Secondly what happens when key figures for the external engine cannot work anymore.
Pixie for example is well in a vegetative state.
Having a stable engine developed for blender might be simply more secure.
Luxrender absorbed the blow that came when Radiance left the Luxrender development scene and now the project goes on with new leadership. This shows that the stability of that project is more stable and is able to take punches more than other open source projects.
That is actually not what I was referring to.
There was an attempt to combine resources and brain to focus on a common product goal instead of everybody going there own way.
Many products come and died in the past and that is just sad to see.
I am not implying that Yafaray or Lux are going to die.
You remember Kerkythea? It offers basically everything Yafaray and Lux can do in one engine.
Yes, but that doesn’t means that it will ever be the case, and moreover, doesn’t implied that the Lux developers will be
- ok to shift the lux development towards being the Blender “official” engine
- or let Blender coders work on it.
All depends of finding a common ground as cekuhnen says.
Totaly agree, perhaps more complex, but less tricky imo.
BTW I am happy that for Lux things can continue since it is a fabulous engine
and their Smal LUX GPU is very promising.
Other engines actually were not so fortunate when key members left.
Cough cough such as Brecht …
- ok to shift the lux development towards being the Blender “official” engine
- or let Blender coders work on it.
I wasn’t trying to say that these two points need to be the case, it’s perfectly fine that Lux is a completely external engine that is able to serve all of the common 3D applications (including Blender) and is being done by a completely different development team.
His name is Steve Worley, is the creator of the lightwave plugin called Fprime, and old but super fast interactive render, this plugin is from 2004, much more before than octante render, hypershot, luxrender (gpu) and many others interactive renderers. Actually is very active member of a CUDA forum so he knows very well how the CPU and GPU renders works, and he can provide an extremly performance into the render areas, I’m thinking… if brecht gets hired for Refractive Software why the foundation cannot hire a good developer from another company?, why not hire him even if it’s only for a couple of months? he is an extremly talented developer and he can provide a big push to blender’s render. Ton said several times that there’s money to pay more than one developers, so I think this would be a good suggestion.
P.S: check the fprime videos/features:
http://www.worley.com/E/Products/fprime/videos.html
P.S.2: His nick is “SPWorley” in the CUDA forums.
Well I can see that they would not want him to work anywhere else so he does not help
a competitive product. Simple as that.
The company has his name, maybe he is the owner of the company. I think they should try to contact him at least, if you don’t try you don’t know.