scott wrote:
>> Sure. I was just wondering, since Blender doesn't do anything a GPU 
>> can't do, whether there's some way to use GPU acceleration, that's all.
> 
> You mean the Blender internal renderer?  Umm, that's a fully-fledged 
> raytracer with multiple reflections/refractions, ray traced shadows, 
> ambient occlusion, all that stuff etc, as you will know from the POV/GPU 
> discussion these things are quite hard to do on a GPU, if possible at all.

It's possible, sure.  This guy ported a small path tracing 
implementation to OpenCL:

http://vimeo.com/8013005

Post a reply to this message

> I thought ambient occlusion (as opposed to other GI algorithms) was 
> specifically suited to GPU implementation?

There's a variety of ways to implement AO, it just so happens someone 
developed a clever way to approximate AO very quickly on the GPU. 
Raytracers typically use a different method to compute AO that is not 
possible (or would be very slow/tricky) on GPUs.

> Anyway, I just thought if you weren't using ray tracing, it ought to be 
> possibly to run on the GPU. I guess not...

If you're not using any features of the ray tracer then isn't what you see 
in the edit view good enough?

> (What's the point of a ray tracer in a product that only renders 
> triangles?)

Ermm, physically correct multi-level reflections and refractions, more 
accurate GI, better AA, more accurate shadows, basically all the benefits of 
a raytracer rendering shapes other than triangles.

Post a reply to this message

>> I thought ambient occlusion (as opposed to other GI algorithms) was 
>> specifically suited to GPU implementation?
> 
> There's a variety of ways to implement AO, it just so happens someone 
> developed a clever way to approximate AO very quickly on the GPU. 
> Raytracers typically use a different method to compute AO that is not 
> possible (or would be very slow/tricky) on GPUs.

I thought the entire definition of AO is that it's a rough approximation 
to true GI that's useful because it renders really fast?

>> Anyway, I just thought if you weren't using ray tracing, it ought to 
>> be possibly to run on the GPU. I guess not...
> 
> If you're not using any features of the ray tracer then isn't what you 
> see in the edit view good enough?

As far as I know, I'm not using any ray tracer features, and yet the 
final render looks different than the edit window. (If only by being 
more grainy...)

>> (What's the point of a ray tracer in a product that only renders 
>> triangles?)
> 
> Ermm, physically correct multi-level reflections and refractions, more 
> accurate GI, better AA, more accurate shadows, basically all the 
> benefits of a raytracer rendering shapes other than triangles.

Well, I suppose. (I idea why AA would be better...) I guess I usually 
think of the main advantage of ray-tracing as being the ability to 
render things that aren't triangles. But sure, reflection, refraction 
and shadows are other big advantages...

Post a reply to this message

Invisible wrote:
>>> OK, this one took me a while to figure out. You'd think you extrude 
>>> it by dragging the face that you want to extrude... but no. You just 
>>> click and Blender places faces at random for you.
>>
>> Select faces/edges/vertices, press E to extrude. The newly formed 
>> faces/edges/vertices are automatically selected, and by default you 
>> are put in Grab mode; move the mouse to move them or right-click to 
>> keep them where they are. You can also switch from Grab mode to Scale 
>> or Rotate by pressing S or R.
> 
> This doesn't appear to match the behaviour I observed. Click somewhere 
> and new faces appear. Move the mouse and nothing happens. Click again 
> and more faces appear.
> 
> The faces aren't random though; it appears that if you click exactly 
> half way up the screen, the new geometry is parallel to the existing 
> cube. Click slightly below the midline and the geometry is connected at 
> an angle. Click lower still and it self-intersects in a way I don't 
> quite comprehend yet.

Extrusions are normally done by pressing E.  Select face/edge, press e 
and push it around (or along an axis by typing the axis name).

But you can also do like I tell above when you're constrained to a plane 
(like xy from top view) and it lets you quickly connect lots of extruded 
faces like as if you were drawing.  Good for a belt, I guess, and also 
good to draw SOR surfaces by begining with a plane (a face actually) and 
deleting all but one vertice and then selecting this one, moving it 
along the y axis with ctrl down until it's on y=0, and then changing to 
front view with 1 and clicking along to finally draw your cup or bottle 
or whatever, both outside and inside.  Next, F9 to get to the mesh edit 
panels bellow and search for Spin button.  Change to top view, then hit 
spin 4 times for a complete 360 turn.  You'll probably need the w menu 
and select "Remove doubles" to remove extra vertices on the same 
coordinates and then select all with a and hit ctrl+n to recalculate the 
normals or else it should display some funky black lines along the 
surface...

Have I mentioned block select operations yet?  b while in edit mode and 
it'll let you make a select window by clicking the mouse, pushing it and 
clicking again.  Or you click b again to select with a "brush" and paint 
along the area you want selected.  Size of radius controlled with 
pgup/pgdown.

If you don't want to select geometry in the background, I don't remember 
any keycombo, but the penultimate button while in edit mode in the bar 
just below the 3D view is called "Occlude background geometry".

Also, perhaps too early to tell, but you may also restrict your editing 
to a certain area by selecting the area you're interested and hitting 
shift+h to hide everything else or h to hide the selection.  Bring 
everything back with alt+h.

oh, and at any time undo is ctrl+z indeed.  There's different undos for 
edit mode and object mode, though.

Post a reply to this message

Invisible wrote:
> I thought ambient occlusion (as opposed to other GI algorithms) was 
> specifically suited to GPU implementation?

