Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


24. января 2017

 

Are you perhaps… artistically challenged?  This tutorial will give you passable 8-bit or 16-bit style pixel art results with a minimum of artistic ability.  Of course it assumes you know a bit about Blender, but dont worry if you don’t.  We have a pair of ground up tutorial series that will0001-0060 teach you everything you need to know to follow along, this Blender text tutorial series and this Blender video tutorial series.  Alright, let’s jump right in.  We are going to use a combination of vertex painting, cycles renderer and freestyle in Blender to create an image like the one to the right.  Not the most impressive thing you’ve ever seen I’m sure… but it was exceptionally easy.

 

 

Without further ado, let’s jump in.  For this example I am not going to model the sprite, if you are interested in seeing that process, watch the full video.  Instead we start with a simple model like the following:

image

 

Now let’s look at first colouring it, then cartoon rendering it and finally how to render it in pixel art style.

 

Vertex Painting The Object

First we start off by painting our surface.  The nice thing about Vertex Painting is it draws the colour information directly on the model, so you dont need to worry about UV maps or textures at all.  We just published a video on Vertex Painting in Blender if you want more details.  In the end we are going to use the Cycles renderer, but for now it’s easier to get started painting using the built in default Blender renderer.  This will enable us to easily see the painted vertices in the Blender viewport.  In the default material make sure that Vertex Color Paint is enabled:

image

 

Now it’s time to start filling out our different colors.  In Edit mode, simply select the faces you want to be a specific colour, like I have done here for the cockpit area:

image

 

Now switch over to Vertex Paint Mode:

image

 

Now select “Face Selection Masking For Painting”

image

 

This limits your painting to the faces currently selected in edit mode.  In the Tools menu ( T ), select the color you want to paint with.

image

 

Now hit SHIFT + K to fill the selection with the current colour, like so:

image

 

Now repeat this process for the rest of the ship.

 

Toon Shading In Cycles

Now that you’ve got your ship coloured, it’s time to switch over to the cycles renderer.  If using a default layout, simply select Cycles Render in the dropdown:

image

 

With the change to Cycles Render, we should now have a new option in the Materials dialog

image

 

Click Use Nodes.  Then select Toon BSDF.

image

 

Out of the box Vertex Colors aren't going to work in Cycles, we need to make a simple shader graph to get things to work.  Don’t worry… it’s super easy.  When you do a vertex paint, the data is stored in the mesh data, like so:

image

 

That “Col” data is about to become very useful.  Switch to Node Editor

image

 

Now what we want to do is add an Attribute input and wire it into the Color field of our Toon shader, like so:

image

 

Notice the name “Col”.  This is the link back to our vertex color data.  This causes the Toon shader to use the painted vertex colors as it’s color source.  If you do a render now, it should look something like…

image

 

Better, but still quite fugly…

 

Using Freestyle

Now to get a bit of a more hand-drawn effect, we want to enable freestyle in the Blender renderer:

image

 

Notice I increased the Line Thickness a fair bit from the default… this is a personal choice.  It’s possible you don’t like the default lines it chose to highlight, but don't worry, you can control that if you prefer.  Simply go to Edit Mode, select the edge you want Freestyle to render, select Ctrl+E then Mark Freestyle Edge:

image

 

Now in the Render Layers property panel, locate the Free Style Line Set, then enable Edge Mark.

image

 

Now when we render, it should look like:

image

 

Ok, that looks a bit better!  Now how about that Pixel art look?

 

Compositor Time

The compositor is a process that runs AFTER the image is rendered and can be used to create all kinds of special effects.  In this case we are going to pixelate the result.  In the Renderer dialog, make sure under Post Processing, that Compositing is enabled.

image

 

Now, back in Node Editor, switch to Compositor mode:

image

 

Now we want to edit our graph like so:

image

 

Essentially we take our input Render Layers, scale down the resulting image to 1/5th its size, apply the Pixelate filter, then scale it back to it’s regular size and finally send it to the Composite output.  Now let’s render and see what we’ve got:

image

 

TADA!  Pixel art in just 20 easy steps.  Granted, at that size it doesn’t look great, but at actual game scale:

