 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"And" <49341109@ntnu.edu.tw> wrote:
> Long time no see.
Indeed. At least it seemed that way at first. Lately time seems to be slowing
down again... overclocked biocomputer, I guess. Might need a better cooling
system ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> 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!
>
> Yes you can create some really cool effects that way, especially things
> like repetition essentially come for free. Being able to watch your CSG
> isosurface repeated off to infinity in every axis and be able to explore
> around it in real time is pretty cool.
Yeah, it's neat alright. But you've got to bump up the maximum number of ray
steps for that, or else the surfaces beyond the edges of closer geometry tend to
disappear.
There are possible extensions to that concept as well, such as adding randomized
transformations per cell, or even picking new objects from an array of unique
distance estimate functions. Neighboring cell evaluation is needed for that,
though, since the DE needs to remain as continuous as possible.
> I tinkered about using shadertoy.com as it allows you to write your
> shader code immediately without having to fuss about with pages and
> pages of C++ boiler-plate code just to get a blank screen rendered. Some
> people have made some amazing creations on there.
Yeah they have. I created a couple of things a while back (look for
BeyondTheStatic), but nothing too great. My Mode7 attempt was cruddy, but it
served its purpose. I'd like to get some more stuff uploaded there soon. One
idea involved displaying numbers without font files. It could help shader
programmers who need to read variables but can't add new input textures.
> Also you can always write your raymarcher to run on the CPU, it won't be
> as fast but if you're running into memory troubles with a small GPU it
> might allow you to do things not possible otherwise.
True, but the complexity of the DE is also a problem, even with more memory.
Could still be worth it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It is good to have you back Sam. I am missing your inspiring work.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
If only it wasn't so damned hard to program GPUs. This stuff sounds fun...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
