» Introducing: The Editing Framework
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Introducing: The Editing Framework

For years now vvvv is shipping with little helper modules like the AxisAndGrid (EX9), Camera (Transform Softimage), PointEditor (3D)... and some more that are hopefully saving you a lot of time while patching. In fact the Camera was the very first module i ever built when we introduced the concept of subpatches. It didn't work well, so gregsn took it over, fixed it and made it a Softimage one as this was the software he was used to at that time...

Anyway, we maintained those modules over time but kinda failed to review/consolidate them. Not least because they were always a bit tricky to handle. While they look quite simple from the outside they are rather complex internally. And as you may have noticed, at certain complexities vvvv patches become a bit tedious to maintain...

Entering VL. With VL we now allegedly have the right tool at hand to tackle such complexities. To put it to a test we thought it would be a good time to rework those Camera and Editor modules. So we went ahead keeping the following things in mind:

Design Goals

  • Modularity: a clear line between Model and View allows
    • easy reuse of individual parts in custom editors
    • a simple way to adapt the look of an editor by simply providing an alternative View node
    • to easily provide DX9 and DX11 versions of all editors
  • Persistence: editing state can be saved to and loaded from disk
  • Boygrouping: editors can be used in boygrouping scenarios by simply putting a halfboygrouped module (provided) between Editor and View
  • Undo/Redo: editing steps can be undone/redone

Performance

By building them with VL (which, remember, is a compiled language) we were hoping for improved performance because the existing modules were actually quite CPU hungry. And indeed we got better results immediately even though there's not been put too much effort in optimization on the VL side yet.

Drawbacks?

Of course! Mainly one though. A little one. More an annoyance. Not a big deal really. You may not even notice it..well..after a while.. in fact some people may even love it..niiiooaaa.. here is the thing: The first time you're using one of those new modules, VL is loaded, which takes a while. That really only happens once per session though, so lets for now pretend it is not that bad...

Here is what you get

  • PointEditor
  • BezierEditor
  • BezierPatchEditor (was: GridEditor)

Each of the above come in two flavors: 2D, 3D

Besides the above design-goals here is what changed with the modules for the user:

  • no more need to connect Mouse/Keyboard
  • no more need to tag points before moving them
  • no more need to press different mousebuttons for operating on different axis. interact with on-screen pivot element instead
  • better handling of point-dragging with extreme camera views
  • on-screen-display informing about the current transformation
  • MeshEditor (EX9) now also modifies normals
  • AxisAndGrid now has pins to show/hide axis and grid

Bonus:

Next Steps

The editors still need a bit of finetuning in terms of interaction and also their internal architecture is not yet exactly optimized for readability. Then the DX11 versions of the views need to be patched but that should be rather trivial since it is really only about drawing. So now you please give it a spin and feed back your findings before we're going into a second round..

Available now in latest alpha builds.

joreg, Tuesday, Feb 23rd 2016 Digg | Tweet | Delicious 6 comments  
u7angel 23/02/2016 - 11:45

one question, if the tings are compiled, is there a way to import the compiled nodes into vvvv without having to initialize the whole VL framework ?

bjoern 23/02/2016 - 14:36
joreg said
Anyway, we maintained those modules over time but kinda failed to review/consolidate them. Not least because they were always a bit tricky to handle. While they look quite simple from the outside they are rather complex internally.
joreg said
The editors (...) internal architecture is not yet exactly optimized for readability.

hm...

joreg 23/02/2016 - 16:26

@bjoern: have a look at both yourself and you should see there is a huge improvement and still a lot to make even better..

joreg 23/02/2016 - 17:51

@u7angel: yes, at some point we could have a "save as .dll" option or do some caching like dynamic plugins do. for now all vl stuff can be inspected at any time and is always freshly compiled.

u7angel 24/02/2016 - 12:47

this would be a nice interim solution, using vl compiled nodes without the vl overhead...

i guess "at some point" means its not yet possible at all ?

joreg 24/02/2016 - 14:30

jes, not possible at the moment.

  • 1

anonymous user login

Shoutbox

~16h ago

metrowave: @mediadog, YOU lucky dog!

~20h ago

~1d ago

colorsound: Hi guys some poc of laser and projection ;D https://vimeo.com/colorsound/laser-projection-interaction

~2d ago

mediadog: @metrowave I just saw the Wilfred Lumia exhibit in DC - I wept. Pics/videos do it no justice, analog = infinite resolution!

~4d ago

udo2013: BeatDetector(bass)not working.ErrorCode from red node:"PLUGINS \BassSound dll BassSound Data BeatDetectorNode" is missing.WhatToDo?