Skip to main content

Posts

Tech Art Bits: Making a basic Web API with Clacks

If you read my first tutorial on "getting started with Clacks" , you might have thought to yourself, not entirely unfairly, that it is not very convenient to _need_ clacks to talk to a clacks server. This is entirely true, and precisely for this reason, in this tutorial, we will be diving into creating a simple HTTP server using standard REST API methods (GET, POST). In this tutorial, we will need two libraries as prerequisite installs for the code snippets to work, Which can both be found on the github pages that are linked if you click on them below. clacks clacks_web Of course, as always, you can download the sample content for this tutorial here: https://github.com/MaVCArt/clacks_tutorials/tree/main/02_SimpleWebAPI Table of Contents Step 1: Create a simple REST API server As before, you can see that the standard clacks_web library offers most of what you need out of the box. In fact, it takes fewer lines of code to build a simple REST API with clacks_we

Tech Art Bits: Getting started with Clacks

clacks  (find it here on github: https://github.com/MaVCArt/clacks ) is a modular TCP framework, designed to be as extensible as possible through the user of various factory-pattern and class-composition-inspired techniques.  In this article, we'll go through a step-by-step guide on how to set up your own server instance in a native python interpreter, and how to attach your code to it through the ServerInterface class, which comes built-in with the vanilla clacks environment. This is repeated at the end of the article, but if you want to skip right to the end and just download the code, you can do so here: https://github.com/MaVCArt/clacks_tutorials/tree/main/01_GettingStarted Table of Contents Step 1: setting up the server First, run the following pip command to install the clacks library; pip install git+https://github.com/MaVCArt/clacks.git@main This will install the default library, with all the bits and pieces you will need to get a fully functional server

Tech Art Thoughts: Remote Development and "Soft Control" Development Environments

One of the most common considerations I have to take into account in my day job is that of User Environments. Like most technical artists, I do not fully control the machine set-up for most of the people using the tools I help build.  This is pretty common; as tech artists, we can ask our IT departments to distribute specific software packages, maybe even versions, but beyond that there's little we can do to ensure a given user is set up entirely in line with our wishes, short of us physically walking over to their desktop and checking it for ourselves; an option not always available to us. Table of Contents The Three Degrees of Control There are many ways to describe the degree of control you can exert over a given user's development environment as a software engineer. However, for the sake of simplicity, I like to categorize them using the following three labels: "Overlord", "Squad Chief" and "Distant Observer". Overlord In the "

Tech Art Bits: Basic DCC Environment Setup

When setting up a new DCC, or building basic infrastructure for your studio's artists to use, one of the most critical components to get right from the start is how they launch, use and interact with their content creation tools, otherwise referred to as DCCs (short for Digital Content Creation software). If you export your content from, say, Maya, you want to ensure that all Maya files in your project are set up correctly, using the same unit scale, system units, up axis, frame rate, etc...  You also don't want any of these things to be left up to the artist; there are simply too many things that can go wrong, and the cost of issues like this not being caught until a great deal of content has been produced incorrectly can potentially be crippling for a project. So how do you ensure a DCC is setup for the artist, correctly, every time they launch it? The simple answer: give them a launcher that does it for them. "But" I hear you say, "launch

Tech Art Bits: Extending Unreal Editor with custom menus using Python: Part 2

Continuing on from my first post on the subject , here we will dive into properly expanding upon the theme of hooking custom python-based menus into the various menus and toolbars that Unreal has to offer. For the sake of example, I will limit myself to containing this to just the Level Editor Toolbar, but I will write another post on how to set your menus up (almost) anywhere in the Unreal Editor Interface. Now that we've got a menu, we can start expanding it! In this example we're going to be building a custom menu using the ToolMenuEntryScript class, which allows developers to implement overrides for various functions it contains, including the execute() function, which allows one to implement multi-line (much more complex) functionality and tie it to a menu entry.  This is a surprisingly undocumented feature of Unreal Engine, and it is very difficult to research without diving into C++ yourself, so I will be breaking things down here. First, let's clean up

Tech Art Bits: Extending Unreal Editor with custom menus (with Python): the Level Editor Toolbar

One of the most common problems tech artists are in need of solving is that of delivery; how do we get our tools into users' hands? There are various answers to this question, and each use case demands a different implementation: for asset-centric tools, a context menu in a content browser tends to work best. For more generic tools, some kind of launcher is generally preferred. In my day job, I work with Unreal Engine, and this is a question I run into a lot, and one I've had to solve a few times. I recently started getting more stuck into this problem however, and I thought I would share what I learned. I should add that I received some assistance in this from friends at Epic Games and the Technical Art Community, who were kind enough to ask around internally at Epic for the solution to the final bit I was stuck on. So let's dive straight into the code, as that's what you're probably here for. Note that all code in this post has been tested on Unreal Engine 5, but

Tech Art Bits: Basic texture packer with PIL

One of the most common parts of any pipeline is a texture packing process of some sort. This is usually the result of the complexities of a shader, requiring artists to adhere to a rigid packing spec to maximize performance and pack masks as efficiently as possible. In any production of any scale, 3D art production will involve some amount of texture packing. There are many ways to perform texture packing, and not all of them require some kind of pipeline solution. However, once the packing spec reaches a certain level of complexity, a measure of control over the packing process becomes desirable. In this article, we will build a simple texture packer (which works with .TGA files and most other common file formats), that could lay the foundation of building a more complex one on your own, without requiring any expensive software licenses to do so. Building the base class Implementing a simple Mask Packer Now that we have a simple base class, we can get to work on the "meat