Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Advanced search

1055616 Posts in 42866 Topics- by 34799 Members - Latest Member: Idea Wing Artworx

October 21, 2014, 04:03:10 PM
  Show Posts
Pages: [1] 2 3 ... 14
1  Feedback / DevLogs / Re: Return of the Obra Dinn on: October 18, 2014, 07:20:03 AM
Slight change of plans. A first playable build is coming in the next few days but I won't be submitting to the IGF this year. The build is a nice vertical slice but I think just not enough to stand up to serious judgement yet.

2  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 29, 2014, 06:54:31 AM

Imagine a zippo-like *chlink* sound when opening/closing.

3  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 29, 2014, 06:46:50 AM
I'm a visual artist and big fan of those early mac dithered pictures.[...]

Whoa big post! Thank you for the suggestions. You're right about the problem with blinking pixels at such large sizes. The frame-to-frame coherence is pretty bad when the pixels are bigger, especially with sharply contrasting shades. There's also the problem that the whole dithering mechanism falls apart if things are so big that your eye can't combine neighboring pixels into the desired shade. So my solution is almost the opposite of yours - to reduce dithering as much as possible. Shape-wise, things are pretty clear with just the lines:

Lines only.

This is easy on the eyes at any size, especially in motion. Dithering improves the look but makes it harder to read, so the goal is finding the right balance. Your sample image looks cool at small sizes but in fullscreen I need to move back from the monitor to parse it. Adding another shade as you've done would let me dither less, which would be nice. But I prefer the challenge of making this work with just 1 bit.

Your other suggestions are spot on and mostly in effect: Simple geometry, Textures tuned for the dithering, and lower contrast colors.

Ridiculously excited about this one. I'll throw my vote against the blur, though, too- seems to just undercut the Apple II-ness of the concept, without adding much. [...]

Thanks! The fullscreen blur is really subtle in practice. It's a half pixel gaussian blur and just adds a slight softening or "oldening" effect. Most monitors/video cards do their own bilinear filtering when upscaling to fullscreen anyways, and this is just a little stronger than that. You'll be able to toggle it for the first demo and I think you'll be surprised how much more comfortable it is in fullscreen with the softening.
4  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 25, 2014, 09:48:12 AM
I mentioned it on twitter, but this fullscreen problem surprised me. Up until recently, I've only been playing the game seriously in the Unity editor's reasonably small play window. It's always looked good to me there. Also in all the screenshots and gifs posted in the devlog.

The problem comes when taking those nice crisp 640x360 black and white pixels and filling your entire view with them. The original Mac Plus monitor was 9". You can't just stretch that to 27" and expect it to be comfortable. Especially (I found) for a 3D game.

Anyways, I most likely won't have a ton of options in the menu for this. I'm not a fan of lots of options in general; makes it harder to develop and maintain. Instead, I'll probably just have two options for fullscreen: normal or "softened".

None of this matters for windowed mode btw. Unfiltered black and white works great as long as the physical size isn't too big.

How about not running fullscreen?  Float the game viewport at a size that feels good in the center of the screen, surrounded by black?  The original 128K mac screen was only 9 inches diagonal, at 72 DPI, which is a good pixel density to read shapes.

Good point. A forced window on a black field would be my first choice. Unfortunately, I learned on Papers Please that players have zero tolerance for black bars. None. I got tons of support requests about this (Papers Please has small but permanent black bars in all resolutions).

Although I may add an option for this too, since I think it will unquestionably look the best.
5  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 25, 2014, 08:14:57 AM
  • Some good news: My next big post here will likely include a playable build.
  • Bad news: That won't be for another month. [...]


Fullscreen Looks Terrible

I've been worried about this:

  • 640x360 1-bit dithered visuals don't hold up well when stretched fullscreen on a 27" monitor. This is probably the most serious problem facing the game right now. There are a few things to try but nothing's ideal. I'll just power through and ignore this for now.

Couldn't ignore it so I went ahead and tried a few things. These pics are all crops of the full 1920x1080 frame. Click on any one for a full-size version. Scale it up to as close to fullscreen as you can to get the right effect.