image

 

It looks pretty solid… for a purple, yellow and emerald model that is!  You can download the Blend used in this example here.

 

The Video

Art , ,

blog comments powered by Disqus

Popular Comments

LibGDX Tutorial 13: Physics with Box2D Part 1: A Basic Physics Simulations.
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


27. August 2014

 

Today we are going to look at implementing physics in LibGDX.  This technically isn’t part of LibGDX itself, but instead is implemented as an extension.  The physics engine used in LibGDX is the popular Box2D physics system a library that has been ported to basically every single platform and language ever invented, or so it seems. We are going to cover how to implement Box2D physics in your 2D LibGDX game.  This is a complex subject so will require multiple parts.

 

If you’ve never used a Physics Engine before, we should start with a basic overview of what they do and how they work.  Essentially a physics engine takes scene information that you provide, then calculates “realistic” movement using physics calculations.  It goes something like this:

  • you describe all of the physics entities in your world to the physics engine, including bounding volumes, mass, velocity, etc
  • you tell the engine to update, either per frame or on some other interval
  • the physics engine calculates how the world has changed, what’s collided with what, how much gravity effects each item, current speed and position, etc
  • you take the results of the physics simulation and update your world accordingly.

 

Don’t worry, we will look at exactly how in a moment.

 

First we need to talk for a moment about creating your project.  Since Box2D is now implemented as an extension ( an optional LibGDX component ), you need to add it either manually or when you create your initial project.  Adding a library to an existing project is IDE dependent, so I am instead going to look at adding it during project creation… and totally not just because it’s really easy that way.

 

When you create your LibGDX project using the Project Generator, you simply specify which extensions you wish to include and Gradle does the rest.  In this case you simply check the box next to Box2d when generating your project like normal:

 

image

 

… and you are done.  You may be asking, hey what about Box2dlights?  Nope, you don’t currently need that one.  Box2dlights is a project for simulating lighting and shadows based off the Box2d physics engine.  You may notice in that list another entity named Bullet.  Bullet is another physic engine, although more commonly geared towards 3D games, possibly more on that at a later date.  Just be aware if you are working in 3D, Box2d isn’t of much use to you, but there are alternatives.

 

Ok, now that we have a properly configured project, let’s take a look at a very basic physics simulation.  We are simply going to take the default LibGDX graphic and apply gravity to it, about the simplest simulation you can make that actually does something.  Code time!

 

package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.math.Vector2;
import com.badlogic.gdx.physics.box2d.*;

public class Physics1 extends ApplicationAdapter {
    SpriteBatch batch;
    Sprite sprite;
    Texture img;
    World world;
    Body body;

    @Override
    public void create() {

        batch = new SpriteBatch();
        // We will use the default LibGdx logo for this example, but we need a 
        sprite since it's going to move
        img = new Texture("badlogic.jpg");
        sprite = new Sprite(img);

        // Center the sprite in the top/middle of the screen
        sprite.setPosition(Gdx.graphics.getWidth() / 2 - sprite.getWidth() / 2,
                Gdx.graphics.getHeight() / 2);

        // Create a physics world, the heart of the simulation.  The Vector 
        passed in is gravity
        world = new World(new Vector2(0, -98f), true);

        // Now create a BodyDefinition.  This defines the physics objects type 
        and position in the simulation
        BodyDef bodyDef = new BodyDef();
        bodyDef.type = BodyDef.BodyType.DynamicBody;
        // We are going to use 1 to 1 dimensions.  Meaning 1 in physics engine 
        is 1 pixel
        // Set our body to the same position as our sprite
        bodyDef.position.set(sprite.getX(), sprite.getY());

        // Create a body in the world using our definition
        body = world.createBody(bodyDef);

        // Now define the dimensions of the physics shape
        PolygonShape shape = new PolygonShape();
        // We are a box, so this makes sense, no?
        // Basically set the physics polygon to a box with the same dimensions 
        as our sprite
        shape.setAsBox(sprite.getWidth()/2, sprite.getHeight()/2);

        // FixtureDef is a confusing expression for physical properties
        // Basically this is where you, in addition to defining the shape of the 
        body
        // you also define it's properties like density, restitution and others 
        we will see shortly
        // If you are wondering, density and area are used to calculate over all 
        mass
        FixtureDef fixtureDef = new FixtureDef();
        fixtureDef.shape = shape;
        fixtureDef.density = 1f;

        Fixture fixture = body.createFixture(fixtureDef);

        // Shape is the only disposable of the lot, so get rid of it
        shape.dispose();
    }

