Ambient NPC Population

Ambient NPC Population, a continuation of an idea ...

CryENGINE 3 SDK

A Free CryENGINE SDK for everyone in August 2011? ...

Adventures In Textures

Seeing just how low you can go with the poly count by offsetting a lack of geometry with normal mapping and hand painted textures ...

UDK - Hawken

Indie development at its best ...

Unreal Engine 3 - Environments Features Overview

Gorgeous tech demo trailer showcasing the features of Unreal Engine 3 and its free counterpart, the Unreal Development Kit ...

Monday 29 August 2011

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.

Tuesday 23 August 2011

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.



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.










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.




Wednesday 17 August 2011

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!


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 ...

Tuesday 16 August 2011

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.



Monday 15 August 2011

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."

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".








Wednesday 27 July 2011

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

Metro : Last Light

Another release I am personally looking forward to. Metro : Last Light  is the sequel to Metro 2033.

Here Huw Beynon from THQ takes us through what to expect for the upcoming game:



"Much as changed since the darkones were scorched from the Earth. The air is not yet pure enough to breath, but sometimes we glimpse the sun for a bit of blue sky and the ice has begun to melt, but sadly we ourselves have not changed. War still rages throughout the Metro and we face a new threat from secrets long buried by our fathers. The prison held at station is our only hope. He is the key to ending this madness. We have to find him Artyom."

Friday 22 July 2011

A Free CryENGINE SDK .. August 2011?

Well, if the hype and rumours are true then in the next few weeks we could be playing around with CryENGINE 3 in all its "full access" glory.

I have blogged about this before, but information has always been scant to say the least.

Crytek planning to release UDK-like version of CryEngine 3

I had completely forgotten about it, but came across An open letter to the Crytek Modding Community:

"In August 2011 we will be launching a free CryENGINE SDK. If you want to use it for fun, like all our previous MOD SDKs it will be completely free of charge, to anyone who wants to play with it! You just register, download the SDK with a personalized license key and you're good to go!"

The letter is from Cevat Yerli the CEO & President of Crytek, and when I say "full access" that seems to be exactly what he is saying:

"This will be a complete version of our engine, including C++ code access, our content exporters (including our LiveCreate real-time pipeline), shader code, game sample code from Crysis 2, script samples, new improved Flowgraph and a whole host of great asset examples, which will allow teams to build complete games from scratch for PC."

So all in all, definately worth the "price" of admission, but it seems it will only be free for non commercial usage, but hints at "rates" or "help" for those wishing to use it to develop commercial ventures:

"If you want to use it to make a game to launch commercially, we'd like to help you with that. If you want to take your product down a traditional commercial route, we will offer an innovative low cost licensing model if you want to release your game digitally."

How close this will be to say, Epic's pricing for commercial games developed with the UDK, who knows, it maybe on par or very much higher. I can't see it being less, it would be nice if it was, but ...

Sunday 5 June 2011

Ambient NPC Population, a continuation of an idea.

Last September I mused about the concept of what I call Ambient NPC populations, I spent a lot of time researching (read playing) certain games that have what I call an ambient NPC population. This is specifically those NPC's that reside in the background and generally have no real or very limited interaction with the player, but may have some limited interaction with each other or the surroundings.

I felt a new approach would be needed to sort through what was and was not required to achieve a similar environment in LE, I decided first to create the environment and to then set about, at different levels, adding in the ambient NPC population, the thought behind this was it would be easier to visualise what I wanted to see taking place, if it took place ... in place ... not the best description but I hope you will understand what I mean.

So the first step is to create a small village environment and then to start adding in the population.

Test/concept scene (test application screenshot) : The Village of Swanwyck





The important thing with this small test village level will be the roads/paths, as the first tier of the population will basically be simple "walkers".

Even now, I am still formulating the different types required from "walkers" to simple "static actors" and how to implement some of those types to have different interaction levels. I will be utilising several different methods to allow the NPC's to navigate Swanwyck, from a simple "follow node" approach to predefined path data and on the fly A* navigation.

I did have some very good results with A* pathfinding already, which can be read about here:

A* Pathfinding Using Blitzmax And Leadwerks Engine

Hopefully I can find the time to get "Swanwyck" up to a usable standard, and get the first tier of the "walking" population up and running.