Base 640x360 stretched to 1920x1080

When viewed small, everything looks great - still or in motion. Stretched to fullscreen on a huge monitor, the pixels end up so chunky that my eye can't resolve the lines and shapes easily. It's even worse in motion.

Double Resolution

The obvious solution is to just increase the resolution:

Rendered at 1280x720, stretched to 1920x1080

That helps with the chunky pixels but it loses some of the low-res style that I like. The 1-pixel wide lines are now half as thick which feels too thin. The biggest problem though is that it exposes my payless modeling and texturing, especially on the characters. I chose this 1-bit low-res style partially so that I wouldn't have to kill myself on high-res asset creation. So either I up-res all my models and rethink the asset creation or find another solution to this fullscreen problem.

Cathode Ray Tube

Ok, next try. Who doesn't like a good CRT shader?:

Base 640x360 rendered through a CRT shader at 1920x1080

Pretty good. The shader itself is not that great but I'll assume it's good enough for this test. The CRT details, border, and geometry are all full resolution 1920x1080. The blurriness helps join the pixels together so they feel cohesive again at fullscreen. The downfall is that you're looking at a low-res CRT. I personally love this effect in most cases but it just doesn't feel right here. Part of that has to do with the audio, which is realistic and high-fidelity; mixing that with an old shitty monitor feels off. The whole CRT effect is also too distracting IMO. It's hard to describe, but this feels like going too far stylistically by clashing "old computer" with "old ship".


Right. Now for something weirder. Diamond-shaped pixels:

Base 905x905 rendered at 45 degrees, then rotated back at 1920x1080

Not sure what I was thinking here. This is pleasantly unique and doesn't look half-bad. Vertical and horizontal lines get a nice stippling effect. Overall though, it still feels too rough and also a little gimmicky. Not that the entire 1-bit thing isn't one massive gimmick; this is just one gimmick too far.


Running out of steam. I went back to some Papers Please experiments and dug up scale2x:

Base 640x360 stretched to 1920x1080 using scale2x

Hey not bad. Not great, but I like the mottled look. The scale2x algorithm connects pixels really well so the lines and shapes are much easier to read. I also tried scale4x (just run scale2x twice), but it creates lots of small artifacts that look terrible. I was pretty happy with this and probably could've left it there but decided to go back and borrow some blur from the CRT technique.

Scale2x + Blur

With a touch of blur:

Base 640x360 scaled2x'd to 1280x720, guassian blurred 1 pixel, then stretched to 1920x1080

Ship it. This ends up as a kind of CRT-lite. None of the skeuomorphic business with pixel grids and screen curves but it does feel "old" without being explicitly "computer old".

Done For Now

Not saying I won't go back and waste more time on this later. Hopefully I can be happy with this for now. There's a ton of other stuff I need to do and not much time to do it.
6  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 21, 2014, 02:04:27 AM
Hey guys. Apologies for the lack of updates here. I'm still working away but there's been nothing stand-out interesting to make a big post about. A few small tidbits:

  • The characters have texture detail & shading which loses clarity from the blue-noise dithering's poor range. At the moment I'm experimenting with using bayer dithering on the characters and blue-noise dithering on everything else. Looks ok.
  • I think I'm gonna try to get some professional voice acting done for the game.
  • Writing the music has been hard. I've got 4 or 5 melodies worked out but they don't have the right feel so I'm still noodling on that.
  • 640x360 1-bit dithered visuals don't hold up well when stretched fullscreen on a 27" monitor. This is probably the most serious problem facing the game right now. There are a few things to try but nothing's ideal. I'll just power through and ignore this for now.
  • Some good news: My next big post here will likely include a playable build.
  • Bad news: That won't be for another month. My goal is to have the first 10~20 minutes playable and submitted to IGF.
  • Depending on how things progress and which stuff gets done first, I may post something playable before the IGF build just to test the visuals and maybe allow walking around the top deck of the ship.

dukope, I have a question about implementing Ulichney's void-and-cluster dither. My implementation seems wrong but it also seems to work. I posted about this in my forums but I wanted to run it by you as well.

