A 3d volumetric renderer of my PowerBulb...

[Chris M. Thomasson]

This plots my experimental power stack Mandelbulb. Its c99 code,
hardcoded at 256^3 resolution. It interpolates the zaxis from 0...1, and
the power from 2...10. The program generates 256 files called
ct_anime_p[0...255].ppm. These comprise the stack that can be loaded
into a volumetric renderer.

Here is the code:

https://pastebin.com/raw/07TWQQYF

Can you run the damn thing! ;^)

I attached a screen shot of a generated volume in ImageJ:

https://www.facebook.com/photo.php?fbid=184724606019879

One can convert the image stack to any format they want to. ImageMagick
works nice. Anyway here is the code, again:
______________________

/*
Experimental Power Stack Mandelbulb for Owen
By: Chris M. Thomasson
*_____________________________________________________________*/


#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>
#include <stdbool.h>


#define CT_WIDTH 256 // width of plane
#define CT_HEIGHT 256 // height of plane
#define CT_FRAMES 256 // slices of the mbulb
#define CT_ITERS 64 // iterations per pixel


/* The Canvas
___________________________________*/
struct ct_rgb
{
unsigned char r;
unsigned char g;
unsigned char b;
};


struct ct_canvas
{
unsigned long width;
unsigned long height;
struct ct_rgb* buf;
};

bool
ct_canvas_create(
struct ct_canvas* const self,
unsigned long width,
unsigned long height
){
size_t size = width * height * sizeof(*self->buf);

self->buf = calloc(1, size);

if (self->buf)
{
self->width = width;
self->height = height;

return true;
}

return false;
}

void
ct_canvas_destroy(
struct ct_canvas const* const self
){
free(self->buf);
}

bool
ct_canvas_save_ppm(
struct ct_canvas const* const self,
char const* fname
){
FILE* fout = fopen(fname, "wb");

if (fout)
{
char const ppm_head[] =
"P6\n"
"# Chris M. Thomasson Simple 2d Plane ver:0.0.0.0 (pre-alpha)";

fprintf(fout, "%s\n%lu %lu\n%u\n",
ppm_head,
self->width, self->height,
255U);

size_t size = self->width * self->height;

for (size_t i = 0; i < size; ++i)
{
//unsigned int c = self->buf[i];
struct ct_rgb* c = self->buf + i;

fprintf(fout, "%c%c%c", c->r, c->g, c->b);
}

if (! fclose(fout))
{
return true;
}
}

return false;
}



/* The Axes
___________________________________*/
struct ct_axes
{
double xmin;
double xmax;
double ymin;
double ymax;
};

struct ct_axes
ct_axes_from_point(
double complex z,
double radius
){
struct ct_axes axes = {
creal(z) - radius, creal(z) + radius,
cimag(z) - radius, cimag(z) + radius
};

return axes;
}



/* The Plane
___________________________________*/
struct ct_plane
{
struct ct_axes axes;
double xstep;
double ystep;
};


void
ct_plane_init(
struct ct_plane* const self,
struct ct_axes const* axes,
unsigned long width,
unsigned long height
){
self->axes = *axes;

double awidth = self->axes.xmax - self->axes.xmin;
double aheight = self->axes.ymax - self->axes.ymin;

assert(width > 0 && height > 0 && awidth > 0.0);

double daspect = fabs((double)height / width);
double waspect = fabs(aheight / awidth);

if (daspect > waspect)
{
double excess = aheight * (daspect / waspect - 1.0);
self->axes.ymax += excess / 2.0;
self->axes.ymin -= excess / 2.0;
}

else if (daspect < waspect)
{
double excess = awidth * (waspect / daspect - 1.0);
self->axes.xmax += excess / 2.0;
self->axes.xmin -= excess / 2.0;
}

self->xstep = (self->axes.xmax - self->axes.xmin) / width;
self->ystep = (self->axes.ymax - self->axes.ymin) / height;
}



/* The Plot
___________________________________*/
struct ct_plot
{
struct ct_plane plane;
struct ct_canvas* canvas;
};


void
ct_plot_init(
struct ct_plot* const self,
struct ct_axes const* axes,
struct ct_canvas* canvas
){
ct_plane_init(&self->plane, axes, canvas->width - 1, canvas->height
- 1);
self->canvas = canvas;
}


