VEX: Space Filling Curves (aka “that Windows 95 Screensaver”)

comments 17
Tutorials
Featured Video Play Icon

Another question that we’ve been asked is how to rebuild a setup similar to that infamous screensaver that slowly filled your display with a maze of pipes. Among various approaches (including some L-System experiments) the most naive setup won. Of course.

Here it is in its simple glory. A brute force approach that yields a maze of individual pipelines that will completely fill any give space (read: volume) that you throw at it. Have fun and leave some feedback!

Download Project File (.hipnc)

Share on FacebookTweet about this on TwitterPin on PinterestEmail this to someoneShare on LinkedInShare on Google+

17 Comments

  1. Emilio says

    Hello Moritz,
    Very nice tutorial, thanks!
    I would like to ask you two things:
    1) How can we change the speed of the lines
    2) Is there a way to turn this into geometry and export it as Alembic?

    • Moritz says

      Hi Emilio,

      the overall speed can be changed by increasing the solver sub-steps. If you want individual lines to have different velocities, the first thing that comes to my mind is to store an attribute on each line’s leading point which stores how many iterations the solver should run. What you’d have to do in the wrangle is import this attribute and have a loop run the given amount of times stored in that attribute.

      Of course you can save this as alembic. The process isn’t any different from the process described here: http://www.entagma.com/quickie-exporting-geo-from-houdini/ However if you’d like to export an animation as alembic you have to buy either Houdini Indie or commercial and use the ROP Alembic output node.

      Cheers,
      Mo

  2. Axel says

    Awesome tute, you canΒ΄t expect less from Moritz.

  3. Ivan says

    Hi Moritz,

    First of all, thank you for this and the other great tutorials you have posted before.
    I have followed the tutorial step by step but when i add the delete node all the points stay there, then when i change from delete selected to delete non-selected, the node deletes all the wires between points but the points are still there. Do you have any idea about why is this happening?

    Thanks for your time!

    • Moritz says

      Hi Ivan, did you compare your setup with the scene file we provided? Maybe that’s gonna shed some light on what is happening there.

      Cheers,
      Mo

  4. For me this tutorial jumps quite deep into code and I find it quite difficult to follow. I think for people with programmatic backgrounds maybe it’s fine but for me it’s too much information. Maybe if I watch a couple of times it will be ok πŸ™‚

    • Moritz says

      Hi Shane,

      one quick solution would be to put the pointwrangle that’s inside of the solver into a for-loop and set that loop to a high number of iterations so the point grid you feed into it will be filled with curves each frame. Be aware however that there are several factors in this setup that are most likely gonna yield a flickering animation as the wires are generated randomly each frame.

      Cheers,
      Mo

      • Aha! Thanks so much for your speedy reply Moritz! I actually tried that and got pretty excited that it was working per-frame. However, go figure that now it’s going to be a flickering animation as you said which is really not what I’m going for. Is there anyway to store that data somehow from frame to frame so that it doesn’t jump and re-calculate to different positions? Any thoughts on what I might be able to look into or try?

      • Made some progress by using a Point Deform node in order to allow the Points from Volume points to stay static with the mesh. πŸ˜€ Now it’s way less jumpy but still some slight issues, no where near as bad though…… Seems other issues might be part of the randomization in the vex code itself I’d imagine.

  5. Yesss! Figured it out!!! Basically you do a Point Deform setup before the VEX code to make the Points from Volume stay the same and not re-calculate. Then you go through the VEX code setup without changing anything at all aside from bringing the VEX code out of the solver and into a for loop. From there you just do another Point Deform node setup *before* the delete SOP and it will hold the shape of whatever frame you put in the time shift. πŸ˜€

    If you’re curious to see the node setup: http://shane-oshea.com/wp-content/uploads/2017/04/Yayyyyy.png

    Thanks for helping point me in the right direction!!!!

    • Moritz says

      Nice one! Very cool that you plowed through it and figured it out all by yourself – good job!
      Cheers,
      Mo

  6. Darwin says

    Whats the reason to not use the group slot in the wrangle node? I saw it in another tutorial as wel.

    • Moritz says

      I had no specific reason for that – it’s a decision based purely on my mood / realtive atmospheric pressure that day / wind direction and temperature of my second coffee πŸ™‚

      Seriously though – there really isn’t any specific point why I used the if-statement instead of the SOP’s grouping function. Just ran a benchmark – and the speed difference between both techiques (0.3s over 250 frames) is in my opinion neglegible.

      Cheers,
      Mo

  7. Darwin says

    Cool!
    Thanks for clearing that up and definitely appreciate the effort to do a benchmark, was just curious if there was a specific reason behind it that I wasn’t aware of. πŸ˜‰

    Keep up the good work!

    Ps : The pointsfromvolume node does accept geo as wel. shaves a couple of clicks.

Leave a Reply

Your email address will not be published. Required fields are marked *