I didn't dig into your code, but my 2nd and 3rd phases look more different than yours. IIRC, the logic needs to invert between the two. Before phase 3, I invert the actual buffer, then start filling tightest clusters instead of largest voids.
7  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 01, 2014, 09:41:38 AM
Layering Without Layers

(Warning: Technical)

Because the character texture UV maps ended up being so complicated, I figured it's easiest to paint the textures directly in 3D for this project. There are two choices for which tool to use for this: Maya or Photoshop. Actually there are a bunch more but I don't want to shell out money and learning-time for another program.

Some pros and cons:
  • Familiar viewport controls
  • Simple color switching between black & white
  • Quick brush sizing controls
  • Paint directly in the full Maya scene
  • Layers!
  • All the convenient PS tools
  • No layers!
  • Can't paint if material is assigned to more than one object
  • Need to export to .obj for painting
  • Most useful when painting a single object
  • Terrible viewport controls
  • Two 3D paint modes: slow or inaccurate. Pick one.

There are objectively more pros for Maya. The viewport controls are especially important since I found it extremely hard to switch between the natural one (Maya) and the batshit crazy one (Photoshop). And as always, some of Maya's quirks can be worked around with MEL scripts.

Unfortunately, the thing that really hurts Maya is the "no layers" bit. Maya can only paint in RGB directly onto a flat png/tga/etc texture file. That's probably enough in most circumstances but in this case, the character textures are built out of (non-destructive!) layers to reduce the workload.

So building a new character texture is as easy as stacking up the clothes and adding a unique layer on top for the face and custom details like tattoos or scars. The character model geometry is built in a similar way, using matching blend shapes to get the clothes geometry to match up. There's nothing special going on here, but the reliance on layers does make it much harder to work around Maya's 3D painting limitations.

Not giving up though.

Compositing Tool

In choosing Maya over Photoshop, the first step was to write an external layer compositing tool. This takes the different layer images and composites them together to give the final image; a very simple implementation of what Photoshop does in-app for layering. I wrote the tool in Haxe since it's perfect for the job. Images are specified as a series of layers in XML:

<image id="Sailor01" source="Naked" publish="true">
<layer image="PantsPantaloonsDark"/>
<layer image="ShirtLong"/>
<layer image="Sailor01Custom"/>
<image id="Sailor01Custom" paintBase="Sailor01"/>

Running the tool processes each image to load the layers, composite them together, and save out a final PNG for use by the game. Pretty basic stuff. This tool also manages the single paintable texture that Maya's 3D paint tool affects. This lets me easily swap which texture I want to paint on without copying files around manually.

No Alpha, RGB Only

This is the last big problem with trying to get layers out of Maya's 3D paint tool. Since it can only paint in RGB, there's no alpha channel to refer to when compositing layers in the external tool. That's a pretty big problem. If this were a full color game that'd be the end of it. Luckily though, again, I can lean on the grayscale-only nature of the art and get the equivalent of a 4th alpha channel out of just RGB.

One way to do this would be to start with a black canvas and paint in shades of blue and purple:

This method allows encoding full alpha and value into RB with a simple decoding algorithm. Paint in blue where you want black, paint in purple where you want white. Adjust the amount of red in your brush to control how bright the final value is. And since the green channel isn't used, it can contain a copy of any underlying layers to make painting easier:

The external tool comes in handy here again. Each image can specify what to put in the unused green channel for the painting base reference:

<image id="Sailor01Custom" paintBase="Sailor01"/>

So this all works great, technically. Artistically it's a mess. Painting in dreamcoat colors gives me a headache and makes it really hard to judge how the final composited image will actually look. There's something better right?

Using "Math"

If we sacrifice the easy to decode part, it's possible to get a much more natural value/alpha encoding out of RB. The trick is to invert our starting channels, so one of them tracks darkening and one of them tracks lightening (more or less). If we start with a pure blue canvas, painting in black will darken the blue channel - painting in white will lighten the red channel. Getting the value and alpha out of this requires solving a simple 2-unknown, 2-equation system:

I say "simple 2-unknown, 2-equation system", but it took me a long time to figure this out. The solution came when analyzing a black-to-white gradient with a perpendicular alpha fade, on top of a solid blue background, in Photoshop:

The right image encodes all possible values of value and alpha on a blue background.

Converting the right image to an equation based on the input value (V) and alpha (A):

R = lerp(V, 0, A) = V*A
B = lerp(1, V, A) = 1 + V*A - A

2 equations, 2 unknowns:
V = R / (R - B + 1)
A = R - B + 1

Since this method still just uses the red and blue channels, the green channel is available for previewing lower layers and is a lot easier on the eyes now:

And in actual usage, the end result allows painting with black/white on any layer like so:

To erase something from the current "layer", I paint it with blue then re-run the external tool, which recomposites everything and updates the texture. In the same way, I can change whatever clothes this guy is wearing, re-run the tool, and have it extract/recomposite the layers without affecting the values I've painted.

Trouble > Worth?

This whole thing turned out to take a lot more time and effort than I expected at the start. In retrospect it probably would've been sensible to just put up with Photoshop's limitations and get advanced layering from the start. But part of what I like about making games is A) solving small well-defined problems, and B) writing quick, focused tools. I got to satisfy both of those with this layering system and the custom nature of the solution slots well into the pipeline I've been building on.
8  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 01, 2014, 09:34:03 AM
Made a huge post. Moving it to the next page.
9  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 22, 2014, 03:21:58 AM
Blend Shapes!

Blend shapes!

It turns out that Maya's blend shapes are uncharacteristically useful. While most morph target/blend shape systems limit you to vertex position adjustments, Maya allows you to make topological changes to the original mesh, then back-port those changes to your blend shapes. This allows a sort of non-destructive workflow since you don't have to get things perfect the first time. And this awesome feature is included in Maya LT, thank Ra.

I was able to bang out a bunch of clothing variations using this technique. Adding edge loops for clothing edges was trivial. Skin-weighting the verts to work well with all variations is a little harder but doable. The biggest downside is that some blend shapes (and the final composed model) may have geometry they don't need since they all get updated to share the same topology. A small price to pay for this workflow.

Body size, pants, and shirt variations applied as blend shapes.

Finding this gives me a much more positive outlook on getting these characters done without an obscene amount of fragile work. I'll use the same blend shape process for face/head variations, attach accessories as separate objects, and compose the textures manually after drawing the relevant parts of each variation once.
10  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 20, 2014, 07:33:51 AM
It's great that you write such detailed devlog, very interesting read.
Also newer versions of Photoshop had some tools for painting directy on 3D models, but they probably are far from perfect.


I completely forgot about Photoshop's 3D tools until your post reminded me. Just tried them out in the latest CC. As you guessed, they're far from perfect. So far from perfect, in fact, that they're terrible. All the photoshop layering stuff is there, which is great, but it doesn't load FBX (so I have to convert FBX->OBJ/DAE), the viewport controls were designed by a blind monkey, and neither of the two paint "modes" works right - one doesn't paint on half the model no matter what I do, the other is hilariously slow and inaccurate.

I give it 5 more years before it's usable.
11  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 19, 2014, 06:16:51 PM
Character Work

I've been spending most of my time recently on the character workflow. The game will have close to 80 fully modeled/textured characters (plus variations) so there's some challenge is figuring out how to create all those without an insane amount of work. 

I usually try to avoid standard game mechanics and visual styles in order to avoid direct competition with other, more resourceful teams. Working in the typical way to model, uv map, texture, rig, and animate characters scares me because it could easily swallow all of my energy trying to match expectations.

When it comes to the 3D human characters, I was originally thinking to use a hyper-stylized design to help with this. My idea was to texture only the face and leave the rest of the body black. That'd let me cut a lot of corners for the modeling and rigging too, since pure black obscures any interior details and I'd only need to worry about the silhouette.

Stylized texturing - Face only

When I tried this out it felt weird and unfinished. I may still go back to that and try some more, but in the meantime I decided to fully texture one character and see how it looked.

Less so

That sits pretty well in-game and matches up with the rest of the visual style better. I'm pretty worried about making 80 of these though so the workflow is going to be pretty important. Also, there are no internal lines/wireframes on the character at the moment. I'll play around with those at some point.