bool
ct_plot_add(
struct ct_plot* const self,
double complex z,
struct ct_rgb const* color
){
long x = (creal(z) - self->plane.axes.xmin) / self->plane.xstep;
long y = (self->plane.axes.ymax - cimag(z)) / self->plane.ystep;

if (x > -1 && x < (long)self->canvas->width &&
y > -1 && y < (long)self->canvas->height)
{
// Now, we can convert to index.
size_t i = x + y * self->canvas->width;

assert(i < self->canvas->height * self->canvas->width);

struct ct_rgb exist = self->canvas->buf[i];

exist.r += 1;

self->canvas->buf[i] = exist;
return true;
}

return true;
}


bool
ct_plot_pixel(
struct ct_plot* const self,
long x,
long y,
struct ct_rgb const* color
){
if (x > -1 && x < (long)self->canvas->width &&
y > -1 && y < (long)self->canvas->height)
{
// Now, we can convert to index.
size_t i = x + y * self->canvas->width;

assert(i < self->canvas->height * self->canvas->width);

self->canvas->buf[i] = *color;
return true;
}

return false;
}


void
ct_plot_clear(
struct ct_plot* const self,
struct ct_rgb const* color
){
size_t size = self->canvas->height * self->canvas->width;

for (size_t i = 0; i < size; ++i)
{
self->canvas->buf[i] = *color;
}
}


double complex
ct_project_to_xy(
struct ct_plot* const self,
long x,
long y
){
double complex p =
(self->plane.axes.xmin + x * self->plane.xstep) +
(self->plane.axes.ymax - y * self->plane.ystep) * I;

return p;
}


bool
ct_plot_point(
struct ct_plot* const self,
double complex z,
struct ct_rgb const* color
){
long x = (creal(z) - self->plane.axes.xmin) / self->plane.xstep;
long y = (self->plane.axes.ymax - cimag(z)) / self->plane.ystep;

if (x > -1 && x < (long)self->canvas->width &&
y > -1 && y < (long)self->canvas->height)
{
// Now, we can convert to index.
size_t i = x + y * self->canvas->width;

assert(i < self->canvas->height * self->canvas->width);

self->canvas->buf[i] = *color;
return true;
}

return false;
}


// slow, so what for now... ;^)
void ct_circle(
struct ct_plot* const plot,
double complex c,
double radius,
unsigned int n
){
double abase = 6.2831853071 / n;

for (unsigned int i = 0; i < n; ++i)
{
double angle = abase * i;

double complex z =
(creal(c) + cos(angle) * radius) +
(cimag(c) + sin(angle) * radius) * I;

struct ct_rgb rgb = { 255, 255, 255 };

ct_plot_point(plot, z, &rgb);
}
}



/* Simple vec3 for just what I need
___________________________________*/
struct ct_vec3
{
double x;
double y;
double z;
};


double ct_vev3_length(
struct ct_vec3 const p
){
double sum = p.x * p.x + p.y * p.y + p.z * p.z;
return sqrt(sum);
}


struct ct_vec3
ct_vec3_add(
struct ct_vec3 const p,
struct ct_vec3 const addend
){
struct ct_vec3 sum = {
p.x + addend.x,
p.y + addend.y,
p.z + addend.z
};

return sum;
}



/* The Power Stack Mandelbulb
___________________________________*/
void
ct_iterate_mbulb_pixel(
struct ct_plot* const plot,
struct ct_vec3 const z0,
struct ct_vec3 const c0,
double power,
long x,
long y,
unsigned int n
){
struct ct_vec3 zs = z0;
struct ct_vec3 cs = c0;

for (unsigned long i = 0; i < n; ++i)
{
double r = ct_vev3_length(zs);
double rpower = pow(r, power);

double angle0 = atan2(zs.z, sqrt(zs.x * zs.x + zs.y * zs.y));
double angle1 = atan2(zs.y, zs.x);

struct ct_vec3 znew;
znew.x = rpower * cos(power * angle1) * cos(power * angle0);
znew.y = rpower * sin(power * angle1) * cos(power * angle0);
znew.z = rpower * sin(power * angle0);

zs = ct_vec3_add(znew, cs);

if (r > 2.0)
{
return;
}
}

struct ct_rgb rgb = { 0, 255, 0 };
ct_plot_pixel(plot, x, y, &rgb);
}


