On 7/3/2015 8:32 PM, Samuel Benge wrote:
>> >What is a like button btw?
> A useless sentiment gauge.
>

I like that. :-)

-- 

Regards
     Stephen

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Fri, 03 Jul 2015 15:33:27 -0400, Samuel Benge wrote:
>
> > Jim Henderson <nos### [at] nospamcom> wrote:
> >> On Thu, 02 Jul 2015 00:38:36 -0400, Samuel Benge wrote:
> >>
> >> > Anyway, that's all for now. I'll be around occasionally, and I might
> >> > even start posing images again :)
> >>
> >> Welcome back - and cool, I always liked your images. :)
> >>
> >> Jim
> >
> > Likewise, Jim!
>
> What few I've done over the years, that is.  Nothing anywhere near as
> interesting as yours. :)
>
> Jim

But at least you tend to bring your scenes to completion!

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> It is good to have you back Sam. I am missing your inspiring work.
>
> --
> Thomas

Thanks Thomas. It's good to hear from you again. I'll have to dig through all
the old posts, to see what you and others have been doing (I /have/ stopped by
briefly a few times since I've been gone (via the library) but never long enough
to initiate and continue contact).

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 02/07/2015 05:38 AM, Samuel Benge wrote:
> > Actually, among other things, I started getting into some 3D programming thanks
> > to: a previously downloaded version of Fragmentarium (guidance); a C++ compiler
> > &  libs; GLSL documentation; POV docs. You know, raytracing via raymarching is
> > actually a lot easier to achieve than traditional raytracing due to the fact
> > that to make objects you pretty much just produce shape functions, and to render
> > you increment a ray variably from the camera until you reach a function's
> > threshold (as apposed to developing intersection functions for different shapes
> > and using octree optimizations). There's more to it of course, but the point is
> > it's simpler (to me anyway). Unfortunately, rendering on the GPU is much more
> > limited due to video memory. But hey, real-time isosurfaces! Yeah!
>
> After spending a while Googling this, is appears that "ray marching" is
> simply another name for the sphere tracing technique that POV-Ray uses
> to render isosurfaces already.

Sphere tracing? As a bounding shape for the distance estimate (shape) function,
or as the basis for all DEs? A bounding sphere isn't needed, and might actually
slow things down (if only slightly). I don't even bother with one.

And something is broken with POV-Ray's isosurface. I remember a time when it
used to have fewer artifacts.

> If only it wasn't so damned hard to program GPUs. This stuff sounds fun...

Not hard but rather easy, if you have a graphics library at hand that supports
OpenGL. I use SFML (C++, other bindings might be available), which is geared
towards 2D graphics. I just use a simple sprite (quad) and use render textures
along with GLSL shaders. (It also helps to get a vector math library, as SFML's
transformation class is not good for 3D). Getting something set up is easy, you
just need to learn GLSL, which is really a fun language to use.

Another good thing about SFML: it's open source, so you can compile it yourself.
(I had to do this to add support for 16 and 32 bit textures.)

Post a reply to this message

"Samuel Benge" <stb### [at] hotmailcom> wrote:
> A bounding sphere isn't needed, and might actually slow things down
>
To clarify: If your renderer uses only raymarching, you don't need a bounding
object. If you're integrating raymarching into a classical raytracer (as is the
case with POV's isosurface), then having a bounding object is highly
recommended!

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 7/3/2015 8:32 PM, Samuel Benge wrote:
> >> >What is a like button btw?
> > A useless sentiment gauge.
> >
>
> I like that. :-)
>
You forgot something: http://tinyurl.com/nj6cgg5

I think that's right...

Post a reply to this message

On Sat, 04 Jul 2015 14:23:58 -0400, Samuel Benge wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Fri, 03 Jul 2015 15:33:27 -0400, Samuel Benge wrote:
>>
>> > Jim Henderson <nos### [at] nospamcom> wrote:
>> >> On Thu, 02 Jul 2015 00:38:36 -0400, Samuel Benge wrote:
>> >>
>> >> > Anyway, that's all for now. I'll be around occasionally, and I
>> >> > might even start posing images again :)
>> >>
>> >> Welcome back - and cool, I always liked your images. :)
>> >>
>> >> Jim
>> >
>> > Likewise, Jim!
>>
>> What few I've done over the years, that is.  Nothing anywhere near as
>> interesting as yours. :)
>>
>> Jim
> 
> But at least you tend to bring your scenes to completion!