It's certainly only dependent on geometry, not light sources.  But how 
do you cast shadows on such geometry?  Blender comes with 2 options: 
Approximate AO and Raytraced AO, which is the default.  AAO is only 
useful if your geometry is dense, with lots of vertices, as all it does 
is pretty much the same as the classic polygon-only radiosity algorithm 
does (also available in Blender but a mess):  it "paints" vertex with 
color information.  If your geometry is not dense, AAO looks ridiculous.

> (What's the point of a ray tracer in a product that only renders 
> triangles?)

Yeah, what's the point of having povray raytrace any non-abstract math 
scenes?...

Post a reply to this message

> I thought the entire definition of AO is that it's a rough approximation 
> to true GI that's useful because it renders really fast?

Indeed.  Raytracers typically cast out a few rays (the more the smoother the 
result) to see if they hit anything within a certain distance.  GPU methods 
typically just compare the depths of the surrounding pixels (so it's 
essentially done in 2D).  Obviously for a GPU this is much faster as it 
doesn't need to access the scene data (it might not even exist in most 
cases!).

> As far as I know, I'm not using any ray tracer features, and yet the final 
> render looks different than the edit window. (If only by being more 
> grainy...)

If it looks grainy then you've probably got AO turned on with a low number 
of rays.

Note that in the edit window there are several different options for the 
display mode (wireframe, shaded, textures etc).

> Well, I suppose. (I idea why AA would be better...)

AFAIK standard GPU rendering uses a very limited AA algorithm (usually fixed 
to a certain number of sub-pixels and some maximum like 8x), a raytracer 
usually can use dynamic AA depth and as many rays as are necessary.

> I guess I usually think of the main advantage of ray-tracing as being the 
> ability to render things that aren't triangles.

I think there are some raytracers that can *only* render triangles.  I guess 
it makes them simpler and they can be highly optimised for huge lists of 
triangles.  Then you can make some layer that converts higher order shapes 
to pixel sized triangles on the fly to feed the raytracer if needed.  IIRC 
this is how Pixar's raytracer works.

Post a reply to this message

>> I thought the entire definition of AO is that it's a rough 
>> approximation to true GI that's useful because it renders really fast?
> 
> Indeed.  Raytracers typically cast out a few rays (the more the smoother 
> the result) to see if they hit anything within a certain distance.  GPU 
> methods typically just compare the depths of the surrounding pixels (so 
> it's essentially done in 2D).  Obviously for a GPU this is much faster 
> as it doesn't need to access the scene data (it might not even exist in 
> most cases!).

Ah, wait... Apparently I'm confusing SSAO with normal AO. (The former 
being commonly run on the GPU, the latter requiring an actual ray 
tracer.) I wasn't aware that Blender is doing true AO. I assumed it was 
just faking it, GPU-style.

>> (I idea why AA would be better...)
> 
> AFAIK standard GPU rendering uses a very limited AA algorithm (usually 
> fixed to a certain number of sub-pixels and some maximum like 8x), a 
> raytracer usually can use dynamic AA depth and as many rays as are 
> necessary.

This puzzles me. I'm not disputing you're wrong - usually there's some 
option to set the number of subsamples taken - but since a GPU can 
*only* draw straight lines, you'd think they could just use the 
closed-form formulas for doing mathematically perfect AA on polygon 
edges. It takes about 3 float-ops. No subsamples required.

Weird...

>> I guess I usually think of the main advantage of ray-tracing as being 
>> the ability to render things that aren't triangles.
> 
> I think there are some raytracers that can *only* render triangles.

Apparently I'm looking at one.

> I 
> guess it makes them simpler and they can be highly optimised for huge 
> lists of triangles.  Then you can make some layer that converts higher 
> order shapes to pixel sized triangles on the fly to feed the raytracer 
> if needed.  IIRC this is how Pixar's raytracer works.

That's what I heard. I also hear that only about 0.1% of the stuff Pixar 
does actually involves any ray tracing, with is kind of unbelievable...

I still find it rather hard to believe that you can take a complex shape 
such as the surface of a water splash and automatically tesselate it. 
But apparently somebody has figured out how to do this.

Post a reply to this message

>> (What's the point of a ray tracer in a product that only renders 
>> triangles?)
> 
> Yeah, what's the point of having povray raytrace any non-abstract math 
> scenes?...

What, you mean other than the ability to draw truly-curved surfaces, 
resolution-independent textures, and construct complex shapes easily and 
intuitively using CSG, blobs, isosurfaces, and so forth? ;-)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> That's what I heard. I also hear that only about 0.1% of the stuff Pixar
> does actually involves any ray tracing, with is kind of unbelievable...
>
> I still find it rather hard to believe that you can take a complex shape
> such as the surface of a water splash and automatically tesselate it.
> But apparently somebody has figured out how to do this.

http://vimeo.com/7875145

no raytracing!  friggin' unbelievable...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> (What's the point of a ray tracer in a product that only renders
> >> triangles?)
> >
> > Yeah, what's the point of having povray raytrace any non-abstract math
> > scenes?...
>
> What, you mean other than the ability to draw truly-curved surfaces,
> resolution-independent textures, and construct complex shapes easily and
> intuitively using CSG, blobs, isosurfaces, and so forth? ;-)

Very rare to have complex "real-life" scenes out of this math objects, except
landscapes due to their fractal nature (but even so, not even trees despite
their fractal base).  Characters and man-made buildings and objects need more
care detailing than one is willing to put forward out of pure math primitives
and functions.

It's very hard to go that route, both as an undertaking and waiting for some
insane render times.  Much easier to just approximate with polygons and
subdivision algorithms.  Have you tried subsurf modifier yet in Blender?

Post a reply to this message