// Gain the field...
void
ct_iterate_mbulb_plane(
struct ct_plot* const plot,
double zaxis,
double power,
unsigned int n
){
for (long y = 0; y < plot->canvas->height; ++y)
{
for (long x = 0; x < plot->canvas->width; ++x)
{
double complex cz = ct_project_to_xy(plot, x, y);

// Well, our per slice coords...
struct ct_vec3 z;

z.x = creal(cz);
z.y = cimag(cz);
z.z = zaxis;

// Iterate the slice
ct_iterate_mbulb_pixel(plot, z, z, power, x, y, n);
}

if (! (y % (plot->canvas->height / 10)))
{
printf("ct_iterate_mbulb_plane: %lu of %lu\r",
y + 1, plot->canvas->height);

fflush(stdout);
}
}

printf("ct_iterate_mbulb_plane: %lu of %lu\n\n",
plot->canvas->height, plot->canvas->height);

fflush(stdout);
}


/* The Animation Driver
___________________________________*/
void ct_anime(
struct ct_plot* const plot,
unsigned long frame_n,
unsigned long n
){
assert(frame_n > 0);

double zmin = 0.;
double zmax = 1.;
double zdif = zmax - zmin;
double zbase = zdif / (frame_n - 1.);

double pmin = 2.;
double pmax = 10.;
double pdif = pmax - pmin;
double pbase = pdif / (frame_n - 1.);

char fname[256] = { '\0' };

for (unsigned long frame_i = 0; frame_i < frame_n; ++frame_i)
{
double zaxis = zmin + zbase * frame_i;
double power = pmin + pbase * frame_i;

sprintf(fname, "ct_anime_%lu.ppm", frame_i);

printf("ct_anime: %lu of %lu, zaxis(%lf), power(%lf), (%s)\n",
frame_i, frame_n, zaxis, power, fname);

fflush(stdout);

struct ct_rgb black = { 0, 0, 0 };
ct_plot_clear(plot, &black);

ct_iterate_mbulb_plane(plot, zaxis, power, n);

ct_canvas_save_ppm(plot->canvas, fname);
}

printf("\n\nct_anime complete! %lu frames: \n", frame_n);
fflush(stdout);
}




void ct_test_plane(
struct ct_plot* const plot
){
printf("Generating...\n\n");
fflush(stdout);

ct_anime(plot, CT_FRAMES, CT_ITERS);
}


int main(void)
{
struct ct_canvas canvas;

if (ct_canvas_create(&canvas, CT_WIDTH, CT_HEIGHT))
{
double complex plane_origin = 0+0*I;
double plane_radius = 1.5;

struct ct_axes axes = ct_axes_from_point(plane_origin,
plane_radius);

struct ct_plot plot;
ct_plot_init(&plot, &axes, &canvas);


ct_test_plane(&plot);


// Our unit circle
ct_circle(&plot, 0+0*I, 1.0, 2048);
ct_circle(&plot, 2+0*I, 2.0, 2048);
ct_circle(&plot, -2+0*I, 2.0, 2048);
ct_circle(&plot, 0+2*I, 2.0, 2048);
ct_circle(&plot, 0-2*I, 2.0, 2048);

ct_canvas_save_ppm(&canvas, "ct_plane.ppm");

ct_canvas_destroy(&canvas);

return EXIT_SUCCESS;
}

return EXIT_FAILURE;
}
______________________


Can you notice any bugs? Its working great.

[Chris M. Thomasson]

On 12/4/2019 8:07 PM, Chris M. Thomasson wrote:
> This plots my experimental power stack Mandelbulb. Its c99 code,
> hardcoded at 256^3 resolution. It interpolates the zaxis from 0...1, and
> the power from 2...10. The program generates 256 files called
> ct_anime_p[0...255].ppm. These comprise the stack that can be loaded
> into a volumetric renderer.

[...]

The subject is a bit misleading. Sorry. My program generates an image
stack that can be viewed with a volumetric renderer. Actually, I am
working on some distance estimated versions. A lot faster to just get a
view. However, my program here creates a 100% fullblown 3d object wrt
the image stack.

[fir]

and where is theh volumetric renderer? do you use online of some ofline?

i find this topic ok though i would need to get a bit into it and im not sure how far i am to the will of doing it (khU)

[Bart]

I ran your program under gcc (as its complex.h and tgmath.h caused
problems with other compilers).

