Salutations! Welcome to the second part of my post on my replica of Penny’s Sword from Rooster Teeth’s animated web show RWBY. If you haven’t read part 1, go ahead and check it out. When we left off, most of the parts were shaped and primed but not yet assembled. This time we’ll get into the painting, and some of it might be hard to visualize so take a look at the tournarounds if you’re not sure what I mean.
In this post, I’ll show you how I built a light-up replica of Penny Polendina’s unnamed swords from Rooster Teeth’s excellent animated web show RWBY. RWBY is what originally got me into propmaking - I’ve already made Yang’s Ember Celica shotgauntlets and Adam’s Wilt & Blush Sword/Shotgun Combo. This is the first time I’ve documented my process, so hopefully you find it useful.
Blueprints & Design First, a quick overview of how I intended to do this build.
Inspired by the always-incredible work on Dolphin, I decided to write myself an NES emulator called Corrosion a couple years ago. I managed to get it working well enough to play basic games, and then put the project aside. This post is not about the emulator itself, but rather the JIT compiler I added to it last year and the upgrades to said JIT compiler I’ve made over the past few weeks.
Long, long ago (December 2015) I wanted to learn how emulators worked, so I decided to write an NES emulator. Not only that, but I opted to write it in Rust, a language which I had never used before. A crazy idea, to be certain, but once I was done I had indeed learned a great deal about emulators, the NES, and Rust.
Anyway, I’ve been working on that project again lately, doing some maintenance work and upgrades.
Hello! This is a detailed example of exposing Rust code to other languages (in this case, Python). Most articles I’ve seen that cover this topic uses really trivial example functions, skipping over a lot of the complexity. Even the better ones out there typically don’t have a pre-existing, reasonably complex program to work with. I’m going to start with trivial functions and build my way up to being able to define a scene for my raytracer in Python using a series of calls to Rust, then render it and return the resulting image data back to Python.
Hello again, and welcome to the final part of my series on writing a raytracer in Rust (Part 1, Part 2). Previously we implemented a basic raytracer which could handle diffuse shading of planes and spheres with multiple objects and multiple lights. This time, we’ll add texturing, reflection and transparent objects.
First, I’ve refactored the common parts of Sphere and Plane out to a separate structure. Since this post is all about handling more complex surface properties, we’ll need a structure to represent them and avoid duplication.
Welcome to Part 2 of my series on writing a raytracer in Rust. If you haven’t already, you may wish to read Part 1. Previously, we implemented a basic raytracer which can render only a single sphere with no lighting. This time, we’ll add multiple objects, planes, and basic lighting.
Multiple Objects It’s pretty easy to change our scene definition to contain a Vec of spheres instead of just a single one.
Hello! This is part one of a short series of posts on writing a simple raytracer in Rust. I’ve never written one of these before, so it should be a learning experience all around.
So what is a raytracer anyway? The short version is it’s a computer program that traces the paths of simulated rays of light through a scene to produce high-quality 3D-rendered images. Despite that, it also happens to be the simplest way to render 3D images.