Leadwerks 3.2 Indie : Animated Character Workflow Test

Testing the animated character workflow from Mixamo's Fuse software to Leadwerks 3.2 Indie. The character was created in Fuse then a whole category of animations from a TrueBones animation pack were re-targeted in Ikinema before the character was finally imported into leadwerks. There were no adjustments or tweaking performed at any stage (although it will be done in future when required), this was simply a test of the pipeline.

Read More

Leadwerks 3.2 Indie : I hate waiting in for deliveries! [HD]

  I hate waiting in for deliveries, so it's essential to pass the time "playing". What did you do today?

Read More

Leadwerks 3.2 Indie : Proof Of Concepts & Several Tests.

It's been a fair while since I updated my blog, I have just been busy. Although I am currently working with Unity 3D, I did purchase a copy of Leadwerks 3.1 Indie on Steam. Not really had much time to dabble with it other than to load it up when I first bought it. So I had a few hours and thought I'd have a tinker with it.



 This is just a quick video of that few hours work prototyping.

It also served as a test of Mixamo's Fuse that I got in the Steam summer sale at 80% off, a test of some textures, the model conversion workflow, a waterfall shader attempt and some Lua AI scripting.

The main test was for using the Navmesh functionality and Basic AI scripting to utilise it. The AI female NPC model was created in Fuse rigged and animated via Mixamo. Basically just a few hours tinkering with several different packages to see what I could come up with.

Read More

Leadwerks 2.5x + DarkBasic's Dark AI [Part 3]

I thought I'd spend a little more time on this integration, using the laptop whilst watching the Olympics. The next phase was to automate the routines for NPC update and compacting the code routines. Ultimately, the idea is that after the scene is loaded, it will be parsed and flagged Dark AI objects, NPC's, Paths and Zones will be set up automatically via information taken from the relative lua scripts. Paths and Zones will be later, collision objects are done, so I was working on how to go about NPC's using this method. As some may have noticed I am using the FPSC Model Pack 53 characters.

I converted about 5 or 6 characters to Leadwerks format and all the weapons for this exercise. I will eventually convert them all but I hand "prune" the bones of the rig and that takes longer than I want to spend at any one time on this side project. The FSM is still very basic but the first goal was to derive a current Animation state with each of those states having sub-FSM's to dictate the current behaviour based on the previous state and internal and external inputs. The framework is in place for the animation state which is derived by performing Boolean logic on returned values and strings from the Dark AI runtime and some stubs are in place nested inside for some basic behavioural sub-FSM's. First though I want to able to set up the scene and then place all the Dark AI objects, NPC's, Paths and Zones directly in the editor and then use the load routines to set all that up in an automagic way inside the application. The collisional objects were easy and are done with some simple tick box flagging functionality added to their property scripts. The NPC's a little more in depth , due mainly to the large amount of usable settings! lol. But I wanted to be able to place the model and then assign it some basic attributes to be read on load, this included what weapon to attach.

So that was the basic NPC property script setup (wasn't that painful anyway). So using the test scene from Leadwerks 2.5x + DarkBasic's Dark AI [Part 2], and placing a few enemies and some friendly's to look after the player, this is the result of the current stage reached in the integration.

Read More

Leadwerks 2.5x + DarkBasic's Dark AI [Part 2]

After the first hour and a half I spent on this little exercise, I followed it up with another couple of hours. The basic integration now has an animation FSM. All still pretty crude and basic but a template to build on at some later date. The NPC's Entity script controls the models animation routines and gun attachment, the c++ application interfaces with the Dark AI library, and then uses messaging to communicate with the NPC Entity via lua script. Again this was just more experimentation and practice for me using c++ to build up techniques that will be beneficial later. Special thanks to Pixel Perfect for pointing out the error in my ways with regard to text strings in c++. Anyway this is the result, I just threw in some values for speed and animation blending off the top of my head just to test the FSM functionality, it will need those tweaking, thats for sure.

Read More

Leadwerks 2.5x + DarkBasic's Dark AI = DAILE?

I am currently working with EKI One, working through its format and structure, getting to grips with the lua behavioural scripting side and trying to brush up on my c++ skills, actually brushing up on my c++ skills is an overstatement as I don't actually have any to brush up! .. lol, I have also been going through my Blitzmax code and trying to compile all the game mechanic functions and methods into a single .mod, trying to keep things tidy. Whilst going through my crap drive, I mean, my well organised storage drive, I found some DarkBasic/DarkGDK stuff, which included the Dark AI library. I have never really used DarkGDK, although I did start out a few years back with DarkBasic. So I wondered (as you do), could it be utilised in LE2.5? Having never used Dark AI (which came in a bundle, that I have never used either, but it was a bargain lol) I knew that R.T.F.M. would be in order. If it relied solely on DBobjects and inherent DarkBasic functionality then probably not. I spent half an hour looking through the commands, and an hour later had it working in an LE context. So to answer the question, it seems you can.

Its all a work in progress, and probably will remain that way as its certainly nowhere near the solution that EKI One is, but as an exercise it wasn't a bad use of a few hours. I will post a demo in the Leadwerks forum showcase later for those interested.

EDIT : Demo posted here : DAILE DEMO

Read More

Meet The Flockers.

Well, it should be more like meet the Swarmers, but you can't have as much fun with the word Swarm as you can with the word Flock. My first port of call was to do some quick research, not a good idea on a Sunday morning after a "busy" Saturday night, lets just say even plain English was reading like Egyptian Hieroglyphics ...

I found a large variety of examples on the Net, but nothing in a programming language I use or with Sunday morning syndrome could be bothered to wade through. Most, and probably all the examples I came across, were 2D, and not what I wanted. I opted for the same route I took when writing my Lua A* Scripts, just to work from a simple written definition of the rules and how they are used. With A* I used:

1) Add the starting square (or node) to the open list.
2) Repeat the following:
a) Look for the lowest F cost square on the open list. We refer to this as the current square.
b) Switch it to the closed list.
c) For each of the 8 squares adjacent to this current square …
If it is not walkable or if it is on the closed list, ignore it. Otherwise do the following.
If it isn’t on the open list, add it to the open list. Make the current square the parent of this square. Record the F, G, and H costs of the square.
If it is on the open list already, check to see if this path to that square is better, using G cost as the measure. A lower G cost means that this is a better path. If so, change the parent of the square to the current square, and recalculate the G and F scores of the square. If you are keeping your open list sorted by F score, you may need to resort the list to account for the change.
d) Stop when you:
Add the target square to the closed list, in which case the path has been found (see note below), or
Fail to find the target square, and the open list is empty. In this case, there is no path.
3) Save the path. Working backwards from the target square, go from each square to its parent square until you reach the starting square. That is your path.
 
And from the written description I then coded the AStar Script. I felt using this approach again would enhance the learning potential. For this new exercise I used the descriptions of the three rules Craig Reynolds uses to take this approach.


Cohesion: steer to move toward the average position of local flockmates

Alignment: steer towards the average heading of local flockmates

Separation: steer to avoid crowding local flockmates


From Conrad Parkers website :


Boids try to fly towards the centre of mass of neighbouring boids.

Boids try to keep a small distance away from other objects (including other boids).

Boids try to match velocity with near boids.

It was also my interpretation that the rules when performed on an individual boid had a limiting radial area when looking for its neighbours, which if I correctly understood was the factor that changed the overall behaviour. I took this to be the case given the graphic representations on Craigs boids page:

So my rules ended up as:


Boids try to fly towards the average position of local flockmates in a given radial volume of 3D space


Boids try to keep a small distance away from other local flockmates in a given radial volume of 3D space


Boids try to match velocity with other local flockmates in a given radial volume of 3D space

Actually I also implemented a 4th rule, which is a mathematically described harsh confinement volume, by harsh I mean zero tolerance, which currently means the boids "bounce" off an imaginary wall belonging to the volume in the same way the ball bounces in the game breakout. However when time permits I will redefine the confinement parameters to coax the boids into staying within the confinement volume as opposed to bluntly preventing them leaving the defined area. Of course, when a boid ricochets of the imaginary wall this repositioning should have a knock on effect through its neighbours and in turn their neighbours and so forth, well that was my thinking.

So 3D vector math was the first thing on the new to do list, I made a new math class to allow all the calculations to be done by a boid type, I decided to simply store all generated boids in a TList, which then could be looped through to adjust the vectors of each one. These I called my Non-corporeal boids, simple mathematical ghosts, without shape or form. Using an Entity array the physical form was generated as a copy of a mesh, in this case a cube. Thus in the draw cycle the Non-corporeal boids have their respective vectors updated based on the stipulated rules and a corresponding pre created body is then assigned to its co-ordinates.

 
Currently this is just an exercise I am using to find out more about this field of AI. It has practical game applications, one could be "wildlife" volumes, like birds in the sky over a scene. But as with all things the first part is to find out how and why it "ticks" and to try and get it working.

This is a slow motion video capture of how the rules effect the behaviour:




Demo Application Can Be Found Here

References:
http://www.red3d.com/cwr/boids/
http://www.kfish.org/boids/

Read More

UDK Custom Weapon Tutorial.

Ok, the boys over at Magic Stone Studios have just released a UDK Custom Weapon Tutorial.




The tutorial series covers modeling a weapon, rigging, animating, and ends with showing you how to program your custom weapon.

The tutorial series is highly detailed with around fifteen hours of video.

I have run through this myself and it is excellent, so a big hats off to them. The tutorial is free and includes art source files and UDK packages, but for only a small donation, which I took advantage of and recommend, you get the High Resolution Skeletal Meshes, High Resolution Textures/Particles, Sound Effects, Asset Source Files and Source Code.

So many thanks for that guys and wishing you all the best and future success with your current project R.A.T.S.

Read More

Revamping A Modular Asset Idea.

I have dabbled with modular construction for 3D scenes, my last efforts where for a sci-fi based corridor which was essentially to test out some texturing methods with heavy use of bump mapping.




From Blog Entry Scale to the Chief
From Blog Entry Bumping ..... Adventures in Textures

Now, I have recently built a new Development PC so most of my development code and "stuff" is on storage drives that I am currently going through. Whilst doing this I came across some of my very first modelling and texture tests.

From Blog Entry Textures

 Kind of makes me shudder although I don't think I have improved that much with time, but it got me thinking about assets I will need and the different workflows I could use. The original "Jetty" was a place holder model created in 3DWS to try out some textures I had made from photographs. It was also my very first attempt at a modular asset, which did not go so well in the area of "snap to gridability". So using this original concept for an asset, I decided that the place to start would be with a base model, which would be kept as simple as possible in regard to geometry and from which the higher and lower level of detail models would be derived. Also, I decided that the individual sections of the model should also inherit this modular aspect.

I started by modelling a basic revamp of the original jetty design.

Then I added more detail, but still keeping the poly count low and the geometry simple.

I managed to get good grid snapping with some careful modelling constraints on the overall volume of the piece and careful placement of the centre of origin.

Now what I can do in Silo is to save segments/objects out, such as posts, planks and roof types, to use as custom primitives and from there simply "blockout" ideas for different things:

So for a few hours work I think I have a fairly good work flow going to at least assemble a modular Bridge/Docks/Jetty "construction kit".

Read More

UDK - Water with Flow Map

This is a rather impressive technique to control the direction and movement of water in UDK via shaders. This has been done by Phill Johnson, who also kindly wrote a tutorial about how to implement this in UDK, along with a downloadable example map. It uses a 2d vector field and vertex colouring.

Respect to Phill Johnson and I look forward to more UDK "watery works" from him.

Read More

Quick 3rd Person View Character Test.

 

Ok, its been a while since the last post, took me a while to regain access to my blog after Blogger was taken over, seems Google had some issues in the "not so smooth change over". Anyhow happy new year.

This was a quick test of a character I purchased from a relatively new 3D asset company, 3dFoin, currently they are having a new year 40% off sale so I though I'd check out one of their character models. I have recently built a new PC so most of my development code and "stuff" is on storage drives that I still need to go through, so I quickly coded a script for "her" and a 3rd person collision cam rig off the top of my head to try "her" out. I made some alterations to the textures and made a few adjustments here and there in UU3D. Overall, I think "she" was worth the money. I may have to try out some more of their wares before the sale is over.



I only set up three of the animation's that come with "her", walk, run and idle. I did not bother with animation blending, or smoothing out the turning when moving from stationary/vanity cam mode, this was just a simple temporary rig. The "level" was just some assets quickly thrown together for effect.

You can find 3dFoin here:

http://3dfoin.com/

The other assets are from several sources that include:

Michael, over at Pure3D:

http://pure3d.de/en/index.php

Steve, at Arteria3D:

http://arteria3d.corecommerce.com/

and the boys over at Dexsoft:

http://www.dexsoft-games.com/

As soon as I locate the 3rd person rig I used here ....



I will test "her" out fully. But on the whole I am very pleased with the purchase and will be keeping an eye on their products in the future.

Read More

Colourful Behaviour.

Currently I am working on the second phase of the MapData generator, which is to scan the map for scene objects and then adjust the walkable/unwalkable data accordingly. The basics are working fine from a simple AABB check per collision type. Although I am only using the x and z returns at the moment, a more "honest" check would also require y0 and y1 with reference to terrain elevation to be taken into account, but for now this will do as I have another system in mind to further "refine" the AABB space check. 

I also integrated a version of my Blitzmax A* system, and have a test "AI Bot" that can path the generated data in the editor and traverse the loaded map. Debugging is currently paramount, especially with regard to the data generated and co-ordinate conversion between the different ways arrays and tables within Blitzmax and lua store data and the co-ordinate system of an .sbx file. On smaller maps I simply drew a small coloured cube at the grid position, and made use of LE's view range to "cull out" an area surrounding the cameras position. A physical pick test which did not rely on any generated data would then tell me if the system was aligned correctly. At the moment I am confident that the formulas I have derived are working fine. 

The issue with this type of debugging is it is only practical on small maps, whilst alignment will (should) remain the same regardless of map size, drawing check cubes for every grid tile is a non starter once the map goes over a certain size, as it eats up the available memory to a point when the application will simply crash whilst generating or indeed with very large maps simply crash on start. The map in the videos is "128 x 128" or more precisely 129 x 129 with an MpT of 2 this equates to 66,049 "tiles" which would require 66,049 check cubes to be created. Whereas a "1024 x 1024" with an MpT of 2 equates to 4,198,401 "tiles" which would require 4,198,401 check cubes to be created and a "4096 x 4096" with an MpT of 2 equates to 67,125,249 "tiles" which would require 67,125,249 check cubes to be created. So my solution was to write a function for both the camera and the AI Bot that would create, on the fly, a set sized area of check cubes around the respective focal points.

So, whilst "playing" around with different ways to save and retrieve the data generated for a map, I tried the Portable Network Graphics (.png) image format, mainly to see a pictorial representation of the walkable and unwalkable areas of a map, but also as another way of storing the data, where the red and green channels act as the 1's and 0's stored in the .dat .txt and .lua files. It then dawned on me that an extra "cost" per walkable tile could be embedded in the green channels value, such as the slope of the tile, the flatter the tile, the easier the route. Writing a small routine to determine the slope of a walkable tile (along the same lines used to determine walkable/unwalkable) the value written to the green channel was adjusted a set amount for a particular slope range. The result can be seen below.

 

I then wrote a small function to read the png's pixel data on the fly and display its ARGB values.

This set me thinking, why just store slope data and walkable and unwalkable logic. Of course, you can change the value of the map data stored as values in .dat .txt and .lua files, for instance, instead of 1 meaning unwalkable, the value 0 could be used with walkable tiles having a value ( 1,2,3,4....) which reflects extra cost. But using the .png format this can be done using only two channels of the single (co-ordinate) pixels returned ARGB value.

But channels A and B are left unused, both of which can contain a value 0-255 (00-ff). So why not use them to reference area specific AI behaviour. One scenario might be, a town crier NPC, areas where that NPC is required to "do his stuff" could be defined by a certain value stored in either the A or B channels of the single (co-ordinate) pixels returned ARGB value, this value would only be recognised by that particular NPC class, so other NPC types would simply ignore it. The AI behaviour routines would be encapsulated into the lua control scripts for that class, simply waiting to be triggered. Of course it maybe required that an "area" should have several AI behavioural aspects associated with it, currently I can think of a way to attach three behavioural aspects to a single grid tile using the colour information from a single pixel, but I have a few other ideas on a way to increase that. Those ideas will have to wait as I am trying not to do what I always do and get side-tracked, but they are on the to do list.


This approach would also fit in well with my ideas about Ambient NPC Populations, where the vast majority of control resides in the hands of the "map".

This is all still very much a WIP, but shows potential.

Read More

A* Pathfinding MapData Generator.

The Alpha of my MapData Generator, this is the first phase where the terrain is interrogated and using pre-defined criteria an external .dat file is created containing the walkable and unwalkable grid information for a loaded map. This information can then be fed into either my Blitzmax/Leadwerks A* solution:

A* Pathfinding Using Blitzmax And Leadwerks Engine

or my Lua/Leadwerks A* Solution:

AI, Waypoints, A* Pathfinding, Lua & Leadwerks.

Of course this is only one way to create the node graph data for A* pathfinding. But for current tests using my Lua A* Library this approach will do just fine. The editor currently has only hard coded settings which in the demo video also checks to see if a grid square is below the waterplane and mark it unwalkable.

Read More

R.A.T.S. – Rodent Army Training Simulator

A friend of mine, Paul Thomas, is a developer on the team behind  R.A.T.S. – Rodent Army Training Simulator. I have been following this closely. I will be placing permanent links to his blog and to the R.A.T.S. website.

In association with, and presented by  Plastic Piranha,  R.A.T.S. was demonstrated at E3 2011 and  reportedly, got fantastic feedback.



I know Paul is hard at work on this, and I wish him and his crew all the best, and look forward to future updates and demos. You can check out the on going development on the R.A.T.S. website or over at 3D Masons. Heres little of the work so far.

Read More

CryENGINE3 Free SDK hits 100,000 downloads

Cryteks CryENGINE®3 Free SDK, has hit 100,000 downloads in only five days of its release on August 17th. That is a massive achievment.CryENGINE®3 Free SDK is free of charge for non-commercial use, but they are offering a royalty-only license model to developers who are interested in using the SDK for commercial projects from which Crytek requires only 20% of the developer’s revenues generated from the commercial launch of their game.

The free SDK can be downloaded from here

Epic Games, announced the Unreal Development Kit (UDK) exceeded 50,000 users worldwide a week after its launch on Nov. 5 2009. In May 24 2011 Unity annouced that its registered user base had doubled to more than 500,000 users in just over 6 months with 150,000 of those users being active monthly users. Unity Indie was renamed and released for free in October 2009.

Read More

CryENGINE 3 Free SDK Released.

"Anyone can now download a full version of the best All-In-One Game Development Engine, for free and use it without charge for non-commercial game development. You can try out the fastest toolset for creating game worlds and use the power of CryENGINE 3 in your own games."

More to come about this, I am just too busy downloading!

CryENGINE 3 Free SDK

Read More

AI, Waypoints, A* Pathfinding, Lua & Leadwerks.

Over the last few days I have been getting into Lua script. A few days ago, I bounced an idea off of Macklebee about path nodes and waypoints, and things kind of took off in all directions. A special thanks to Macklebee for authoring the random visible node selection routine and other scripts and Lua snippets in this joint venture. Between us over the last few days we now have a small arsenal of different waypoints, path nodes and pathing techniques including a Lua scripted A* solution, which can use pre-calculated map data or be dynamic. Mack is currently working on another interesting idea along this route, and I have more functionality to code for some other ideas I have in this venture, from NPC behavioural information exchanges to waypoint 3D A* pathing, amongst other tweaks and new AI functionality.

Anyway, here is a short video of just some of the things we have put together entirely in Lua over the last few days. The video was shot inside the Leadwerks Engine Editor with the Lua scripts running in real-time.

Previous entries for AI and A* Pathfinding:

Oh how I hate AppTime() and the randomness of it all.

Attack of the Killer pathfinding butterflies!

A* Pathfinding Using Blitzmax And Leadwerks Engine

The Way Forward ... Making Blitzmax Trax ...

On The Right Path, A* Pathfinding In Leadwerks.

Don't you just hate it when that happens?

OOP I did it again ...

Read More

UDK APEX Destructible asset test

Just a quick and simple test of the workflow. I created a "metal crate" in Silo 3D, textured it in Ultimate Unwrap 3D and then imported it into APEX 1.0 PhysX Lab, where it was "sliced and diced" and exported as an APEX Destructible asset, this was then imported into UDK and placed in a default scene. Took about 5 minutes start to finish.

Read More

TGC Launch AGK (App Game Kit)

  

Well, this product has been in the offing for a while now, but as of today it is officially released. I pre ordered my copy a week or so ago. It did how ever take nearly an hour to get a download slot to retrieve my prize, I guess the bandwidth was taking a hammering over at TGC. I only have had a short time to play with this and go through the examples but it looks fun and relatively easy. The Tier 1 basic is pretty close to Dark Basic Pro which I used to use, and the rest of the syntax is not that dissimilar to Blitzmax or Lua. Tier 2 for this game engine is C++, or what they call native.

"The App Game Kit solves many problems caused by mobile device fragmentation. With it you can code your game once and then deploy your game to multiple platforms. Different resolutions and input systems are all handled by AGK."

App Game Kit

Current support at the time of release is for Windows, iOS, MacOS, Samsung Bada and MeeGo with support coming post release for Symbian, Android, Windows Mobile 7 and Blackberry.

I will blog about it more later when I have had a chance to "play".

Read More

3rd Person Movement & Animation Control Rig Test

This is a video showing a simple test of a 3rd person view Movement & Animation control rig. Features include camera collision, movement to animation synchronisation and skeletal bone spatial position reference routines as demonstrated here with the throwing of grenades. Written in Blitzmax and using the Leadwerks Engine this is the simple base code off of which a more robust solution will be created. The test also utilises a Blitzmax module that I created to take the game mechanic aspects from Furious Frank and have them readily available for other projects, in this case the explosion system and particle FX were used. The grenade object/model Lua script is a hybrid of two scripts written by Macklebee for a grenade launcher and ammo, which is used in Furious Frank.

Character model is by Arteria 3D





Also in HD

Read More