 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
Indeed.
> 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.
I thought ambient occlusion (as opposed to other GI algorithms) was
specifically suited to GPU implementation?
Anyway, I just thought if you weren't using ray tracing, it ought to be
possibly to run on the GPU. I guess not...
(What's the point of a ray tracer in a product that only renders triangles?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] dev null> 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
|
|
| |
| |
|
|
|
|
| |
|
|
