[Bf-funboard] GPU accelerated rendering

[Konrad Haenel]

Let me make my thoughts clear on some of the issues discussed here.

First of all, I don't think Gelato is suited to bring GPU-rendering to 
an open-source project. In fact, there are too many drawbacks of Gelato 
to even consider it:

- it's a commercial product, only the Plugin for usage with Renderman is 
free
- it only supports nVIDIA cards and only few of them
- it's not even available for Windows yet

I definitely don't want Gelato, that's for sure.

Now on to the problem of inconsistent output in different cards:

Yes, output on different brands of cards might differ, but I don't think 
this should be a reason to dump the whole idea of GPU-rendering 
completely. I have read tests on picture-quality of Doom 3 recently, 
where there was an in depth-coverage of the differences of captured pics 
on different cards. It is true that actually every card rendered 
pictures differently, but once some of the deeper settings of this game 
were changed those differences weren't visible to the naked eye anymore. 
Only bytewise comparison of identical pictures made those differences 
visible. Although this might lead to problems in some cases I doubt it 
will be a hindrance for most users.

Now on to the general idea about using OpenGL:

There's simply no other choice. And no ominous "them" decide what will 
be part of the next generation of OpenGL but the OpenGl Architectural 
Review Board. AFAIK the Blender GUI is based entirely on OpenGL, so the 
same questions you raised about it would apply there too. This doesn't 
seem to bother anyone, though. I guess what's good enough for the GUI 
should be good enough for the Renderer as well.

So how about rendering pro work with an OpenGL-GPU-renderer?

I don't see the main usage of a GPU-renderer in doing the final 
rendering. It would have it's main appliance during production, where 
animatics have to be tested, lighting has to be adjusted etc. The 
increase of speed during these tasks would be the main benefit of quick 
GPU rendering. Absolute precision isn't a must for this, but time is 
quite an issue. Doing only animations myself I know how much this would 
enhance my workflow.

And lastly I feel the urge to quote:

"I stand by what I said.  If you want Gelato (et al.), the best way to get it 
is to support the Blenderman project.  If we had a fully useable Renderman 
interface today, we'd have GPU rendering (plus about 20 other software 
renderers) _TODAY_ .  Some work on Blenderman has already been done."

Gelato isn't free. We might have nice watermarked images with it's 
evaluation copy now, in case we own an nVIDA Quadro FX board 
(requirement). That's some downside I see.

Nothing against Blenderman, I really think this is one important 
project, but it simply doesn't have anything to do with my proposal 
which is:

"OpenGL GPU rendering"

So if someone works on Blenderman, don't divert your attention to this 
topic. But for the dev's out there willing to do something different and 
hot I suggest thinking it over.

And some more points why developing our own GPU-renderer would be good:

- it'd release a GPU-renderer in the OS-community, something that seems 
to be currently missing
- it's highly educational for the devs and might lead to interesting 
additions to the Blender GUI and GameBlender
- it's more interesting to have a bigger choice of renderers instead of 
having to rely on only few

So much for today,

Konrad
____________________
www.konrad-haenel.de


Robert Wenzlaff wrote:

>On Tuesday 19 October 2004 22:20, Konrad Haenel wrote:
>  
>
>>My knowledge of OpenGL is a little too limited to know an answer to this
>>question:
>>
>>Is it possible to save definite frames of OpenGL-output to files?
>>    
>>
>
>Not directly.  OpenGL (OpenGL 1 that is OpenGL 2 has more features, but what 
>I'm about to say is still somewhat true even for it) is meant as a standard 
>way for a program to talk to a graphics card.  Yes, you can read back pixels 
>and convert them to a file format, but that's not what it's intended for, and 
>you may not get back what you expect. 
>
>Also OpenGL doesn't standardize what the output should look like.  A person 
>with an nVidia OpenGL lib may see something different than a person with an 
>ATI or a person using software OpenGL.  If you rendered 99% of a film and 
>burned out your GFX card, you might be screwed if you can't get an exact 
>replacement.
>
>OpenGL is not the high quality renderer needed for pro 3D work.  Blender 
>doens't use OpenGL to render it's final output, not because it's technically 
>difficult or hackish, but because it's output would suck.  OpenGL was 
>designed to be flexible, however, and only recently have GFX card 
>capabilities surpassed what OpenGL could do.   What you are seeing in Gelato  
>is nVidia recognizing that fact, and developing their own API to reach the 
>features of their cards that OpenGL can't.
>
>As I said, OpenGL 2 covers some of this ground, but AFAIK OpenGL 2 is still a 
>somewhat moving target.
>
>  
>
>>In case we can use a highly standartized API it won't 
>>matter what brand of GPU is used to render the output. That's what APIs 
>>are for, isn't it?
>>    
>>
>
>Exactly.  If we try to integrate a GPU rendering API directly, we must make 
>one important realization right away; _It's not our API_.   We don't get any 
>say in how standard it is (other than voting with our money - and a lot of 
>Blender users are Blender users because they don't have any money :p).  It's 
>the manufacturer's API  - They own it - They decide what it looks like.  I 
>don't even know if nVidia's Gelato API is available for all the platforms we 
>support - They decide that, too.
>
>  
>
>>Anyway, even if certain manufacturer-specific criteria have to be met it 
>>basically comes down to ATI and nVIDIA. It's safe to assume that there 
>>won't be any more major players in the 3D-card field in the forseeable 
>>future.
>>    
>>
>
>There's no guarentee that Gelato2 will be the same as Gelato1 though.  It's 
>completely in the hands of the manufacturer and they have little use for full 
>compatability since it means people won't go out and buy their newest card 
>right away.  We can chase that whim or we can look for a standard.
>
>Renderman is that standard API and the manufactures (or someone)  will bend 
>over backwards to make sure there is an interface to their hardware API -  It 
>represents millions of users.  They won't do the same for the few 10's of 
>thousands of Blender users - we'd be lucky if they gave Ton _one_ of their 
>cards for free.  
>
>I stand by what I said.  If you want Gelato (et al.), the best way to get it 
>is to support the Blenderman project.  If we had a fully useable Renderman 
>interface today, we'd have GPU rendering (plus about 20 other software 
>renderers) _TODAY_ .  Some work on Blenderman has already been done.  
>
>I don't see any downside.
>
>I [lightly] opposed Yaffray integration into Blender, too.  Not because I 
>don't like Yaffray's output (I do), but because I think Yaffray made a big 
>mistake in not being Renderman compliant and we are perpetuating that 
>mistake.  
>
>The resources used to integrate that one renderer could have been used to get 
>20 different ones all at once, and we would not have had to deal with the 
>rush of "me-too's" wanting us to support every non-compliant renderer under 
>the sun.  This is exactly the reason Pixar pubished the Renderman spec and 
>pushed it to the point of making it a defacto "standard".
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-funboard/attachments/20041020/5950628e/attachment.htm