ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/v01.n025

Internet Message Format | 1999-10-31 | 41KB

From: [e-mail] (fractdev-digest)
To: [e-mail]
Subject: fractdev-digest V1 #25
Reply-To: fractdev-digest
Sender: [e-mail]
Errors-To: [e-mail]
Precedence: bulk


fractdev-digest        Monday, November 1 1999        Volume 01 : Number 025




----------------------------------------------------------------------

Date: Tue, 25 May 1999 16:59:21 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

On Tue, 25 May 1999, Phil McRevis wrote:

> The mipmap datastructure is an approximation to the true convolution --
> since doing the true convolution is quite expensive.  A mipmap contains
> prefiltered versions of the texture at various levels of decimation.
> For instance a 256x256 texture would be filtered to produce decimated
> versions at resolutions 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2
> and 1x1.  The collection of decimated images plus the original texture
> image is referred to as a "mipmap".  When rendering instead of
> performing the full convolution, it is approximated by interpolating
> both within a single level of a mipmap and between two adjacent levels
> in a mipmap.  This is called bilinear and trilinear filtering,
> respectively.

    The structure os a MIP map reminds me of two things: the wavlet
transform and my dithereing drawing method. :-) In this last I effectively start
with a 1x1 pixel and go down to the full resolution of the image.

[...]
> With a procedural texture, consider the mipmap as an infinite pyramid,
> with the 1x1 version at the apex and finer and finer renderings of the
> procedural texture appearing as the pyramid gets wider and wider.

    Even more like my method.


[...]
> Another advantage a mipmap like storage technique would get you
> (besides avoiding recomputation of orbits, regardless of the
> orientation of the viewport) is that anti-aliasing comes "for free"
> and getting an anti-aliased image doesn't imply the loss of any data.
> Thus you could swith coloring methods after the anti-aliased view is
> finished and get an anti-aliased view with the new method without
> recomputing any orbits.

    Hm. or I could make the dithering method go 1 level deeper (with some
easy adjustments to avoid over calculation of points) and derive anti aliasing
from there.
>
> The definitive reference for "mipmaps" and its application to computer
> graphics and anti-aliasing can be found in this paper:
[...]

    Thanks, rich.

    BTW: how're things with the flat memory model?

    []'s

    Humberto R. Baptista
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>pu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>+++++$ h(---)>*$ r+++
y+++*
- ------END GEEK CODE BLOCK------



- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Wed, 26 May 1999 08:50:16 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:

>     The structure os a MIP map reminds me of two things: the wavlet
> transform and my dithereing drawing method.

I don't know what your dithering drawing method is, but its only
relation to the wavelet transform is that they both have recursive
elements to their structure.  But then again, so does counting to 100
by tail recursion.

>  Hm. or I could make the dithering method go 1 level deeper (with some
> easy adjustments to avoid over calculation of points) and derive anti
> aliasing from there.

Dithering != anti-aliasing; either we are not using the same terms
consistently, or we have some confusion on what "anti-aliasing" and
"dithering" really do.  One would typically apply anti-aliasing to a
full 24-bit RGB image and then dither it to the resolution of the
device (i.e. 16-bit color, or 8-bit LUT).  The two techniques are
often useful at the same time, but you definately do not want to try
and "anti-alias" a dithered image if you expect to get quality
results.

>     BTW: how're things with the flat memory model?

Clunking along.  I am trying to get my own business off the ground
before I run out of $$, so I can't work on the flat memory model
24/7.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Wed, 26 May 1999 12:16:57 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

On Wed, 26 May 1999, Phil McRevis wrote:

>
> In article <[e-mail]>,
>     Humberto Rossetti Baptista <[e-mail]>  writes:
>
> >     The structure os a MIP map reminds me of two things: the wavlet
> > transform and my dithereing drawing method.
>
> I don't know what your dithering drawing method is, but its only
> relation to the wavelet transform is that they both have recursive
> elements to their structure.  But then again, so does counting to 100
> by tail recursion.

    Ups, old terminology: i meant diffusion method (i changed the name some
time ago to avoid confusion, but I keep forgetting :-)

> >  Hm. or I could make the dithering method go 1 level deeper (with some
> > easy adjustments to avoid over calculation of points) and derive anti
> > aliasing from there.
[... mess I made ...]

    What I meant is that the diffusion drawing method uses a spcial