There are a couple things I have going for me, resource production-wise:

There's no color
I just need to worry about getting the shapes and shades right. Maya's 3D paint tool is also drastically more useful when you're just painting with black and white. If you select black for the paint color, holding CTRL lets you paint in white. So there's no annoying palette to go back and forth to.

The game is low resolution & dithered
Even if the player wanted to, they couldn't get a super close look at the models. There's a lot more room for error on my end.

The characters aren't elaborate
These are all sailors with very basic clothing. Most of the work will be focused on the faces, which I can sketch pretty quickly.

Characters won't have traditional animation
This'll get explained later when I talk about the core mechanic (still prototyping).

Painting in 3D

Terrence Stamp + Kevin Spacey + Abe Lincoln. The triumverate.

On this project I'm gonna paint the character textures in 3D. This'll be a first for me - in the past it's always been very simple UV mapping that was best textured in Photoshop. Now that the models are more complex I thought I'd try just painting directly in 3D.

Maya's 3D Paint tool is pretty good in use. Of course there are all kinds of stupid limitations (you can't easily paint a model that's already been rigged), but I've been able to work around everything so far with a touch of MEL scripting.

I use a small Wacom Bamboo tablet for drawing and I've found it pretty natural to paint directly on the model. The big saving grace is the game's black & white palette, which saves me from having to do any color management in Maya. I just have my swatch set to black at 10% opacity. I can easily build up shades with repeated strokes or pen pressure, and holding CTRL gives me a white brush for highlights/corrections. And because there's so much post-processing going on with the lighting and 1-bit dither, I can work to my style (fast and loose) when building up the texture.

It's easier to get this right when painting directly on the model.

Character Dithering & Lighting

One consequence of the character style is that the characters will be more heavily dithered than the environment. Seeing some amount of detail in the characters will be important to the game's mechanics, so I didn't want to go fully undithered like much of the ship.

More texture dithering & brighter/harsher lighting on characters

Because the game's post-processing handles lighting and dithering differently already, I'm able to treat characters specially and light them more harshly while also giving their texture more range (the ship textures are saturated towards white.)


Base character model

Now that I've taken one character through to the game, I'm working to create a base character model that can be tweaked and retextured for the rest. I may make some basic variations of that (skinny, short, tall, etc) first. This is a case where non-destructive editing would come in handy. Would be nice if fixing certain things in the base model would propagate up to the variations. As it is, I'll need to get the base models as close to perfect as possible before making any variations. If any problems come up it could mean either tons of rework or just accepting the faults.

One thing I need to get right on this base model is the clothes. Adding clothes requires adding geometry, changing much of the shape, leaving space in the texture for added bits, and correctly weighting all the verts. Alot of stuff that can go wrong down the line.

Also, I don't really know the ideal facial structure to use as a base. In the best case I can just push/pull verts from this one shape to get a bunch of different heads. But If there's some critical detailing or edge loops to make that easier, I won't really know until later.

UV Mapping

UV mapping in Maya

Maya has really good UV mapping tools. There's the cavaet that it trips up when UV'ing an already-rigged model, but besides that things are really nice. The "Unfold3D" feature makes it kinda enjoyable to go through, mark your UV edges, unwrap, adjust uv shell scales/rotations, then run auto-layout to arrange everything nicely. I've only done one character so far, but already learned from a few mistakes.

Tweaking the UV map

There were a couple problems with the first mapping:

1. Too many shells. Eg: arms, legs, and hands are split front-to-back. This creates visible seams on the outside and makes duplicating left/right in Photoshop more difficult.
2. The texel density isn't balanced well. Areas closer to the player (hands, arms) should have more texels since they will ultimately take up more screenspace.

A common trick to get more efficient texture usage is rely on the model's symmetry to mirror the left/right UVs. For this game, though, unique texturing across the model is important for some necessary details so I can't use that technique. Instead, the plan is to paint one side, copy it to the opposite side, then add unique details. That process is a lot easier if the UV map is laid out nicely and has fewer shells. My first UV map required lots of fine-tuned repositioning in Photoshop to copy/paste pixels from one side to the other. The updated mapping makes this process much easier.