Eventually. ;)

Jim



-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On 04/07/2015 07:43 PM, Samuel Benge wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> After spending a while Googling this, is appears that "ray marching" is
>> simply another name for the sphere tracing technique that POV-Ray uses
>> to render isosurfaces already.
>
> Sphere tracing? As a bounding shape for the distance estimate (shape) function,
> or as the basis for all DEs?

No.

As you'll recall, you have to specify the max_gradient for a POV-Ray 
isosurface. That means that if you evaluate the function at a specific 
point, based on the maximum gradient you can compute a sphere of maximum 
radius that cannot contain any solutions. And that's how far you move 
along the ray. (Rather than having a constant step width.)

This of course is thwarted by functions that are extremely steep at the 
edges, yet quite shallow near where the solutions are. [*cough* 
Mandelbrot set *cough*] You end up needing an insanely high 
max_gradient, yet in the vicinity of the solutions you could actually 
afford to take much bigger steps.

You almost end up needing an estimate of the higher derivatives. Or 
perhaps you want a kind of "bounding function" which is simpler than the 
one you actually want to trace, just to estimate where to start tracing 
the slower function... [In the case of the Mandelbrot set, a lower-order 
iteration nicely fulfils that requirement. I wouldn't be surprised if 
that's how the built-in object type works.]

> And something is broken with POV-Ray's isosurface. I remember a time when it
> used to have fewer artifacts.

It depends on the function you're trying to trace, and the configured 
max_gradient.

>> If only it wasn't so damned hard to program GPUs. This stuff sounds fun...
>
> Not hard but rather easy, if you have a graphics library at hand that supports
> OpenGL. I use SFML (C++, other bindings might be available), which is geared
> towards 2D graphics. I just use a simple sprite (quad) and use render textures
> along with GLSL shaders. (It also helps to get a vector math library, as SFML's
> transformation class is not good for 3D). Getting something set up is easy, you
> just need to learn GLSL, which is really a fun language to use.
>
> Another good thing about SFML: it's open source, so you can compile it yourself.
> (I had to do this to add support for 16 and 32 bit textures.)

In my day job, I have trouble just making C++ *compile* and *link* 
successfully, never mind actually run without segfaulting. Kind of 
amazing I had paid for this...

Post a reply to this message

On 7/4/2015 8:29 PM, Samuel Benge wrote:
> Stephen <mca### [at] aolcom> wrote:
>> On 7/3/2015 8:32 PM, Samuel Benge wrote:
>>>>> What is a like button btw?
>>> A useless sentiment gauge.
>>>
>>
>> I like that. :-)
>>
> You forgot something: http://tinyurl.com/nj6cgg5
>
> I think that's right...
>
>
So that is where I went wrong.
This is from a long-ago project.



-- 

Regards
     Stephen

Post a reply to this message

Attachments:
Download 'a02b_12c1_0000.png' (416 KB)

Preview of image 'a02b_12c1_0000.png'

> No.
>
> As you'll recall, you have to specify the max_gradient for a POV-Ray
> isosurface. That means that if you evaluate the function at a specific
> point, based on the maximum gradient you can compute a sphere of maximum
> radius that cannot contain any solutions. And that's how far you move
> along the ray. (Rather than having a constant step width.)

Distance Fields are similar to isosurfaces, but the isosurface value is 
used to store the minimum possible distance to any surface. Then it 
makes your raymarcher algorithm very simple:

do{
  point = rayStart + rayDirection * distance
  stepSize = EvaluateDistanceField(point)
  distance += stepSize
}
while( stepSize > someVerySmallAmount)

The functions and methods are very similar to isosurfaces:

http://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm

There are also some clever tricks you can do to get soft shadows and 
ambient occlusion for free.

Post a reply to this message