I’m very much aware of this.
Which is why “render api will solve it” post are slighly irritating (similar “coming soon” statement that never realize fully with other projects have happened, where people are overoptimistic promising near future changes).
Find someone who can continue the render api work
currenly the SVN is missing some files and I can’t compile all of it… I can… well, except for plugins 
which makes it entirely useless. (and I can’t develop the plugins since… they dont compile)
Well… i think oogsnoepje has a good point here…
As i first went in contact to the 3D world of Blender (some 8 months ago…Dgeeeeee), I was surprised by the number of open-source projects sharing the same goal.
I mean, i dont know Wings 3D at all, but if i were in the position of its main developper, i think i would join the Blender team and share the good points of Wings with them…
The same for Yafray etc…
At the moment, while it is OK to use the exporters like Blendigo, Blender to sunflow etc,… one can only dream of this little menu (where Yafray is available) offering Internal, a good rock-solid non-biased renderer and 1 or 2 Full GI renderers, ready to be used without the hassle.
Besides, wouldn’t a better integration to Blender be productive for these stand-alone renderers ? I mean they would take advantage of a huge community, maybe by having their own setion in the forum f.i… This would mean more feedback, and may bring up volunteers to help out. (I wish i’d choosen to learn programming instead of violin-making…:()
Thanks for mentioning this. I heard rumors of this before, but I wasn’t sure of they were just that… Rumors
I never said that Yafray or Yaf(a)Ray weren’t good. I think they’re both very good and have served the Blender community well. Still the question remains… Yaf(a)Ray, Where is it? Why can’t I download a binary? Can I load it onto Linux and OSX? Is he just going to get tired of it and abandon it? And so on and so on.
So you’re saying that Blender shouldn’t support ANY internal 3rd party renderers? I guess that’s fair. Maybe with the new API you may be spot-on.
Well truthfully… Yes I did. I meant remove YafRay and replace it with SunFlow. Sorry if I wasn’t clear.
I choose SunFlow because it’s OpenSource just like YafRay. I know some of you listed Kerkythea and Indigo. Those are great, and they’re free but they are not Open Source.
I hope no one whips a non-smoothed, non-subsubsurfed, sharp and pointy iconoshpere at my head for suggesting this, but if the new API will open up the Blender better to 3rd party renderers, maybe Blender Internal should be removed as well??? I see it this way… Make Blender Internal an External Renderer just like the rest. Make it conform to the same APIs as the rest. That will have several improvements…
1: The code for the renderer will be separate from the Modeler making for quicker, less confusing development of both. (Less Bugs??)
2: Developers can focus more on either the Modeler or the Renderer. Blender users won’t have to wait for an upgrade of one because the upgrade of the other is stalled.
- The Renderer will still be open source and will conform to the new API so it will help serve as an example and maybe even a tutorial for anyone wanting to add support for any other renderers.
Bad Idea? Good Idea?
Yafray hasnt updated in far to long. And its just not compatable enough. It doesn’t support so many image textures and you can’t use nodes.
Perhaps it would have been better to say: Yaf(a)ray is being developed now, and it’s the only renderer that’s actually meant to support Blender as its main input-target (as far as I understand). It has great GI solutions, the current available materials are more useful than ever, and I’m sure there’s lots to come if more developers would join the project and if Matthias continues working on it (I would definitely name my firstborn after him if he would do so!).
Still the question remains… Yaf(a)Ray, Where is it? Why can’t I download a binary? Can I load it onto Linux and OSX? Is he just going to get tired of it and abandon it? And so on and so on.
I can imagine he would get tired if everyone would keep saying that. It’s kind of a self fulfilling wish. Anyhow, you can find test builds for Windows at the yafray forum, it’s in the news section afaik (topic title was something like “latest testbuilds”).
but if the new API will open up the Blender better to 3rd party renderers, maybe Blender Internal should be removed as well??? I see it this way… Make Blender Internal an External Renderer just like the rest. Make it conform to the same APIs as the rest. That will have several improvements…
That’s what the plan was, but like you could read, it seems to have become vapor until someone (or the original coder) picks it up again…
the render API is just a matter of time i think…
even if the original coder doesnt pick up his project… an easy way for adding external renderers is something Blender cant really go without, seeing as Blender is all about customisation and lettings users add stuff.
so… if not 2.50 (i’m sure that version wont get it) then maybe 2.60 ! 
Maybe they can even make the internal renderer into a seperate project, so people wont have to wait that long untill added features get released, i’m sure the speed wont change in any way. hell… it might even speed up
As said, there is no binary because at the moment Yaf(a)ray implementation is experimental (but fast evolving).
Removing the internal renderer would be a false choice.
It gives very unique results and has a clearly visible and attractive “style”, especially for cartoon, or other “unrealistic” scenery.
It is not like, just because photorealism becomes easier it is the only way to go…
I know many renderers, and if I had some more abstract render, I would choose Blender internal over anything else…
I pity you for having such a shortsighted vision :ba:
(Which can also be read in a rude or more friendly way)
Nnnnnnnnnnot really. I don’t really care either way, but just for your benefit, you’re now coming off as colorful while evidently trying to cover for your previous one-sided abrasiveness. Don’t worry though, most of us don’t really pay any mind to whatever it is you’re trying to come off as.
Well, I’m also at fault for not making myself clear. I meant to say that none of the renderer integration suggestions truly need to imply the destroy the existing Yafray support. New efforts to integrate Sunflow or any other renderer don’t really need to dump that other part of the existing codebase. Now nobody needs to be offended, see?
Which is why “render api will solve it” post are slighly irritating (similar “coming soon” statement that never realize fully with other projects have happened, where people are overoptimistic promising near future changes).
Find someone who can continue the render api work
Sorry if discussing the render API irritates you, that’s not my intent. It’s just a good idea, and it works towards making Blender an universal platform for users of all of those juicy renderers. It makes sense in many ways: it allows for niche expansion, more artistic choice, more inter-community integration – not to mention it makes Blender more likely to be integrated in new and existing production pipelines.
Yeah, forgot about those ^^
I meant official libraries of course 
Yes, think fair not to favor one or two renderers. With the new render API when/if it is finish, all external renderes (that have been installed) will be as easy to acess as Yafray is today (if I have understand everthing correctly) anyway.
But I don’t agree with about making the internal renderer external. Blender needs a reliable internal renderer that always will be supported no matter what. We can’t only put our trust in 3rd party projects, that often only has one developer (just take a look what happed to Yafray…)
IAs broken said, I really hope the original coder or someone else can continue work on the Render API, it’s needed…
he didn’t say that he wouldn’t like to have it, he, i know for sure, would love it the most in here, of all the people…
he just said that he becomes irritated when people say things like: “the render api rewrite will do this and that” even though the render api rewrite has become vaporware… 
I should clarify. It’s not fair or accurate to call the Render API ‘vaporware’. Aaron has done a reasonable amount of work on it, including spending a lot of time researching the requirements from other renderers, working out a good API design, and doing some coding too. If you want, you can go and get what exists of the code currently from SVN, it’s there.
The thing is just that it’s not finished, and still will need a lot of work to become usable and production-ready, and I hope this work can be done before too long.
I have SOOO been waiting for his renderer. He was talking about doing some GPU acceleration with CUDA as well.
Blender internal being “vaporware” ??? huh
the only two things I miss are better AO (smoother) with color bleeding
and some better real GI solutions.
With that I think Blenders internal would be very very useful.
The blurred reflections, anisotropic shaders, fur and hair, texture baking and and and …
I like Inigo but many Blender features are just not supported …
What do you actually miss? I had the same opinion before I experimented more with it but right now, I think it’s very useful already and I don’t really miss anything, even though there is “only” a script.
I use it as well for rendering stills.
the problem is that basically you can only bring mesh over to there and UV coorinates.
Nodes and compositor etc are all gone when you use externals.
I would love to see Blenders internal to be more complete because together with the Node system Blender would than provide a complete and powerful solution an all in one.
the discussion was about “render api” not about blender internal.
I would start taking render api seriously if and only if all files are provided to make it compile WITH plugins. currently it just doesn’t work. at least for me.
yeah, i actually know that, sorry, used the word “vaporware” for the lack of a better word in my mind at that exact moment… :o