#dmwow makes things

[the-dmwow]

Working on making another iris.

I’m using the new peel-away sockets from keeb.io for socketing the pro micros, which has had its own fair share of gotchas. It was surprisingly easy to accidentally separate a socket from its plastic backing before soldering it, which makes it difficult to keep all the sockets aligned.

For the other half, here’s what I think the ordering should be:

Solder the sockets first without trying to pre-insert diode legs. Peel away plastic backing.

Add pro micro, use diode legs as headers for the pins. Solder them onto the pro micro.

Pry out the pro micro with a knife or a thin screwdriver (the peel away sockets are much thinner than other variants I’ve used, so a knife might be the only tool thin enough). I ended up getting some solder through the holes in the pro micro, so I needed to use a lot of force to pry them loose.

Solder diodes and switches, then insert pro micro back into place.

[the-dmwow]

I’ve been working on creating an engine for writing interactive fiction with ReactJS for a few days, and my plan is to draft out that violent lesbian story with it.

I’ve already written the absolute bare-bones features: you can write pages as React components, style them with CSS, link between pages normally, and save / load your place in the story.

Today I added integration with Spectacle — which is a slide deck library.

Parts of the story can now be written as a slideshow (and then gracefully link to another page). It looks like Spectacle has pretty good support for animations too, which is nice.

(The only gotcha is that it plays weirdly with react-router by default, since it’s not really meant to be used as a part of a larger app. I had to set react-router’s historyMode to browser so that it wouldn’t create an infinite chain of hashes in the addressbar.)

At any rate, I am unreasonably excited about this. I honestly think that ‘slideshow’ is a pretty good format for telling visual stories, and I want to show that for myself.

[the-dmwow]

Now interrupting your regular Inktober to show off more keyboard renders.

I think I’ve gotten to the space where the lighting and rendering parameters are setup properly. I’m still not 100% about camera parameters, but either way it’s waaaay too much fun to just create renders of various angles.

[the-dmwow]

(and yes, the alpha colors changed to purple along the way – I had to re-import the keyboard model, and ended up tweaking some things along the way. I’m anticipating that I’ll use red alphas, but the purple does kinda look nice.)

[the-dmwow]

After a bit more tweaking of the lighting parameters (and colored lights!), this is what I’m ending the night on.

I don’t think I have a good enough eye to say whether or not my changes are making things better or worse right now – I think I’ll need to play around with lighting a lot more to get that feel for myself.

But I think I’m at a good enough state to move on, for now. Maybe I’ll actually design some novelties…?

[the-dmwow]

I’ll be done with lighting after this post – this is apparently material from a course on lighting at University of Washington, and has the best description of 3 point lighting I’ve seen yet: https://courses.cs.washington.edu/courses/cse458/05au/reading/3point_lighting.pdf

I should really go to sleep now.

[the-dmwow]

Tumblr doesn’t seem to like the big screenshots, so here’s a clearer look at the de-noising panel. (I’ll have to fix Tumblr bot so that it grabs full size images…)

[the-dmwow]

Noise in Blender

As I was doing the rendering, I realized that they were pretty noisy:

It almost looked like there was a thin layer of static on the render, and while it looks great from a distance, it bothered me a lot. Apparently this is not an unusual problem for Blender / Cycles, so I’ll note here the things I did to solve it.

Increase samples – this was the most common tip given to people who asked about this.

Uh, it’d take a while to truly explain what a sample is, so hopefully the short version makes some sense: basically, the program is trying to calculate what color each pixel should be, given the scene and the lighting, and each ‘sample’ is a single calculation of how light would travel to reach that pixel. Since light can bounce randomly, each calculation doesn’t give a very accurate view of what the scene would actually look like, but if you do it a bunch of times, the results will average out to generally the correct values.

Anyway, this is the panel to actually change the number of samples:

Note the square samples checkbox – I’m not sure why this is a feature, but if it’s checked, then the actual number of samples would be the number squared. In this screenshot, we actually would render with 144 samples.

The downside of increasing samples is that more calculations take more time. It slows down rendering considerably. I’ve found that I get a lot less noise with around 250 samples – 1000 would be ideal apparently, but I’m not that patient.

Blender’s De-noising function

Increasing samples decreased noisiness, but I don’t think I was ever able to make it totally go away. Fortunately, new in 2.79, Blender also has a (ridiculously well-hidden) de-noising function that goes through and cleans up the noise from the renders as it’s rendering.

It’s in the ‘render scene’ tab of the properties manager, at the very bottom.

Checking that also slows down render time a lot, but got rid of virtually all the noise. I’ve seen some warnings about increased memory usage from this function, and it can produce other artifacts, but given a high enough sampling rate, I’ve been satisfied with the results.