I recorded another timelapse of creating, testing, texturing the character over a couple days. No annotations this time.

12  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 19, 2014, 02:23:35 AM
Have you ever heard of Softimage GATOR system? I had an XSI guy demo it to us at work once, it was really impressive... I think it's pretty much it's what you are talking about... however I have never used it myself in production.

I looked it up. Damn. I've heard good things about Softimage for a long time. Their editing workflow looks fantastic and non-destructive. And of course Autodesk just killed it.

On a side note... for some reason I kept thinking about this project last night,  and I couldn't keep my mind from coming back to the case of The Queen vs Dudley and Stephens.

Thanks for the tip! The wikipedia article is chilling. It's an interesting case but the circumstances were so extraordinary that I don't feel much connection with the ambiguity. I prefer more everyday mundanity in my life or death decisions.
13  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 15, 2014, 03:12:30 AM
For your next project you could take a look at Houdini [...]

I'll definitely include Houdini on the list, thanks!

what do you mean by "destructive 3d modelling" ?

Every 3d app I've seen follows an old school "do it right the first time" philosophy. Editing a model, adjusting a rig, painting skin weights, etc. All of these things make step by step changes that can't be undone except sequentially. And if there are non-destrutive/non-sequential ways to do things (Maya's construction history or Max's modifier stack), many operations require you to collapse those edits in order to work properly.

Destructive editing like this is by far the easiest thing to program so it's no surprise that's how all these old apps work. But I'd really like to see a modern app using a more forgiving design philosophy to put the burden on the tool and not the artist. Node-based editors like Houdini go some of the way there, but nodes have a tendency to focus on minutiae that matter to programmers' logical minds, not artists' workflows.

Imagine something more like Photoshop layers - not just to show and hide objects, but to group edits. So if you're going to work on the face, you can create a new edit layer and make all your changes there. Or make a new layer when you start rigging. If you want to try again, just hide that layer and you're back to the original mesh. Just like in a layered PSD. You could also:

- Duplicate and group edit layers to get a really nice non-destructive workflow.
- Pull parts of edits from one layer and put them in a different one to try different iterations of one particular area.
- Collapse edit layers together once you're totally happy with them.

Max's modifier stack is the closest I've seen to this but the UI is really poor and it's mostly focused on per-object edits. The ideal non-destructive editor wouldn't be easy to implement but the usability would be through the roof. A guy can dream.

It was a few years since I rigged a proper character in Maya so I don't remember the exact steps, but you can export the skin weights, then tweak the rig, and import the weights back to the model.

The in-app way to modify a rigged mesh is to copy your skin, edit the copy, reskin it to the skeleton, copy the weights from the original, then delete the original. A huge pain. I recently just got a skin weight export/import script that makes it much easier. The only catch is that Maya LT doesn't allow file writing from MEL Grin. Had to edit the script to print out the file contents to the script console, then manually copy/paste it into the file. Still faster than the in-app method!

Secondly, one way of improving shoulder deformations is to not use the standard T-pose, but instead give the model a more relaxed pose. I've even seen FPS models which were modelled with (almost) 90-degrees bent elbows, which makes sense if all they will be doing is running around with guns.

Yeah I really wanted to use an A-pose instead. IIRC, all the Uncharted characters are rigged in A-pose. But Unity-friendly rigs should always be in T-pose, and I actually need the full shoulder range for what I'm planning with these characters.
14  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 14, 2014, 07:37:23 PM
I don't want to be that kind of guy, but I hope you will consider using Blender on maybe, your next project. Having feature that 'should be there but isn't there' isn't that much fun.

I'm pretty sure Blender (or any tool really) isn't immune to small feature gaps. Switching to another package would just be trading one set of quirks and workarounds for another. The important thing for me is how hard it is to get around these limitations. So far Maya LT hasn't been that bad. But I will definitely go back and resample Blender and others after this project.

Blender scares me a little bit personally because it's open source and there are no limits to what you can fix yourself. At least with Maya LT I can say "this is unfixable and I need to work around it and move on." With Blender I could spend days editing the actual source or writing elaborate plugins. Fun but counterproductive.