recursive subdivision method that is very economic in memory and is similar to
the structure you descibed to the mip maps.

    Por instance we can star with a 1x1 pixel image (the pixel covers the
whole screen) then to a 2x2, then a 4x4 and so on until the 2^nx2^n you want.
Right now my method stops in the screen resolution, but there is nothing that
stop us to go further, that is calculate all points between the screen points,
this could help anti-aliasin. This also could be done w/ images generated with
other drawing method (i can start my method in any point).

    Since we're on the subject let's check some things that are not clear
for me.

    I do not see how we can do anti-aliasing without reducing the resolution
of the final image. But:

    *   *  < pixels in the maximum resolution evaluate
      #    < interpolated pixel calculated on a 2x resolution than above

    What could the interpolated pixels help on the anti-alias calculation?

    I think I miss somenthing here as I see little advantage on the use of
anti-alias on our fractal drawing work.

> >     BTW: how're things with the flat memory model?
>
> Clunking along.  I am trying to get my own business off the ground
> before I run out of $$, so I can't work on the flat memory model
> 24/7.

    Right. I never expected anyone to get full 24/7 on this (though it would
be nice to earn a livin like this :-)))) But the scheme you presented was so
simple (to the sense that it interferes little with the existent code) that I
was curious to know.

    I have to come back to my bussiness now too :-)) Gook luck.

    Humberto R. Baptista
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>pu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>+++++$ h(---)>*$ r+++
y+++*
- ------END GEEK CODE BLOCK------



- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Wed, 26 May 1999 09:37:46 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:

>     Ups, old terminology: i meant diffusion method (i changed the name some
> time ago to avoid confusion, but I keep forgetting :-)

Ah... OK, that makes much more sense.

>  I do not see how we can do anti-aliasing without reducing the resolution
> of the final image.

In the context of fractals, it is impossible to construct a bandwidth
limited version of the fractal that you then sample.  Because you are
always sampling a "thing" which has frequency components higher than
the highest representable frequency component on the screen, you
always have aliasing.  If you could bandwidth limit the fractal before
sampling it, then the samples would reproduce the frequencies exactly
and no anti-aliasing would be needed.

So, we're stuck with aliasing and the best we can do is try to
minimize the aliasing by applying anti-aliasing techniques.  This
generally implies supersampling the fractal and filtering the
supersampled fractal to the final resolution.  In order to support
anti-aliasing, fractint would need to devote memory storage (either
incrementally on a scanline-by-scanline basis, or in toto) to the
supersampled image.  The screen displays the result of the
anti-aliased filter.

>     *   *  < pixels in the maximum resolution evaluate
>       #    < interpolated pixel calculated on a 2x resolution than above
>
>     What could the interpolated pixels help on the anti-alias calculation?

Decimation and interpolation are opposites.  Decimation (usually
combined with filtering; decimation without filtering just throws away
pixels and/or scanlines) decreases the number of pixels in an image
and interpolation increases the number of pixels in an image.  When
you are approximating a fractal with a few samples, then you
interpolate.  If you have more samples than your final resolution, you
decimate -- hopefully with a nice anti-aliasing filter so that you
don't introduce aliasing in the decimation process.

>     I think I miss somenthing here as I see little advantage on the use of
> anti-alias on our fractal drawing work.

Damien has a wonderful set of images on his web area that exaplains the
advantage of anti-aliasing for fractals.

> [...] the scheme you presented was so
> simple (to the sense that it interferes little with the existent code) that I
> was curious to know.

As it stands right now, the X11 "driver" appears to be working OK for
the code that I migrated from unixscr.c into d_x11.c; what is missing
is native X11 text output (so that an xterm window + curses isn't
required for X11 text output).  My plans are:

    o add native X11 text output
    o integrate driver into the video mode selection logic, similar to
    the ASCII mockup I posted earlier
    o massage curses driver for "graphic" output a la XaoS
    o massage disk driver for diskvideo output