    @Override
    public void render() {

        // Advance the world, by the amount of time that has elapsed since the 
        last frame
        // Generally in a real game, dont do this in the render loop, as you are 
        tying the physics
        // update rate to the frame rate, and vice versa
        world.step(Gdx.graphics.getDeltaTime(), 6, 2);

        // Now update the spritee position accordingly to it's now updated 
        Physics body
        sprite.setPosition(body.getPosition().x, body.getPosition().y);

        // You know the rest...
        Gdx.gl.glClearColor(1, 1, 1, 1);
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
        batch.begin();
        batch.draw(sprite, sprite.getX(), sprite.getY());
        batch.end();
    }

    @Override
    public void dispose() {
        // Hey, I actually did some clean up in a code sample!
        img.dispose();
        world.dispose();
    }
}

 

The program running:

 

test

 

What's  going on here is mostly defined in the comments, but I will give a simpler overview in English.  Basically when using a Physics Engine, you create a physical representation for each corresponding object in your game.  In this case we created a physics object ( Body ) that went along with our sprite.  It’s important to realize, there is no actual relationship between these two objects.  There are a couple of components that go into a physics body, BodyDef which defines what type of body it is ( more on this later, for now realize DynamicBody means a body that is updated and capable of movement ) and FixtureDef, which defines the shape and physical properties of the Body.  Of course, there is also the World, which is the actual physics simulation.

 

So, basically we created a Body which is the physical representation of our Sprite in the physics simulation.  Then in render() we call the incredibly important step() method.  Step is what advances the physics simulation… basically think of it as the play button.  The physics engine then calculations all the various mathematics that have changes since the last call to step.  The first value we pass in is the amount of time that has elapsed since the last update.  The next two values control the amount of accuracy in contact/joint calculations for velocity and position. Basically the higher the values the more accurate your physics simulation will be, but the more CPU intensive as well.  Why 6 and 2?  ‘cause that’s what the LibGDX site recommend and that works for me.  At the end of the day these are values you can tweak to your individual game.  The one other critical take away here is we update the sprites position to match the newly updated body’s position.  Once again, in this example, there is no actual link between a physics body and a sprite, so you have to do it yourself.

 

There you go, the worlds simplest physics simulation.  There are a few quick topics to discuss before we move on.  First, units.

 

This is an important and sometimes tricky concept to get your head around with physics systems.  What does 1 mean?  One what?  The answer is, whatever the hell you want it to be, just be consistent about it!  In this particular case I used pixels.  Therefore 1 unit in the physics engine represents 1 pixel on the screen.  So when I said gravity is (0,-98) that means gravity is applied at a rate of –98 pixels along the y axis per second.  Just as commonly, 1 in the physics engine could be meters, feet, kilometer, etc… then you use a custom ratio for translating to and from screen coordinates.  Most physics systems, Box2d included, really don’t like you mixing your scales however.  For example, if you have a universe simulation where 1 == 100 miles, then you want to calculate the movement of an Ant at 0.0000001 x 100miles per hour, you will break the simulation, hard.  Find a scale that works well with the majority of your game and stick with it.  Extremely large and extremely small values within that simulation will cause problems.

 

Finally, a bit of a warning about how I implemented this demo and hopefully something I will cover properly at a later date.  In this case I updated the physics system in the render loop.  This is a possibility but generally wasteful.  It’s fairly common to run your physics simulation at a fixed rate ( 30hz and 60hz being two of the most common, but lower is also a possibility if processing restrained ) and your render loop as fast as possible.

 

In the next part we will give our object something to collide with, stay tuned.

Programming , , ,

blog comments powered by Disqus

Month List

Popular Comments