I tweaked the generation of the file name to use "007", "017", "117" etc
instead of "7", "17" and "117", so that the alphabetical ordering of the
files would still be in the correct numerical order.

This way, I got 256 files that I could load at the same time into my
little image viewer. Being in order, I could step between them fast
enough to give the illusion of animation as it displays the
cross-section of the volume from bottom to top and back.

(Which I have to say was prettier than the odd-looking solid it
represents, according to your 3D shot.)

Then I decided to try it under other compilers. First I got got rid of
complex.h and tgmath.h (and added math.h). Now it could run under Tiny
C. (And here I think the structs representing complex look better than
native complex.)

But I made further changes to allow it be compiled with bcc and DMC:

* Fixed some struct initialisations (needed for both)
* Avoided using compound literals for 'mycomplex' in the ct_circle
calls (needed for bcc)

Result is here:

https://github.com/sal55/langs/blob/master/mandelbulb.c

This runs on my gcc, tcc, dmc and bcc. (lcc however has some problems.)

[Chris M. Thomasson]

On 12/5/2019 2:39 AM, fir wrote:
> W dniu czwartek, 5 grudnia 2019 05:07:27 UTC+1 użytkownik Chris M. Thomasson napisał:
>> This plots my experimental power stack Mandelbulb. Its c99 code,
>> hardcoded at 256^3 resolution. It interpolates the zaxis from 0...1, and
>> the power from 2...10. The program generates 256 files called
>> ct_anime_p[0...255].ppm. These comprise the stack that can be loaded
>> into a volumetric renderer.
>>
>> Here is the code:
>>
>> https://pastebin.com/raw/07TWQQYF
>>
>> Can you run the damn thing! ;^)
>>
>> I attached a screen shot of a generated volume in ImageJ:
>>
>> https://www.facebook.com/photo.php?fbid=184724606019879
>>
>> One can convert the image stack to any format they want to. ImageMagick
>> works nice. Anyway here is the code, again:
>> ______________________

[...]

>>
>> Can you notice any bugs? Its working great.
>
> and where is theh volumetric renderer? do you use online of some ofline?

Fwiw, there are different ways to render this. One is a distance
estimator, another is a volumetric renderer, ect... ImageJ, wrt Fiji can
do it, you have to convert the ppms to jpg or something first. Actually,
a lot of really expensive medical volume renderers can do it as well.
Think of DICOM.

> i find this topic ok though i would need to get a bit into it and im not sure how far i am to the will of doing it (khU)
>

Check out:

https://imagej.net/Fiji

[Chris M. Thomasson]

On 12/5/2019 4:05 AM, Bart wrote:
> On 05/12/2019 04:09, Chris M. Thomasson wrote:
>> On 12/4/2019 8:07 PM, Chris M. Thomasson wrote:
>>> This plots my experimental power stack Mandelbulb. Its c99 code,
>>> hardcoded at 256^3 resolution. It interpolates the zaxis from 0...1,
>>> and the power from 2...10. The program generates 256 files called
>>> ct_anime_p[0...255].ppm. These comprise the stack that can be loaded
>>> into a volumetric renderer.
>> [...]
>>
>> The subject is a bit misleading. Sorry. My program generates an image
>> stack that can be viewed with a volumetric renderer. Actually, I am
>> working on some distance estimated versions. A lot faster to just get
>> a view. However, my program here creates a 100% fullblown 3d object
>> wrt the image stack.
>>
>
>
> I ran your program under gcc (as its complex.h and tgmath.h caused
> problems with other compilers).
>
> I tweaked the generation of the file name to use "007", "017", "117" etc
> instead of "7", "17" and "117", so that the alphabetical ordering of the
> files would still be in the correct numerical order.
>
> This way, I got 256 files that I could load at the same time into my
> little image viewer. Being in order, I could step between them fast
> enough to give the illusion of animation as it displays the
> cross-section of the volume from bottom to top and back.

Perfect! Thank you Bart. :^)

>
> (Which I have to say was prettier than the odd-looking solid it
> represents, according to your 3D shot.)

The image I posted to is very low res. This object has many interesting
features. Can you view the content in the following link:

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=17187

Its an older example. The fun part of the volumetric is that one can
spin the object around and go transparent, take slices, whatever.

Fwiw, here is the animation of the stack:

https://youtu.be/wJQRaKB2LtY

That creates the following 3d object:

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=17204

