Showing posts with label technical. Show all posts
Showing posts with label technical. Show all posts

Saturday, 3 September 2022

Drawing the line


I'm currently re-making an old Missile Command-esque ZX Spectrum Next game I wrote a couple of years back that, to be honest, could have been way better (but I really didn't know any better back in those days).  There are some graphical differences I want to make, and one of the major considerations regarding graphics is how I can get more speed when it comes to creating linear missile trails.

Wednesday, 17 June 2020

What is MMUFPHK?

Yes, what is MMUFPHK?  I recently ran into a situation regarding file management and team production which resulted in a task I decided to call Massive Multi User File Path House Keeping.  This is where you (hopefully don't) find multiple Maya project folder structures that have become buried within a singular project on a team server, and worse - production files that are referencing or importing elements from a variety of these individual project folders.

Monday, 10 September 2018

Archive those Maya projects - cleanly...

A great way to make sure that you keep the project files that made up your scene in Maya is to use Maya's File menu's Archive Scene option.  One of the reasons I like Archived scenes is that it keeps things clean.  It makes sure that only those files that make up the project are backed up, which then ensures we don't end up with the usual bombardment of multiple 'test' files, WIPs, etc.  This is a great way to set up a project to be transported across to say, a render farm.  Which was part of my original goal for developing this...


Saturday, 28 October 2017

Maya TD tips - that awesome 'toolkit' you always wanted...

I got tired - tired of seeing icons on shelves in Maya disappear and noting that even when working, flipping to shelves to change the tool set that was being used meant the pipeline tools that I'd painstakingly developed would be hidden in a shelf that probably wouldn't be set back again when needed.

Friday, 13 October 2017

Maya swatch headaches be-gone!

This was something that frustrated me this afternoon, so much that I thought I'd slap this very short and concise blog entry for anybody interested...

I loaded up a rather complex project to test that had been set up to use VRay materials, and had been choking up and causing havoc on the render-farm here. 

Wednesday, 16 August 2017

More TD tips - Trello for task management

In any pipeline, communication is key - sharing and passing data back and forth, whether its from application or process to another or from a manager to an artist.  Over the years I've developed plenty of scripts to manage file naming, server logging and automating processes.  I'd also built a SQL feedback and approval system that didn't see the light of day - and after reviewing what I'd done, it was a great learning process but it was fairly limited.

Sunday, 15 January 2017

Beeps and bleeps - playing Speccy music in python

While I was messing about with converting old UDG graphics to PNG files, I figured one of the other things I was curious to recreate was the beepy music from the ZX Spectrum.  BASIC code loaded with BEEP commands created that "I wonder what does that sound like?" curiosity that made me wonder just how easily I could use python to listen to the classic Sinclair hits of the 80's...

To export or just listen?

I tried two methods.  One was to make use of python's wave module.  This is a module that allows you to work with audio files.  That includes the ability to both read and write.  Being able to export the music to a .wav mean't that it could be bought into those recreated games and used.

One problem I did run into was getting the beepy-sound out nicely.  I tried many of the tried-n-tested code examples online that generated a sine wave - however while it worked, the final audio sounded pretty odd and didn't have that nice clean bleep I was expecting.  I figured I'd come back to this later...

Exporting aside, I felt there must be a better way to just listen to the music - afterall, its that curiosity of hearing what it sounded like I was after.  Lucky python has a module designed just for the task... The winsound module.  I also wanted to create pauses in the music, so I imported the sleep function from the time module as well.

import winsound
from time import sleep

Yup, winsound has a Beep function (note the uppercase B).  Much like the ZX Spectrum's own beep, you just pass the note and duration.  Sounds like it should be a real doddle!

Hmmm, note vs. frequency

ZX Spectrum audio uses semitone numbers.  A value of 0 is middle C.  1 is the next semitone of C# / Db, 2 is D and so on.  However winsound.Beep required a frequency value (in hertz).  How do I translate that number into a frequency?

Did I mention I suck at maths?

Maths was never my strong suit at school, but luckily for me that's where the internet comes in with the answers!  The formula for calculating a frequency is simply

Frequency = base-note * a^semitone

Where base-note is the lowest frequency of your musical scale (in this case, I decided to go for 3 octaves below which is 32.70 hertz).  The value of a is calculated as the 12th root of 2 ( in nerdy math terms, its 2^(1/12) ).

Maths always looks easier in code

I created a function to calculate the correct frequency from the beep value.  I calculated this from the lowest frequency of 32.70...  As I knew middle C (beep value of 0) was three octaves higher, I just added 36 (which was 3 * 12 semitones) to the value first...

In case you're wondering about the code below, 0.083 is 1 / 12.

def beepFreq(ZXVal):
    zxNote = ZXVal + 36
    a = 2.0 ** 0.083
    freq = 32.70 * (a**zxNote)
    return freq

Getting them tunes down...

The music data itself I passed as a sequence of tuples in a list, copied directly from the BEEP parameters in the spectrum listing.  This isn't the most musical of pieces, but it came from a listing so it was a good test...

As there were often pauses added through music, I needed a way to indicate this.  I used a note value of 99 to signal a pause.

musicData = [ (.1,0),(.1,0),(.1,2),(.1,2),(1,0),(1,99),
              (.1,0),(.1,4),(.1,4),(.1,0),(.1,0),(.1,2),(.1,2),
              (.1,-1),(.1,-1),(.1,0),(.1,0)]

Looping through this list, I read the duration and note value.  The duration is slightly different between the winsound.Beep function, and the sleep() function that I used to introduce pauses.  The Beep function requires the length in milliseconds.  This is simply the duration from the list multiplied by 1000.  The sleep function just uses the value (number of seconds) directly.

The rest of the code was a piece of cake.  I feel there's no real explanation necessary as the code can speak for itself...

for musicPlay in musicData:
    # Calculate the duration (in milliseconds)
    duration = int(musicPlay[0] * 1000)
   # Work out if we play a note, or whether this is a pause
    if musicPlay[1] == 99:
        sleep(musicPlay[0])
    else:
        note = int(beepFreq(musicPlay[1]))
        # Call the Winsound Beep
        winsound.Beep(note,duration)

Budum-tish!

And there you have it.  Go grab those old ZX Spectrum basic listings and type in the beep values to enjoy all of those bleepy tunes that were part and parcel of games in the 80's

Monday, 7 November 2016

Maya 2016 - small changes make for some small headaches

Lately I've been running into a few issues with projects and scripts that relate to some small changes made in Maya 2016, and 2016.5.  Like most of my discoveries, I'm posting them to the blog here for those of you who may find them of use...


Saturday, 29 October 2016

Subfolders, referencing - Yes, its more Maya scripting fun!

In the last couple of weeks, I've had to modify and tweak all the scripts that I developed for my students to automate file management from Maya.  In the process, I added new features and added extra functionality to handle some of the changes that this class had decided to implement.

One of my students asked me if I would be sharing these things on my blog - so yup, here we go - again...  I have a few, but to keep these posts nice and short I'll start with just a couple.

Saturday, 6 August 2016

Fixing a sticky stick...


As you may have seen in a previous post on the blog, I bought an old Atari 2600 a while back. It came with two sticks.  One looked in better condition then the other, however while it may have looked better, it was actually a lot worse then it looked in terms of play-ability.

After a few rounds of River Raid, I found having to push extremely heavily to get a reaction out of the game indicated that perhaps the contacts in the joystick had worn down...  With these old devices, its basically a set of little metal 'clickers' (best description I can think, though I'm sure there's an official name for them) that push down and make contact in a circuit - and when these lose their conductivity - well, that's when you die in River Raid, more times then you would like to!

So - I decided that perhaps one way to make sure I show everybody my true River Raid expertise would be to fix up those unreliable contacts...  And what better way could there be then replacing tired old technology with modern micro switches.

Cheap as chips

I went ahead and ordered some micro-switches from Aliexpress.  They cost US$1.15 (free shipping) for a bag of 50.  Locally here in NZ, these can sell for NZ$0.50 each, so I definitely made a better choice spending my dollar and a half.

2-pin 6 x 6 x 5mm switches

Technically I only needed about 5, but you can never have too many spares - which was lucky, as I did run into 2-3 duds...

Opening it up

The Atari stick is a real doddle to open up - just 4 screws in the bottom.  The only thing to watch out for was a small spring that sat below the fire button, but other then that its just a collection of plastic bits and nothing overly technical to worry about - especially when it comes to that "Heck!  How do I put this back together!?" moment.

Nice and simple...  No crazy "springs-go-everywhere" panic here!

The 2600 Vader model I believe was released in NZ around 1984-ish, making these around 32 years old.  It was covered in dust, worn plastic and the plastic coating on the PCB was bubbling in places.  What I needed to do was to lift the 5 metal clickers from the PCB...  Like most joysticks of this era, these are usually held down with a plastic tape/adhesive cover - and in this case, the whole board was covered in one big sticky sheet.

32 year old dust...  Ewww!

With some careful craft-knife action, and a finger-nail I did pull away a lot of the plastic.  I needed to ensure that I had plenty of track to solder my switches on as well.

Lifting the clickers - a little cut-n-scratching...

A little methylated spirits and cotton bud action, it was looking pretty clean and ready for the switches.

Looks brand new - well, kinda

Switched on

It wasn't as easy to get these switches on as I'd first thought.  Each switch is pretty tiny and I needed to make sure that the switches sat over that central point where the pad had been.  Also, the legs needed to be bent about to match the tracks.

Holding buttons down on a smooth circuit board is tricky - they slip and slide about a little more then I'd liked.  I could have glued them down first, but I didn't want to do that should I need to replace out one later on.  It took a handful of 'finger pressing' and careful maneuvering of a hot soldering iron to prevent melting my skin off as I soldered each one in place.

Soldered on - ready to play... Almost!

Did it work?

As I attached each individual switch, I felt I should really make sure that the switch works before carrying on to the next.  I had an old app on my Samsung Tablet for testing gamepad diagnostics.  There are plenty of tools for this - do a simple search on the Google play website - and its handy for such a project.

I'd also just bought a 9-pin to USB adapter so I could use my old joysticks with my RPi games (retroPie) so hooking that in to the tablet let me see when a switch was pressed...  It cost about $15 (free shipping) from Aliexpress and came with a pretty nifty USB adapter on the end.  This saved me having to dig out my OTG cable...

Very cool USB adapter lets me use this on both Tablet and Pi!

I did run across a couple of switches that didn't appear to work, and one that operated as though it was always on, and pressing down made it go off.

Since I'd actually tested these switches with a multi-meter prior to soldering them in, I'm not sure why that's the case, though some I had held down when soldering. My only real guess here is that possibly the heat, combined with the depressed button could have caused damage to the switch...  But it wasn't hard to just grab another!  (Given there were 50 of them).

Almost done

I finally managed to solder all of them in.  They sent appropriate on-off as expected through the tablet and I started to reconstruct the joystick.  However there were a few things that I had to do before this would work.

These had to be surgically removed.

The main one were the pins on the joystick shaft that were designed to press down on the contacts. The original pads were around a millimeter high, but these new switches were 5 mm (about the same length as these pins).  That mean't I had to cut those off - in fact, I had to make sure that they were 100% flat - even a small amount of plastic was too much.  But it worked.

The fire button was the same.  I had to remove the pin in the center completely.  I also had to remove the spring which let it bounce back up, though this wasn't an issue given that the micro-switch has its own spring loaded button.

And lastly - the switches had to be pretty accurate in where they sat on the PCB.  I found the down switch was just slightly off, and that meant the joystick shaft was on one side of the button rather then directly above it.  The space was pretty small, but just enough to not press down on the switch properly.  A little heat and a tap with a screw driver and it was fixed.

Done!

I managed to reassemble the stick.  Moving it around has a nice click to it and feels great.  If anything, down sounds like it may be not quite returning back to center, but its not hard to fix later.  I'm thinking if necessary, I might buy some fairly small springs (or remove some from a couple of ball-point pens) to sit around each switch just for the extra 'bounce' but we'll see how she goes with River Raid.

It seemed to work with the tablet testing software.  The real test will be with the 2600 when I get back to work (where its sat for a while, occassionally being pulled out after work)

Next time...

In hindsight, I should have gotten smaller 1.5mm high buttons rather then the larger 5 mm ones that I did.  That would have meant no need to cut back the plastic on the stick, but definitely will consider those for the next joystick project...

Roll on River Raid!  Woo!

Sunday, 7 February 2016

Rejuvenating my geriatric childhood friend

I was really happy a few years ago to get my first home computer back in my hands from a friend who'd kept it safe.  It was one of those 'worked when I last used it' machines, and I had made the assumption all would be good...

I had broken the ends of the keyboard membrane when I decided to open it once, but I knew I could replace that as there were new replacements available.

Sunday, 17 January 2016

Automating Maya render layers with Python

I had hoped to take a break from writing up Maya python related articles on the blog, but hey - when there's plenty to share, may as well keep popping it up.  This time, its all about building a tool (rather then a UI) for automating the render layer setup process...

Sunday, 10 January 2016

Python (Maya UI) - just finishing up the window

Ok - I was tossing up whether to post a final few very basic tips of UI advice here, just to finish up for now on working with UI's in general.  But hey, I think just for new users, it doesn't hurt to add those little tweaks and answer some very simple questions I'd been asked in the past....

Saturday, 12 September 2015

Python and BASIC games, mumble, mumble, mumble...

A few weeks back, I presented my project here to the New Zealand Auckland Python Users group meetup.

They web stream everything via Google hangouts, and as expected often the quality can suffer a little, however if anybody's interested in an hour of me mumbling my way through it, you can view it online here...

Monday, 8 June 2015

Python snippets (Maya) for the budding TD Part 3

I'm continuing my ongoing collection of tips for working in Maya using Python, with a few more small snippets of knowledge that may be of interest...  As per the last article, I've got a few small bites for working with Maya UI's along with some others.

This article is a little shorter as well, but obviously I'll post more at a later date...

Wednesday, 20 May 2015

Python (Maya UI) snippets for the budding TD Part 2

 In this article, I'm going to discuss a variety of features offered by Maya for effective UI development and design.  This is all done in Maya's native UI code (not QT or TkInter) which is easy to use and can create some very nice interfaces with a little work.

Tuesday, 19 May 2015

Introduction to simple Maya UI coding with Python

Maya provides a fairly straightforward way to create UI's for scripts and tools that you develop.  Of course, there are more powerful and flexible options such as QT (via PyQT and PySide), as well as Python's own TkInter if you wanted to toy with it - but for this article I'm going to show you how easy it is to build them using Maya's native system.

How exciting!  A tool to help me google stuff!


Note that this initial article is extremely basic and intended for someone completely new to using Maya's native UI code.  For more advanced information, I'm writing a more indepth article of tips to using many of the other features provided by Maya.

Windows, Layouts and Controls

Creating a Maya UI in python is a very simple process.  We start by creating a window, then we add a Layout (a container that defines how the controls in the UI are laid out) and fill it with controls such as buttons, text boxes and more.  This very simple piece of code does just that.  Its a simple window with a button that doesn't do anything other then to display "Click me".

import maya.cmds as cmds

# Start with the Window
cmds.window(title="Simple UI in Maya" )

# Add a single column layout to add controls into
cmds.columnLayout()

# Add controls to the Layout
cmds.button( label="Click me")

# Display the window
cmds.showWindow()

FYI : The main thing that throws new coders is not understanding that a UI is actually a hierarchy.  When we see code, to most it just looks like a linear dump of commands.  There's no apparent hierarchy stuff visibly going on, but internally there is.  I'll explain a little more later - but for now, just add that as a mental note.

It all starts with a Window

As per the previous source code, you start by creating a window.  When we invoke the window() command, it generates a new window that will eventually hold our UI once we've coded it in.  By default a window is just a blank container floating on screen without anything inside it.

Preventing multiple windows

Now, one thing that can be frustrating is that the window() command will do just that - make a window - and another, and another, and another blindly if we ask it to.  One very important task you should always perform at the start of your UI code is making sure that you close (or delete) the window if it already exists...  This can be done by using a unique id string that relates to your tool, and the deleteUI() command.

import maya.cmds as cmds

# Define an id string for the window first
winID = 'kevsUI'

# Test to make sure that the UI isn't already active
if cmds.window(winID, exists=True):
    cmds.deleteUI(winID)

Once you've checked for this, then you can go ahead and create your UI by using the window() command and passing the id string as the first parameter.  If you don't specify the id string, that checking code just won't find it.

# Now create a fresh UI window
cmds.window(winID)

Creating the contents

Think of a window as a bucket - there's just one big empty space and throwing things into it will just have them fall into the bucket and pile up messily at the bottom.  Obviously a UI shouldn't be a bunch of controls piled in a messy heap, and Maya won't let you just start to throw controls into a window directly anyway.

The next thing you need to do is add a Layout.  This is another container of sorts that defines a structure for how controls will be drawn (or laid out) inside it.  A columnLayout is perhaps the most basic of all of them, providing a vertical container where controls appear underneath each other as they are added.  As far as the concept of hierarchy goes (that I mentioned at the start), this Layout is a child of this window.

# Add a Layout - columnLayout stacks controls vertically
cmds.columnLayout()

When a Layout is created, it automatically becomes a parent object - any lines of code after the Layout command that create controls are the children (contents) of this Layout.

FYI : Just to make it more confusing - creating another Layout will set it as a new parent (any new controls will become its children.)  But it will also be a child Layout of the first Layout. You can start to insert Layouts into each other if you want to separate your UI up into blocks, and by knowing that this occurs is important for creating clean UI code that doesn't just become a messy jumble of Layouts within each other.

Adding some wizz-bang controls

The fun is in adding the controls we need for our UI - buttons, images, check boxes and other handy items.  Its all pretty straight forward, though any field that you want to be able to query information from should be declared as a variable.  In the code below, the button control does not have a value that needs to be queried (its simply used to run a function or command).  However, the textField is an input box that a user can type text into.  As this will likely be queried, its been declared as a variable called whatUSay.

# Add controls into this Layout
whatUSay = cmds.textField()
cmds.button(label='click me')

FYI : This variable will store a reference to the control, and not the value which is typed into the control.  When we want a value, we need to query the control to get it.  We'll look at that shortly.

Adding functionality to the controls

Obviously a UI that doesn't actually do anything is a tad pointless (even if it looks cool) so we'll add in some code to query the text field and print it to the history pane of the script editor whenever the button is clicked.  For this, I've written a simple function that sits at the top of the code.  The function requires that the control reference is passed to it (ie. the variable that we used when we created the control) so it can do a query.

# Function that queries the textField and prints it to the
# History pane in the script editor
def printTxtField ( fieldID ):
    print cmds.textField( fieldID, query=True, text=True)

The button requires a command to tell it to do something when its clicked on.  In this case, I've added the function name and the variable between quotes as the value for the command parameter

cmds.button(label='click me', command='printTxtField(whatUSay)')

Controls often have MANY parameters that we can set, adjust, query and use to change the way they are displayed and behave.  You should check out the Autodesk documentation and familiarise yourself with what's available in each one.

Now show us the money... Eh, window.

After we've created a window, added a Layout and filled it with controls, we just need to tell Maya to display it using the showWindow() command.  The complete script should now look like this...

import maya.cmds as cmds

# Function that queries the textField and prints it to the
# History pane in the script editor
def printTxtField ( fieldID ):
    print cmds.textField( fieldID, query=True, text=True)

# Define an id string for the window first
winID = 'kevsUI'

# Test to make sure that the UI isn't already active
if cmds.window(winID, exists=True):
    cmds.deleteUI(winID)
    
# Now create a fresh UI window
cmds.window(winID)

# Add a Layout - a columnLayout stacks controls vertically
cmds.columnLayout()

# Add controls into this Layout
whatUSay = cmds.textField()
cmds.button(label='click me', command='printTxtField(whatUSay)')

# Display the window
cmds.showWindow()

Conclusion

If we now run the script in Maya, entering text and pressing the button should display the text into the history pane.  And that is the most basic of UI's for now.  Its fairly straight forward to do something very basic like this - and making sure you understand what is happening with the whole parenting hierarchy is fairly important to moving forward into more advanced stuff.

Of course, its no fun if its this simple.  In the next article (which will be a continuation of my Python snippets for budding TD's), I'll create a collection of tips on using various types of controls and look at some of the other great Layouts - as well as talk more about this hierarchy and how we can jump about inside it to give us some more dynamic results.

Ciao for now!

Sunday, 5 April 2015

Python snippets (Maya) for the budding TD Part 1

Over the last 2-3 years, I've been involved in Maya based team projects with students.  I've seen all of the common issues that come up - mostly from just not following the protocols they were told to use when working within a team project, and just bad file management in general.

As part of a group project last year for my class, I decided to take a lot of these problems out of their hands and automate them with tools specifically designed to manage parts of the pipeline and work flow.

Wednesday, 6 August 2014

800 bits - 27 days later...

I've made it 27 days so far - and I have to say I impress even myself in just how many small CG projects I've managed to pull out of my hat so far.  I thought its worth a short catch up on some of the things that I've done/used/etc to get me this far.

Before I do, I felt its worth also mentioning a fairly amusing comment I got from someone who spotted my work online.  They thought I'd been posting up photographs - and said that I should really make them look 'less real and more 3D' otherwise nobody would realise I was creating 3D images...

Its not often I will hear someone tell me that they think it looks too real and ask me to make it look more computer generated.  Too funny, but I know where they were coming from on an artistic direction.

"This is too real... Make it less real so its obvious that its fake"

Its all in the software

For this challenge I decided to use LightWave rather then Maya.  Originally I thought it could be a great challenge to pull this off with Maya (having taught Maya exclusively for the last 4 or so years) but knowing the amount of time that some areas of Maya's workflow take was enough to warrant going back to my roots (as it were).

There are also some tools and features that are just not found in Maya, and these would allow me to get what I wanted at the quality I wanted with the tight time frames of a daily project.

What took the most time?

In the last few images, a series of isometric-styled computer hardware renders, production time and rendering can be done in 1 to 1.5 hours.  That's because they are comprised of simplified iconic models with basic colour textures.



However for the first 20 or so, an average of 3 hours was normal with some of the more complex ones taking up to 5.  These I attempted to go for a more complex realistic visual, which is why the time was so vastly different to the more recent projects.

In general, my gut feeling is usually 10% modeling and 90% everything else.  In this case, modeling objects was more around 15%.  Where the most effort seemed to go was on the composition, lighting and rendering.  Surfacing didn't take as long (with fairly low amount of Photoshop effort required - but more about that later) for most things, however the amount of additional tweaking I would do while rendering was where this would increase.

Hmmm, deciding on an angle...  Tricky...


It takes a surprisingly long time to get that shot just right, and often the shot I had originally envisaged didn't look as great on screen once it was rendered - which meant a lot of adjusting and testing.  However this is the area where LightWave really shined...

Don't over-model...

The tip of the day - just model what you see in shot.  For instance in the first image I produced of a ZX81 I never modeled any of the sockets or insets of the machine because they weren't seen - and I simply positioned the cables to sit in the correct locations.

Another example here is a BBC computer where the image rendered was of the BBC logo in the top-right corner.  Did I need to model every key?  Nup...

Model what's seen, not what you think you might see...

Bumps, bumps, bumps...

A lot of 80's computers were built with plastics, and as we know, not all plastic surfaces are smooth and shiny.  This is where adding bumps to the surface helps break up the surface and simulates the appearance of these types of materials - and I can honestly say that I did this with literally every project (given just how much plastic was involved obviously)

It may be tiny, but its essential to getting the look
As I said, this wasn't as time consuming as the cinematographic aspect of each project.  One reason being that I made use of a lot of procedurals for adding extra texture to plastics and other types of surfaces through their bump channels.

Bumps, bumps and more bumps...


I also took advantage of LightWave's gradients to assist in controlling some of these to behave the way I needed them.

Using a slope-driven gradient let me produce smooth edged keys on the BBC

Cameras

To pull off some shots, many of the scenes were fudged.  That is, elements are moved, scaled and rotated to suit the shot and assist in making effects like fogs and depth of field behave the way that you need them to.  Its pretty common in CG to 'work to the camera' with anything - its often the only way to pull off many shots.

Tiny tapes, HUGE TV set, fish eye lens and fog to haze it out in the distance

I also took advantage of a Photoreal camera type that allowed me to apply a lens profile to the render to generate a true fish-eye effect.  While that effect can be faked with Photoshop, you won't get quite the same result as a camera that sees the scene around it by processing the render through a lens.

Depth of field can also be viewed in real time (and very quickly) in the viewport, and that assisted a lot in fine tuning the final effect.

DOF preview in real time helped a LOT in getting the shot

Themes

I knew I wanted interesting interesting ways to display items, and while camera angles and various rendering styles are one thing, I figured I'd also try playing with how to interpret the ideas.  One in particular was when I wanted to produce something to represent the arcade game Dig Dug.  Originally I'd thought all the video game related artwork would be sprites built from 3D cubes (which can look cool) but in this instance I decided to try something different.

We'd been talking at work about post-it artwork just the day before this piece was done. In the last building we were, I'd drawn up some Defender sprites on the windows with post-it notes...  And I figured why not replicate that same idea in 3D.  Then I thought a glass window or office may be a little ambitious - so I went with what we do at work often - producing display boards and hanging the work from thin nylon...  Well, virtually that is.

Virtual art exhibition, anybody?
This was built from about 5 variations of post-it note (ie. a divided plane and a variety of bends) model and by placing them a little imperfectly with some random rotation I managed to get something that looks a little more human.

Lighting and Rendering

Along with surfacing, one of the key features that LightWave has is its Viewport Rendering - or VPR for short.  This feature alone is worth its weight in gold, providing real-time rendered feedback as you adjust and move elements about in shot.  When I was surfacing I used this a lot to see the result of tweaks to bump maps, reflections and node-based materials.  As its a render, it also allowed me to preview my fish-eye camera, as well as depth of field and adjust as I needed.

New Style

All that photo-real style work does take a lot of effort in modeling, surfacing and rendering.  So, I decided after 20 days had passed I would swap my style and try something new and different to keep the work interesting...  I also wanted to see if I could make things faster to create.

A whole new style
For the next set of images, I went for an isometric-angled simplified design - creating machines I recall from my youth (and mostly the ones I wanted, not the ones I owned) in their iconic form and giving them a simple shading style.

Advantages here - I didn't have to worry about fine detail modeling, as I was after the shape and form of the machine and not an accurate model.  Keyboards could be simple blocks, icons and branding didn't have to be added to the model...  Though I decided to model the branding and place it next to the machine.

Taking a break from detail modeling and rendering for a while

The shading was all done by driving the surface luminosity (or incandescence in other applications) through a mix of occlusion shader and a gradient ramp driven by the surface slope to allow shading of curved surfaces.  The floor was a flat plane and simply used a radial gradient to create a 'spot light' style effect from the center.

That meant no need for lighting, calculating shadows - which then made render times a little faster to boot.

So yeh...

There's still 70+ days to go - its a fun project, though at times it feels like it overwhelms everything else around me when I know I have to complete something that night.  With work, time is tight so I squeeze in things when the day is done and I'm sitting in the office...

I'll do another update when I make any new changes in direction...  And obviously a post when I'm complete!  Feel free to check out the project so far HERE.

Friday, 7 March 2014

TECH : Broken doesn't mean it can't be pretty...

Recently a local retro collector was giving away some of his excess gear - in his collection, he had an old Commodore 64 that was dead. It had been gutted - all of its chips had been removed and someone had soldered in a few random wires - and it was missing a few keys which had broken off.  While only my brother had Commodore (I was the "Sinclair" side of the family), the old "bread box" styling of the machine is iconic.  I also felt even if it didn't work, it could make for a nice display unit.

Not one - but two - but inside none...


On a little googling, I also saw a few small projects with Raspberry Pi emulators, old keyboards and a device called a Keyrah.  It is a small PCB that converts the Commodore keyboard input into a USB compliant USB keyboard.  I figure if I get the time, I may consider looking into projects like this at a later date.

Inspection - yup, its missing a few keys.

The machines arrived well packed inside an old Banana box.  I'd been sent two (I only expected one) - the Commodore 64, and a Commodore 64c that apparently would only produce a black screen and was rather messy inside as well.  The Commodore 64c's keyboard, however was intact.

Yes - I suspect that there may be something missing here

I'm not a big fan of the newer model casing that Commodore started to release its machines in (the later C128, Amiga 500's, etc).  While I could have just transplanted the keyboard across to the older box, its keys are light and the old bread box has great looking dark brown keys.  To keep the retro appeal, I just needed to replace those 3 that were missing with brown keys.

Washing away the dust

These machines have obviously been stored somewhere dusty - covered in grime and dust bunnies (or as they are otherwise known - clumped dust and hair) - a quick wash in some warm soapy water did wonders for the cases.  Obviously - I removed the keyboards and PCB's first!


So it was off to eBay...

I found a reseller who had classic brown C64 keys (refurbished, but in very good condition).  He also had pegs (the things that had snapped on the old keyboard, hence the missing keys) as well as springs.  So I ordered the 3 keys I was missing, a pack of springs and stems.

3 missing keys - now found (on eBay).  US$3.99 each


They arrived around a week later.  So - a little unscrewing (the keyboard PCB has almost 16-20 tiny screws hold it on) and some prying later, I managed to get the pegs in place, sit the springs on top and clip down the keys.

So many screws!



Viole!  Now looks much nicer.

Ta-da!  Now almost complete...


But something was still missing...


The C64 was missing its power LED.  This is a cheap 5mm Red LED - around $0.25 NZ cents.  I bought a couple (along with a green and a yellow one - Just because I could round it up to $1.00 - and because I thought its always handy to have some on hand)



At first I thought I would just clip it into the small black mount - it fits great - but then the clip is way too wide to go back into the case.


I placed the clip back in, inserted the LED and carefully (but forcefully) pushed it in with a pair or needle-nosed pliers.  The "click" meant it was in, and the case now looks complete.


Still one last detail... But for now...

There is still a missing black plastic cover that sits over the joystick and power connectors on the side, but from what I can tell this is really just a piece of black plastic with holes carefully punched into it.  Something for another time...

Something for another rainy day

Ready for display... or...

The case looks great (as long as I don't stare at the joystick connector "space" in the side) - its a classic design, and along with the ZX Spectrums (all 6 of them - lol!), the Atari 600 and the C64c - I now feel I need a display space.

I am definitely keen to make these two C64's at least do something more then sit pretty.  At a later date, I'll try my hand at throwing in a Keyrah interface.  If I'm feeling ambitious enough, a Raspberry Pi project may also be on the horizon...


UPDATE (April 2014)

Thanks to Terry 'tezza' Stewart, I now have that elusive plate.  It was definitely a lot different then I had imagined it to be (wasn't quite as simple as a 'plastic with holes')... A metal plate, with a large base folded flat to sit underneath the Circuit board.  However, that aside - I can now officially say that the case is complete...

Woohoo!  Nuff said...