Ship, Captain, and Crew: Cross Platform Differences?

Hopefully, the above pictures came through for you, or this wont make much sense. I’ve been working on my dice game, and it is nearly completed. However, as I test it out on different platforms, I notice that it doesn’t look the same. In the above screen shots, the left is from my Linux desktop, and the right is from my Android phone.

What hopefully is obvious is that the Android phone has an abnormal pixelation/black dots on it. Also notice that the table and dice are brighter on the Linux machine. Both screens are using a 1920×1080 resolution, so it isn’t a stretch/scale problem. The darkness of the Android screen is not a display brightness problem, as these are screen shots and not pictures of the screen. So what is causing this?

Well, after a bit of web searching, I came up with nothing. Thus, I must be using the wrong key words. But, after some trail and error, I found that the culprit was the texture normals for the table. Interesting. As far as I can tell, the normals are used to calculate light beams reflecting/refracting off of the surface of the object. For some odd reason, the normals texture overlay work great on the computer, but fail miserably on the phone. But both phone and computer support openGL 2 and 3, and this game is only openGL 2.

So, I don’t know why it happens. If you happen to know, please feel free to let me know in the comments. What I did to fix it was remove the normals texture overlay, and just use the textured wood overlay for the table. Now both the phone and the computer look the same. As always, you can check out the full project on my GitLab.

Linux – keep it simple.

Ship, Captain, and Crew: Exports and keys

withKeys

So, as I near completion of my 3D dice game, I ran into several small issues that I thought I would share here, since they all apply to exporting your game. Of course, as you go along, if you are making a cross platform game, you occasionally need to export it and test various things on the different platforms (more on that in another post). And when you export them, you have to use this export function and templates.

So, that said, a few interesting tid-bits:

First, I found it interesting that when you make a release key for your Android version of the game it saves your key password in a plain text file in your directory folder. Ordinarily, this wouldn’t be a terrible issue, except that as a maker of open source games, when I use git to sync my work, it then would save the release key in plain text on GitLab! So, if you are to the point where you stop using debugging, and start using release keys that you made or signed, you will have to do the following:

  • Open you project folder
  • Find the file called: export_presets.cfg
  • Find the line called: keystore/release_password=
  • and delete your password.

Or, you can delete your password from inside Godot, in the exports screen by scrolling down to it and deleting it and saving the project. I find this to be a bit annoying. I would think Godot would at least hash it, or something. Or keep passwords in another file, specific for Godot, and not in your project folder. But that’s just me, I guess.

Second, if you are making an Android version of the game, you will need an icon. By default, it uses the icon you already have for your game in the main project folder, called “icon.png”. But if you don’t specify an icon for the Android game, your main icon will come out looking wrong (way zoomed in) on your Android device.

After some reading, I found that you need to supply one 192×192 pixel icon, which Godot will then translate into the various other icon sizes. But, this didn’t work. I found out later that is because in Android 8+ you need 432x pixel icons. So, in all, you will need several icons, each used for different launchers. Or, carefully edit your main icon and it will be used in a fallback chain and edited by Godot to make your icon for the Android application.

Third, I ran into a lot of problems with key signing. I’d like to point out that in the guide it says that you set the debug key in the editor settings. This is true, and without that it will not work at all. That said, with that, it will not work at all either. At least for me. I had to also specify in the project export template for the Android app the paths to the debug keys again. Otherwise I got an error about “jarsigner” failing. Overall, this is only a minor inconvenience, but it was a big hang up for me until I figured it out. You then have to remove all of that and enter you release keys if you want to make a release version.

Just a few thoughts from a guy who doesn’t really know what he’s doing, so take it with a grain of salt. But, if you run into the above issues, be sure to try these out. Also, you can check out the full code for my game here on my GitLab.

Linux – keep it simple.

Ship, Captain, and Crew: Give it a spin!