Then what remains is to go through the use of memory to remove the
overlay and wacky memory buffers that fractint uses.  Things like
MK_FP() will go away, but since a single chunk of memory is aliased
(like a fortrash common block) by different routines, that will take
some careful work.  Finally, all the "far/huge/near" qualifiers on
memory can be removed (FCODE too).  At that point, I'll take the code
over to the DJGPP -- I'm currently developing everything on unix since
the tools and debuggers are more familiar to me -- and get disk and
curses video drivers working on DOS.  The final thing will be to get
the assembly code working for graphics output on DOS.  This may be
more trouble than its worth for me, and instead I may just implement
a graphics driver based on allegro and leave the assembly code to some
other motivated individual :-).
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Wed, 26 May 1999 08:50:16 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:

>     The structure os a MIP map reminds me of two things: the wavlet
> transform and my dithereing drawing method.

I don't know what your dithering drawing method is, but its only
relation to the wavelet transform is that they both have recursive
elements to their structure.  But then again, so does counting to 100
by tail recursion.

>  Hm. or I could make the dithering method go 1 level deeper (with some
> easy adjustments to avoid over calculation of points) and derive anti
> aliasing from there.

Dithering != anti-aliasing; either we are not using the same terms
consistently, or we have some confusion on what "anti-aliasing" and
"dithering" really do.  One would typically apply anti-aliasing to a
full 24-bit RGB image and then dither it to the resolution of the
device (i.e. 16-bit color, or 8-bit LUT).  The two techniques are
often useful at the same time, but you definately do not want to try
and "anti-alias" a dithered image if you expect to get quality
results.

>     BTW: how're things with the flat memory model?

Clunking along.  I am trying to get my own business off the ground
before I run out of $$, so I can't work on the flat memory model
24/7.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Thu, 27 May 1999 14:57:38 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

On Wed, 26 May 1999, Phil McRevis wrote:

>
> In article <[e-mail]>,
>     Humberto Rossetti Baptista <[e-mail]>  writes:
>
> >     Ups, old terminology: i meant diffusion method (i changed the name some
> > time ago to avoid confusion, but I keep forgetting :-)
>
> Ah... OK, that makes much more sense.
>
> >  I do not see how we can do anti-aliasing without reducing the resolution
> > of the final image.
>
> In the context of fractals, it is impossible to construct a bandwidth
> limited version of the fractal that you then sample.  Because you are
> always sampling a "thing" which has frequency components higher than
> the highest representable frequency component on the screen, you
> always have aliasing.  If you could bandwidth limit the fractal before
> sampling it, then the samples would reproduce the frequencies exactly
> and no anti-aliasing would be needed.
>
> So, we're stuck with aliasing and the best we can do is try to
> minimize the aliasing by applying anti-aliasing techniques.  This
> generally implies supersampling the fractal and filtering the
> supersampled fractal to the final resolution.  In order to support
> anti-aliasing, fractint would need to devote memory storage (either
> incrementally on a scanline-by-scanline basis, or in toto) to the
> supersampled image.  The screen displays the result of the
> anti-aliased filter.
>
> >     *   *  < pixels in the maximum resolution evaluate
> >       #    < interpolated pixel calculated on a 2x resolution than above
> >
> >     What could the interpolated pixels help on the anti-alias calculation?
>
> Decimation and interpolation are opposites.  Decimation (usually
> combined with filtering; decimation without filtering just throws away
> pixels and/or scanlines) decreases the number of pixels in an image
> and interpolation increases the number of pixels in an image.  When
> you are approximating a fractal with a few samples, then you
> interpolate.  If you have more samples than your final resolution, you
> decimate -- hopefully with a nice anti-aliasing filter so that you
> don't introduce aliasing in the decimation process.
>
> >     I think I miss somenthing here as I see little advantage on the use of
> > anti-alias on our fractal drawing work.
>
> Damien has a wonderful set of images on his web area that exaplains the
> advantage of anti-aliasing for fractals.
>
> > [...] the scheme you presented was so
> > simple (to the sense that it interferes little with the existent code) that I
> > was curious to know.
>
> As it stands right now, the X11 "driver" appears to be working OK for
> the code that I migrated from unixscr.c into d_x11.c; what is missing
> is native X11 text output (so that an xterm window + curses isn't
> required for X11 text output).  My plans are:
>
>     o add native X11 text output
>     o integrate driver into the video mode selection logic, similar to
>     the ASCII mockup I posted earlier
>     o massage curses driver for "graphic" output a la XaoS
>     o massage disk driver for diskvideo output
>
> Then what remains is to go through the use of memory to remove the
> overlay and wacky memory buffers that fractint uses.  Things like
> MK_FP() will go away, but since a single chunk of memory is aliased
> (like a fortrash common block) by different routines, that will take
> some careful work.  Finally, all the "far/huge/near" qualifiers on
> memory can be removed (FCODE too).  At that point, I'll take the code
> over to the DJGPP -- I'm currently developing everything on unix since
> the tools and debuggers are more familiar to me -- and get disk and
> curses video drivers working on DOS.  The final thing will be to get
> the assembly code working for graphics output on DOS.  This may be
> more trouble than its worth for me, and instead I may just implement
> a graphics driver based on allegro and leave the assembly code to some
> other motivated individual :-).
> --
> <http://www.xmission.com/~legalize/>    Legalize Adulthood!
>     ``Ain't it funny that they all fire the pistol,
>       at the wrong end of the race?''--PDBT
> [e-mail]    <http://www.eden.com/~thewho>
>
> --------------------------------------------------------------
> Thanks for using Fractdev, The Fractint Developer's Discussion List
> Post Message:   [e-mail]
> Get Commands:   [e-mail] "help"
> Administrator:  [e-mail]
> Unsubscribe:    [e-mail] "unsubscribe fractdev"
>

    Humberto R. Baptista
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>pu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>+++++$ h(---)>*$ r+++
y+++*
- ------END GEEK CODE BLOCK------



- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Thu, 27 May 1999 16:00:48 -0300 (EST)
From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

    Sorry last one went without the actual reply.

On Wed, 26 May 1999, Phil McRevis wrote:
>
> So, we're stuck with aliasing and the best we can do is try to
> minimize the aliasing by applying anti-aliasing techniques.  This
> generally implies supersampling the fractal and filtering the
> supersampled fractal to the final resolution.  In order to support
> anti-aliasing, fractint would need to devote memory storage (either
> incrementally on a scanline-by-scanline basis, or in toto) to the
> supersampled image.  The screen displays the result of the
> anti-aliased filter.


    Right, now I'm seeing the point.

>
> >     *   *  < pixels in the maximum resolution evaluate
> >       #    < interpolated pixel calculated on a 2x resolution than above
> >
> >     What could the interpolated pixels help on the anti-alias calculation?

> Decimation and interpolation are opposites.  Decimation (usually
[...]

    Hm. But if we go calculating an over sampled image then we use the pixes
of higher frequency to influence the cnormal frequency ones and with this (an
the appropriate filter) generete the anti-alias effect.

> Damien has a wonderful set of images on his web area that exaplains the
> advantage of anti-aliasing for fractals.

    I'll check.

[...]
> the assembly code working for graphics output on DOS.  This may be
> more trouble than its worth for me, and instead I may just implement
> a graphics driver based on allegro and leave the assembly code to some
> other motivated individual :-).

    Great, it seems very interesting and motivating. If you need any help at
any point (for instance on the setup of DJGPP w/ the appropriate tools) let me
know. Th idea of linking against allegro seem like a good one for me. I'll allow
the proliferation of colaboration on the flat model version.

    []'s

    Humberto R. Baptista
    [e-mail]

- ---------------------------------------------------------------------------
Insite - Solucoes Internet                         http://www.insite.com.br

- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>pu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>+++++$ h(---)>*$ r+++
y+++*
- ------END GEEK CODE BLOCK------



- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Thu, 27 May 1999 15:42:55 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: (fractint) Re: last bug report

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:

> Hm. But if we go calculating an over sampled image then we use the pixes
> of higher frequency to influence the cnormal frequency ones and with this (an
> the appropriate filter) generete the anti-alias effect.

With the supersampling anti-aliasing method, what you are doing is
attempting to integrate the signal (i.e. the fractal) over the 'area'
of the pixel and come up with an appropriate average value.  This is
what makes highly dense chaotic regions fade to a uniform shade as the
characteristic length of the chaotic region approaches the dimensions
of a pixel.  In a strict mathematical and signal processing sense, you
still have an aliased image, but the aliasing is at a higher frequency
component which isn't as perceptible.