Can you view the fractalforums links?

>
> Then I decided to try it under other compilers. First I got got rid of
> complex.h and tgmath.h (and added math.h). Now it could run under Tiny
> C. (And here I think the structs representing complex look better than
> native complex.)
>
> But I made further changes to allow it be compiled with bcc and DMC:
>
> * Fixed some struct initialisations (needed for both)
> * Avoided using compound literals for 'mycomplex' in the ct_circle
>   calls (needed for bcc)
>
> Result is here:
>
>   https://github.com/sal55/langs/blob/master/mandelbulb.c

Double perfect! Now its in a form that can just compile on many
compilers. Back to C89 is fine. :^)

>
> This runs on my gcc, tcc, dmc and bcc. (lcc however has some problems.)

Will have some more time later on tonight to get back to you. This can
be colored such that internal structures form. This gives internal
structure.

[Chris M. Thomasson]

On 12/5/2019 2:39 AM, fir wrote:

> W dniu czwartek, 5 grudnia 2019 05:07:27 UTC+1 użytkownik Chris M. Thomasson napisał:
>> This plots my experimental power stack Mandelbulb. Its c99 code,
>> hardcoded at 256^3 resolution. It interpolates the zaxis from 0...1, and
>> the power from 2...10. The program generates 256 files called
>> ct_anime_p[0...255].ppm. These comprise the stack that can be loaded
>> into a volumetric renderer.
>>
>> Here is the code:
>>
>> https://pastebin.com/raw/07TWQQYF
>>
>> Can you run the damn thing! ;^)

[...]

> and where is theh volumetric renderer? do you use online of some ofline?

To clarify, this program generates a stack of images that can be used
within a volumetric renderer. It creates a full blown 3d object.

[jadi...@gmail.com]

You can also probably find or adapt a sample program to do this with the
Visualization Toolkit or VTK. Used it way back in the day for doing
image visualizations of radiation dose calculations.

Basically, I had 3 volumes, one of the patient CT scan raw grey level
data, one of the radiation dose, and another of the doctor defined contour
surfaces of the anatomy.

I rendered three planes that was texture mapped with the CT data in a 3D
view that one could rotate and zoom with the mouse. You could also use
the mouse to select one of the planes and then drag to change the slice
of data you're looking through. I also colorized the gray scale with
a color map according to the amount of radiation dose. And the contours
representing the segmentation of the anatomy receiving the dose was
smoothed and tessellated and rendered semi-transparently in the image data.
I could also just show the contoured anatomy with the radiation dose
color maps applied to the surface rendering.

Just something to consider since it seems you're interested in visualization
of your fractal creations. You might find some inspiration.

Best regards,
John D.

[Chris M. Thomasson]

On 12/5/2019 4:05 AM, Bart wrote:

Need to try it out on my lcc. Iirc, have lcc-64 installed, version:

Logiciels/Informatique lcc-win (64 bits) version 4.1.
Compilation date: Oct 27 2016 16:34:50

[Bart]

Same version as mine. At first it will give an internal compiler error
(on your original version). This can be by-passed by commenting out the
first assert. But then when it runs, it crashes.

The 32-bit version gives further compiler errors. Either lcc version,
and either program version, you can get so far, then it will fail. So I
think it's compiler bugs rather than the program or the kind of C used.

[Bart]

This version also works on rextexter.com's VC (MSVC), which had problems
with tgmath.h, and gave syntax errors on double complex.

(Although it doesn't really run, because there's a 10 second time-out,
and also there's no way to get hold of the output files. But this is
about compiling.)

[Chris M. Thomasson]

The damn thing should run. I do not bother with MSVC wrt c99. Never has
worked. Thanks for giving it a go on your own compiler. It works! Thanks
Bart.

[Chris M. Thomasson]

Nothing wrong with converting back to c89. I have not had the time to
try your conversion code yet. Trust in you Bart. Will do.

[Chris M. Thomasson]

Agreed. So far, I cannot find any bugs in there. C99 is c99, therefore
it should work. Can you find any buffer errors?

[Bart]

Apart from the internal compiler errors, lccwin seems to have a bug in
its pow() function.

This causes a crash at runtime, which can also happen at compile-time
when using constant operands. Defining it in terms of exp and log didn't
work (same problem).

