I think there is more to it than that, but not sure on the details. The reason I think that is because CPU mode is faster for me than GPU for cycles because my video card sucks. But even on CPU it renders in 3-6% of the time.
My guess is that it is optimized and designed for raytracing, where BI was not. Cycles probably does some interesting caching and octree stuff that BI does not. I haven’t looked much at the Cycles code or the BI ray code though, so just guessing. The scary part about the cycles code is they have separate branches for different hardware. So they have to update/add things in many places which may have very different language, to take advantage of GPU for example (CUDA/OPENCL)
I think this really have a place in Blender. Mostly cause we (game developers) are without any GI solution for Bake.
We can ignore many concerns about time of render for Bake if we remember the fact that when baked this maps can be refined by bilateral blur and wavelet denoise. even a low sample is enough. This don’t work so easily with a rendered final image.
Nice work
I have been doing a lot of tests comparing this patch to the renderbranch actually. How on earth they rendered Sintel on that is beyond me, it’s filled to the brim with bugs and inaccuracies.
That being said it it much faster than your branch though, by a number of times. If your patch can be optimized to be even half as fast as the renderbranch then I think we have a winner.
Also about the softlamp patch. Sorry but I don’t agree with you there, BI was never intended to be physically accurate. It was made for you to have full control over your render, which I think that patch fits perfectly. I don’t mind my renders being physically correct but it is the final look that matters and if I need to break a hundred laws of physics then I want the ability to do that.
Thanks a lot for your hard work on this patch but I like both of them and I would like the option to use them both in production.
And the GI inaccuracies in the render25 branch was only part of the issues that the artists had to deal with, remember that they were using unstable alpha software that did not yet have all of the features developed during the Blender 2.4x days. (The idea was getting 2.5 alpha production-ready, but even that didn’t get it all the way which was seen in the betas and ultimately 2.59).
When I tested the render25 branch, I was forced into using the more inaccurate bumpmap shading because the full shading was plagued with black dot/NaN issues, even worse, a complex SSS material can’t be rendered because it would render as black. I never really did get any real good results out of it.
Though I didn’t quite recall the render25 branch GI being that abysmal (suggested by the image even I do recall of people talking about a yellow-tint issue), all I know is that Cycles can do it much better.
It is in fact incompatible, I had to recreate my super complicated scene from scratch to test it. Did you have anything constructive to add to the conversation?
My guess as to why it is slower is because the renderbranch is not doing the right thing. It is very likely shooting rays and only sampling surface color on the ray-hit surface rather than calculating lighting + occlusion and any other expensive shading routines.
As mentioned, I think it could be sped up, I’m just not sure it would be worth it over maintainability. Especially in under-maintained code, I’d hate to give more reasons for people not to do any more dev in there. Though if I add toggles to make it not calculate shading on the ray-hit samples, that would go hella fast.
It’s a tough call though for BI, few people would indeed want to see the BI source code become messier, but there’s also not a lot of people who would like to see BI’s raytracer become slower (because it’s already slow in areas like glossy reflections and can nearly grind to a halt if blurry refraction is added on top).
Anyway, the raytracing code would need a lot more changes if it was to become not only more maintainable, but faster to boot, some people may end up going to Cycles permanently if baking support for that engine is added, but there’s always going to be some demand for the legacy rendering features that do not use raytracing.
What is non-constructive here is your severe case of NIH syndrome. Your evaluation of the Render Branch based on a single test render in a build of unknown origin completely misses the fact that many people have used that branch and managed to get good results out of it. Despite its unfinished state, you should at least be curious about why it gets the job done so much faster. Its source is still available for review: https://svn.blender.org/svnroot/bf-blender/branches/render25/
I fail to see a case of NIH here. This did not previously exist in any form, which is why I wrote it. Perhaps you would prefer I do not contribute back to the community. If you don’t want it, that is fine with me, I will still use it and get my art looking prettier than yours much faster, until there is a better solution which gives the kind of accuracy that I demand. If other artists here do want it, well, they will and have made their voice heard.
Defending a piece of software based on some piece of art that was created with it is not a good argument. You can get pretty images from just about any software if you spend enough time doing it with the right talent. The point is that good software allows those same artists to push the art further. Artist time is much more important than CPU time.
The Render Branch build does offer some semblance of Indirect Lighting because there are colors bouncing around which are related to nearby objects. Of course you would have to fine tune the bounce factor and add bounce lighting where bounce isn’t as strong as it should be. And you must do this by hand instead of just getting a good result the first time. Sorry, but I can’t afford the extra artist time, and if I could, I would rather they spend their time on art rather than overcoming technical issues.
Besides all these points, what kind of artist would complain about a GI system which is not only bake-able, but also matches Cycles? Slow or not, show me another tool that does this.
If for some reason you don’t want to see my implementation get into Trunk, make a good argument for that case. I am fine if it does not. (Though I think having a slow indirect lighting feature which can be baked is better than not having that feature. Speed can always improve.)
I’d like to reiterate my advice to get into contact with the actual Blender developers. If you want to take over responsibility for improving BI, I’m pretty sure the code is yours to take over, so long as you maintain compatibility. Nobody else wants to work on Blender Internal, especially because it is so hard to make changes that don’t break things.
One thing that has been mentioned quite a lot (by people involved with development) with all these discussions, is that stakeholders are supposed to have the say what is and isn’t acceptable for development. Hearing out all the opinions on the forums generally leads nowhere. It is my impression that, in order to get code into Blender, you need to take over such a stakeholder role. Otherwise, your patch will most likely just lie around, pending a review that nobody has time for.
I’m not totally sure I want that responsibility at this point. I don’t mind making changes here and there now that I have an idea of what the code is doing, especially if I need the functionality in my own projects (like this patch.) But outside of that criteria, I don’t have a ton of time to clean things up. Do you know what the other big requests are right now for BI? aside from being slow and not as pretty as Cycles and not having shader nodes?
Joining in on what Zalamander says. Most likely you’ll get better feedback from the developers that can’t be bothered to spend all their time arguing on the forums.
Speaking of which, please don’t get emotional over lighting solutions. It’s not worth it and it’ll murder the constructive nature of the thread.
Edit: GI was the main thing. I think getting emmisive lights to work properly was amongst those(they don’t cast shadows in main releases). Other than that theew was the BEER thread(ask uncle_entity about this, he has some code lying around), cage-baking(ask dfelinto about it), and antialiasing on baking. There’s a lot of mention of shader rewriting in the bugreports and mailing list, but I can’t seem to find actual plans.
I’ve spoken with past devs about it before and the general consensus is that to get BI modernized and up to acceptable speeds it would almost be easier to start from scratch since large chunks of it rely on code that has gone unchanged for decades. In fact, this is exactly what Brecht did. I believe that there is a market for a nice biased render engine inside of Blender, but the more and more I look into things, the less I think that continuing to hack options on top of the existing BI structure is the answer. When compared to a truly modern biased option like Thea it’s really incredibly sad to use, and any real attempts at breathing new life into it will totally break compatibility which pretty much guarantees that it will never be in trunk. Maybe with 2.7/2.8 they would allow some larger compatibility destruction, but that still means there would need to be a dev willing to tackle the project.
I think that the best option would really be to strip it back to its core and start Blender Internal Plus or Blender Internal 2.0. Technology has just come way too far since BI was created to dream of creating a modern biased renderer out of it.
@m9105826, could you elaborate on the issues that make you think it’s the core that needs rewriting? Because I see a lot of coders comment similarly, but I never hear them bring up any points. And just going into the BI code hardly allows one to see the big picture. It would be nice to hear people discuss the weaknesses of the BI code more openly.
I never said or implied that I would downvote this feature. I would not do that even if it was totally useless to me personally. I downvote only if something is seriously broken or about to break something else.
Sorry if my suggestion to look into render25 for possible speed improvements upset you. I just logged into the projects site and voted for inclusion.
I think the reason why there is little progress in Blender Internal is because it is trapped in some sort of catch-22. Every time someone suggests to add or change a few lines of BI code, people start talking about BI’s complicated code base and how it needs a total rewrite or at least a stakeholder to take over and run the whole dog and pony show, and eventually the thread grinds to a halt and drops off the screen. Rinse, repeat. It is about to happen here, it happened in the softlight thread and in the BEER thread and probably countless times before that.
The reason why there are BI patches lying around forever in the tracker is because few people bother to actually go there and vote for the things they want to see in trunk. There were at least eight users expressing their +1 for raytraced indirect lighting in this thread, but when I looked up the patch in the tracker, the number of votes there was zero. It’s not surprising that BF developers don’t spend their time reviewing patches that collect zero votes, and we should not expect external developers to approach the BF before their patch has received a reasonable minimum of feedback in the tracker.
The stakeholders of BI are its users. BA is the proper place to discuss a patch, but the blender.org patch tracker is where your votes should go.