In this sense, "anti-aliasing" is a bit of a misnomer, because it
attenuates the effect of aliasing but doesn't eliminate it.  The only
way to truly eliminate aliasing is to limit the bandwidth of the
signal before it is sampled.  For real-world signals like audio, they
can be bandwidth limited before sampling so that aliasing isn't a
problem.  For synthetic signals like fractal renderings or ray-traced
scenes, it is difficult if not impossible to limit the bandwidth of
the signal before sampling.  Theoretically, one could analytically
limit the bandwidth of a raytraced scene, but in practice it is so
computationally intractable that supersampling is a more realistic
solution.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Thu, 27 May 1999 18:23:49 -0400 (EDT)
From: [e-mail] (Kragen Sitaker)
Subject: (fractdev) Re: antialiasing

Rich writes:
> Theoretically, one could analytically
> limit the bandwidth of a raytraced scene, but in practice it is so
> computationally intractable that supersampling is a more realistic
> solution.

Hmm, that's an interesting thought.

Have people actually analyzed the computational complexity of doing
this?  Clearly it would require significantly more complex *programs*,
but they might not necessarily run slower.

It is not obvious to me how to do it at all, either for raytraced
scenes or for Mandelbrots.

- --
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
- -- http://www.performancecomputing.com/opinions/unixriot/981218.shtml


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Thu, 27 May 1999 16:29:16 -0600
From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Re: antialiasing

In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:

> Have people actually analyzed the computational complexity of doing
> this?  Clearly it would require significantly more complex *programs*,
> but they might not necessarily run slower.

<shrug>  The only reason I believe it theoretically plausible for
ray-tracers is that one can obtain a description of the scene in
closed form.  You may have to restrict your scene a little bit in
order to maintain a closed form -- i.e. no procedural mandelbrot
textures.

Since you can't get a fractal into a closed form, that is what
prevents you from analytically limiting its bandwidth in the scene.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Fri, 11 Jun 1999 10:04:35 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) rhide?

Has anyone else had any problems using rhide (the djgpp IDE) with
Win98?  Every time I quit the IDE it hangs my whole system (even the
three-finger salute doesn't get its attention) and I have to
soft-boot.
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Thu, 17 Jun 1999 15:34:02 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) List glitch

There was a problem with the fractdev list the last few days, but it
has now been fixed

Tim Wegner

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 7 Sep 1999 19:16:20 -0600
From: "Tim Wegner" <[e-mail]>
Subject: (fractdev) Xfract proposed release

We are inches from releasing a new version of Fractint. The only
reason it isn't released now is that Robin and Bill have requested
time to make some evolver and sound demos.

The proposed Xfractint packaged is at

ftp://ftp.phoenix.net/pub/USERS/twegner/tw04.zip

This is still pretty rough. Is there anyone who could look at the
makefile?

What are good default directories for BINDIR and SRCDIR? The
current ones in Makefile don't seem appropriate for Linux. I have left
things pretty much the way Ken Shirriff set things up originally. He
did a good job, although I can't say that I like hard coding
directories at compile time. There must be better ways, maybe
using SSTOOLS.INI and at most hardcoding where that file is.

There are hundreds of new mapfiles that Anglea a.k.a Wizzle
collected a few years ago. I have dumped them all into the
distribution. In the Fractint DOS distribution I left them in a zip file.
Maybe that is better. Any opinions appreciated.

Tim




- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 28 Sep 1999 10:07:30 -0600
From: Phil McRevis <[e-mail]>
Subject: (fractdev) DPMI for DOS

Tim,

Didn't you ask recently about a DPMI for DOS?  I found this on the
NT emacs page (<http://www.fsf.org/software/emacs/windows/ntemacs.html>)

    People who would like to run Emacs on plain DOS (as opposed to
    Windows) will need to download and install a DPMI host at this URL:

    ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2misc/csdpmi3b.zip
- --
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.thewho.net>

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 11 Oct 1999 19:14:28 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) DPMI for DOS

Does anyone know a place where there is a nice short summary of
 different open source licenses? We are about to embark on a
major redo of Fractint, and this would be a good time to use a
better license.

If anyone has some recommendations we'll listen, if the
recommendation comes with a real short three-or-four point
summary of what that flavor of license accomplishes.

I guess what I need is a list of a few questions with yes or no
answers that indicates which license to use when I'm done
answering :-)