Getting a pow() wrapper function to always return 1.0 seemed to 'work'
using 32-bit lccwin, on my version, and with no optimising (no crashing
but obviously wrong results). Any other combination, even that pow()
results in a crash.

Whether there are other things in the program that may be affecting it
or not (maybe some buffer error as you say), this program:

#include <math.h>

int main(void) {
double x=0, y=2;
pow(x,y);
}

Crashes on my lccwin in 64-bit mode, optimised or not. No buffer errors
here.

[Chris M. Thomasson]

Will take a look at it. Thank you for the heads up.

> Basically, I had 3 volumes, one of the patient CT scan raw grey level
> data, one of the radiation dose, and another of the doctor defined contour
> surfaces of the anatomy.
>
> I rendered three planes that was texture mapped with the CT data in a 3D
> view that one could rotate and zoom with the mouse. You could also use
> the mouse to select one of the planes and then drag to change the slice
> of data you're looking through. I also colorized the gray scale with
> a color map according to the amount of radiation dose. And the contours
> representing the segmentation of the anatomy receiving the dose was
> smoothed and tessellated and rendered semi-transparently in the image data.
> I could also just show the contoured anatomy with the radiation dose
> color maps applied to the surface rendering.

Excellent! To clarify, did the axial, sagittal and coronal slices
belonged to their own respective volumes? Interesting because I have
only used a single volume to feed the xy, yz and xz slices. Fwiw, here
are some other 3d volumes I created:

https://www.facebook.com/photo.php?fbid=185009805991359

(btw, can you even see these renderings on the fb link?)

> Just something to consider since it seems you're interested in visualization
> of your fractal creations. You might find some inspiration.

Absolutely. I really need to code up a distance estimator for this. They
work pretty fast, and do not require a per-computed volume for the
fractal. A voxel can be tested to see if its in, or out of the fractal
surface. However, having the whole volume is nice for 3d printing.

[Chris M. Thomasson]

On 12/6/2019 6:36 PM, Chris M. Thomasson wrote:
> On 12/5/2019 2:59 PM, jadi...@gmail.com wrote:
>> On Thursday, December 5, 2019 at 5:32:38 PM UTC-5, Chris M. Thomasson
>> wrote:

[...]

> Excellent! To clarify, did the axial, sagittal and coronal slices
> belonged to their own respective volumes? Interesting because I have

^^^^^^^^^^

belong

To clarify, did the axial, sagittal and coronal slices belong to their
own respective volumes?

> only used a single volume to feed the xy, yz and xz slices. Fwiw, here
> are some other 3d volumes I created:

[...]

[Chris M. Thomasson]

On 12/5/2019 2:59 PM, jadi...@gmail.com wrote:

> On Thursday, December 5, 2019 at 5:32:38 PM UTC-5, Chris M. Thomasson wrote:

[...]

> Basically, I had 3 volumes, one of the patient CT scan raw grey level
> data, one of the radiation dose, and another of the doctor defined contour
> surfaces of the anatomy.

[...]
Do you happen to remember the dimension of the volumes? I guess now,
they can be gigavoxels? Somebody used my program to generate a 4096^3
dimension stack. That's a lot of data! He cannot get it to render in 3d.
Now, think of a binary representation of voxels, they are either on or
off. This reduces space, but for shi% like 4096^3, well... Crap happens!

With wrt to 3d... Distance estimation can render a view of this at
4096^3. A bitcoin rig with a lot of GPU's can do it. DE does not need to
take the whole object into account, only the rays that hit it during the
march.

What is the biggest volume you have ever seen?

[Chris M. Thomasson]

So far, I cannot find any bugs in my program.

> this program:
>
>   #include <math.h>
>
>   int main(void) {
>       double x=0, y=2;
>       pow(x,y);
>  }
>
> Crashes on my lccwin in 64-bit mode, optimised or not. No buffer errors
> here.

Wow: That's a bad one!

[Chris M. Thomasson]

On 12/5/2019 2:39 AM, fir wrote:

[....]

> and where is theh volumetric renderer? do you use online of some ofline?
>
> i find this topic ok though i would need to get a bit into it and im not sure how far i am to the will of doing it (khU)
>

Working on porting a ray marched version. Fwiw, my first little scheme
wrt marching rays at fractals can be visualized here:

https://youtu.be/TLd64a4gdZQ

This can be fairly easily converted from my c++ into c99, where each
frame is a ppm.