Friday 8 April 2011

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

Actually I don't hate AppTime() I just don't like using it in some instances. Its extremely useful and from what I can tell a more accurate mechanism to use than AppSpeed().

Whilst working on Furious Frank, one thing I noticed and it always caught my eye, was what I term “Chorus Line Syndrome” where using the basic AppTime() frame incrementing code for looping animations results in a regimented animation playback for like models/characters. I have ignored this issue thus far as it was not such a big deal in the early stages. However I decided it needed to be sorted, rather than just left as this issue will no doubt crop up again and its always handy when problems do arise again to have a basic template solution. First I took the lua entity script for the bug and removed all dependence on AppTime() completely using AppSpeed() to adjust for running speed variations. This worked fine but still broke down under high stress tests. The only way I can simulate high stress is to run some background applications and Fraps. Of course some breakdown would come about when the stress is heavy. I then switched to using a mechanism that relied on AppTime() as the base, but not in the same way that it was used for the basic AppTime() frame incrementing code for looping animations. There was still some breakdown under heavy load but not as much as the AppSpeed() based script.

Utilising this script with other aspects to add extra randomness to same type character animation playback I made a few tests. The results are in the video below, in the first part the “Red Bugs” are running the original script and the “Blue Bugs” the new one. In the second half of the video I applied the template to some “Fast Horde” zombie AI I had been working on previously:






Some synchronisation still occurs but that's just inevitable given the constraints of the character models used, that is, how many frames per loop are used in a cycle of animation and indeed how many animation types per action there are. Even slightly interrupting the “Chorus Line Syndrome” has much nicer results. I added some small mechanisms to the “Fast Horde” zombie script to continually mix things up over time. But all in all I am much happier with the results than not having addressed it. There is still some translational movement patterns, like the "flying V" the Zombies exhibit in the video now and again, but I already have a solution involving types of same entity types to add a few extra parameters to help limit the occurrence.

As for Furious Frank, I'd like to say a big thank you to Paul Thomas for his contribution to this little side project. Paul kindly integrated into Furious Franks source code one of his older basic cloud and ToD (Time of Day) systems. It will need tweaking for the project but it was most generous. Heres a little look at the current stage of integration:






When more time is permitting I will continue with working toward a release of Furious Frank V0.03

The current version of Furious Frank can be found here:

Furious Frank V0.03

Previous entries for this project:

MAGIA .. Monday

MAGIA .. Monday ... and a little bit.

MAGIA .. Monday .. a little bit .. and beyond

Friday 1 April 2011

MAGIA .. Monday .. a little bit .. and beyond

Furious Frank V0.01 came about from my requirement to have a simple application in which to test code in my code archives from the last year. It What was supposed to be a simple cleaning out the harddrive exercise got a little side-tracked. This version was achieved in about 14 hours on a Monday.

MAGIA .. Monday

MAGIA .. Monday ... and a little bit

Furious Frank V0.02 is the 10 or so hours I have worked on it since. With the prospect of a whole 3 days ahead with nothing to take up my time, I wanted to get Furious Frank V0.02 uploaded and start on Furious Frank V0.03. It has so far taken the best part of 3 hours to wrestle out that which was required for this demo from my oh so tidy development folder.

I have coded the settings to make this still an easy "game", but as its still in development with feedback on the functionality and performance being more important, if you died in a few seconds then there would be nothing to report, except maybe "its too hard ".

When you die you die, so keep that health topped up.

Not had anytime yet to code and develop a spawning system for the Bugs so I kind of just drop them in on the player, so, wear a hat.

Showcase Page & Download Link Here.

Wednesday 30 March 2011

UDK - Hawken

Hawken is a FPS multiplayer mech combat game. The team behind the development is Adhesive Games, a small independent game studio located in Los Angeles.


"When the Adhesive Games team set out to create Hawken, they had almost no experience using Unreal Engine 3. For Khang Le, art director at Adhesive Games, the focus was on finding a robust solution that could deliver the graphically intense vision he had for the game on a tight schedule and with triple-A quality.


Le and his team decided to use UDK for the game because, when it came to Unreal Engine 3, he says, “We were familiar with its reputation as possibly the most licensed game engine in the industry. Being able to begin production using a cutting-edge game engine with no start-up cost offers an important opportunity to indie developers like us.”


Adhesive Games considered other options before choosing UDK, but Le explains that it quickly emerged as the frontrunner."

Hawken UDK - Showcase


Monday 28 March 2011

MAGIA .. Monday ... and a little bit

Just a little update, I have managed only to grab a few hours here and there to spend on this since last Monday, and its now looking like it will not be until thursday when I can get into it like I did last monday. So heres a quick low quality video of how it stands at the moment.

Have a good week all.

I hope to get V0.02 uploaded by the end of the week.




Tuesday 22 March 2011

MAGIA .. Monday

Feeling the need to finally start sorting through my storage HDD's I came across my Blitzmax code library. I needed to test the code snippets and sort through what was worth keeping and what was broken. I found a FPS framework I had been working on but the code got broken with the release of 2.32, so before I binned it I thought I'd have yet another go at getting it at least to run. This was about 6.00 am monday morning, well I did have the whole of the day to myself, quite a rare occurrence. At around 11.00 am it was up and running, took an hour to locate all the assets it utilised lol. Still full of bugs and problems, I thought what the ... Heck .. and sat down with a gallon pot of coffee and tinkered with it ... and tinkered.. and tinkered a little more .. by the afternoon I was down to two issues, both to do with parenting objects in the transparency world. I left this and started looking through other code and slowly began to add different proof of concepts I had worked on over the last year or so...

Don't you just hate it when that happens ...

OOP's I did it again ....

I continued to tweak and tinker and add ..at around 10pm .. I had an Idea how to tackle the original transparency/parenting problem whilst chatting with Paul. At around 11.30pm I realised, the makings of a game had been born ... that game is currently known as:

Furious Frank


Well, its quite an easy "game" at the moment with infinite ammo and infinite life even if the HUD is telling me its running down .. but not a bad days work I felt .. hopefully next monday I can wrangle some more time and tweak it and add to it.

If I get time today, I will upload a demo to the showcase under the title, MAGIA Monday (as I Dont have time to spend a month on it).

Wednesday 16 March 2011

Crytek to release UDK-like version of CryEngine 3

Last April, I blogged about the news that Crytek might be releasing a free version of the CryEngine, much in the same way that Epic did with UDK and the Unreal 3 engine and also Unity licensing the indie version of their engine as free. Well, it seems that this will happen with CryEngine 3.

According to Crytek co-founder Anvi Yerli, "The barriers for entry will be very low, and perhaps [it will be distributed] for free." Details and a release date for this CryEngine 3 Lite SDK have yet to be announced. It seems resonable to speculate that such a release could be similar to what Epic Games did when it released its UDK tools in 2009.

Full Article Here

Sean Tracy also mentions this at the end of an interview recorded at GDC 11.







It is turning out to be an interesting year for indie developers.

Tuesday 8 March 2011

Unreal Engine 3 Samaritan Real-Time Demo

Revealed at the 2011 Game Developers Conference, the real-time demo of "Samaritan" shows what Epic wants to see in the next generation of games.

The features demonstrated in this video are available now in UDK


Thursday 24 February 2011

The Elder Scrolls V: Skyrim - Official Trailer

"We're pleased to share the first ever in-game trailer for The Elder Scrolls V: Skyrim, the next installment in The Elder Scrolls series from award-winning creators of The Elder Scrolls IV: Oblivion and Fallout 3, Bethesda Game Studios. "






You might find you need to log into Youtube to view the trailer for age verification.

It seems Skyrim will be released world-wide on 11.11.11 on the Xbox 360, PlayStation 3 and PC ... so something to look forward to at the end of the year other than the cold weather. If they release another instalment of Fallout at the same time ... then hibernation this coming winter will just not be an option

Thursday 10 February 2011

I'll Take What's Behind Door Number 3

Time is proving to be a most scarce commodity at the moment. So having a few hours spare I set myself some tasks and as usual did something completely different :rolleyes: I started work on a room and ended up on a new 90 degree section, corridor doorway section (with separate reusable door frame / doors and simple placeholder keypad switch box all to need textures), a few WIP scripts for the doors and some hashed together sound FX for them to and a short corridor "Door Plug" section to allow the standard sections to fit the door frame. Part of the plan for this modular approach to the level is that as many sections/parts as possible will be able to "plug" into each other. I also wanted to test out some new base metal textures to try and break up the "monotone" look. The door keypad switch would also require some sort of 3rd person object interaction functionality which was hastily coded and again as with everything else, still very much a WIP.