Tim


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon, 11 Oct 1999 22:36:19 -0300
From: Humberto Baptista <[e-mail]>
Subject: Licences (was:Re: (fractdev) DPMI for DOS)

Tim Wegner wrote:
>
> Does anyone know a place where there is a nice short summary of
>  different open source licenses? We are about to embark on a
> major redo of Fractint, and this would be a good time to use a
> better license.
>
> If anyone has some recommendations we'll listen, if the
> recommendation comes with a real short three-or-four point
> summary of what that flavor of license accomplishes.

    There are three tht I know reasonably well:

    GPL, LGPL and BSD-style.

    The first, GPL (GNU Policy Licence), says that the program is free in
the sense that people are allowed to freely copy, modify and use, but it
mus always contain the copyrights and all direived work should have the
same license.

    The LGPL (Lesser GPL or as was previolsy known: Library GPL) is a less
restictive licence that the first one. Is is like GPL but is allows
other programas to be linked to the one under LGPL (or to use an API of
a LGPL program) without imposing any restricions on them or on their
licences. It is good for libraries, programs that support external
compiled modules etc.

    The BSD-style is less restrictive yet. It allows the same kinds of
freedom guaranteed by GPL BUT it does not require the modified versions
(derived work) to be free, that is you can make a commecial program and
conceal the sources if you only mantain the original Copyright.

    The licenses (especially *GPL) are rather long if there is interest I
can post the three above.

> I guess what I need is a list of a few questions with yes or no
> answers that indicates which license to use when I'm done
> answering :-)

    There is the issue of the original authors permitting a change of
licence. I dont know if this is really a problem, but should be thought
out anyway.


    Humberto R. Baptista

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 12 Oct 1999 08:06:12 +0200
From: Tonton Th <[e-mail]>
Subject: Re: (fractdev) DPMI for DOS

Tim Wegner wrote:
>
> Does anyone know a place where there is a nice short summary of
>  different open source licenses?

    You can try http://www.opensource.org/ or ...
    ... ask Richard Stallman !

> We are about to embark on a
> major redo of Fractint, and this would be a good time to use a
> better license.
>

    Oh ? It's a dream or I have really read:
        "an independant 32bits fractal engine" ?

- --
            ----------------------------------------------
       <  tonton Th  /  Thierry Boudet  /  Mr Oulala  >
        ----------------------------------------------

- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 12 Oct 1999 17:10:54 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: Licences (was:Re: (fractdev) DPMI for DOS)

>     There is the issue of the original authors permitting a change of
> licence. I dont know if this is really a problem, but should be thought
> out anyway.

This is an issue but I don't think it is a practical problem, especially
if the new license is similar to the old one. We would make an
effort to contact contributors.

The real problem is that the existing legalese is just something we
wrote down and is not clear or airtight.

Tim


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Tue, 12 Oct 1999 17:10:54 -0600
From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) DPMI for DOS

Thierry wrote:

>     You can try http://www.opensource.org/ or ...
>     ... ask Richard Stallman !

Yeah right, I'm sure I know what license he advocates :-)

>     Oh ? It's a dream or I have really read:
>         "an independant 32bits fractal engine" ?

It's still a dream until we do it!

Tim


- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

Date: Mon,  1 Nov 1999 01:32:16 -0800
From: tim gilman <[e-mail]>
Subject: Re: (fractdev) DPMI for DOS

> [e-mail] (Tim Wegner) wrote:
> (on 10/12/99 at 5:10 PM)
> Thierry wrote:
>
> >     You can try http://www.opensource.org/ or ...
> >     ... ask Richard Stallman !
>
> Yeah right, I'm sure I know what license he advocates :-)

Is there some sort of list or outline describing what a new
license must necessarily preserve or emphasize?

> >     Oh ? It's a dream or I have really read:
> >         "an independant 32bits fractal engine" ?
>
> It's still a dream until we do it!
>
> Tim

Where can I get the latest code sync for the fp only base?
I'd like to start running this dream down..  I'll be using a
sparc10 to run and test XFract, but I'll also be building
some prototypes and developing on a Mac.

Thanks,

=- Tim
[e-mail]



- --------------------------------------------------------------
Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"

------------------------------

End of fractdev-digest V1 #25
*****************************