Welcome to Fractal Forums

Spline paths over 28 Keyframes 1500 Frames 60 Seconds
Rendered with Fragmentarium 1.0b+

http://vimeo.com/moogaloop.swf?clip_id=72241427

I think this "world" is going to be explored a few more times.

 Source Code (http://www.digilanti.org/fragmentarium/) Modified from v0.9.51 "Amber"
 Windows Executable (http://www.digilanti.org/fragmentarium/) Compiled against Qt 5.1.1 with MinGW 4.8.1 on a Windows 7 box.

awesome! the camera path is perfect!

Thanks  :D
starting from scratch was a good thing.

Looks great. Very smooth camera control.

tnx  :D

I used a spline function from Inigo Quilez, I did have to modify it so that the start and end points landed on the first and last control points but that was just a little bit of logic and not my math skills that made it work. Have a look at the next animation, Liberta, there you can see where it breaks down at the end, not enough decimal places in a float me thinks.

I love the atmosphere in this video.

tnx  :)

I like the "Alien Organic" sort of fractals but some of the intricate geometric stuff is very cool too.

that animation possibilities is just nice, until now it was so hard to make a decent
animation out of a fragmentarium script, just consider what is possible with keyframing
regarding that kalis winner image of this years axolotl section was a single fragmentarium script ;)

it's not enough to create keyframes, still need to implement a good management system, maybe the "Animation Controller" window will make a comeback as "Keyframe Editor" and save them as a separate file instead of wedging them into presets and settings.

I hope I've got this board off to a good start

maybe we'll see a deep exploration of kalis winner soon  :dink:

I kind of like the idea of storing data in presets, though. I think it would work out alright with a few changes.

It would be possible to create animations without messing up the original fragment, just by including the file before starting making an animation, e.g.


Especially, if the system automatically sorted the entries and removed any redundant parameters that didn't change between keyframes.

This way the UI could do with a simple 'Animation' toolbar, with buttons for [Add Keyframe] and [Write Keyframe Presets] and [Read Keyframe Presets].

 :embarrass:
isnt there a function for save a current param configuration as preset ???
 :embarrass:

Sure, but I imagined the button would write all the keyframes to the editor, sorted, and with the proper time stamps, and removed redundant settings.

the way you layout the GLSL frag side of things lends itself well to that idea, I imagine the keyframes portion could be "#include"ed at the end of a fragment as well.


there's so much more to keyframing than add/read/write there's also twiddle, fiddle, adjust, compensate, rearrange, insert, remove etc.
I had an "entity" in mind that presents a list of current available parameters to add/remove, with each in the "added" list for this keyframe presenting options based on what kind of parameter it is when selected for editing.
Also using "default" preset for parameters that don't change and being able to drag flags along a timeline to position the in/out points for this keyframe.
There is also the idea of overlapping transitions, how does that fit into one keyframe? something else in my mind is per/parameter timeline that is to say: eye/target paths use keyframes to represent controlpoints but parameter transitions may not sync-up with what the camera is doing and so each one needs a timeline of their own.


F8 key (3dickulus version (http://www.digilanti.org/fragmentarium/Fragmentarium-v0.9.53Dickulus.zip)) ;D saves to editor as preset or keyframe, for preset it jumps to the end of file, for keyframe inserts at cursor or overwrites marked block.

The idea was that you could create some keyframes, and then write them as a set of preset. Then if you needed to remove or adjust or fine tune some of them, you could just do it in the text file and press the 'Read Keyframe Presets' button to parse the changes.


I imagine that when you pressed the 'Add Keyframe' buton, it would create a keyframe but only with the changed information compared to previous keyframes. This would make overlapping transitions easy, e.g.

easy for coder, confusing for artist, but anyone working with Fragmentarium should have some idea of what the numbers are doing when they tweak them a little this way or a little that way


yes, that works :) I have kept the camera/path keyframes separate from the other parameter settings just so I can keep from getting confused and work on one thing at a time, my implementation of each works smoothly, now just need to refine and merge them.

saving fov,eye,target,up as path keys, (the absolute minimum for a valid preset,I think?) with parameter datas saved on one line as...
representing...
|parseflag|varName|curveName|curveNumber|startVal|endVal|startFrame|endFrame|period|amplitude|overshoot

the last three are QPropertyAnimation settings only valid for some easing curve types but included with default values for all

edit: part of the reason I've kept them separate is that parameter easing curves are very different than eye/target paths, mathematically identical, sure a curve is a curve but completely different in what they represent.

How about a poll?

Should things that change the world be kept separate from things that change the object?
ie: camera path/settings vs object parameters/attributes

Harkening back to my early days with Turbo Silver (Amiga raytracer) the object edit mode and camera edit mode were in separate view ports, the camera had a single perspective view while the object had three X,Y&Z ortho views each using 1/4 of the screen, a pretty standard sort of thing now. The global editor handled things like camera, background, lighting, environment maps, while  the object editor handled points, lines, polygons and their colors, attributes and materials. It was comfortable and worked well. In this case we don't have an object with points and polys to edit just a formula with lots of parameters and in some cases the object is the world. What used to take hours on my 16Mhz 68000 cpu now gets rendered in milliseconds, oh how things have changed, maybe I'm just being nostalgic :)

now back to animating....

Soon ihope to begin a de based renderer haha if none other starts first
in fact the thinking is reasonable and the camera needs more sophisticated control  in such a de based environment an additional obstacle comes into play one has to deal with drasric scale changes so that when zoomed very deep the control has to reflect that and move slower

in my eyes fragmentarium should not aim for a full set of threed controls, it is a convenient gpu editor which can be used for other things than threed scenes but nevertheless the animation tools need improvement editing pathes of parameters is just a pure joy especially sincr they adjust dynamically to new params

Yes you're right, it's not a "3d scene modeler" it's a "fragment/vertex shader editor", the 3 things I've implemented, path, morph, and focal plane target, were just to see if I could and cuz I wanted them, really the first thing I said after playing with Fragmentarium for the first time was "how do I animate this, I want to fly around in there".
It's done to my satisfaction in that I can use it now to make some funky animations, I probably won't do much more coding unless something bugs me to the point where I just have to fix it but will always be available for input and Qt bug busting ;)

shift+mousewheel adjusts the step size but automatic adjustment would be nice, the question will be:how to tell when zoomed in as opposed to just moving around. Leads me to think it will always be a manual thing.

currently in Fragmentarium the FOV is adjusted with the xyz eye position when zooming with left mouse + right mouse + move but the FOV is not adjusted when zooming with the mouse wheel. also the value is 0.0 - 2.0, needs to be in human terms like degrees.
So, real (photographic) zoom = FOV+/- while the eye xyz position remains the same, in 3D computer generated world FOV and xyz make zoom so to tell how zoomed you are you need to test FOV, xyz eye pos and distance to surface. A photographer would use Macro lens when close to subject and telephoto lens for far away, so really same thing in 3d world, the animator/artist has to setup for the type of scene, in the heart of a flower? or taking in a panoramic vista?.