The best way to explore a Fragmentarium hybrid...

[3dickulus]

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

<a href="http://vimeo.com/moogaloop.swf?clip_id=72241427" target="_blank">http://vimeo.com/moogaloop.swf?clip_id=72241427</a>

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

 Source Code Modified from v0.9.51 "Amber"
 Windows Executable Compiled against Qt 5.1.1 with MinGW 4.8.1 on a Windows 7 box.

[cKleinhuis]

awesome! the camera path is perfect!

[3dickulus]

Thanks 
starting from scratch was a good thing.

[Syntopia]

Looks great. Very smooth camera control.

[3dickulus]

tnx 

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.

[Dinkydau]

I love the atmosphere in this video.

[3dickulus]

tnx 

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

[cKleinhuis]

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

[3dickulus]

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 

[Syntopia]

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.

Code:

#include "fractal.frag"

#preset Keyframe 0.1
pos= 23,45
#endpreset

#preset Keyframe 0.3
pos= 28,56
....
#endpreset

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].

[cKleinhuis]

 
isnt there a function for save a current param configuration as preset
 

[Syntopia]

isnt there a function for save a current param configuration as preset
 

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.

[3dickulus]

@Syntopia: 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.

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.

@Syntopia: 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].

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.

@cKleinhuis: isnt there a function for save a current param configuration as preset

F8 key (3dickulus version) 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.

[Syntopia]

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.

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.

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.

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.

Code:

#preset Keyframe 0.2
Param1 = 1
 
#preset Keyframe 0.5
Param2 = 1

#preset Keyframe 0.7
Param1 = 5

#preset Keyframe 0.9
Param2 = 13

[3dickulus]

Then if you needed to remove or adjust or fine tune some of them, you could just do it in the text file

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

This would make overlapping transitions easy

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...

Code:

/// Power:SineCurve:43:1:6:20:220:0.3:1:1.7

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.