My real problem with all these tools is the destructive nature of the editing. When I have some more material for it, I'll probably make a post about exactly how this negatively affects the entire project and how it could be so much better.
15  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 14, 2014, 07:08:56 AM
Fortunately the old Polycount wiki is still alive, great topology examples there:

Oh man, score! The shoulder stuff is basically what I ended up with already, but the face topology examples are really useful. I went through and made a few tweaks and edge loop changes based on that. Actually I had to force myself to stop - I could happily tweak face verts forever.

I don't think I'm a fan of the color changes, personally I preferred the plain white and black color scheme over the more bluish and brown variation. I know there are people that do like that though so I'm hoping that it's an option.

I haven't quite decided how to handle the palette yet. The blue/brown is some experimentation for slightly less contrast. It'll probably change again.

Maya LT vs. Maya

Maya LT is missing a bunch of features from the full version but it's been pretty good at including what I need so far. There are a handful of little missing things that you are naturally meant to want, once you start using the app more. The biggest is probably python scripting. Not having that precludes using a lot of popular scripts. I've managed around this limitation by sticking to MEL scripts and writing anything I can't find online.

Today, I hit another little thing that turned into a huge pain in the ass. The HumanIK biped character rigging system is thankfully included, but the Maya LT version doesn't allow the transfer of animation from one rig to another and HumanIK keyframes can't be copied/pasted like normal keyframes. Normally this wouldn't even come up, except that editing a skeleton after it's rigged (tweaking joint positions) requires regenerating the rig and losing all your animation.

Another one of those shitty destructive workflow things where you can't go back and make changes past a certain point.

The "Bake to Control Rig" option is missing from Maya LT. Have fun re-animating everything.

I was able to work around this by writing another custom script to go through each rig control to copy/paste the keyframes with the right parameters. Since it's a straight copy, there's no rig retargeting that the "Bake To Control Rig" would do. But it's enough to let me at least shift the joints around a bit without losing everything.

16  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 13, 2014, 07:45:39 AM

Character Modeling

I've finally started to prototype the gameplay for this. Part of that requires getting some characters in the game, so actually creating those has been my current task.

I need relatively low-poly realistic characters to represent the crew on the ship. The last time I modeled human characters was ~15 years ago in 3dsmax so I've been pretty worried about keeping up with current expectations. I watched a bunch of instructional videos on character modeling, started with a reference, and spent a few days modeling.

Reference (including sack) and after two day's work, 2684 triangles (sans sack)

The game is pretty low res at 640x360, so low poly models seem reasonable. I wanted something even lower than what's here but I noticed that the silhouette is still critical at low res and getting that right requires more triangles. Hopefully I won't need LODs or anything complicated when there are ~80 crew members on board. The model still needs a lot of polishing (and clothes) but it's enough to start prototyping.


Following tutorials and researching construction methods, it was interesting to see the wide range of techniques that artists use. For the face in particular there are two main factions. Some use box-modeling to start with a basic structure and fill it out with more and more detail. Others use straight-up poly modeling to lay down quads from the start and build out around the entire head. In each case, the main goal is to generate clean geometry with nice edge loops around the flexible parts of the face.

Eye & ear details will be in the texture.

I used the box modeling technique here since it felt a little more natural to me. Took forever but was relatively straightforward. I just kept tweaking verts until it looked ok. Something interesting I found is that it's much easier to see what's going on in flat-shaded mode. With so few polys, smooth shading looks terrible and makes tweaking the details really hard.

With fire we kill it.

Maybe this is actually a problem with my modeled shapes and using flat-shading is just a crutch to hide that. Probably!


One particular area that I had trouble with is the shoulders. It's easy to make them look good in a static T-pose but to support the wide range of natural movement is a lot harder. On my first try I just modeled the shoulders as usual and matched the poly density of the rest of the body. Unfortunately, I found it impossible to get it looking good for all the different twists.

Initial shoulder

I think it'd be possible to add some helper bones and maybe driven keys to get different areas of the shoulder/clavicle to compensate for the distortion. That didn't seem very sporting (and too hard anyways) so instead I:

  • Added a bunch of geometry on the shoulder to smooth things out
  • Manually transfered some of the movement to the clavicle
  • Tweaked the shit out of the skin weighting

Updated shoulder

And even so there's still some unnatural pinching and stretching. I think I'll wait until I've put some clothes on before worrying about it more.

Full Body Rig

For the player's hand I made a custom rig of joints and controllers. For the full body stuff here, I've decided to use Maya's builtin HumanIK system. Seems to be working well enough. The support for non-modal FK and IK in the same rig is really nice. It's still a pain in the ass to make changes or edit the skin mesh, but not so much that I'm getting too frustrated yet.

HumanIK rig.
(His dome looks a little coney here. Gotta fix that.)
17  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 13, 2014, 05:52:24 AM

This is a great resource, thanks! I just went through the entire list and found a few good sources. I wish more of them sold individual sounds instead of entire libraries though. I don't necessarily need 6GB of chain sounds - just one or two choice ones.

This is why sites like Pond5 or SoundDogs are useful. They're just distributors for different audio vendors so the quality can span a pretty wide range. But they let you search/preview/purchase individual sounds, which is ideal for my case. They're not exactly cheap either - but you can save a lot of $$ by just buying the files you need.

The biggest problem I've found with the big distributors is not the poor quality but the loss of uniqueness, since whatever you find has often been used (and reused) many times before in other stuff. I guess that's also the advantage of hiring a sound designer with his own collection.

I enjoy putting this stuff together though. Learning new things and making mistakes is all part of the fun. Not saying I do the best job, but I wouldn't even bother with making games if it was a "hire other people to do all the work" deal.
18  Feedback / DevLogs / Re: Even the Ocean (demo available. follow-up to Anodyne) on: August 12, 2014, 07:52:21 AM
Cutting it out [...]. A good lesson is just minimize, minimize, minimize, cut back. seems to wokr well for design overall but also i've noticed it helps a lot in music too. probably art in general, hm.

Cutting stuff is the best tool for figuring out what defines the game and what makes it good. The more you cut, the sharper that definition becomes. I love cutting stuff. My past self was an idiot anyways - he wasted countless hours on the stupidest stuff. I have no reservations about throwing his work in the trash and making it easier for me and my bud, future self.
19  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 07, 2014, 07:42:24 AM
Maybe a different dither for each material..?

I really love characterful dithers like this. I was originally planning to vary the dither on materials but changed my mind after realizing that the ultimate goal is to reduce the amount of dithering altogether. Any texture imparted by a different dither would only be visible in a narrow band of the lighting gradient. IOW, not worth the trouble.

One question, will this game has some kind of replayibility?

I'm not sure yet. I'm leaning towards no, but there may be a way to get a little bit of replayability in there.

So where is the ship gonna be located? Will it be in a harbour (meaning you would have to model a backdrop-city-thing) or out on the ocean?

It's "just outside port" for the specific reason that I don't want to have to worry about showing any kind of harbor/city/whatever backdrop.
20  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 06, 2014, 07:09:24 AM
Thanks for the positive notes everyone! Those big posts are a lot of work so I'm glad you enjoy them. Writing them is a pretty good way to decompress after finishing a big feature though so I'm not complaining.

Will the game have different weather conditions (heavy wind, rain, thunder,...)?
Are you planning on having seagulls?
Are you the only person on the Obra Dinn?

Different weather conditions: Sortof, but not as you think
Seagulls: I thought about leaving them out to accentuate the isolation, but now I think I'll put a few in. I'll probably also add a bit of the ship's bell.
Only person: NO COMMENT

Will the footsteps be dynamic depending on the deck you're on? I wouldn't expect to hear much running on the top deck.

At the moment, I'm not planning any footstep variations beyond what I've got. But the ship isn't fully modeled yet so there may be cases where a different floor surface could use a different footstep sound. If you mean about switching running/walking sounds, then no. There's no running in the game - it's all walkin.

Title Blue Noise

Meant to post this earlier. The title screen with blue noise dither.

Pages: [1] 2 3 ... 14
Theme orange-lt created by panic