Well, I suppose “roll” would be a more popular dice game term, but spin is actually more accurate in this case! I’m actually rotating the dice in a spin maneuver, and having them fall on the table, rather than rolling them across it from an angle or the side.

diceroll

The first question I had to tackle was what type of object to use for the game. The three types are Static Body, Kinematic Body, and Rigid Body. Each have their own uses, and here I put into words my limited understanding. Be sure to comment if you can clarify any of these.

Static Body is an object that is not supposed to react to any force. It should instead stay right where it is when it is struck by another object. In this game, I used a static body for the table top. This way the force of being struck by objects, such as the dice, and physics powers, like gravity, have no affect on it. In fact, I didn’t even give the table legs, because nothing is needed to “hold” the table up, since it is a static body.

Kinematic Body is an object that is often used for making the main player of a game, or something like that. It is not affected by physics unless you program it too. Gravity and such have no affect on it until you tell it to through code. So, if I had a kinematic ball roll across the table, when it gets to the edge, it would keep rolling on air, as if the table were still under it. This is what we used in BornCG’s great video game tutorial for the main player. It is very easy to control movement of this object.

Rigid Body is a type of object that by nature is fully affected by physics. Gravity and inertia all come into play on this type of object. If the table were not there, a rigid body object would fall indefinitely. These objects are difficult to move in one sense, because you can’t just say, “go that way” like you do with kinematic bodies, instead you have to exert force against them in a direction to cause them to move that way.

To make the dice game as realistic as possible, I used rigid bodies for the dice. When they fall to the table, they can bounce, tumble, or bump and shove other dice. The big question was how to move them. Of course, once in the air, they fall to the table and tumble, etc. That was the easy movement, because it is not programmed by me at all, it is simply the engine physics taking place. The tough movement was what to do with them after they hit the table.

Originally, I was planning to move them aside, and set them out of the way so I could roll the remaining dice. Not having any 3D experience, I thought this wouldn’t be too hard, but it became a nightmare for rigid bodies. Here are several methods I tried after reading hours of documentation and QA forums:

var oldPosition = get_node("LowPolyDiceC").get("dicePosition")
var targetPostion = get_node("pirateShip").get("shipPosition")
var newDirection = targetPostion-oldPosition
print(newDirection)
$LowPolyDiceC.apply_impulse(Vector3(),newDirection)
#translate(translation.direction_to(newDirection)) 
# This one only moves a tiny bit, and not in the right direction.   
#translation.direction_to(newDirection) 
# This one doesn't move at all.   
#apply_impulse(Vector3(),newDirection) 
# This one rockets it towards the ship, then it falls off the table.   
#translate(newDirection) 
# This one does not go to the ship, but goes up in the sky near it.

I found several ways to translate, or “teleport” the dice somewhere else, but not where I wanted them. And, once transported, they didn’t work with physics anymore. I also found ways to whack them with a force, but they arced up through the air and fell off the table (think golf club hitting golf ball). None of those would do. I tried asking my issue as a question on Godot’s QA forums, but I didn’t get a response from anyone, so I had to give this idea up.

Instead, I used the impulse (force) to send the dice straight up into the air again. Then, as they go up into the air, I perform several “spins” of the dice to randomize the result. Here’s my code:

func _make_dice_random (diceName):
	var x = randi() % 365 + 1
	var y = randi() % 365 + 1
	var z = randi() % 365 + 1
	get_node(diceName).rotate_x(deg2rad(x))
	get_node(diceName).rotate_y(deg2rad(y))
	get_node(diceName).rotate_z(deg2rad(z))

func _spin_dice():
	if tumbler > 0 :
		tumbler = tumbler - 1
		#print (tumbler)
		var upAmmount = 4
		if takenA != 1:
			$LowPolyDiceA.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
			_make_dice_random("LowPolyDiceA")
		if takenB != 1:
			$LowPolyDiceB.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
			_make_dice_random("LowPolyDiceB")
		if takenC != 1:
			$LowPolyDiceC.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
			_make_dice_random("LowPolyDiceC")
		if takenD != 1:
			$LowPolyDiceD.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
			_make_dice_random("LowPolyDiceD")
		if takenE != 1:
			$LowPolyDiceE.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
			_make_dice_random("LowPolyDiceE")
		$spinTimer.start()
	else :
		$spinTimer.stop()
		$Timer.start()
	
func _roll_dice():
	$ControlHUD/HUDrollButton.hide()
	remainingRolls = remainingRolls - 1
	get_node("ControlHUD/HUDrollsNumLabel").set("howManyRolls", remainingRolls)
	tumbler = 3
	var upAmmount = 6
	if takenA != 1:
		$LowPolyDiceA.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
	if takenB != 1:
		$LowPolyDiceB.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
	if takenC != 1:
		$LowPolyDiceC.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
	if takenD != 1:
		$LowPolyDiceD.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
	if takenE != 1:
		$LowPolyDiceE.apply_impulse(Vector3(),Vector3(0,upAmmount,0))
	$spinTimer.start()

It reads from the bottom up. First I call the _roll_dice() function to send any dice up that are not “taken” or in use by the player for their ship, captain, or crew. Then a timer is started, to allow the dice time to rise up off the table. Once the timer ends, it calls the _spin_dice() function, which has several calls to the _make_dice_random(dicename) function, picking random numbers of 365 degrees*. This is done as many times as the “tumbler” variable is set to, or in this case, 3 times. Since the dice are rotated on the x, y, and z axis, they get very randomly arranged, and then fall to the table, tumbling around to their final position.

Each dice has 6 small invisible cube areas on the faces of the dice that correspond to the opposing sides number. So, when they hit the table, that reports the number the dice has face up to the variables, so the dice number is set and known. That looks like this:

func _on_AreaA2_body_entered(body):
	if body.name == "TableObject" :
		$diceSoundPlayer.play()
		diceA = 2
		#print (diceA)

And finally, once the dice have come to rest, they are checked for their number:

func _check_all_dice():
	$Timer.stop()
	#print ("dice check")
	#print (diceA, diceB, diceC, diceD, diceE)
	# Check for Ship
	if hasShip == 0 :
		if diceA == 4 :
			hasShip = 1
			$pirateShip.show()
			takenA = 1
		elif diceB == 4 :
			hasShip = 1
			$pirateShip.show()
			takenB = 1
		elif diceC == 4 :
			hasShip = 1
			$pirateShip.show()
			takenC = 1
		elif diceD == 4 :
			hasShip = 1
			$pirateShip.show()
			takenD = 1
		elif diceE == 4 :
			hasShip = 1
			$pirateShip.show()
			takenE = 1
	# Now check for captain
	if hasShip == 1 :
		if diceA == 5 :
			hasCapt = 1
			$pirateHat.show()
			takenA = 1
		elif diceB == 5 :
			hasCapt = 1
			$pirateHat.show()
			takenB = 1
		elif diceC == 5 :
			hasCapt = 1
			$pirateHat.show()
			takenC = 1
		elif diceD == 5 :
			hasCapt = 1
			$pirateHat.show()
			takenD = 1
		elif diceE == 5 :
			hasCapt = 1
			$pirateHat.show()
			takenE = 1
	# Now check for crew
	if hasCapt == 1 :
		if diceA == 6 :
			hasCrew = 1
			$piratecrewHat.show()
			takenA = 1
		elif diceB == 6 :
			hasCrew = 1
			$piratecrewHat.show()
			takenB = 1
		elif diceC == 6 :
			hasCrew = 1
			$piratecrewHat.show()
			takenC = 1
		elif diceD == 6 :
			hasCrew = 1
			$piratecrewHat.show()
			takenD = 1
		elif diceE == 6 :
			hasCrew = 1
			$piratecrewHat.show()
			takenE = 1
	# Now check cargo
	if hasCrew == 1:
		if remainingRolls > 0:
			$ControlHUD/HUDkeepButton.show()
		else:
			$ControlHUD/HUDkeepButton.hide()
		_update_score(diceA + diceB + diceC + diceD + diceE - 15)
	else :
		_update_score(0)
	
	if remainingRolls > 0:
		$ControlHUD/HUDrollButton.show()
		if theCurrentPlayer == 0:
			$computerTimer.start()
	else :
		$ControlHUD/HUDrollButton.hide()
		$updateTimer.start()

This string of if/elif statements is really ugly, but gdScript doesn’t have a “switch” or “case” block method. It does have a “match” method, but I couldn’t understand how to implement it properly.

Hopefully that was interesting and or helpful to other newbies like myself. You can always check out the full source code for the game at my GitLab.

Linux – keep it simple.

* Yes, I know there are really only 360 degrees in a circle, but this actually improved the random factor, based on my research, because I was under the impression that the random number generator seemed to favor slightly lower numbers, so I added a few. If it goes over 360, it just keeps rotating, as if from 0.

Ship, Captain, and Crew: Scaling the Screen

diceGameScalescript

So, now that I’ve completed BornCG’s great 3D game tutorial, I’m ready to set out on my own! Of course, I already mentioned what the game would be about, it is a remake of the classic “Ship, Captain, and Crew” dice game. I’ve already made a 2D version of this game as an Android app, but now I’m trying to develop some 3D skills by remaking the game using Godot’s 3D engine.

I have several goals for this game:

  1. 3D – I know, it seems kind of obvious, but I never made a 3D game on my own before! (No tutorial, help, etc.)
  2. Featuring all of my own 3D models – I want to personally build each 3D model to enhance my limited Low Poly Blender skills.
  3. Cross platform – I would like to be able to play this game on a Linux, Windows, and Android OS.
  4. Open Source – It is important to me that this project is open sourced to the public for any to view, edit, copy, and use. Perhaps my meager and fledgling skills will help some other newbie to create something better than I did.

So, with that in mind, my first goal was to tackle screen size. Once before, I made a 2D side scroller called Critical Velocity using the libGDX library, and I found out after I made the game that I needed to work out different screen sizes. It was really hard to do so after the fact, and so I wanted to start with that here, so I don’t run into the same problem.

I found several guides on how one might accomplish this in Godot. Some just moved the camera further or closer based on the size of the screen. Some used the stretch mode. Others scaled objects to meet the criteria. And yet others had different assets to use for various sizes. So, after viewing all three, here is what I came up with:

First, I made a global.gd script that is automatically loaded as soon as the game starts. It looks like this:

extends Node

var my_viewport_scale = 1
var actualScreenRatio = 1.777777
var numberOfPlayers = 1
var computerPlayer = 0

func _ready():
randomize()
var viewport = get_node(“/root”).get_children()[1].get_viewport_rect().size
# comment the below call for OS.get_screen_size() if you want to force a
# certain screen size. If this call is not commented out, it will use the
# native screen size of the device or computer, unless it is greater than
# the Godot project settings of 1920*1080.
viewport = OS.get_screen_size()
# print(viewport) # Reference only

actualScreenRatio = viewport.x / viewport.y

my_viewport_scale = viewport.y/1080

So, in this script, I am asking the operating system for the size of the screen. I am building the entire game in a 1920×1080 resolution, but I use this math to find the screen ratio, and the screen size. I then set a scale based on the y axis ( my research seemed to point to that one being the best to base off of, but I don’t know particularly why ). Once these variables are in place, I can put this at the beginning of any “scene” that I make:

func _ready():
# My way to change the scale for every screen size. This allows me to build
# in 1920 x 1080 resolution, and scale it for bigger or smaller displays.
# This works for both 16:9 and 4:3 screen ratios, although 4:3 may not have
# the proper look.
# Tested satisfactory on: 800×480, 854×480, 800×600, 960×540, 1024×600, 1280×768, 1280×720, 1280×800, 1824×1200, 1920×1080
# Did not work well on 1400×900.

var new_y_scale = get_node(“/root/global”).my_viewport_scale
var new_x_scale = new_y_scale

if get_node(“/root/global”).actualScreenRatio < 1.4 :
new_x_scale = new_y_scale * ((800/600) / get_node(“/root/global”).actualScreenRatio)
elif get_node(“/root/global”).actualScreenRatio < 1.61 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.45)
elif get_node(“/root/global”).actualScreenRatio < 1.76 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.54)
else :
new_x_scale = new_y_scale

get_node(“/root”).get_children()[1].set_scale(Vector2(new_x_scale,new_y_scale))
# print(get_node(“/root”).get_children()[1].get_scale()) # Reference only.

In the title screen scene, I use the “ready” function, which is called as soon as a scene launches, to set the scale of that scene/node. By doing this, everything in that scene is not directly scaled, but is automatically set to scale as the whole view is scaled. This saves me from scaling each object, but rather scaling the view as a whole. At least, as far as I understand it in my limited knowledge of Godot and 3D programming, and it seems to work well.

The key part being that I want to check the actual screens ratio. Once I have that actual ratio from the global script, I can edit the scenes scale to match (at least closely) the ratio of the screen, and scale appropriately. This allows the game to be viewed on a 4:3 ratio screen (like an older computer), and a 16:9 screen (like most phones and modern computers), and several odd phone screen sizes.

As you can see in my notes, I tested this out on various screen sizes, and it worked well on a lot of them. This does have one downside, as it will make some screen resolutions look “squished” a tiny bit. But, with my limited repository of Godot/3D knowledge, this will do for now.

Here is an example from a 3D scene, the game table:

func _ready():
var new_y_scale = get_node(“/root/global”).my_viewport_scale
var new_x_scale = new_y_scale
var new_z_scale = new_y_scale

if get_node(“/root/global”).actualScreenRatio < 1.4 :
new_x_scale = new_y_scale * ((800/600) / get_node(“/root/global”).actualScreenRatio)
elif get_node(“/root/global”).actualScreenRatio < 1.61 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.45)
elif get_node(“/root/global”).actualScreenRatio < 1.76 :
new_x_scale = new_y_scale / (get_node(“/root/global”).actualScreenRatio/1.54)
else :
new_x_scale = new_y_scale

get_node(“/root”).get_children()[1].set_scale(Vector3(new_x_scale,new_y_scale,new_z_scale))
# And set the HUD scale…
get_node(“ControlHUD”).set_scale(Vector2(new_x_scale,new_y_scale))
get_node(“winControl”).set_scale(Vector2(new_x_scale,new_y_scale))
# print(get_node(“/root”).get_children()[1].get_scale()) # Reference only.

Most looks the same, with the addition of scaling the “HUD” display. In the 3D scene, I over-layed a control node with essentially a 2D scene where the controls and such are floating above the game and within view for the player to use. Of course there is also another axis to change, the “z” axis, which is added in as well.

So, perhaps there is a better way to do this, but it seems to work pretty well for me. I also don’t notice any sort of performance hit doing this, as it only scales once at the scene change, and the scenes seem to load instantly. So I’ll stick with this for now. If you want to check out the project as a whole, you can find it on my GitLab.

Linux – keep it simple.

Collector3D! My First Ever 3D Game, Programmed in Godot!

Collector3D

Well, I finished the online YouTube tutorial by BornCG, which you can check out here. His tutorial is great and I learned a lot. I did make several changes along the way, and I used this as an opportunity to practice my work in Blender, making my own graphics for everything, as opposed to using the material he presented.

Code wise, it is the same game, but I did code several things differently, as I worked on expanding my knowledge of programming. An example would be the player ball rotation. In the tutorial, he shows how to use a variable and a set number to change the degrees to radii of the ball when it rotates.

However, This had several drawbacks. The first was that you needed to fiddle with it in relation to the variable of the ball’s speed. In other words, if you changed the speed of the ball, you would need to watch it move and guesstimate the change needed to the variable for rotation. Secondly, if you use his method, then when you stop pressing the arrow keys to move the ball, the ball stops rotating, but still “slides” until it comes to a stop.

To fix this, I changed the rendering of the ball rotation to be based off of vector speed. This makes the ball look very natural when it rolls. E.g., if it rolls forward, the degrees of roll looks naturally like the distance it is rolling over, and gives it a more realistic look. This also allows me to change the ball speed without having to adjust it’s degrees of roll. The best part, though, is when you release the arrow keys, and the ball is slowing to a stop, it now rolls, in accordance with it’s speed, slowing it’s roll as it slows to a halt in speed. It just look much more realistic.

I do believe that the author, BornCG knows how to do all this, and was just making a simpler tutorial for the viewers to follow. Or perhaps more specifically was trying to show the relationships of variables to those new to programming.

Other examples were just style points, adding timers and effects when you “die”, rather than the simple “cut to end screen” approach, and other such small things. Overall, the game mechanics and idea came from BornCG’s great tutorial. For a free resource that is widely available, I’d say this tutorial was a 5 star product, and I highly recommend it for anyone looking to start using Godot. I found numerous 2D tutorials for Godot on YouTube, but this is one of the very few 3D tutorials for Godot. Certainly worthy of your time if you are looking to start using Godot.

That said, here are some great links for my game:

* Notes: I did not try the Windows executable, since I didn’t have a Windows machine to test it on. I did try out the Linux executable on two different Ubuntu machines (17 and 18). If you try the Linux executable, be sure to chmod a+x the file so you can run it. Also, if you try out any of the executable files, be sure to comment below how well they worked and what OS you tried them on!

Linux – keep it simple.

Dice, anyone?

LowPolyDice

Now that I’ve completed the low poly course from Udemy, I’m ready to start using my fledgling, but newfound skills in some form of application. That said, the most fun and easiest way that I can imagine using 3D models is in some kind of game. The question is, what to make?

If you’ve been reading this blog for a while, you may remember that I once made a dice game app called “Ship, Captain, and Crew”, based on the sailor dice game of the same name. So, I’ve decided to revamp that project by creating a 3D version of the app. Essentially, I’ll be starting from scratch, but utilizing the same game mechanics that are in the first game.

The two big things I think I will need are the 3D objects and then some form of 3D game engine to render it. Today I completed the first part, which was making the dice. It took me about an hour to throw this together, but I think it will do as a low-poly die for the game. In theory, I will just use 5 of them during the game itself.

Now the big question is what game engine to use. There may be many to choose from, but from a mobile app perspective, there seem to be only 4 that I would want to use. Of course, I’m ruling out Unity, because it is not open source. I’m trying to make an open source game, and I’d like to use open source tools so that anyone can openly tinker with it. I’m also ruling out several that work for Android, but the sdk is only available on Windows computers (irrlicht for example). That leaves the four main options of LibGDX, GoDot, Ogre, and jMonkeyEngine. There may be others, these are just the ones I know about.

So, now I need to do some research and see which one will work best for me. I’ve never made a 3D game before, so this might take a while….

Linux – keep it simple.

Low Poly Course: A walk in the park?

0175

While deeply investing my time in the study of servers for the upcoming Server+ beta test, I took a few hours to relax and made this fun low poly man walking in the park. If you are interested, you can see the video I made of it here:

https://youtu.be/jySydnNXhwU

This concluded the Low Poly course, and I really, really loved it. I can’t wait to try out some more fun stuff with my new low poly renders!

Linux – keep it simple.

CompTIA Server+ and Low Poly People…

So, I missed a few posts over the past week or so. Actually, I’ve been really busy, but for a good cause. I’ve been fortunate enough to be selected by CompTIA to beta test the new Server+ exam. The busy part is all of the studying I am doing to try to pass the exam. I have a very short window of time in which to take the exam as well. Servers are not a new thing for me, but I have my doubts about passing the test, so I’m trying really, really hard to study up for it.

At work we use a few servers. From file hosts to PXE boot servers, but we don’t use them the way most of the IT world does. Here at work, our servers are offline and not connected to the internet at all. We manage and maintain nodes, as well as re-image them “remotely”, but by remotely, I mean that we do it in the same room from the servers to the machines. We don’t do patch management or updates, either. Some of our servers are running the same way they started out five years ago, because they are closed loop systems. Often component fail, but we don’t upgrade them, we repair them with pre-stocked and approved replacements of the exact same parts, even if those parts are no longer manufactured. Some of the motherboards and graphics cards we use have been out of production before we installed the servers. It’s just not exactly the way servers are typically used, especially in the scope of this exam.

Of course my server at home is a web, FTP, photo, and Jabber server, but I’m not sure that it’s being implemented the way a typical IT setup would be. It is only accessed by myself and my wife, and it is tied specifically to our cell phones with dynamic IP addresses. I manage users on a one on one basis, because there are only 2 users. Not your typical use case, for sure.

So, I’m doing a lot of studying. Fortunately for me, my company provides a video series specific to the Server+ exam, albeit the previous version of the test (of course, the one I’m taking is a beta, after all), which is free for me to peruse. I also picked up a Sybex Server+ book, which I’m reading through as well. Kindle readers can be really handy! If I had to order the book, I would lose a week of study time waiting for it to arrive in Alaska!

All of that to say I’ve been busy.

In the interim, however, I’ve been playing around with the Low Poly course lessons some more, and been trying to make some low poly people. There are several styles of low poly people, so I’m trying out a few of them. If you can see this posts pictures in your viewer, then hopefully you can see the little police man that I made. Well, I guess at the moment, he’s just a man in a blue shirt, but I was going to put a badge and tie on him later.

Linux – keep it simple.

Low Poly Course: A whole new world….

The title might suggest something about a princess, a monkey, a thief, and a Disney movie, but it’s not so glamorous. It’s just a low poly world I created for my low poly class. I had some fun with lighting, and it is amazing what changing the background lighting color can do to your planet.

SpaceWorld

Above is a generic lighting fading from white to black. Kind of gives it a nice “space” look. But, it seems a bit moody, so I tried some sunrise, daylight, and sunset looks:

I’m no expert, but it’s a pretty fun way to change the mood and look of the model, without changing anything else. I’m really enjoying the class so far, but I’m not far from the end of it now. I think next up is a low poly character that moves, so I’m really looking forward to that!

Linux – keep it simple.

Low Poly Course: T-Rex times four!

Hopefully above, you can see my latest creation, a low poly T-rex! I’m still taking the low poly course, and really enjoying it. Perhaps because it is low poly, it makes it a little easier to have good results, even for beginner’s like me. Above is my “square method” low poly T-rex. Here is my decimated “triangle style” T-rex:

Not too much difference, although the triangle style does have more menacing looking teeth. For fun, I then made this “high poly” version by subdividing the square version:

And then I decimated the high poly model, as per the instructor’s suggestion in the course. It made for an interesting low poly/high poly mix:

In all four versions, I used the same colors, the same lighting, and as close to the same position/camera angle as I could. One interesting note about the decimated high poly model – it was really difficult to color it. When I would go into edit mode to select surfaces to color, it would look “high poly” again, but when I would select vertices, and went back to paint it, it was “low poly” again. So, I realized I forgot to apply my decimation. So it was showing the decimation, but it was not applied to the model. So, apply, apply, apply. That’s my lesson learned for the day!

Linux – keep it simple.