Phellow Phractologists,
<br>
<br>Thank you all, for your help with the 'fractint.cfg' dilemna. Fortunately a backup was at hand. I was going to throw a newer .cfg file in there, but I noticed that periodicity checking seems to have been dropped from versions after 20.02.5 (at least it doesn't appear on the 'Y' menu anymore). Not sure if this would cause problems, so I went with the OEM. Is this a recently-discarded option, or does the toggle reside elsewhere now?
<br>
<br>As for the 3D pixel concept, Jonathan wrote:
<br>
<br>"Given that, conceptually, it isn't any harder to iterate through a
<br> volume than it is to iterate through a plane, what you suggest is
<br> possible.  However, I'm sure the devil is in the details.  For example,
<br> what points would be displayed?  We only have a 2-dimensional surface to
<br> display on.  If we are going to display an x-y plane with a fixed z
<br> value, then Gerald's formula is an acceptable solution."
<br>
<br>The question of which points to display is probably the easiest to answer (and hopefully to implement as well); only points that fail to escape display. An 'outside = no color' option, so to speak. There are other details, of course, but a basic functionality shouldn't require very much. There could be a default volume, i.e., a Z value proportionate to X and Y; but there would also be a need for variable inputs for the front and back clipping planes. A question that arises here is, "Do Z-axis values always auto-scale, or would they stay fixed through zooms?" Naturally, Z floats to the same accuracy as X and Y, and about all we need now is a way to interface the existing 3D rotation functions with our new workspace...
<br>
<br>That said, per your suggestion
<br>
<br>"Take a look at the julibrot type.  It may be more along the lines of
<br> what you have in mind.  It might be possible to expand it to use the
<br> formula type."
<br>
<br>I'm now more familiar with the existing formulas, and it does appear that most all I've suggested is already there. Indeed, to work from this context would evidently be a quick and easy way to get started, and that deserves consideration. There are, however, many possible variants of these new formulas, and it seems that ultimately a 3D pixel option will afford a lot more freedom to explore.
<br>
<br>Russell
<br>
<br>
<br>
<br>---------[ Received Mail Content ]----------
<br>>Subject : Re: [RE]Re: [Fractint] 3D pixel
<br>>Date : Sat, 14 Oct 2006 16:07:27 -0500
<br>>From : Jonathan Osuch <osuchj@avalon.net>
<br>>To : Fractint and General Fractals Discussion <fractint@mailman.xmission.com>
<br>>
<br>>Russell,
<br>>
<br>>> As to your 3D pixel question, we'll hopefully get to that... but just
<br>>> a moment ago, in the Fractint 20.02.5 program file, I saw this icon
<br>>> named 'MAKEFCFG.EXE'. "Hmm... what's that do?" I wondered, even as I
<br>>> reflexively gave it a click... Suddenly a small dos screen opened,
<br>>> quickly closed and a file named "fractcfg.old" appeared in the
<br>>> folder. 
<br>>> No big thing, but as I then opened the program, I discovered that my
<br>>> choice of video modes is now severely constrained: F2 to F10 and SF1
<br>>> to SF3 are my only remaining options. I deleted the .old file, but the
<br>>> former functionality has not returned. Any suggestions? 
<br>>
<br>>You need to restore the original fractint.cfg file.  Either from a
<br>>backup or from the latest developer's zip file.
<br>>
<br>>> As to the original question, ideally a 3D pixel would allow us to
<br>>> write/render formulas such as 
<br>>> 
<br>>> M3D { 
<br>>> Zrng = (-2,2) 
<br>>> a = Xpt(3Dpix), b = Ypt(3Dpix), c = Zpt(3Dpix) 
<br>>snip
<br>>> Gerald's formula is innovative and ingenious, but ad hoc. A built-in
<br>>> 3D pixel would surely save rendering time and ultimately provide many
<br>>> more options for resolution, colors and so forth. 
<br>>> 
<br>>> Of course, there are a lot of ramifications to this idea; but even the
<br>>> most basic implementation would be a good start, and it would be fun
<br>>> to see where it eventually leads... 
<br>>
<br>>Given that, conceptually, it isn't any harder to iterate through a
<br>>volume than it is to iterate through a plane, what you suggest is
<br>>possible.  However, I'm sure the devil is in the details.  For example,
<br>>what points would be displayed?  We only have a 2-dimensional surface to
<br>>display on.  If we are going to display an x-y plane with a fixed z
<br>>value, then Gerald's formula is an acceptable solution.
<br>>
<br>>Take a look at the julibrot type.  It may be more along the lines of
<br>>what you have in mind.  It might be possible to expand it to use the
<br>>formula type.
<br>>
<br>>Jonathan
<br>>
<br>>
<br>>
<br>>_______________________________________________
<br>>Fractint mailing list
<br>>Fractint@mailman.xmission.com
<br>>http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
<br>>
<br>>
<br>