Simple keypad switch prop:


Development in Silo PRO:



A quick medium resolution video to show the "worksite" test scene. I can't take credit for the blue and yellow textures they are curtesy of Paint.NET's floodfill tool..






Hopefully next week I will be able to free up more than only a few hours to get fully back into this "adventure", but I was not unhappy with the progress I made in only two hours.

Saturday 5 February 2011

Scale to the chief

With the basic texture workflow pretty much sorted for the modular level design (see here), I have turned my attention to getting a scale I am happy with. When this is done then after each section is modelled and then UV mapped it should be just a simple case of converting to .gmf format (famous last words). Scaling seems to be an issue that crops up across all the engines I use. But truthfully it matters not what others scale to, but that the relative scaling used in a scene is consistent for all static and animated meshes from props to scene to characters. LE has a scale of 1 unit is about 1m, I simply use 1 unit as 1m, therefore a character needing to be 6 foot tall would simply be a "metric" 6 foot.. or 1.8 units. This is the rule of thumb I use for all scenes and corresponding code. But sometimes its also good to check how it looks by eye. In a 3rd person situation its not just the scale of the level and the characters but having to remember the camera offset and how this would be effected. I normally do two tests, a simple static scene with characters and props placed to get a simple overall picture of the scaling.


And I like to knock up a quick app with a basic 3rd person collision cam and have a quick walk through (HD available):






So far I am happy with the results which means when time permits I can get on with creating the rest of the sections/rooms ect. I have also checked the scaling to make sure I can easily "block out" the level and run it through my pathfinding mapdata generator app which I had some success with in earlier tests of A* pathfinding (see here).

Monday 31 January 2011

Bumping ..... Adventures in Textures

Firstly, I'd like to take this opportunity to wish you all a belated happy new year. I hope you all have had a great start to it.

I have not been doing much on the coding front for the last few weeks. I decided to get some assets created and try and develop my texturing skills a little further.

I also purchased Silo 3D Pro over the Christmas period as it was on offer. I had used the demo and was impressed at how "comfortable" it was to use. I now use this package as my main modeller but in conjunction with AC3D and UU3D. Basically Ultimate Unwrap 3D is the junction where all my modelling and art packages meet. Not only for Leadwerks with its .gmf export for both static meshes and animated assets but for all the engines I use, for me its an invaluable tool and a good investment for the minimal cost.

I have need of a modular corridor/room set, and decided to set about seeing just how low you can go with the poly count and how much you can offset the inherent "flatness" of a low poly environment with normal mapping and "hand painted" textures. This would be moving on directly from a previous flirtation with texturing which can be found here. Some more incriminating evidence can be seen in the gallery as well, fairly obvious I am no artist.

Another aspect of texturing I have been playing with is bump mapping. I use ShaderMap Pro which is great but making bumpmaps from diffuse textures can have horrible "side effects" when creating panelling.

Diffuse only:


Diffuse and Normal map created directly from the Diffuse texture by ShaderMap Pro:


Not really the effect I was after. After a few ideas and some testing I found hand crafting a Normal map "template" from which a Normal map would be generated by ShaderMap Pro gave much better results for this exercise.


I then made the first test section of the low poly modular level pack:


The textures were then UV mapped onto the section in UU3D and then converted all over to .gmf .dds and created the .mat files using ADN ... I love ADN truly one of the most useful tools written by a community member ever!!


I Lined a few of them up just for show .. 480 polys not bad .. considering the default rusty oildrum is 256.


Encouraged by the result thus far I moved on, making the section bigger but retaining the tilable nature of the textures




Unfortunately real life commitments caused a pause in my endeavours until a day ago so I have spent the last few hours refining some aspects and making a few more test sections:




The overall effect of the technique I am developing can be seen better in this video (HD available):




This is currently the point I am at, With some preliminary drafts for doors/doorways rooms and elevators/elevator shafts ect. I am trying to reach a point where variation is only a texture change away on standard section low poly models. I am still getting my templates organised and fine tuning the work flow and still very much a WIP, but so far I am quite pleased with the results.

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites