Shop Forum More Submit  Join Login
About Deviant MattMale/United States Group :iconfractorium: Fractorium
 
Recent Activity
Deviant for 4 Years
Needs Core Membership
Statistics 26 Deviations 87 Comments 4,802 Pageviews
×

Newest Deviations

Hexes Perlin Honeycomb by mfeemster Hexes Perlin Honeycomb :iconmfeemster:mfeemster 2 3

Favourites

Journal
Hypertile Basics
First of all, special thanks to Zueuk who had the patience to explain me all the hypertile stuff =D
There is also an awesome hypertile tutorial that you should check out first: Hypertile Uncovered With 3D
 
 
Basics
To make a basic hypertile, you will need 2 transforms: Basic hypertile
hypertile2, rotated 180 degreesbubble (small amount, about 0.25 lets say) with pre_blur

The exact bubble size to fill a hypertile can be calculated exactly, or you can just change the amount of bubble until it fits.
The hypertile has two parameters, p and q. Basically, this means it takes p-gons, with q polygons meeting at each vertex (this do
:icontatasz:tatasz
:icontatasz:tatasz 51 15
Hypertile Uncovered With 3D by guagapunyaimel Hypertile Uncovered With 3D :iconguagapunyaimel:guagapunyaimel 142 24
Journal
Interview with Matt (Fractorium dev)

First of all , please introduce yourself to the community.

My name is Matt. I’m 35 and I live in San Diego, California, United States with my wife. I graduated with a Bachelor’s degree in computer science in 2001 and have been working ever since writing software. This project was done outside of my full-time job as a senior software developer.

And, of course, tell us about your software.

My project has several pieces and can be found here:https://github.com/mfeemster/fractorium/wiki
Before I give the details, I’d like to preface it by saying this is beta software, so you might find bugs or things that you don’t like. Rather than reject it, I would really appreciate feedback so I can incorporate good ideas into future releases.
With that out of the way, here it is:
Ember - A rewrite and redesign of the original flam3 code in C++. In addition to the rewrite, several bu
:icontatasz:tatasz
:icontatasz:tatasz 9 13
Journal
Return
Hi there! :wave:
I was so much inactive these days that some of you maybe don't even know who am I ;)  Well, I was busy at my new job, but now I'm back, and you can try catching me at #Aposhack channel.
Apophysis 3
It is that time when you can post your thoughts or ideas about new Apophysis. Yes, it is under its way :)
Be warned though, the new major version number is not for nothing... Apophysis 3 will be a huge step forward.
The most important thing is it will support layers. Every layer can be a flame, a background,
a time-escaped fractal... and probably other types, too. A single design can have as many layers, as you can create.
Isn't it fascinating? :)
It's also one and the only moment when we can get rid of Delphi and scripting library - finally! It's in C++ with Qt4,
which means it's portable and relatively easy for other coders to mess with it as they like.
The main design is ready, skeleton code is up and running - now I ne
:iconutak3r:utak3r
:iconutak3r:utak3r 14 238
Starting Out: Learning Apophysis by ChaosFissure Starting Out: Learning Apophysis :iconchaosfissure:ChaosFissure 160 67

Groups

Activity


Various testers have reported serious animation bugs. Upon close inspection, I found ten major animation bugs. This is unfortunate because it means all existing animations were likely wrong, and you'll need to regenerate the sequence, then re-render them. The bugs have been present since the program's initial beta release in late 2013.

--User changes
  -No longer constrain pitch, yaw or depth spinners to -180 - 180.

--Bug fixes
  -Always write animate tag on final xform when saving to Xml.
  -Clamp flame rotation values to -180 - 180 when reading a flame from Xml.
  -Events were not properly wired for user changes in the random rotations per blend controls in the sequencer.
  -Fix major UI bugs with sequencer min/max random controls which made it nearly impossible to hand type values.
  -Values from rotations per blend and rotations per blend max were not being saved to file between program runs.
  -Checking animate for an xform was not applied to all flames even if Apply All was checked.
  -Changing interpolation type, temporal filter width, temporal type, and affine interpolation type were not actually saving to the flame when changed.
  -Grid on the main window was not being drawn at the right scale initially due to some OpenGL initialization occurring in the wrong order.
  -Severe bugs in sequence generation code:
   --Motion was being applied incorrectly.
   --Improperly detected padding xforms.
   --Properly set color index on padded xforms.
   --Adding a padding final xform included a linear variation with a weight of zero to not appear empty. Made it have a weight of 1.
   --Prevent divide by zero when normalizing variation weights.
   --Was accidentally adding the placeholder value of -9999 for motion_offset to varation weights and parameters when applying motion. Set to zero if no value present.
   --When looking for specific variations during xform aligning, only presence was detected, when it should have been presence plus a weight greater than zero.
   --When adding specific variations during xform aligning, must first remove any variations of that type.
   --Two variables were unsigned when they should have been signed. This prevented large blocks of code from ever executing.
   --When interpolating affines, an EPS that was too small was used, causing affine values to interpolate incorrectly. Instead use 1e-10 to ensure results equal to flam3.

My sincere apologies, but the last release, 1.0.0.8 had a severe bug in it such that I had to make a new emergency release.

The render pausing feature in the final render dialog only worked for CPU renders. It did not work when using the GPU.

This has been fixed, so pausing works for both types of renders now.

www.fractorium.com
I hope everyone is doing well. Everything is great on my end. It appears my releases have slowed to about twice per year, which is roughly what I planned at this point in the life of the program.

This release fixes some bugs and adds some features as usual. Below are the important changes with explanations in bold.

--User changes
 -Change variation spin boxes to only show the precision needed, and also allow scientific notation.
   (This makes the variations list box a little easier on the eyes since it will now show less unnecessary zeroes. It also supports scientific notation. See how you like it after getting used to it and let me know if it's worse than before in which case I'll change it back.)
 -Add pixel_flow variation from user bezo97.
 -Add two new variations, hypercrop and hypershift2 from user tatasz.
 -Add the ability to drag the rotation of the current palette via the palette preview table.
  (This was requested by a user because Apo has this functionality.)
 -Allow for pausing and resuming of final renders.
  (This is useful if you're doing a big render using the final render dialog, and want to pause to use your machine for something else.)
 -Allow for animating final xforms.
  (The ability to rotate a final xform the same way regular xforms are rotated during the "loop" phase of animating a keyframe was strangely disallowed in flam3. My animation code is just a port of flam3 and I had never thought twice about this behavior. An eagle eyed user spotted it and requested the ability to allow for animating final xforms.)
 -More detailed diagnostics when any action in the OpenCL renderer fails.  -Allow for creating an OpenCL renderer which does not share a texture with the main window, and instead manually copies its final output image from GPU to CPU then back to GPU.
  (When using the GPU in the editor, the final buffer where the image is rendered to is the same place in memory used for the OpenGL texture to display it on the screen. This is an optimization trick which alleviates the need to copy the data from one place to the other. For some strange reason, a user with two identical Nvidia cards reported that creating the OpenCL renderer would continually fail for this reason. So I added an option in the options dialog called "Shared Texture". Uncheck this if you are suffering from this extremely rare problem. Note there is a slight performance penalty on each edit because the final image must be copied from the GPU, to the CPU, then back to the OpenGL texture on the GPU.)
 -Allow running command line programs from outside of the folder the executable is in, by adding the install folder to the PATH variable.
  (Users running the command line tools were always required to be in the folder where the executables are located. One user reported the desire to be able to add the install folder to the system PATH variable, then run the command line tools from anywhere.)


--Bug fixes
 -Fix a variety of very strange bugs when clicking around on palettes in different files in the palette editor.  -Animate flag was not properly being set when checking the checkbox, and also did not work correctly when Apply All was checked.
 -Text was not properly being copied out of the Info | Bounds text box.

I normally don't post code change information in these journal entries, but I made some changes that were rather significant under the hood. I finally converted the old fixed function pipeline OpenGL code to the newer (2005+) GL Shading Language system. I had been meaning to do this for years, and it was quite a pain, but am glad it's finally done. The user should not see any difference between the old and new systems, but it was just something I wanted to do. Also, embarrassingly, it was the first time I had learned to use GLSL (over a decade late), so that was a personal side benefit.

Download here.
Another release for Windows and Linux just in time for Christmas! Mac version coming next week.

For Linux users: Note that in order to use apt to install it from the repository, you need to add the ubuntu repository "artful". If you do not do that, you will not be able to access the new version. Alternatively, just download the .deb from fractorium.com and install directly. I had to move to artful to use a newer version of Qt.

This release focuses mostly on bug fixes and new variations, but has a couple of cool new features that are important: Support for 4K monitors and the ability to create multiple linked xforms at once. Thanks to the users who helped me out with reporting bugs, testing and adding new features: IDeviant, RationalParadox, triptychaos and others!

Important issues are bolded below.


--User changes
-Support 4k monitors, and in general, properly scale any monitor that is not HD.
-Allow for a spatial filter of radius zero, which means do not use a spatial filter.
-Add new variations: concentric, cpow3, helicoid, helix, randCubes, rays1, rays2, rays3, sphereblur.
-Use a new method for computing elliptic which is more precise. Developed by Discord user Claude.
-Remove the 8 variation per xform limitation on the GPU. You can now use as many variations per xform as you want.
-Allow for loading the last flame file on startup, rather than randoms.
-Use two different default quality values in the interactive renderer, one each for CPU and GPU.
-Creating linked xforms was using non-standard behavior. Make it match Apo and also support creating multiple linked xforms at once.


--Bug fixes
-No variations in an xform used to have the same behavior as a single linear variation with weight 1. While sensible, this breaks backward compatibility. No variations now sets the output point to zeroes.
-Prevent crashing the program when adjusting a value on the main window while a final render is in progress.
-The xaos table was inverted.
-Place the xforms and palette tabs in a scroll area to prevent weird sizing problems on low resolution monitors.
-Allow group dragging and floating of dock widgets.
-Make some tables auto size to their contents because some text appeared obscured on Linux.
-Opening an Xml was not properly setting the background field on the GUI, even though it was correctly parsed and used.
-Clicking random palette when using a palette file with 2 palettes could lead to a program freeze.


In addition to these new features and bug fixes, I've gotten around to my long sought after goal of making a benchmarking suite. I've gotten flames from users golubaja, tatasz, tyrantwave, and zy0rg (major thanks to all). I run some tests on the CPU and GPU and put the results in a spreadsheet, which you can analyze further on your own. In order to run the benchmark, go into the Bench subfolder in the install folder:

C:\Users\[YOURNAME]\AppData\Roaming\Fractorium\Bench

Open up a powershell window there and ensure you have permission to run scripts on your machine by running:

> Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass

You only have to do this once.

Edit the file EmberBench.ps1 and see the third line:

> $devices = "2"//Set this to whatever device index your main GPU resides at. If you are unsure, just run emberrender --opencl info to find out.

You need to set that device index to whatever device index your GPU resides at.

Save the file, close all other programs, then run

> .\EmberBench.ps1

Which will take a about 15 minutes and output the results into a file in the parent folder called benchout.csv. It also creates benchout.txt which just gives the program output if you're interested in it.

Open benchout.csv in a spreadsheet viewer and optionally make a bar chart out of it to see how different flames perform in terms of iterations per second on the CPU and GPU.

fractorium.com/
My sincere apologies, but the previous release had a major bug in it: rendering with strips would crash the program.

Please go to fractorium.com and download the latest, 1.0.0.6

Sorry for the runaround, but things like this happen with only a small number of people testing.
Various testers have reported serious animation bugs. Upon close inspection, I found ten major animation bugs. This is unfortunate because it means all existing animations were likely wrong, and you'll need to regenerate the sequence, then re-render them. The bugs have been present since the program's initial beta release in late 2013.

--User changes
  -No longer constrain pitch, yaw or depth spinners to -180 - 180.

--Bug fixes
  -Always write animate tag on final xform when saving to Xml.
  -Clamp flame rotation values to -180 - 180 when reading a flame from Xml.
  -Events were not properly wired for user changes in the random rotations per blend controls in the sequencer.
  -Fix major UI bugs with sequencer min/max random controls which made it nearly impossible to hand type values.
  -Values from rotations per blend and rotations per blend max were not being saved to file between program runs.
  -Checking animate for an xform was not applied to all flames even if Apply All was checked.
  -Changing interpolation type, temporal filter width, temporal type, and affine interpolation type were not actually saving to the flame when changed.
  -Grid on the main window was not being drawn at the right scale initially due to some OpenGL initialization occurring in the wrong order.
  -Severe bugs in sequence generation code:
   --Motion was being applied incorrectly.
   --Improperly detected padding xforms.
   --Properly set color index on padded xforms.
   --Adding a padding final xform included a linear variation with a weight of zero to not appear empty. Made it have a weight of 1.
   --Prevent divide by zero when normalizing variation weights.
   --Was accidentally adding the placeholder value of -9999 for motion_offset to varation weights and parameters when applying motion. Set to zero if no value present.
   --When looking for specific variations during xform aligning, only presence was detected, when it should have been presence plus a weight greater than zero.
   --When adding specific variations during xform aligning, must first remove any variations of that type.
   --Two variables were unsigned when they should have been signed. This prevented large blocks of code from ever executing.
   --When interpolating affines, an EPS that was too small was used, causing affine values to interpolate incorrectly. Instead use 1e-10 to ensure results equal to flam3.

deviantID

mfeemster
Matt
United States
Software developer and author of Fractorium. Looking to advance the tools and ideas of the fractal art community.

Comments


Add a Comment:
 
:iconesherymack:
Esherymack Featured By Owner Aug 2, 2017  Hobbyist Digital Artist
Hi! :wave:
I just found Fractorium today, wanted to say thanks for a renderer that can use OpenCL, lol :D
It's a fantastic program, easy to use, fast, and produces good results. Thank you, keep up the good work :D
Reply
:iconmfeemster:
mfeemster Featured By Owner Aug 3, 2017
Glad you like it! There are some bugs in that version with the Mac build. I will be releasing a new version soon.

Just curious, what OS are you using and what graphics card?
Reply
:iconesherymack:
Esherymack Featured By Owner Aug 3, 2017  Hobbyist Digital Artist
lol, I'm actually using it on Windows 10 (most recent version, not sure what it is, but post Creator update) on an AMD Radeon Sapphire 390x with backplate (www.sapphiretech.com/productde…). So kind of a beefy computer :lmao:

Renders a 2200x1444 fractal in under 40 seconds, with results almost what I get from 3-5 hours of rendering in Apophysis, or an hour and a half in Chaotica. Super fantastic :D
Reply
:iconmfeemster:
mfeemster Featured By Owner Aug 14, 2017
Very glad to hear it! I run an R9 280x and love it. It was one of the last mass market cards they released which had good fp64 support.

The new version of Fractorium has been delayed a bit, as some of my testers have discovered bugs. Keep an eye on my journal for when I release it.
Reply
(1 Reply)
:icondotaandme:
DotAandMe Featured By Owner Jun 1, 2016  Hobbyist Digital Artist
Hey!
I'm here to wish you a really happy birthday! I wish you the better results for all you're doing!
Keep it up and don't give up, there's not a lot of people out there doing what you are :)

I hope to help you somehow in the future,
Enjo the rest of the day! :D
Reply
:iconmfeemster:
mfeemster Featured By Owner Jun 3, 2016
Thanks Dot, I am aiming to wrap things up by the end of this month. In the meantime, check out the website, I finally got it up! www.fractorium.com
Reply
:icondotaandme:
DotAandMe Featured By Owner Jun 11, 2016  Hobbyist Digital Artist
Of course! Keep it up! :)
Reply
:iconbrusvejn:
brusvejn Featured By Owner Oct 1, 2015
Thanks!
Reply
:iconnightmaretf:
NightmareTF Featured By Owner Dec 2, 2013  Professional Digital Artist
Nice work with Fractorium! It's excellent.
Just one thing I was wondering about, though. Somehow images won't render above a certain (I'm not sure where the tipping point is yet, but 2560x1600 rendered ok for sure, under a minute @ 5000 quality :D) resolution for me, are you familiar with such a problem?
Using a 560GTX for rendering.

Again, awesome work! Thanks :)
Reply
:iconmfeemster:
mfeemster Featured By Owner Dec 8, 2013
Hi NightmareTF,

Both Fractorium, and its associated command line programs EmberRender, EmberAnimate and EmberGenome have no hard coded limit on anything. The limit is how much memory your GPU has. Sadly, GPUs are much more memory limited than the usual CPU configuration. For example, I'm running with 8GB of RAM, yet my GTX 460 has a measly 1GB. I looked up your card, and it's got 1GB also.

If you go into the final render dialog of Fractorium and play with the size and supersample values, you can see how much memory it requires to run.

Also don't forget, part of your video memory is also reserved for use in general system video display, so the usable amount for rendering will be less than the advertised 1GB.

As a last resort, if you really need a huge render, but don't want to buy a new card, switch to the CPU renderer.

Hope that helps, let me know how it goes. I'll be releasing updated versions with new features/bug fixes periodically.

Thanks for using it!
Reply
Add a Comment: