<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Let me make my thoughts clear on some of the issues discussed here.<br>
<br>
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: <br>
<br>
- it's a commercial product, only the Plugin for usage with Renderman
is free<br>
- it only supports nVIDIA cards and only few of them<br>
- it's not even available for Windows yet<br>
<br>
I definitely don't want Gelato, that's for sure.<br>
<br>
Now on to the problem of inconsistent output in different cards:<br>
<br>
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.<br>
<br>
Now on to the general idea about using OpenGL:<br>
<br>
There's simply no other choice. And no ominous "them" decide what will
be part of the next generation of OpenGL but the<tt> 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.</tt><br>
<br>
So how about rendering pro work with an OpenGL-GPU-renderer?<br>
<br>
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.<br>
<br>
And lastly I feel the urge to quote:<br>
<pre wrap="">"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."</pre>
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.<br>
<br>
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:<br>
<br>
"OpenGL GPU rendering"<br>
<br>
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.<br>
<br>
And some more points why developing our own GPU-renderer would be good:<br>
<br>
- it'd release a GPU-renderer in the OS-community, something that seems
to be currently missing<br>
- it's highly educational for the devs and might lead to interesting
additions to the Blender GUI and GameBlender<br>
- it's more interesting to have a bigger choice of renderers instead of
having to rely on only few<br>
<br>
So much for today,<br>
<br>
Konrad<br>
____________________<br>
<a class="moz-txt-link-abbreviated" href="http://www.konrad-haenel.de">www.konrad-haenel.de</a><br>
<br>
<br>
Robert Wenzlaff wrote:
<blockquote cite="mid200410200922.22941.rwenzlaff@soylent-green.com"
type="cite">
<pre wrap="">On Tuesday 19 October 2004 22:20, Konrad Haenel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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".
</pre>
</blockquote>
<br>
</body>
</html>