The main thing that I want to see improved is the Blender scanline process in which the renderer interprets photoreal lights, surfaces and shadows. We want photoreal features like Yafray but without the waiting. What steps are taking place now in this, area?

I belive when XML is crafted into blender. That will solve Trillons
of external render problems. Including Yafray

{spelling} go

Quote:

We want photoreal features like Yafray but without the waiting

Yafray doesn't render quite as fast as Blenders Scanline renderer. I have some test that I did for one of the city scenes that I'm working on. I used 26 array lights to accomplish "faked GI". I will post the render if anyone wants to see it. I think that it is a good example of the usefulness of Blenders scanline in the area of speed and good looking renders. The 26 light setup tool about 40 seconds to render. A Yafray render would have taken longer. The Yafray setup process would have involved more test and tweaking to get things to look just right.

Blender needs a better scanline rendering system. One that can produce rendering result using maybe some automated hybrid lighting array features or some "unknown" 3d mad-science technology that will produce great photoreal lighting and shadows with the same speed renders that Blender has always had.

Thats what we need Ton, 3d Mad-science. Yeah.

JA-forreal wrote:

some "unknown" 3d mad-science technology that will produce great photoreal lighting and shadows with the same speed renders that Blender has always had.

Could we have world peace too?

Hopefully there will be some more scope to extend Blender's internal renderer once Cessen has finished his material plugin work. However, different rendering techniques are done with different code, and more often than not, a general rule is that better looking results will take longer to render. I don't know how optimised yafray is either, so maybe in the future it may be sped up a little too.

JA-forreal wrote:

Blender needs a better scanline rendering system. One that can produce rendering result using maybe some automated hybrid lighting array features or some "unknown" 3d mad-science technology that will produce great photoreal lighting and shadows with the same speed renders that Blender has always had.

The more photorealistic you get, the more complicated the math behind it becomes (since you have to consider more things affecting the "scene"). I think dramatically improving Blender's internal renderer is not really the way to go (for now), it would be much wiser to try and get a file format other rendering engines can use and after OpenGL 2.0 comes out try and go for a OpenGL 2.0 rendering/shading system. This way you'd have ultr-fast rendering (vie GPU) and the option to use advanced renderers by saving/converting Blender data to data they can read.

It's important to realize that the rendering engine can only do so much to improve the final result... How the scene is built, how the lights are rigged and how the textures look are far more important than what renderer is responsible for producing the output. This is very easy to test - just download the free and crippled version of Maya and SoftImage XSI, build a simple scene and render it. It will most likely look like something you might just as well have done in Blender.

In my very humble opinion, the shortcomings of the current renderer can be fixed - without a total change of technology:

A) AA filters: Currently we've got a boxfilter. That is (almost) the worst possible algorithm. Hack in support for Lanczos, Hamming, Catmul-Rom and Gaussian. Let the user choose which one to run. And increase the upper limit for OSA to 32 or maybe 64.

B) Lamp toggles: Enable the user to select, for all lamptypes, if the lamp in question should or should not emit specularity.

C) Depth of field: The Z-buffer is already there whenever an image is rendered. Use that for a Z-based gaussian blur, hardcoded into the rendering pipeline. The Z-blur sequence plugin can already do this, but it would be very nifty to have something similar in the pipeline by default.

D) Selective raytracing: Whenever you need real reflection or refraction, it should be possible to raytrace those. I'm sure it could be done. Personally I think that environmentmaps are far more flexible when it comes to reflections, but there are times when they get you in trouble.

E) Texture preprocessor: Currently we can change the filterwidth for texture interpolation and mipmapping. This should be improved to support a wider range of filters, somewhat similar to the AA-filters mentioned above. It could also be useful to have access to other 2D-processors here, like gaussian blur for instance.

F) Output postprocessor: When an image/frame is rendered, there should be some way to pass it through a final set of 2D-processors. This could include, but not be limited to, level adjustment, hue, brightness, contrast, colorize, unsharp mask, saturation and so on. In short - ordinary 2D-post filters. All of these things are already available in several open source libraries, so the only real effort would be to code the "hook" that would grab the buffer and send it through these filters.

<edit type="just remembered">
G) Deep shadowmaps: Shadowmap calculations should take opacity and optionally also color of geometry into account when creating the final shadowmap.
</edit>

Except for D above, these things should be "relatively easy" to implement in the current engine. Since I'm such a lame coder myself, I don't know how hard it would be to hack selective raytracing into Blender. But the other things should not be too hard to fix.
_________________
eXo.Entity - the movie-in-progress-project

xype wrote:

JA-forreal wrote: Blender needs a better scanline rendering system. One that can produce rendering result using maybe some automated hybrid lighting array features or some "unknown" 3d mad-science technology that will produce great photoreal lighting and shadows with the same speed renders that Blender has always had. The more photorealistic you get, the more complicated the math behind it becomes (since you have to consider more things affecting the "scene"). I think dramatically improving Blender's internal renderer is not really the way to go (for now), it would be much wiser to try and get a file format other rendering engines can use and after OpenGL 2.0 comes out try and go for a OpenGL 2.0 rendering/shading system. This way you'd have ultr-fast rendering (vie GPU) and the option to use advanced renderers by saving/converting Blender data to data they can read.

One of blender's strengths are raw-rendering capability from the get go.
I think it would be okay to add some support for advanced ray-tracing and rendering features. The OpenGL2 would be good too.. Yafray could
be coupled with OpenGL2.0 and supplied with Blender, so that blender
doesn't take a particular bias toward any particular render package.

And blender's existing rendering capabilities could be expressed as OpenGL2.0 shaders.

i totally agree with jamesk. Those are the things we need.. And maybe
shadows from all lamps would be nice

cya henrik

Jamesk - you've summed up my thoughts exactly. Especially about deep shadow maps. In my more ambitious days, I did some reading about them. There are full explications of dsm's available on the Internet for the bored coder to read.

JA-I've always been able to acheive more than satisfactory results from Blender's renderer. Is it prman? Of course not. Can it get better than most of the stuff you see in the WIP forum on elysiun? Absolutely. I think that 80% of Blender users just don't spend the time learning to push the renderer around. And maybe that's why I never really invested the time into tweaking things for Yafray - my work is quite happy where it is now.

But yeah, you make the improvements to the renderer, and I will be extra extra happy.

I agree with jamesk.. and would like to add just one thing: area shadows =) Haven't seen a realistic looking shadow map yet! I know they aren't needed all the time but neither are refractions or caustics... they just add so much whenever you actually need them.

keep it up everyone..

harkyman wrote:

I think that 80% of Blender users just don't spend the time learning to push the renderer around.

Most likely so! I would not trade the "immediateness" you get using the internal renderer for any external solution. The current scanliner is fast, flexible and predictable. Those are VERY valuable properties in a real production situation. It is indeed very pushable and it can only get better. If treated right, it performs miracles. Naturally it has its limitations and quirks, but so does any software. It remains a good solid foundation upon which we can add the suggested improvements.

Yafray can produce very pretty renders, but frankly - I don't want to wait 40 minutes to get one single pretty frame if I can get 10 blenderframes for the same price...
_________________
eXo.Entity - the movie-in-progress-project

Jamesk wrote:

A) AA filters: Currently we've got a boxfilter. That is (almost) the worst possible algorithm. Hack in support for Lanczos, Hamming, Catmul-Rom and Gaussian. Let the user choose which one to run. And increase the upper limit for OSA to 32 or maybe 64.

Choose OSA 8, press the mblur-button and there you have your 64-limit. The result will not be that much better thought. Blender >needs< a better AA algorithm.

Eric wrote:

Choose OSA 8, press the mblur-button and there you have your 64-limit.

O'yea. That works fine most of the time. Gets rid of 99% of any nasty jaggies, but it still doesn't help the boxfilter-look of course... I'd like to get the occasional Catmul-Rom crispness, or some smooth photographic Gaussian.
_________________
eXo.Entity - the movie-in-progress-project

Have any good links other algo's for it? Shouldn't
be too hard for someone to add a menu with other
options. I'd be happy to help out with questions on how to
go about adding this and or provide as much info as you
can if you really want to see it get done.

Sample code, links, questions for adding it yourself etc.......

SirDude wrote:

Have any good links other algo's for it?

Here's a start at least, a 28 page PDF on "Antialiased voxelization of Geometric objects". I quickly browsed through it, and there seems to be pretty detailed explainations of the catmul-rom cubic spline filter. And a huge list of references of course =) Get that coffee now!

----> http://www.cs.brown.edu/research/vis/lists/pdf/Sramek:1999:AVO.pdf

<edit>
I would help out in the actual implementation, but seriously - when I read stuff like that, particularly the math-bits, my eyes start to behave strangely. I think it's some sort of allergy... I go temporarily blind =)
</edit>
_________________
eXo.Entity - the movie-in-progress-project